스크립트
00:00:00皆さん、おはようございます。AI Engineering World Fair最終日、最初のInfluence Talkへようこそ。
00:00:17Nishan Guptaと申します。本日は共同スピーカーのNaman Ahujaと共に登壇いたします。
00:00:23私たちはMetaで、効率化、学習、推論インフラの構築を担当しています。
00:00:27本日は、大規模な分散推論システムをどのように運用するかについてお話しします。
00:00:32ご承知の通り、推論はもはやプロダクトに組み込まれた単なる研究成果ではありません。
00:00:37凄まじい勢いで成長している、ハイパースケールインフラの基幹ワークロードとなっています。
00:00:43推論トラフィックはすでに世界最大級のマイクロサービスをも凌駕しており、
00:00:47その成長速度は過去に見られたどのワークロードよりも高速です。
00:00:542008年頃まで少し時間を巻き戻し、AI時代とクラウド時代を比較してみましょう。
00:01:002008年頃、クラウドは仮想マシンの提供から始まりました。
00:01:05当時の興味深い技術は仮想化でした。
00:01:07その後、価値はスタックの上層、つまりBorg、Kubernetes、Mesosといったスケジューラへ移行しました。
00:01:14さらにサービスメッシュ、オートスケーラー、その上に構築された各種プラットフォームへと広がっていきました。
00:01:18実際に価値と複雑さを捕らえたのはオーケストレーション層だったのです。
00:01:24AIも全く同じ軌道を辿っていますが、10年ではなくここ数年に凝縮されています。
00:01:30最初はGPU上で動作するシンプルなモデルから始まりました。
00:01:33そしてvLLM、TorchServe、Tritonといったモデルサービングフレームワークの進化を経て、現在我々はルーティング、KVキャッシュ管理、Prefill/Decode分離、マルチモデルのマルチプレクシングといった複雑な課題に対処するオーケストレーション層がリアルタイムで台頭するのを目の当たりにしています。
00:01:51AI時代の次のフェーズにおいて重要なのは、優れたモデルやカーネル、最適化だけではありません。
00:01:57エコシステム全体が重要になります。
00:01:58コントロールプレーンとオーケストレーションこそが肝であり、今回のトークで重点的に扱うテーマです。
00:02:06では、エージェント型需要の爆発的増加について少しお話ししましょう。
00:02:09AI推論ワークロードが始まる前の従来のWebサービングでは、ワークロードの種類に応じて容量はユーザー数におよそ比例してスケールしていました。
00:02:17ユーザーが2倍になれば、最適化がなければQPSもおよそ2倍、インフラフリートも2倍になり、キャパシティプランニングは主にスプレッドシート上の作業でした。
00:02:28新しいエージェント型サービングでは、キャパシティは「ユーザー数 × ユーザーあたりの呼び出し回数 × トークン数」に比例し、これはモデル、最適化、保有するハードウェアSKUによって変動します。
00:02:40チャットボットは1ターンに1回のモデル呼び出しですが、Copilotでは10〜20回、リサーチエージェントでは50回と進化しており、人間が介入しない自律型ワークロードでは数千回にも及びます。
00:02:54重要なポイントは、マイクロサービスと同じ方法でエージェントのキャパシティ計画は立てられないということです。
00:03:00弾力性（エラスティシティ）を考慮し、ワークロードを認識したスケジューリングとアドミッション制御を実装する必要があります。
00:03:08では、従来のマイクロサービスサービングと現代の推論サービングの違い、メリット・デメリットについて、主要な観点から深く掘り下げてみましょう。
00:03:19リクエストの形状について。
00:03:20マイクロサービスは短く均一なリクエストを前提としますが、我々のワークロードで見られるLLMリクエストは50トークンから100,000トークンまで様々で、PrefillとDecode段階で計算特性が大きく異なります。
00:03:33バッチ処理について、従来のマイクロサービススタックでは、バッチ化を行うとしても主にロードバランサー層で行われていました。
00:03:40しかし、LLMサービングには継続的なインフライトバッチ処理が必要であり、そうでなければスループットが桁違いに低下します。
00:03:48ステート（状態）について。
00:03:49ストレージ層を除けば、従来のマイクロサービスのほとんどはステートレスでした。
00:03:54しかし、LLMサービングではリクエストごとにKV Cacheという膨大なステートが必要となり、その構築コストは非常に高く、破棄コストはさらに高くなります。
00:04:02スケーリングの単位について。
00:04:03スケーリングの単位について。
00:04:05従来のマイクロサービスであれば、安価なCPU上のPodで実行することができました。
00:04:11しかし、現代の推論では100倍高価で調達に10倍の時間がかかるGPUでの実行が必要であり、安易に過剰調達することはできません。
00:04:20さもなければ、大きな無駄につながってしまいます。
00:04:23障害モードについて。
00:04:25私たちが過去数年間構築してきたような従来のマイクロサービスでは、ホストやPodがクラッシュしても再起動することができました。
00:04:34必要に応じてステートを再構築することも可能でした。
00:04:36しかしモデルの推論では、コールドスタートからウォーム状態にするまでに非常に長い時間がかかります。
00:04:42また、GPUがDecode処理の途中でクラッシュすると、処理中の数千のトークンが失われ、キューの滞留を引き起こします。
00:04:50結論として、ボトルネックはモデルだけではありません。
00:04:53オーケストレーションそのものがボトルネックなのです。
00:04:58プロンプトの裏に隠された決定事項に見られるように、エージェントアプリケーションを実行する際、水面下では多くのステップが必要です。
00:05:06認証を行う必要があります。
00:05:07リクエストの種類に応じてモデルを選択する必要があります。
00:05:09送信先のリージョンを選択する必要があります。
00:05:11アドミッション制御を行う必要があります。
00:05:12キャッシュの参照を行う必要があります。
00:05:14GPU上で処理を実行する必要があります。
00:05:17バッチ処理を行う必要があります。
00:05:18その他にも多くのステップが関わっています。
00:05:19お分かりの通り、これらすべてのステップの中でモデルを必要とするのはPrefill/Decodeの1ステップのみです。
00:05:25それが分離型推論であるか、そうでないかにかかわらずです。
00:05:29その他のステップにはインフラが必要です。
00:05:31知性はモデルにあるかもしれませんが、経済性、信頼性、ユーザー体験はすべてインフラに依拠しています。
00:05:38だからこそ、多くの企業のプラットフォームチームが、プロダクトの品質と成功に対して以前よりもはるかに大きな影響を与えているのです。
00:05:50会場の皆さんの多くは、1つから3つの層において深い専門知識をお持ちでしょう。
00:05:54カーネルやカーネルの最適化を担当している方もいれば、
00:05:57ルーティングやプロダクト自体を担当している方もいるでしょう。
00:05:59あるいはGPUインフラやクラスタ自体を運用しているかもしれません。
00:06:03しかし、スタック全体を運用したり、エンドツーエンドで思考したことのある方はごく一部です。
00:06:08ご覧の通り、これらの階層自体は新しいものではありません。
00:06:1120年以上前から存在しています。
00:06:13新しいのは、それらの組み合わせと相互の結合度です。
00:06:18ルーティング層での決定がモデル層でのキャッシュヒット率を変え、それがバッチの構成を変え、GPU利用率を変え、その結果としてオートスケーリングの決定をも変えてしまう可能性があります。
00:06:32つまり、すべてが複雑に絡み合っているのです。
00:06:33推論ワークロードで性能低下が発生した場合、キャッシュ層やアドミッション制御で何が起きたかを知るだけでは不十分です。
00:06:41スタックを上から下まで全体的に考える必要があります。
00:06:43そしてボトルネックを見つけた際、適切な投資を行うためには、どの層にボトルネックがあるかを理解することが非常に重要になります。
00:06:54では、プロンプトの仕組みについて詳しく見ていきましょう。画像生成、リサーチタスク、複雑なマルチエージェントのオーケストレーションなど、あらゆるアプリケーションのプロンプト処理は、概ね以下のようなステップを辿ります。
00:07:08プロンプトはまずゲートウェイに届きます。
00:07:10次にルーターへ送られ、以前に処理されたリクエストであればキャッシュの参照が行われます。
00:07:17続いてスケジューラに送られ、どのGPUクラスタ、どのハードウェアで実行すべきかが決定されます。
00:07:22NVIDIA、AMD、あるいは自社製チップの可能性もあり、その後vLLMやSGLangなどの適切なサービングランタイムへ送られます。
00:07:30そして、最初のトークン生成時間（TTFT）やトークン間間隔のSLOを満たし、要求されたスループットを維持しながら、レスポンスをユーザーにストリーミング返送します。
00:07:41ご覧の通り、この推論処理は分散トランザクションのように振る舞います。
00:07:45図の中の各矢印はネットワークホップを表しています。
00:07:47これらのホップはどれも再試行する可能性があります。
00:07:50タイムアウトすることもあります。
00:07:51フォールバックすることもあります。
00:07:53失敗することさえあります。
00:07:54そして各ホップにはSLOが存在し、ユーザーへデータをストリーミング配信しています。
00:08:00そのため障害が発生した場合、一部失敗時のセマンティクスは通常のRPC呼び出しよりもはるかに扱いづらくなります。
00:08:06すでに200トークンをユーザーにストリーミング返送した時点で、計画的または予期せぬメンテナンスにより
00:08:15GPUホストが突如プリエンプション（中断）された場合を考えてみてください。
00:08:16単にリトライすれば済む話ではありません。
00:08:17全体を考慮して対処する必要があります。
00:08:19だからこそ、信頼性を末端（エッジ）だけで構築することは不可能なのです。
00:08:23ワークフロー全体を把握しているのはコントロールプレーンであるため、信頼性はコントロールプレーンの特性として組み込む必要があります。
00:08:31次に、スケジューラといくつかの最適化手法、その考え方についてお話しします。
00:08:37従来のマイクロサービスでは、3つか4つの次元でビンパッキング（最適配置）を考えていました。
00:08:43CPUやメモリなどのリソース、あるいはAWSや自社クラウドなど利用環境に応じた障害ドメインに基づいていたでしょう。
00:08:52しかし推論においては、リクエストをスケジュールする際、スケジューラは少なくとも7つの軸を認識する必要があります。
00:08:59まず、GPUのタイプを把握しなければなりません。
00:09:00クラスタ内にはH100、E100、B200など、ネットワーク構成が異なる多様なハードウェアが混在している可能性があります。
00:09:09HBMの空き容量やKVキャッシュの状態を認識する必要があります。
00:09:13モデル重みがすでにロードされているか、コールド状態か、ウォームアップ済みか、コールドスタートが必要かを認識する必要があります。
00:09:19テナントの優先順位を認識する必要があります。
00:09:21マルチテナントクラスタ上には、異なるSLO特性を持つ多数のテナントが存在し得ます。
00:09:27また、ワークフローのコンテキストも意識する必要があります。
00:09:30すでにコストを費やした推論プロセスの第3ステップにいるのか、あるいは過剰調達時に中断可能な初期段階にいるのか。
00:09:39構築するエージェントアプリケーションの種類に応じて、レイテンシの許容値も考慮しなければなりません。
00:09:44つまり、エージェントの特性を意識したスケジューリングを確実に実装すべきだという考えに至ります。
00:09:49ランダムなGPUに配置するのではなく、最速かつ最も低コストで完了する場所に確実にタスクを割り当てる必要があります。
00:09:58具体的な例を挙げると、スケジューラはリクエストRが5段階のワークフローのステップ3に位置していること、
00:10:05そしてステップ1と2ですでに一定のコストを消費していることを認識する必要があります。
00:10:09ステップ3が失敗するとワークフロー全体が終了し、それまでの計算リソースが無駄になってしまいます。
00:10:14だからこそ、ワークフローを認識したオーケストレーションが極めて重要なのです。
00:10:18それがアドミッション決定、優先度、そしてリトライ処理の方法を変えるからです。
00:10:25では、最適化についてお話ししましょう。
00:10:27個々の最適化手法について細かく深掘りはしません。
00:10:29世の中にはすでに多くの研究が存在しますが、私が活用しているフレームワークをご紹介したいと思います。
00:10:34このフレームワークは4つの象限に分けて考えることができます。
00:10:40第1に、「処理そのものを回避できるか？」
00:10:42つまり、プレフィックスキャッシュ、レスポンスキャッシュ、セマンティックキャッシュなどの技術により完全にスキップできるかということです。
00:10:48第2に、「処理を共有できるか？」
00:10:51バッチ処理によって複数のリクエストで計算を共有できるかということです。
00:10:54連続バッチ処理、Prefill/Decode分離、Chunked Prefill、投機的デコーディングなどが挙げられます。
00:10:59第3に、「処理を他へ逃がせるか？」
00:11:01より安価なモデルや、ユーザーに近い場所に処理を送信できるでしょうか？
00:11:05主にルーティングを通して、より小さなモデルや安価なリージョンなどに振り分けられるかということです。
00:11:12そして最後は、処理を後回しにできるか？
00:11:13アドミッション制御やキューイングを通して適切なタイミングを待てるかであり、これにはリクエストの優先度クラスの理解とデッドラインを意識したスケジューリングの実装が必要です。
00:11:25このフレームワークは多様な技術スタックに応用できるため、非常に強力です。
00:11:29vLLM、SGLang、TensorRTなど何を使っていても、あらゆる手法がこの4象限のいずれかに該当します。
00:11:35そのため、モデルの最適化を検討する際は、常に従来の手法と比較・対照を行い、
00:11:41これらがどのように組み合わさるかを確認する必要があります。
00:11:47スケールを考える際、モデルのパフォーマンスだけを考慮するのは不十分です。
00:11:51コスト、つまり経済性についても考えなければなりません。
00:11:54ここで重要になるのが、どの指標を最適化しようとしているのかを理解することです。
00:11:58コストとは、単にGPUやモデルの費用だけではないからです。
00:12:02これら全パラメータ、リトライ、ストレージ、障害、ネットワーク、そしてもちろん開発運用コストなども含まれます。
00:12:09重要なのは、ユーザーに価値をもたらすプロダクトの重要業績評価指標（KPI）が何であるかを把握することです。
00:12:17したがって、単にトークン単価やリクエスト単価を最適化すればよいわけではありません。
00:12:22ユーザーが本当に重視しているのは「成功したタスクごとのコスト」であり、これを最適化すべきなのです。
00:12:26それを最適化できれば、プロダクト全体のコストが下がり、ユーザーの満足度も大幅に向上します。
00:12:36では次に信頼性について、特に連鎖障害を防止することの意味について少しお話しします。
00:12:43障害の話の本質は、GPUのプリエンプションや停止そのものではありません。
00:12:46興味深いのは、その後に続くフィードバックループです。
00:12:49GPUの性能低下に伴いレイテンシが上昇し、クライアントが再試行してキューが滞留すると、正常なGPUが飽和してさらなる再試行が発生し、リージョン全体の大規模障害へと発展します。
00:13:02これは典型的な連鎖障害ですが、生成AIアプリケーション特有の要素として「KVキャッシュ」が絡んできます。
00:13:09安易に再起動したり、別のクラスタにルーティングし直したりすることはできません。
00:13:13コールドプールがトラフィックを処理できるようになるにはウォームアップが必要であり、その間はホットプールが全リクエストを引き受けなければなりません。
00:13:20だからこそ、ループブレーカーを極めて意図的に設計することが重要なのです。
00:13:24ルーティング層でのサーキットブレーカーやアドミッション制御、さらには単なるCPUやメモリの使用率だけでなくキューの深度に連動した負荷制限（ロードシェディング）などが挙げられます。
00:13:34また、再試行予算（リトライバジェット）についても考慮する必要があります。これらを考慮しないと、コストが非常に急激に膨らんでしまうためです。
00:13:43それでは、残りの発表を共同スピーカーのNamanに引き継ぎます。
00:13:50ありがとうございました。
00:14:20共同スピーカーのNamanに引き継ぎます。
00:14:22共同スピーカーのNamanに引き継ぎます。
00:14:25共同スピーカーのNamanに引き継ぎます。
00:14:26共同スピーカーのNamanに引き継ぎます。
00:14:27共同スピーカーのNamanに引き継ぎます。
00:14:28共同スピーカーのNamanに引き継ぎます。
00:14:29共同スピーカーのNamanに引き継ぎます。
00:14:30共同スピーカーのNamanに引き継ぎます。
00:14:31共同スピーカーのNamanに引き継ぎます。
00:14:32共同スピーカーのNamanに引き継ぎます。
00:14:33共同スピーカーのNamanに引き継ぎます。
00:14:34共同スピーカーのNamanに引き継ぎます。
00:14:35共同スピーカーのNamanに引き継ぎます。
00:14:36共同スピーカーのNamanに引き継ぎます。
00:14:54マイクは使えているようですね。
00:14:57失礼いたしました。
00:14:58推論が本番運用スケールに達すると、
00:15:00分散システムとしての性質が強く表れてきます。
00:15:03もはや単にモデルを呼び出すだけではありません。
00:15:06典型的な分散システムの問題に近くなります。
00:15:09分散システムでは、キュー、スケジューリング、
00:15:13オートスケーリング、障害隔離などが議論されます。
00:15:14これらは重要な観点の一部です。
00:15:16推論処理にもこうした課題が存在しますが、
00:15:18新たな制約も加わっています。
00:15:20CPUやメモリだけでなく、HBM、KVキャッシュ、
00:15:25成功タスクあたりのコストが関係してきます。
00:15:27運用上の核心的な問いは、
00:15:28「プラットフォームが次に何をすべきかをどう判断するか」です。
00:15:31そこで可観測性（Observability）が不可欠となります。
00:15:34単にダッシュボードを表示するだけではありません。
00:15:35制御ループに入力信号をいかに供給するかが重要なのです。
00:15:39テレメトリの収集と分析により意志決定が行われ、
00:15:43スケジューリングやルーティングの変更が適用され、
00:15:45最後にこのサイクルを繰り返します。
00:15:47ここで特に重要な指標の概要を説明します。
00:15:50まずは「最初のトークンまでの時間（TTFT）」です。
00:15:52最初の応答が得られるまでに
00:15:56実際にどれだけの時間がかかるかを示します。
00:15:58次に「リソース利用率」があります。
00:16:00ボトルネックがメモリなのか計算能力なのかを把握できます。
00:16:04「1ドルあたりの成功数」は、
00:16:06プラットフォームが実際に価値を提供し
00:16:08効率的に動作しているかを示します。
00:16:10最後に「エンドツーエンドのトレースレイテンシ」は、
00:16:12リクエストの経路全体で
00:16:15どれだけ時間が消費されたかを明らかにします。
00:16:19レイテンシ、コスト、スループットの間には根本的なトレードオフがあります。
00:16:22すべてを同時に手に入れることはできません。
00:16:24CAP定理と非常に似ています。
00:16:26バッチサイズを大きくすれば、
00:16:28スループットと費用対効果は向上しますが、
00:16:31テールレイテンシが悪化する可能性があります。
00:16:33投機的デコーディングを行えば
00:16:35レイテンシは改善しますが、余分な計算が発生し、
00:16:38結果としてトークンあたりのコストが上がります。
00:16:41また、シンプルな小型モデルを使用すれば
00:16:44レイテンシとコストを削減できますが、
00:16:45回答の品質は低くなります。
00:16:48最終的に障害分析や再試行を行うことになり、
00:16:50結局コストが再び増加します。
00:16:52サービングに関するすべての決定は、
00:16:54システムをこのトレードオフの三角形のどこかに移動させます。
00:16:56私たちの仕事は最適な設定を見つけることです。
00:16:58これはまさに最適化問題と言えます。
00:17:03これこそが、現在業界が向かっている方向です。
00:17:05推論には独自の制御プレーンが必要です。
00:17:07これまで議論してきたルーティング、バッチ処理、キャッシュ、
00:17:10スケジューリング、信頼性といった要素は、
00:17:12もはや個別の調整ツマミであってはなりません。
00:17:15これらは1つの論理層へと統合されつつあります。
00:17:17これを「推論制御プレーン」と呼びましょう。
00:17:19かつて分散システムではVMを管理し、
00:17:21オートスケーリングのスケジューラを使っていました。
00:17:23そしてKubernetesが登場し、これらを制御プレーンに統合しました。
00:17:27推論も現在、同様の変革期を迎えています。
00:17:30モデルはリソースとなりつつあり、
00:17:32GPU、KVキャッシュ、トークン、レイテンシ、コストが統合管理されます。
00:17:36制御プレーンが、どのモデルがどのリクエストを処理し、
00:17:40どのようにバッチ処理するかを決定します。
00:17:42この層を自社で構築するにせよ、
00:17:44オープンソースやベンダー製品を利用するにせよ、
00:17:46この層が存在することを前提に設計することが重要です。
00:17:50次に、AIインフラで私たちが得た運用上の教訓と、
00:17:53それらがここでどう適用できるかについて議論しましょう。
00:17:55最初の教訓は、インフラのボトルネックは
00:17:57通常、モデルのボトルネックよりも前に発生するということです。
00:18:00本番環境では多くの障害が発生しますが、
00:18:02それらは単なるスケジューリングやルーティング、
00:18:04あるいはキャパシティの不足に起因している場合があります。
00:18:07これらは推論処理そのものではなく、
00:18:08インフラストラクチャの問題なのです。
00:18:10次に伸縮性（エラスティシティ）についてです。
00:18:12システムには伸縮性が必要です。
00:18:14GPUを増やしても根本的な解決にはならず、
00:18:15単に問題を覆い隠しているに過ぎません。
00:18:18また、スケジューリング決定の解決策は、
00:18:20無理な増強よりも効率性を重視すべきです。
00:18:24同じマシン群であっても、スケジューリングや
00:18:26バッチ処理のやり方次第で
00:18:28非常に効率よくパフォーマンスを発揮できます。
00:18:30さらに、自動制御ループは手動プロセスに勝ります。
00:18:31プラットフォーム自体がシステムの状態を感知、検知し、
00:18:35自動的に適応しなければなりません。
00:18:37最大の要点は、トークン数で最適化するのではなく、
00:18:39成功したタスク数で最適化するということです。
00:18:43最後に、皆さんにお伝えしたいより大きなパラダイムシフトがあります。
00:18:48AIインフラの第1段階は「より優れたモデル」の構築でした。
00:18:51モデルの改良、スマート化、
00:18:54そして優れたベンチマークの策定に多くの時間を投資してきました。
00:18:56現在の第2段階は「より高速な推論」です。
00:18:58低レイテンシ、効率的なバッチ処理、
00:19:00そしてGPU利用率の向上が求められています。
00:19:03しかし、次の段階は「オーケストレーション」です。
00:19:05つまり、GPU、メモリ、キャッシュなどのすべてが単なるリソースであり、
00:19:08適切にスケジューリングされ制御される必要があります。
00:19:10これを早い段階で理解したチームこそが、
00:19:13将来に耐えうるインフラを構築できるのです。
00:19:14結論として申し上げたいのは、
00:19:17インフラはもはや単なる「サービング」の課題ではなく、
00:19:19「オーケストレーション」の課題であるということです。
00:19:21ご清聴ありがとうございました。
00:19:23ありがとうございました。
00:19:25ありがとうございました。
00:19:27ご清聴ありがとうございました。
00:19:29ありがとうございました。
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기