llm-d 1.0 は 2026 年 10 月 20 日、北米の PyTorch Conference で正式に披露され、IBM Research が公式ブログで発表した。Kubernetes ネイティブな分散推論プロジェクトで、Red Hat、IBM、Google が中心となって保守し、2025 年に CoreWeave と NVIDIA とともに立ち上げた。AMD、Cisco、Hugging Face、Intel、Lambda、Mistral AI などもその後貢献者に加わっている。1.0 の見どころはベンチマークの数字ではなく、推論を動かせる段階から長期運用できる段階へ進めた点にある。
補われたのは単体性能ではなく運用面
llm-d で知られる五つの技術、プレフィックスキャッシュ対応ルーティング、KV キャッシュのオフロード、バッチ推論の最適化、プリフィルとデコードの分離、ワイドエキスパート並列は 1.0 でも変わらない。変わったのはその上の運用レイヤーで、安定した API、マルチテナントのサービス品質管理、無停止アップグレード、優先度の異なる負荷が同じ基盤を共有しても引きずり合わないフロー制御が加わった。共同創設者で IBM Research の Distinguished Engineer である Carlos Costa は、1.0 は llm-d を他の重要サービスと同じように運用できるようにするためのものだと述べている。
同じ入り口でも、人とエージェントの依頼は分けて扱う
企業向け推論サービスのトラフィックは姿を変えつつある。一つのエンドポイントの背後には、即答を待つコーディング支援の利用者と、断続的に大量リクエストを送り、ツール利用で間を空けるエージェントが同居する。1.0 のフロー制御と公平なスケジューリングは、需要のピーク時に誰を優先するかを明示的に決め、複数ターンのリクエストを同じレプリカに固定してプレフィックスキャッシュを温かい状態に保つ。IBM のテストでは、エージェント型コーディング負荷で再利用可能なキャッシュの 97% を捉え、別のセルフホスト実演では 3,000 のソフトウェアエンジニアリングエージェント同時実行のコストが同等のホスト型サービスの 5 分の 1 から 10 分の 1 に収まった。
自前で推論を運用するチームにとっての中立な選択肢
llm-d は vLLM や SGLang といった推論エンジンの代替ではなく、その上に分散ルーティングと運用機能を足すもので、プロジェクトは CNCF のサンドボックスとしてホストされている。自前の Kubernetes クラスタでモデルを運用しているチームにとって、1.0 はオープンウェイトモデルを本番サービス化する際の工学的ハードルを下げ、計算資源の使われ方やキャッシュの命中状況を管理可能にする。一方で限界もある。Kubernetes の運用スキルは依然として前提であり、クラウドのマネージド推論で足りている小規模チームが自前運用でコストを取り戻せるとは限らない。
