10月21日、Beth Pariseauが「CNCF's llm-d 1.0 tackles high AI inference costs」と題した記事を公開した。CNCFのオープンソースプロジェクト「llm-d」がバージョン1.0に到達し、分散AI推論基盤として本番利用可能な水準に達した。IBMリサーチの実証では、AIエージェントの24時間稼働コストをフロンティアモデル利用時の**$300からわずか$26**へと削減したという。GPUコストの高騰に悩む現場にとって、見逃せない動向だ。
AIインフラの新たな共通基盤として
GPUは希少で高コストだ。その現実の中で、AI推論コストをいかに下げるかは、多くのエンジニアにとって切実な問題となっている。
llm-dは、AI推論ワークロードをGPUクラスター全体に自動分散させるクラスターレベルのオーケストレーターだ。IBM・Red Hat・Google・Nvidia・CoreWeaveらが支援するCNCFプロジェクトとして2025年に発足し、今週バージョン1.0に到達した。
最大の技術的なポイントはキャッシュヒット率の最大化だ。llm-dは、AIワークロードができる限りローカルキャッシュからデータを引き出すようルーティングを最適化する。これにより、大規模なAI推論におけるトークンコストを大幅に削減できる。
実績：24時間で$300 → $26
IBMリサーチが実施したコスト比較が具体的だ。量子コンピューティングプロジェクトでAIエージェントを活用した際、llm-dを使ってフロンティアモデルと安価なオープンウェイトモデルの性能・コストを比較検証した。
- Anthropic Claude Opus 5（フロンティアモデル）で24時間エージェント稼働 → $300
- z.AI GLM-5.3（安価なオープンウェイトモデル）+ llm-d → $26
※z.AI GLM-5.3は元記事に登場するモデル名だが、公式情報の詳細については元記事を参照されたい。
IBMリサーチのチーフサイエンティスト、Ruchir Puri氏によれば、llm-dはGLM-5.3の性能をClaude Opus 5に匹敵するレベルまで引き上げたという。コスト差は約11分の1だ。
Puri氏はllm-dをKubernetesになぞらえてこう述べた。
「Kubernetesがワークロード管理に果たした役割を、llm-dはモデルに対して担う。どのモデルを動かすか、どうスケールするか、どうロードバランスするか——詳しくないユーザーをその複雑さから解放する」
1.0で何が使えるようになったか
バージョン1.0に含まれる主な機能は以下の通りだ。
- マルチテナンシーサポート：共有クラスター上で複数のAIモデルが稼働する際のQoS（サービス品質）維持
- 無停止バージョンアップグレード：本番環境でのアップデートを中断なく実施
- 安定・堅牢化されたAPIとリクエストパス
- エージェント対応サービング（agent-aware serving）：AIエージェントがコンテキストキャッシュを再利用し、出力を再計算せずに済むようにすることで、トークン消費を削減する機能
なお、Kubernetes上で動作させることが必須ではないが、Kubernetesと組み合わせた場合はKubernetes API Gateway Inference Extensionを含む各コンポーネントと深く統合される。
クラウドプロバイダーDigitalOceanはllm-dのフォーク版を自社のManaged AgentsおよびServerless Inferenceサービスに採用している。同社のAIエンジニアリング担当SVP、Salman Paracha氏はこう述べた。
「llm-dなしでは分散スケールを実現できない。大規模なGPUフリート全体にトークンワークロードを分散させ、高いキャッシュヒット率を達成することが、良質なサービス品質の前提条件だ」
「Kubernetesの瞬間」はまだ先か
Red HatはAI製品内にllm-dとノードレベルの推論エンジンvLLMをパッケージング済みで、Google Kubernetes Engine（GKE）でも既に稼働している。バージョン1.0に対する支持表明にはAMD、Cohere、JetBrains、Mistral、Robloxも名を連ねる。
一方でアナリストのJason Andersen氏（Moor Insights & Strategy）は慎重な見方を示す。
「CoreWeaveはllm-dをオプションとして提供しているが、コアプロダクトには組み込んでいない。ベンダーの支持は、必ずしもコミットメントと同義ではない。今の段階では、『使うなら構わない』と言っているに過ぎない」
NvidiaはDynamoフレームワークの一部（NIXLデータ転送・KV-キャッシュ管理ユーティリティ）をllm-dに提供しているが、両者の間には機能の重複も多い。
Kubernetesが2014年の登場から5年で業界標準となったように、llm-dも同様の普及を目指すが、VMwareなどエンタープライズ向けプレイヤーの参加が今後の鍵になるとAndersenは指摘する。
マルチチップアーキテクチャへの対応
GoogleはllmーdによってTPUワークロードのスケジューリングもサポートしており、GPU以外のアクセラレーターへの対応を示唆している。TPUはGPUとは異なるメモリ・通信アーキテクチャを持つため、llm-dがTPU上でもキャッシュルーティングや負荷分散を機能させられれば、ハードウェア選択の幅が大きく広がる意義がある。
ただし、DigitalOceanのParacha氏とIBMのPuri氏はその実現可能性に懐疑的だ。vLLMやSGLangといったコンポーネントは特定のハードウェア（TPU・Nvidia・AMD）向けに最適化されており、「現時点では相互互換性は高くない」とParacha氏は述べた。マルチチップ対応が真に実用化されるには、推論エンジン側との協調した標準化が不可欠と言えるだろう。
詳細はCNCF's llm-d 1.0 tackles high AI inference costsを参照していただきたい。
