AI推論を本番インフラへ オープン標準を担う分散推論フレームワーク「llm-d」、CNCFが採択：KubernetesをAIインフラに最適化

CNCFは、Kubernetes向けの分散推論フレームワーク「llm-d」をSandboxプロジェクトとして採択したことを発表した。

[＠IT]

　クラウドネイティブ技術の標準化団体「Cloud Native Computing Foundation」（CNCF）は2026年3月24日（米国時間）、Kubernetes向け分散推論フレームワーク「llm-d」を、Sandbox（実験段階）プロジェクトとして採択したことを発表した。

　llm-dは2025年5月、Red Hat、Google Cloud、IBM Research、CoreWeave、NVIDIAの共同プロジェクトとして発足した。その後、Advanced Micro Devices（AMD）、Cisco Systems、Hugging Face、Intel、Lambda、Mistral AI、さらにカリフォルニア大学バークレー校とシカゴ大学の支援者も参画している。

　今後はLinux Foundationの傘下で開発が継続される。

「llm-d」が解消するAI推論の課題とは

　生成AIが研究段階から本番環境へ移行する中、プラットフォームエンジニアリングの現場では新たな課題が浮上している。

　過去のやりとりを記憶するステートフルな特性を持つAI推論は、レイテンシ（遅延）に敏感で、その処理コストはプロンプトの長さやキャッシュの局所性、モデルの実行フェーズによって大きく変動する。

　しかし、従来のKubernetesにおけるルーティングやオートスケーリングの仕組みはこうした推論の状態を認識できないため、非効率な配置やキャッシュの断片化、負荷時の予測不能なレイテンシを招いていた。

　llm-dはこの課題を解決するため、「KServe」などの上位コントロールプレーンと、「vLLM」などの下位推論エンジン間のギャップを埋めるKubernetesネイティブの事前統合された分散推論フレームワークとして設計されているという。

CNCFエコシステムへ提供される4つの機能

　llm-dはCNCFエコシステムに以下の機能を提供するとしている。

• 推論対応トラフィック管理
  • Kubernetesの「Gateway API Inference Extension」（GAIE）の主要実装として、「Endpoint Picker」（EPP）拡張機能を用いたプログラマブルなルーティングを提供。プレフィックスキャッシュを考慮した効率的なトラフィック配分を可能にする
• Kubernetesネイティブなオーケストレーション
  • LeaderWorkerSet（LWS）などのデプロイAPIを活用し、マルチノードでのレプリカ管理や広範なエキスパート並列処理を統合管理する
• PrefillとDecodeの分離
  • プロンプトを処理する「Prefill」とトークンを生成する「Decode」を独立したポッドに分離。リソース利用率のミスマッチを解消し、スケーラビリティを向上させることを目的とする
• 高度な状態管理
  • GPU、TPU、CPU、ストレージ層にわたる階層的なKV（Key-Value）キャッシュオフロードを実現する

llm-dの推論トラフィック管理アーキテクチャ（提供：CNCF）

パフォーマンス実績：高負荷下でも低レイテンシを維持

　llm-dのv0.5のベンチマーク（Qwen3-32B、vLLMポッド8台、NVIDIA H100 16枚構成）では、マルチテナントSaaSのユースケースにおいて、llm-dの推論スケジューリングがほぼゼロのTTFT（最初のトークンが生成されるまでの時間）を維持しながら約12万トークン毎秒のスループットを達成。一方、同条件の標準Kubernetesサービスは負荷増大とともに急速に性能が低下した。

llm-dと標準KubernetesサービスのQPS（クエリ毎秒）に対するTTFTとスループット比較（提供：CNCF）

「well-lit paths」で本番環境への最短距離を目指す

　llm-dは「well-lit paths」（明るく照らされた道）という設計思想を掲げている。不安定なブラックボックスを構築するのではなく、実際の負荷環境で検証済みの本番向けデプロイパターンをユーザーに提供するという方針だ。

　llm-dのミッションは、「あらゆるモデル、あらゆるアクセラレーター、あらゆるクラウド」で最先端の推論性能を実現することであり、NVIDIA、AMD、Googleなどのハードウェアに依存しない設計となっている。