PyTorch ConferenceでLlm-D 1.0が発表、本番環境向け推論スタックを公開

llm-dプロジェクトの貢献者は、2026年10月20日、PyTorch Conference North Americaで、Kubernetesネイティブの分散型推論サービングスタックであるllm-d 1.0を発表した。IBM Researchの発表によると、IBMは、このリリースによってllm-dは個々の性能向上手法を実証する段階を超え、推論コストの上昇を受けて、組織がモデルのデプロイを自社内で行えるよう支援することを目指すと述べた。

llm-dは、あらゆるモデルを、あらゆるアクセラレーター上で、あらゆるクラウドにデプロイする推論スタックとして構築されている。Red Hat、IBM、Googleがプロジェクトの主要メンテナーであり、CoreWeaveおよびNVIDIAとともにllm-dを共同設立した。AMD、Cisco、Hugging Face、Intel、Lambda、Mistral AIも貢献者として参加している。Cloud Native Computing Foundation（CNCF）は、サンドボックスプロジェクトとしてllm-dをホストしている。IBMは、この成果を、単一の独自モデルプロバイダー、クラウド、またはハードウェアプラットフォームに全面的に依存せずに、同社が「最先端クラス」と呼ぶ推論性能を求める組織に向けた、ベンダー中立の選択肢だと説明している。

IBM Researchのディスティングイッシュト・エンジニアで、llm-dの共同創設者兼リードメンテナーでもあるCarlos Costaは、バージョン1.0によって、llm-dを他の重要なサービスと同様に運用できるだけの成熟度が加わったと述べた。その根拠として、安定したAPI、優先事項が競合する複数のテナントによる同一インフラの共有、運用を中断しないアップグレードを挙げた。

バージョン1.0で加わった機能

2026年10月20日にGitHubで公開されたプロジェクトのv1.0.0リリースノートは、署名済みかつ検証済みのタグとともに、マルチテナントのサービス品質を中心に据えている。具体的には、負荷を制御しながら処理を抑制する、優先度と公平性を考慮したフロー制御を導入しており、確率的な受付制御、プログラムを考慮した公平性、ターン優先度のスコアリングを含む。これにより、過負荷時にも互いの処理を妨げることなく、レイテンシーに敏感なリクエストと、負荷が急増するエージェントのワークロードを同じフリートで処理できる。フロー制御の設定は、単一のflowControlフィールドに集約された。

ダウンタイムのない運用に向けて、ルーターにはホットスタンバイと安全なローリングアップデートによる高可用性が加わった。また、DisaggregatedSetコントローラーは、prefillとdecodeのレプリカを1つの論理単位として管理する。これには、連携したロールアウト、足並みをそろえたアップグレード、Podスナップショットを条件とするレディネス判定、ネイティブなリビジョンルーティングが含まれる。ルーター設定APIはv1に昇格し、Responses APIはprevious_response_idに対応した。さらに、エンドポイント選択機能のリクエスト経路は、信頼性、性能、拡張性を高めるために強化された。DRAとDRANET向けに、トポロジーを考慮したアクセラレーターガイドも含まれている。

エージェントを考慮したサービングでは、複数ターンにわたる会話をキャッシュ済みのコンテキストの近くに保つため、session-state-producerプラグインと、変化に応じて更新されるセッションアフィニティが加わった。ターン優先度に基づくスケジューリングとResponses APIの状態管理により、エージェントがターンをまたいでコンテキストを再利用できるよう支援する。今回のリリースでは、プロジェクトの各コンポーネントをv1.0.0にそろえたほか、モデルの重みをピアツーピアで読み込むai-dynamo/modelexpressとの統合、llm-d-api-extensionsパッケージ、診断ツールのllm-d-pd-utilsなど、エコシステムを構成する要素を追加した。また、プロジェクト独自のllm-d-rocmコンテナイメージのビルドは非推奨となった。モデルサーバーのイメージには、さまざまなアクセラレーターを対象とするvLLMおよびSGLangのビルドが含まれる。さらに、prefill/decodeの分離に関するガイドでは、DisaggregatedSet APIを有効にしたうえで、LeaderWorkerSet v0.11.1以降を使用することが新たに必須となった。

中核技術とフロー制御

プロジェクトは立ち上げ以来、推論の改善に向けて5つの手法に取り組んできた。共有コンテキストをすでに保持している可能性のあるインフラへリクエストを振り分ける、プレフィックスキャッシュを考慮したルーティング。GPU、CPU、ストレージの各リソース間でキャッシュ情報を移動させるKVキャッシュのオフロード。バッチ推論の最適化。プロンプトの読み取りと応答の生成を分離するprefill/decodeの分離。そして、大規模な混合エキスパートモデルを多数のアクセラレーターに分散させる、幅広いエキスパート並列化だ。これらの手法はバージョン1.0より前から存在していた。IBMによると、新しいのは、これらを取り巻く統合と運用面の成熟度であり、トラフィックの変化、ハードウェアの故障、ソフトウェアの更新、あるいは同じリソースをめぐるユーザー間の競合があっても性能を維持する、日々の運用管理の徹底だという。

バージョン1.0では、フロー制御、公平性、優先順位付けによって、バースト性の高いワークロードがレイテンシーに敏感なサービスを圧迫しないようにする。ワークロードが同じハードウェアを共有する場合も、複数種類のアクセラレーターにまたがる場合も同様だ。また、複数ターンにわたってリクエストを適切なインフラに固定し、プレフィックスキャッシュを有効な状態に保つことができる。llm-dはvLLMやSGLangなどの推論エンジンと連携し、その上に分散ルーティングと運用機能を追加する。Red Hatの最高技術責任者室の副社長であるStephen Wattは、KubernetesネイティブのオーケストレーションをvLLMや最新の推論エンジンに直接導入することで、llm-dはPyTorchとCNCFのエコシステムを統合すると述べた。

実証された成果と公表されたコスト

2026年7月22日公開のベンチマーク記事で、このプロジェクトはGLM-5.2のエージェント型サービングを測定した。同記事では、GLM-5.2は744Bのパラメーターを持つ混合エキスパートモデルで、アクティブパラメーターは39B、層数は78と説明されている。ワークロード分析には、本番環境でのClaude Codeのセッション219件が用いられた。各セッションでは、メインエージェントのリクエストの入力トークン数の中央値は195K、出力トークン数は317で、メインエージェントのターンの96%が入力の少なくとも90%を再利用していた。同記事によると、プレフィックスを考慮したルーティングによって、ワークロードで利用可能だったキャッシュ再利用の96～97%を実現した。H200のレンタル料金をGPU 1時間あたり2.71ドルと仮定した場合、64基のGPUを使う2種類の構成でセルフホスト型サービングを行うと、入力トークン100万件あたり0.05～0.08ドル、出力トークン100万件あたり1.92～3.55ドルになると試算している。著者らによると、これらの金額に含まれるのはGPUのレンタル料金のみで、負荷が継続的にかかることを前提としている。

別のデモでは、IBMとRed HatがGLM-5.2を544基のNVIDIA H100 GPUに導入した。IBM Researchの報告では、GLM-5.2はおよそ7530億のパラメーターを持つオープンウェイトモデルで、アクティブパラメーターは約390億と説明されている。IBMによると、この導入環境ではピーク時に毎分660万を超える出力トークンを生成しながら、最大3,000件のコーディングエージェントを同時に稼働させ、プリエンプションは発生しなかった。また、2,500エージェントの稼働時には、毎分7,612件のリクエストを継続して処理した。IBMは、現在のクラウドレンタル料金で比較した場合、llm-dを使ってH100 GPU上にGLM-5.2をセルフホストすると、同等の商用API料金よりトークンあたりのコストを5～10分の1に抑えられるとしている。Red Hatの推論エンジニアリングチームでシニアプリンシパル・機械学習エンジニアを務めるMaroon Ayoub氏は、「数千のエージェントを同時に稼働させてもプリエンプションが起きないことは、ベンチマークの結果を本番環境への導入につなげる、確かな道筋を運用者に示します」と述べた。

同じ報告によると、こうした結果を支えた分離型データプレーンでは、転送1件あたりの平均サイズが2.71 GiBのKVキャッシュ転送620万件を、転送失敗ゼロで完了した。また、すべてのベンチマークがサービングエラーゼロで完了した。