ビジネスの拡大に応じて専用 AI 推論とサーバーレス AI 推論のどちらを選択するか

ほとんどの場合、開発者は適切な AI インフラストラクチャを選択するという課題に直面しており、主な会話は、AI システムを構築するための正しい選択は何かという単純な質問を中心に展開します。 柔軟性のためサーバーレス、制御専用 、利便性とパフォーマンス。

実際には、推論インフラストラクチャは一度「正しく選択」できるものではありません。これは、製品、トラフィック、期待が進化するにつれて、時間の経過とともにひっそりと間違っていくものです。

AI を活用した会議アシスタントの例を考えてみましょう。初期のバージョンでは、1 日に数件の会議を処理し、一度に 1 つずつ文字に起こして要約します。使用は不定期であり、機能を動作させることだけが優先されます。ここではサーバーレス推論が自然に適合します。

製品が注目を集めるにつれて、それは日常のワークフローの一部になります。チームは一日中会議を処理するためにこれに依存しており、所要時間に対する期待が厳しくなり始めています。全体的なパフォーマンスが許容範囲内であっても、時折レイテンシが急上昇することが問題になり始めます。

最終的に、システムは、予測可能な毎日のパターンで大量の会議を処理できるようになります。この段階では、要件は一貫性とコスト効率に移行します。専用の推論が論理的基盤となるのは、以前のアプローチが間違っていたからではなく、システムがそれを超えてしまったからです。

興味深いことに、サーバーレスは消滅しません。多くの場合、予期しないスパイクの処理、実験的な機能の実行、または低頻度のタスクのサポートなど、エッジ ケースに引き続き役立ちます。当然のことながら、固定計画ではなくシステムが必要とするものに基づいて、両方のアプローチを組み合わせたものになります。

この記事では、システムが成長するにつれてサーバーレス推論と専用推論の間の選択がどのように進化するかを理解しようとします。また、サーバーレス推論がいつ機能しなくなるのか、ワークロード パターンがどのように正しい選択を形作るのか、システムが拡大するにつれて専用インフラストラクチャへの移行が避けられなくなる理由を理解するための例として、Modal や Together.ai などの非常に人気のある 2 つのプラットフォームについても検討します。

初期段階

AI プロダクトを構築する最初の数日間、最大の制約はパフォーマンス、特にレイテンシーの一貫性 (各リクエストの応答速度) やスループット (一度に処理されるリクエストの数) ではなく、いかに迅速に出荷し、反復し、実際の使用状況から学習できるかです。

初期の段階では、ワークロードはまだ理解されておらず、トラフィックは一貫性がなく、モデルは変化しており、製品自体はまだ形成中です。このような場合、サーバーレス プラットフォームは開発者のニーズにほぼ完璧であると感じられます。

そうしないと作業が遅くなる可能性がある決定を取り除きます。 GPU プロビジョニング、スケーリング ポリシー、容量計画について考える必要はありません。コードを作成してデプロイすると、システムはどのような需要が現れてもそれに適応します。プロトタイプのチャットボット、ドキュメントサマライザー、社内 AI ツールなどの初期段階のアプリケーションの場合、これは便利なだけではありません。それは、発送するか発送しないかの違いです。

この段階では、使用自体が不確実であるため、非効率は問題になりません。インフラストラクチャの効率ではなく、反復速度を最適化しているのです。

最初の変化:遅延が製品の問題になる

インフラストラクチャの選択がずれ始めているという最初の兆候が、請求ダッシュボードに現れることはほとんどありません。それはユーザーエクスペリエンスに現れます。使用量がたとえわずかであっても増加すると、レイテンシは理論上の指標ではなくなり、目に見えるようになります。

サーバーレス システムは弾力性を中心に構築されており、多くの場合、変動性が伴います。環境がすでに暖かい場合はリクエストが即座に返される可能性がありますが、コールド スタートまたはモデルのロードがトリガーされる場合は大幅に時間がかかる場合があります。単独では、これは許容されます。しかし、ユーザー向けシステムでは、不一致は平均的なパフォーマンスよりもはるかに目立ちます。

カスタマー サポート ワークフローに埋め込まれた AI アシスタント、または IDE 内のコード生成機能を考えてみましょう。どちらの場合も、ユーザーは応答性が即時​​的で予測可能であると感じられることを期待します。いくつかの遅い応答は、知覚において平均的ではありませんが、目立ちます。かつてインフラストラクチャの詳細だったものが、製品の欠陥になります。

第 2 のシフト:コストがかさみ始めるとき

システムが成長するにつれて、使用はより定期的に行われます。以前は時折リクエストされていたものが安定したトラフィックに変わり、かつては実験だった機能が日常的に使用されるようになりました。この時点で、サーバーレスの料金が違うように感じられ始めます。

サーバーレスは、何かが実行された場合にのみ料金が発生するため、使用量が予測できない場合に適しています。しかし、システムが常にアクティブになって、継続的なリクエストを処理したり、バックグラウンド ジョブを実行したりすると、同じ作業に対して何度も料金を支払うことになります。時間が経つにつれて、その利便性は高価になり始めます。

この時点で、固定 GPU でモデルを実行する専用インフラストラクチャがより意味を持ち始めます。リソースを効率的に使用する限り、パフォーマンスをより安定させるためには、コストをより細かく制御する必要があります。

ここでは何も問題は起こっていません。これは、システムが成長し、以前のセットアップが最もコスト効率の高い選択肢ではなくなったことを意味します。

プラットフォームの選択ではなく、ワークロードの形状が結果を左右します

時間が経つにつれて明らかになるのは、決定は実際には 2 種類のプラットフォームのどちらかを選択することではないということです。重要なのは、ワークロードがどのように動作するか、そしてその動作がどのように変化するかを理解することです。

多くのチームが犯す間違いは、現在のワークロードの形状が永続的であると想定していることです。実際には、ほとんどのシステムは複数の状態を経由します。アプリケーションは、使用量が非常に急増することから始まり、ほぼ予測可能な毎日のサイクルに移行し、最終的には安定した高スループットのパターンに落ち着く可能性があります。これらの各段階では、異なるアプローチが推奨されます。

中盤

最も困難な段階は、始まりでも終わりでもなく、それらの間の移行です。これは、たとえ何も壊れていないとしても、システムが「調子が悪い」と感じることがよくある場所です。遅延の問題は時折発生しますが、一貫して発生するわけではなく、コストが上昇し始めますが、完全なアーキテクチャの変更を正当化するほどではありません。開発者は、応答のキャッシュ、環境の事前ウォーミング、事態をスムーズにするための同時実行性の調整などの回避策を追加し始めます。これらの変更は一時的に役立ちますが、システムが当初の設計を超えて推進されているというシグナルでもあります。

再び、成長を続ける AI カスタマー サポート アシスタントの例を見てみましょう。初期段階では、少数のクエリを処理できますが、採用が増えるにつれて、システムはピーク時に数百のリクエストを処理し始めます。ほとんどの応答は依然として高速ですが、コールド スタートやスケーリングの遅延により、著しく時間がかかるものもあります。チームは、繰り返されるクエリに対してキャッシュを追加し、レイテンシのスパイクを減らすためにプレウォーミングを試みます。同時に、システムがより安定して稼働するようになるため、月々のコストも増加します。ただし、専用 GPU への移行を完全に正当化できるほどトラフィックはまだ安定しておらず、営業時間外にはアイドル状態になる可能性があります。これにより、システムは技術的には機能するものの、継続的な調整が必要となり、サーバーレス インフラストラクチャも専用インフラストラクチャも完璧に適合するとは思えない、もどかしい中間点が生まれます。

大規模

ある時点で、システムは予測不能でなくなります。受信するリクエストのおおよその数がわかり、混雑する時間帯がいつになるかもわかります。推測はなくなりました。
これからは、実行が決して停止しないシステム上で、リクエストごとに料金を支払うことになります。以前は時々あったコールドスタートは、今では受け入れられないと感じています。ユーザーは高速で一貫した応答を期待するようになり、差異があれば注目されます。最初は迅速な動作をサポートしていたインフラストラクチャが、今では速度を低下させる原因になっています。専用の推論がこれをきれいに解決します。 GPU を予約すると、モデルはロードされたままになり、すべてのリクエストで同じエクスペリエンスが得られます。共有もスピンアップの遅延も、驚くようなこともありません。
経済学も変化します。システムが常にアクティブな場合、予約されたコンピューティングに対する支払いは、使用ごとに支払うよりも安くなります。たとえば、Togetter.ai の専用エンドポイントは、H100 で 1 時間あたり約 3.99 ドルから始まります。トラフィックが安定している場合、多くの場合、サーバーレスに費やしていた費用よりも安くなり、その上でパフォーマンスが向上します。得られるのは、コストの削減や応答の高速化だけではありません。それは安定性です。インフラストラクチャの調整をやめて、インフラストラクチャを信頼し始めます。そうすることで、その下にあるレイヤーの管理ではなく、製品の構築に完全に集中できるようになります。サーバーレスが完全になくなるわけではありません。予期せぬスパイク、実験的な機能、低頻度のジョブなどのエッジケースにも引き続き対応します。しかし、それはもはやコアのワークロードを担っていません。専用インフラストラクチャがそれを実現します。

開発者がサーバーレス推論プラットフォームを実際に体験する方法

これらのシステムがどのように動作するかを理解する良い方法は、開発者が一般的に使用される 2 つのプラットフォーム、Modal と Together.ai とどのように対話するかを調べることです。どちらもインフラストラクチャを抽象化するという同様のアイデアから始まりますが、その抽象化が実際にどのように現れるか (特に価格設定とスケーリング) によって、どこでうまく機能し、どこでトレードオフが始まるかが明らかになります。

モーダル

Modal は、コンピューティング時間に対して厳密に料金を支払うサーバーレス モデルを中心に設計されています。たとえば、GPU 使用量は秒単位で請求され、小型 GPU (L4 など) の場合は約 0.0002 ドル/秒、H100 などのハイエンド GPU の場合は最大約 0.0011 ドル/秒で、ハードウェアに応じて 1 時間あたり約 0.8 ～ 4 ドルに相当します。月額約 30 ドルのクレジットが含まれる無料枠もあり、前払い費用なしで簡単に始めることができます。実際には、これは、ユーザーがトリガーした場合にのみトラフィックを取得する画像生成 API や、1 日に数回実行されるバックグラウンド ジョブなど、バースト性の高いワークロードに対して非常にうまく機能します。アイドル状態の GPU に対して料金を支払う必要はなく、スケーリングは自動的に行われます。しかし、使用が継続的になると、たとえば、画像を 1 日を通して継続的に処理するリアルタイムの物体検出モデルを実行すると、価格モデルのトレードオフが明らかになり始めます。システムは常に使用されているため、「使用したときのみ支払う」というメリットはもうありません。代わりに、事実上、同じ GPU を少しずつ繰り返しレンタルすることになり、多くの場合、単に 1 つを稼働し続けるよりも累積コストが高くなります。同時に、コールド スタートやコンテナの再利用などのパフォーマンス特性により変動が生じ、実稼働環境では無視することが難しくなります。

Together.ai

Together.ai はサーバーレス API から始まりますが、成長するシステムにとって興味深いのは、ニーズの変化に応じてプラットフォームを切り替える必要がないことです。コードの方法を変更することなく、基本的な API の使用法から専用の GPU エンドポイントに移行できます。

エントリーレベルでは、トークンごとに支払います。価格はモデルによって異なり、100 万トークンあたりおよそ 0.10 ドルから 3 ドルですが、交通量が少ない場合や予測できない場合に適しています。自動スケーリングが利用できるため、インフラストラクチャを管理する必要はありません。これは、ほとんどのユースケースにとって適切な開始点です。

トラフィックが増加し、遅延が問題になり始めた場合、Togetter.ai を使用すると専用のエンドポイントに移行できます。ハードウェアを選択すると、H100 は 1 時間あたり約 3.99 ドル、H200 は 1 時間あたり約 5.49 ドルになります。その GPU はあなたのものになります。共有コンピューティングがなく、他のワークロードからの干渉もありません。モデルはロードされたままになり、レイテンシ プロファイルが一貫したものになります。

トレードオフは、他の専用セットアップで直面するものと同じです。営業時間外にトラフィックが減少しても、その GPU はまだ動作しています。使用するかどうかに関係なく、容量に対して料金を支払うことになります。ワークロードが安定している場合は問題ありません。

規模を拡大しているチームにとって、Togetter.ai の実際的な利点は、移行パスが社内にあることです。専用のパフォーマンスを得るために統合を再構築する必要はありません。エンドポイント構成を変更します。これにより、切り替えが混乱しすぎると感じてシフトを遅らせるのではなく、適切なタイミングでシフトを行うための本当の障壁が 1 つ取り除かれます。

たとえば、中規模のモデルを実行すると、100 万の入力トークンあたり約 0.10 ～ 0.60 ドルの費用がかかる可能性があり、モデルによっては出力トークンが高くなる場合があります。これにより、チャットボットやテキスト生成 API など、使用量に応じてコストが増加するユースケースでも直感的に操作できるようになります。たとえば、1 日に数百万のトークンを生成するカスタマー サポート ボットの場合、量に応じて月に数十ドルから数百ドルの費用がかかる可能性があります。同時に、Togetter.ai は、ワークロードが安定した場合、H100 で 1 時間あたり約 3.99 ドルから専用の GPU エンドポイントを提供します。これは一般的なパターンを反映しています。開発者は単純な API ベースの使用から始めますが、トラフィックが安定し、レイテンシの予想が増加するにつれて、より予測可能なパフォーマンスとコストを求めて専用のセットアップに移行することがよくあります。

重要な変化はプラットフォームではなく、 それを長期的にどのように使用するかです。 :

• 初期段階 → 単純な API のように使用します
• 成長段階 → レイテンシとコストについて心配し始める
• スケール →同じプラットフォーム内の専用エンドポイントに移行します。

そのため、純粋なサーバーレス プラットフォームとは異なり、必ずしもプロバイダーを切り替える必要はなく、モードを変更します。 .

決定する前に考慮すべき点

• コストのスケールが予想とは異なる場合: サーバーレス プラットフォームでは、コンピューティングの 1 秒ごとに固定のオンデマンド料金が課金されます。システムがアイドル状態のとき、そのモデルは効率的です。システムが継続的に稼働している場合、その同じレートが 24 時間体制で軽減されることなく稼働します。予約容量をサポートするインフラストラクチャは、時間当たりの実効コストを大幅に、場合によっては半分以下に削減できます。ワークロードが予測可能な期間が長くなるほど、その差はさらに大きくなります。
• 管理されたデフォルトは時間の経過とともに制約になります :マネージド推論プラットフォームは、ユーザーに代わって構成の決定を行うことがあります。どの最適化が実行されるか、メモリがどのように処理されるか、リクエストがどのようにバッチ処理されるか。初期段階では、これらのデフォルトを使用すると時間を節約できます。後で、特定のワークロードに合わせて推論レイヤーを調整する必要がある場合、同じデフォルトが邪魔になります。構成にアクセスできない場合、構成を変更することはできません。インフラストラクチャを所有するということは、それらの設定が自分のものになることを意味します。
• あなたの可視性はプラットフォームがあなたに示すものに限定されます :マネージド プラットフォームでは、何か問題が発生したり、コストが予期せず高騰したりした場合、調査できる機能はプラットフォームが構築したダッシュボードに限定されます。何かが遅い、または高価であることはわかりますが、インフラストラクチャ層がアクセスできない場合、その理由を正確に追跡するのは困難です。専用インフラストラクチャにより、コンピューティング、ネットワーキング、ストレージ全体にわたる完全な可観測性が実現します。すべてが見えており、それに基づいて行動することができます。
• コントロールが強化されると、責任も強化されます: インフラストラクチャを所有すると、コストが削減され、より詳細な制御が可能になり、完全な可視性が得られます。ただし、これは、マネージド プラットフォームが処理するセットアップと運用作業を自分で引き受けることも意味します。特にチームが小規模である場合やワークロードがまだ変化している場合には、これが常に正しい判断であるとは限りません。とはいえ、適切なプラットフォームは常に適切なバランスを取り、マネージド プラットフォームとセルフマネージド プラットフォーム間のギャップを縮めます。一部のインフラストラクチャ プラットフォームには、事前構成された推論イメージ、ワンクリックの GPU 導入、すぐに使える Kubernetes サポートが付属しています。これは、ゼロから始めるわけではないことを意味します。運用上のオーバーヘッドは実際にありますが、以前よりもはるかに軽くなります。

結論

サーバーレス推論により、スムーズに開始、実験、出荷を行うことができます。しかし、システムが成長するにつれて、かつては高速化に貢献していた抽象化そのものが、レイテンシーの一貫性、スループット、コスト効率といった最も重要なものを隠し始めてしまうことがあります。Modal や Together.ai などのプラットフォームを使用すると、早期の構築と拡張が容易になり、多くの場合、後になってもアーキテクチャの一部として残ります。しかし、ワークロードが予測可能になり、期待が厳しくなるにつれ、さらなる制御の必要性が避けられなくなります。現実世界のシステムは静的なものではありません。不確実性から予測可能性へ、実験から生産へ。そして、そうするにつれて、「正しい」インフラストラクチャの選択も変化していきます。チームが犯す本当の間違いは、サーバーレスを実際のフェーズではなく、長期的なデフォルトとして扱うことです。ワークロードが安定してから専用インフラストラクチャへの移行が遅れるほど、コストかパフォーマンス、あるいはその両方でより多くの費用を支払うことになります。

この作品は、クリエイティブ コモンズ 表示 - 非営利 - 継承 4.0 国際ライセンスに基づいてライセンスされています。