10月12日、IBMが「How distributed inference keeps large AI models moving」と題した記事を公開した。この記事では、大規模言語モデルを大量のリクエストに対してスケールさせるための分散推論（Distributed Inference）の主要技術と、その実装としてのオープンソースフレームワーク「llm-d」について詳しく紹介されている。

なぜ今、分散推論が問題になるのか

LLMをGPU上で動かすこと自体は、もはや難しくない。問題は、それを同時に何千・何百万ものユーザーやAIエージェントに対してサービスとして提供することだ。

エージェントワークフローが普及した今、リクエストのパターンはさらに複雑になっている。エージェントはバーストでリクエストを送り、ツール呼び出しのために一時停止し、ほぼ同じコンテキストを持って戻ってくる。単純なロードバランサーでは対処しきれない状況が生まれている。

vLLMやSGLangといった既存の推論エンジンは、単一サーバー上でのスループット・レイテンシ最適化に優れている。しかし複数GPUノードにまたがるクラスター全体のリクエスト調整、キャッシュ状態の追跡、異種ワークロードの優先度制御は、それらのエンジン自体のスコープ外だ。llm-dはその「一層上」に位置するクラスター横断の調整レイヤーとして設計されており、バックエンドの推論エンジンにvLLMやSGLangをそのまま利用しながら動作する。

この記事では、IBMが中心となって開発するKubernetesネイティブの推論フレームワーク「llm-d」を題材に、分散推論を支える6つの技術革新を解説している。llm-dは2025年5月にIBM Research、Red Hat、Google Cloud、NVIDIA、CoreWeaveによって立ち上げられ、2026年3月にはCloud Native Computing Foundation（CNCF）にサンドボックスプロジェクトとして寄贈された。

最も重要な技術：プレフィックスキャッシュ対応ルーティング

6つの技術の中でエンジニアとして最も注目すべきは、プレフィックスキャッシュ対応ルーティング（Prefix-cache-aware routing）だ。

LLMはプロンプトを処理する際、トークン間の関係を内部表現として計算し、その中間状態をKVキャッシュ（Key-Valueキャッシュ）として保存する。後続のリクエストが同じプレフィックスを持つ場合、その計算を再利用できる。

例えば「What is the capital of Kansas?」を処理したサーバーに「What is the capital of California?」が来れば、「What is the capital of」の部分の計算は再利用できる。

問題は、従来のロードバランサーが「最も空いているサーバー」にリクエストを振る点だ。そのサーバーが必要なキャッシュを持っているかどうかは考慮しない。結果として、別のサーバーがすでに処理済みのプレフィックスを再計算することになる。

llm-dのルーターは2つの問いを立てる：

1. どのサーバーがこのプロンプトのプレフィックスを最も多く保持しているか
2. そのサーバーに処理する余力があるか

実装は2種類用意されている。最近のルーティング決定の軽量インデックスを使う近似実装と、モデルサーバーから実際のトークンデータとキャッシュ状態の更新を受け取る精密実装だ。

llm-dチームの実証実験では、プレフィックス対応ルーティングによって利用可能な再利用機会の97%を捕捉できたと報告されている。エージェント系のシステムでは、長いシステムプロンプト・ソースコード・会話履歴・ツール出力を繰り返し参照するため、この効果は特に大きい。

KVキャッシュのオフローディング：GPUメモリを超えて

キャッシュ対応ルーティングは、キャッシュが残っていることが前提だ。しかしGPUメモリは有限で、長いプロンプトや多数の同時セッションによってすぐに埋まる。

llm-dはKVキャッシュオフローディングによってこの問題に対処する。GPUメモリに収まらないキャッシュエントリをCPUメモリ、ローカルSSD、共有ファイルシステムといった低速だが大容量のティアに退避させる仕組みだ。キャッシュインデックスが「何がどこにあるか」を追跡し、ルーティング層がオフロードされたデータも考慮できるようにする。

実証実験では、128の同時リクエストに対してGPUメモリが再利用可能なプレフィックスの90〜92%を供給し、残りをCPUオフローディングで補ったという結果が示されている。オフロードへの書き込みは非同期で行われるため、トークン生成のスループットには影響しない。

その他の4つの技術

フロー制御（Flow control）

リクエストの優先度と流量をクラスター全体で管理する仕組みだ。レイテンシに敏感なインタラクティブトラフィック（チャットUIなど）を保護しつつ、バースト的なエージェントトラフィックを平滑化する。単一のテナントやエージェントの急増が他のユーザーのレスポンスタイムを悪化させないよう、キュー深度やスロットル閾値をリクエスト種別ごとに制御する。プレフィックスキャッシュ対応ルーティングと連携することで、優先度の高いリクエストをキャッシュ命中率の高いノードへ誘導する効果も生まれる。

バッチ推論最適化（Batch inference optimization）

研究評価・文書処理・合成データ生成など、即時応答を必要としないワークロード向けの仕組みだ。OpenAI互換のBatch Gatewayと、RedisやGoogle Pub/Subからリクエストを取り出す非同期プロセッサを備える。フロー制御と連携し、バッチジョブが一度にクラスターへ流入しないよう調整することで、インタラクティブワークロードへの影響を最小化する。スループット優先のバッチ処理とレイテンシ優先のリアルタイム処理を同一クラスター上で共存させることが、この技術の主眼だ。

プレフィルとデコードの分離（Prefill/decode disaggregation）

LLMの推論は2フェーズに分かれる。プレフィルはプロンプト全体を並列処理してKVキャッシュを構築し、デコードはトークンを1つずつ逐次生成する。この2つは計算特性が大きく異なる。llm-dではそれぞれを専用のワーカーに割り当て、独立してスケールできる。長文ドキュメントが多いならプレフィルを、会話セッションが多いならデコードを増強するといった柔軟な運用が可能になる。

ワイドエキスパートパラレリズム（Wide expert parallelism）

Mixture-of-Experts（MoE）アーキテクチャを持つ大規模モデル向けの技術だ。MoEモデルはすべてのパラメータを使うのではなく、トークンごとに一部の「エキスパート」のみを選択して実行する。しかしモデル全体のウェイトはメモリに保持する必要があり、これが数百GBに達する場合もある。llm-dは各エキスパートの担当をノード間で分割し、エキスパートルーティングをクラスター規模で処理することで、単一GPUのメモリ容量に収まらない大規模MoEモデルの推論を可能にする。テンソルパラレリズムのようにウェイト自体を分割するのではなく、エキスパートの選択・実行単位で分散させる点が特徴だ。

まとめ

分散推論はvLLMやSGLangのような個別サーバー上の推論エンジンの一層上に位置し、クラスター全体を横断してリクエストを調整・最適化するレイヤーだ。エージェントワークフローが当たり前になるにつれ、この層の重要性は高まり続けるだろう。llm-dはその実装として、CNCFの傘下でオープンな開発が続いている。

詳細はHow distributed inference keeps large AI models movingを参照していただきたい。