同じ 16 GPU で 2 倍のユーザー：LLM クラスタの推論対応ルーティング

要約： 同じ 16 GPU で、ユーザー数は 2 倍になります。つまり、GPU の利用コストを据え置いたまま、処理能力を倍増させることができます。かつては 20 人の同時ユーザーを処理していたクラスタで、今では 200 人に対応できるようになるのです。これを可能にするのが、llm-d の推論スケジューラーです。このスケジューラーは、すべてのノード、キュー、キャッシュの状態を可視化した上で、分散クラスタ体にすべてのリクエストをルーティングできるように構築されています。大規模言語モデル (LLM) へのリクエストは、処理に時間がかかり、処理内容も不均一で、コストも高いという特徴がありますが、この推論スケジューラーはまさにそうした特性に対応するために構築されました。

他のあらゆる場面で機能するパターン

GPU の利用には常にコストがかかります。重要なのは、そのコストに対してどれだけの処理を得られるかという点です。

Kubernetes は、分散型サービスを大規模に構築、デプロイ、運用するための標準的な手法です。標準的な Kubernetes 構成では、デプロイメントを定義してレプリカ数を設定します。すると、Kubernetes サービスが入り口の役割を果たし、すべてのPodに対してラウンドロビン方式で負荷分散を行います。REST API、Web サービス、マイクロサービスの場合、このパターンは基本的に最適です。リクエストは高速かつ均一で、それぞれのリクエストの完了までの時間はほぼ同じ 1 秒未満で一定しているからです。

しかし、Llama、Mistral、GPT クラスのオープンソースモデルなど、大規模な生成モデルを大規模に運用し始めると、その前提はもはや通用しなくなります。

ラウンドロビン方式の限界

LLM の推論リクエストは通常​​の HTTP リクエストとは異なり、その違いこそが標準的な負荷分散機能に影響を与えるものです。

• 処理時間のばらつき：モデルへの指示内容次第で、処理時間は 1 秒未満で終わることもあれば、1 分以上かかることもあります。ラウンドロビン方式はリクエストを分散するだけで、実際の作業負荷までは考慮しません。あるレプリカに時間のかかる重いリクエストが連続して割り当てられると、そのレプリカがボトルネックになる一方で、別のレプリカはほとんどアイドル状態となります。
• 処理パターンのばらつき：短いプロンプトで長い回答を生成する場合と、長いプロンプトで短い回答を生成する場合では、挙動が異なります。計算プロファイル、メモリーの負荷、完了までの時間など、すべてが異なるのです。
• 処理フェーズのばらつき：すべての推論リクエストは、内部的に 2 つのフェーズで構成されています。入力プロンプト全体を一度の並列処理で処理する「プリフィル（prefill）」フェーズと、回答を 1 トークンずつ生成していく「デコード（decode）」フェーズです。これら 2 つのフェーズは、リソースプロファイル、期間、負荷増大の度合いが異なります。リクエストの中身を区別できないシステムでは、どちらのフェーズに対しても最適化を行うことができません。

ラウンドロビン方式は、リクエストが短時間で完了し、均一かつ低負荷なワークロードを想定して設計されたものです。リクエストの内部構造を認識できないスケジューラは、それらをすべて同じものとして扱ってしまうのです。

図 1：ラウンドロビン方式はリクエストを分散するだけで、実際の作業負荷までは考慮しません。同じ 5 つのリクエスト (サイズとコンピューティングコストは異なります) が、Pod 間で不均等に割り当てられる様子を示しています。ある Pod は 2 つの長いリクエストで処理され、別の Pod はほとんどがアイドル状態です。これに対し、推論を考慮したルーティングはリクエストの特性(形状、サイズ、負荷)を認識し、実際の作業負荷を適切に分散させます。

間違った Pod でのキャッシュヒットは、実質的にキャッシュミスと同じ

vLLM は LLM 向け推論エンジンのデファクトスタンダードとなっており、主要なハードウェアアクセラレータはすべて vLLM 向けに最適化され、新しいモデルもリリース初日から vLLM に対応しています。また、単一ノード上での推論処理の仕組みを極めて効率的に制御します。

vLLM は、推論において最もコストのかかる処理の一つである、同じプロンプトのプレフィックスの繰り返し処理に対処するため、プレフィックス・キャッシュ機能を導入しました。システムプロンプト、ドキュメント、会話履歴など、複数のリクエストが共通のプレフィックスを共有する場合、vLLM は最初の計算で生成されたキー値（Key-Value）状態をキャッシュし、後続のリクエストで再利用できます。キャッシュがヒットすると、プリフィル工程が完全にスキップされます。その結果、キャッシュ済みのプロンプト部分の割合に応じて　TTFT (Time To First Token：最初のトークンが生成されるまでの時間）が短縮されますが、これはリクエストがそのキャッシュを保持している特定のレプリカにルーティングされた場合に限られます。

あるレプリカであればほぼゼロコストで処理できたはずのリクエストが、別のレプリカにルーティングされると、ゼロから処理をやり直すことになります。最適化の仕組みは存在しているのに、ラウンドロビン方式のルーティングではそれが無視されてしまうのです。

トラフィックが少ない状況では、これは単なる機会損失に過ぎません。しかし、大規模な運用環境では、同じ計算に対して二重にコストを支払っていることになります。

ノードからクラスタへの移行

それぞれの vLLM Pod は、メモリ管理、効率的なバッチ処理、ハードウェアの限界まで高速なトークンの提供といったタスクを適切にこなしていますが、自らの状態しか認識していません。つまり、他の Pod が何を処理しているか、どのレプリカに負荷がかかっているか、あるいはクラスタ全体でプレフィックスキャッシュの状態がどこに保持されているかといった情報は把握していないのです。 

こうした調整の課題はノードより上位のレイヤーに存在します。大規模な分散インフラとオーケストレーションにおいて Kubernetes が事実上の標準プラットフォームとなっていることを踏まえ、llm-d はまさにこの課題を解決するために、ゼロから Kubernetes ネイティブな設計で構築されました。  

その具体的な実装形態が推論ゲートウェイ (IGW) です。これは Envoy と Kubernetes Gateway API をベースに構築されたトラフィックレイヤーであり、単なる HTTP 通信ではなく、LLM のワークロードを理解して処理を行います。その背後で動作する推論スケジューラーは、InferencePool 内のすべての Pod の状態（キューの深さ、KV キャッシュの状態、負荷など）をリアルタイムで監視し、単にローテーション順で次のインスタンスにリクエストを回すのではなく、最適なインスタンスへとリクエストをルーティングします。

図 2：推論ゲートウェイ (IGW) は各リクエストを受信し、ext_proc 経由で推論スケジューラー (EPP) に問い合わせます。スケジューラーは 2 つのライブシグナル (KV キャッシュ状態と負荷) で InferencePool 内のすべての Pod にスコアを付け、選択されたエンドポイントを IGW に返し、IGW はリクエストを転送します。キャッシュヒット時には、プリフィルのキャッシュ済みの部分が再利用され、デコードがすぐに開始されます。キャッシュミス時には、プリフィルが完全な形で実行されます。

大規模な推論スケジューリング： 同じハードウェアで、容量は 2 倍に

推論スケジューラー (llm-d の Inference Scheduler (EPP)) は、クラスタレベルの調整を具体的に実現するコンポーネントです。すべての Pod を交換可能なものとして扱うのではなく、リアルタイムのシグナルに基づいて各リクエストをルーティングします。シグナルには、KV キャッシュの状態、キューの深さ、および負荷が含まれます。これにより、あらゆるリクエストが確実に適切なインスタンスへと送られます。

llm-d v0.5 のベンチマーク結果は、これが実際の運用においてどのような効果をもたらすかを示しています。

推論スケジューリング (Qwen3-32B、vLLM Pod × 8、NVIDIA H100 × 16)：

• ベースラインの Kubernetes サービスと比較して、スループットが 109% も向上。同じ 16 GPU を使用しつつ、サービスレベル目標 (SLO) を満たした状態で、約 2 倍の同時ユーザーを処理できます。
• 同等の負荷で最初のトークンが生成されるまでの時間 (TTFT) が最大 99% 短縮。このベンチマークは、ベースラインの TTFT が高負荷の状況下でおよそ 80 秒にまで上昇することを示しています。しかし、インテリジェントなスケジューリングによって、最大 150 ミリ秒に保持されます。これは、「動作が壊れている」と感じさせる製品と、「即座に反応する」と感じさせる製品との決定的な違いです。
  • このベンチマークでは、16 の GPU で 約 11,000 出力トークン/秒の処理能力を維持しました。1 レスポンスあたり約 1,000 トークン、アクティブユーザー 1 人あたり毎分約 3 件のリクエストと仮定すると、ベースラインの Kubernetes サービスが 20人を超えると提供を終了するハードウェア上で、SLO を満たした状態で約 200 人の同時ユーザーをサポートできる計算になります。

すべての結果はバージョン管理され、再現可能な特定のガイドに関連付けられます。

図 3：llm-d 推論スケジューリングとベースライン Kubernetes の比較：平均 TTFT およびスループットと QPSトポロジー：vLLM Pod × 8、NVIDIA H100 × 16 (TP=2)ワークロード：共有プレフィックスを用いた合成データ（150 グループ × 5 プロンプト、6,000/1.200/1,000 システム/質問/出力の長さ結果：P50 TTFT 136 - 157 ミリ秒、4.5 - 11,000 出力トークン/秒、ベースラインと比較してスループットが最大 109% 向上、TTFT が 99% 低下ソース：llm-d v0.5.

vLLM がノードを最適化し、llm-d がクラスタを最適化する

vLLM と llm-d は連携して動作するように設計されており、これらを併用する場合とそうでない場合では、測定可能なほどの性能差が生じます。同じハードウェアで 2 倍のユーザーを処理できる、負荷がかかってもレイテンシーが 99% 改善する、同時ユーザー数が 20 人の場合と同様に 250 人の場合でもクラスタが安定して動作する、といった違いです。

2 つ以上のレプリカを実行している場合、インテリジェントな推論スケジューリングがワークロードに今すぐ適用されます。その性能差は単なる微増ではありません。スケーリング可能なクラスタと、負荷への対応に苦戦するクラスタとの決定的な違いなのです。 

ここから、分散推論が始まります。

スケールを実際に体験する

本ブログ記事で示された数値の根拠となる llm-d のガイドやベンチマーク設定は公開されており、再現可能です。まず、llm-d v0.5 リリースから始めましょう。

Red Hat AI Enterprise には企業向けサポート付きの llm-d が含まれており、Red Hat AI Enterprise の 60 日間無料トライアルが提供されています。独自のインフラストラクチャで実行したい場合は、ここから始めるのが最適です。

最初にスケジューラーの動作を確認したい場合は、llm-d の概要インタラクティブデモで、リクエストがルーティングされる仕組みを説明します。

著者注：ベンチマークデータは llm-d v0.5 リリースに基づいています。すべての結果は、llm-d ガイドで公開されているバージョン管理された設定を使用して再現可能です。