llm-d 1.0はAI推論をどう変える？文脈の再利用と混雑制御の仕組み｜2026年10月23日版
AIエージェントが同じ資料やコードを何度も読み込む。そのたびに計算を繰り返せば、高性能なGPUを増やしても待ち時間と費用は膨らむ。2026年10月20日に発表された「llm-d 1.0」は、計算済みの文脈があるサーバーへリクエストを送り、用途に応じて処理の順番を制御することで、この問題に取り組む。
新しい言語モデルではない。複数のモデルサーバーをまとめて運用する、Kubernetes向けのオープンソース推論基盤だ。1.0では、従来からの高速化技術に加え、複数部門での共用や更新時の継続運転など、本番運用の機能を強化した。IBM Researchの発表が、その位置付けを説明している。
日本時間2026年10月23日時点の公開情報から、仕組みと導入判断のポイントを整理する。
- 再計算を減らす： 共通する入力の処理結果を持つサーバーへ振り分ける。
- 混雑を制御する： 大量の自動処理と、人が待つ対話処理に優先順位を付ける。
- 更新を運用に組み込む： 推論を分担する構成でも、関連するサービスを連携して更新する。
なぜAIエージェントは推論基盤を混雑させるのか
一問一答のチャットに比べ、エージェントは同じ文脈を使って何度もモデルを呼び出す。
例えばコードを扱う処理では、指示、コード、会話履歴を参照しながら、ツールの実行結果を受け取って次の判断に進む。この往復が多数並行すると、入力の重複とリクエストの急増が同時に起きる。
IBM Researchは、こうした処理では同じ資料を繰り返し計算することが継続的な推論費用につながると説明する。重要なのは、モデルの生成速度だけでなく、すでに済ませた計算をどれだけ次の呼び出しに生かせるかだ。
文脈を持つサーバーへ送る「キャッシュ対応ルーティング」
llm-dの中心となる仕組みの一つが、入力の共通部分に対応した振り分けだ。
言語モデルは、入力を処理する過程で、後続の生成に使う中間状態を保存する。これがKVキャッシュで、完成済みの回答を保存する仕組みとは異なる。共通する入力部分を再利用できれば、その部分の計算を減らせる。
ただし、複数サーバーへ単純に順番でリクエストを配ると、必要なキャッシュがないサーバーに届くことがある。
キャッシュと混雑の両方を見る
llm-dは、共通する入力のキャッシュを持つサーバーを考慮して送信先を選ぶ。エージェントが次の処理に戻ってきたときにも、関連する文脈を再利用しやすくする。
一方、キャッシュを持つサーバーだけに処理を集めれば、そこが混雑する。そこでキャッシュの有無に加え、負荷や予測待ち時間も振り分けの判断材料にする。Google Cloudの技術解説は、この動作を説明している。
メモリーに収まらないキャッシュも扱う
アクセラレーターのメモリーには限りがある。llm-dが組み合わせるKVキャッシュのオフロードは、キャッシュをホスト側のメモリーやストレージへ移し、再利用の余地を広げる仕組みだ。
ただし、保存先からの転送にも時間がかかる。導入時には、保持量を増やした効果と、読み戻す負担の両方を測る必要がある。
1.0の焦点は、速い推論を運用し続けること
キャッシュ対応の振り分けやKVキャッシュのオフロード自体が、1.0で初めて登場したわけではない。今回の重点は、それらを共用環境で安定して動かすことにある。
公式リリース発表では、次の機能が示されている。
- 優先順位と公平性の制御： 大量のエージェント処理と、低遅延が必要な対話処理が計算資源を共用できるようにする。
- 更新時の継続運転： ルーターの高可用性やローリング更新を支える。
- 安定した設定API： v1の設定APIを、運用基盤として利用するための土台にする。
- セッションを考慮した処理： 複数ターンにまたがる文脈の再利用を助ける。
例えば、社内チャットと大量の自動分析を同じ設備で動かす場合、処理件数だけを最大化すると、チャット利用者の待ち時間が延びかねない。優先順位を設定する意味は、限られた設備でどのサービスの応答を守るかを明確にすることだ。
入力処理と生成処理を分けると、更新も連携が必要になる
推論には、入力をまとめて処理する「prefill」と、出力を順次生成する「decode」がある。両者は計算資源の使い方が異なるため、別のサーバー群に分担させる構成がある。
しかし、分担すれば管理対象も増える。片方だけを更新するのではなく、関連する構成の整合性を保つ必要がある。
llm-d 1.0のDisaggregatedSetは、これらのサーバー群を一つの論理単位として管理し、更新を連携させるための仕組みだ。高速化の構成を採用した後も、保守を続けられるようにする点が重要になる。
日本の開発・運用チームは何を測るべきか
直接の検討対象は、vLLMやSGLangなどでモデルを自社運用するチームだ。外部の生成AIサービスだけを利用する企業にとって、llm-dがそのまま追加できる利用者向け機能というわけではない。
導入を評価するなら、まず既存環境で同じ入力がどの程度繰り返されているかを確認したい。そのうえで、次の指標を比較する。
- 最初の出力までの時間： 平均値に加え、混雑時に長く待たされるリクエストを見る。
- キャッシュ再利用率： 会話が続く場合と、新しい案件が増える場合を分ける。
- 用途別の待ち時間： 対話処理と大量の自動処理を同時に動かして測る。
- 運用全体の費用： 計算資源に加え、キャッシュ保存先や監視、保守の負担も含める。
これらは導入判断のための評価項目だ。公開された性能値だけで、自社の処理でも同じ改善が得られるとは判断できない。
継続ウォッチ：キャッシュが使えないときも速いか
llm-d 1.0が示す方向は明確だ。モデルの呼び出しを個別に処理するだけでなく、文脈の再利用、混雑、更新までまとめて扱う。
次に確認したいのは、都合のよい条件を外したときの動作になる。
- 新規の入力が増え、キャッシュがほとんど使えなくても応答を維持できるか。
- 自動処理が急増しても、人が操作するサービスの待ち時間を守れるか。
- 更新や障害の際、キャッシュの再構築がどれだけ負荷を生むか。
導入試験では、キャッシュが温まった状態と、空の状態の両方を測る。 その差を把握することが、日常運用で期待できる効果を見積もる出発点になる。