llm-dとは？Kubernetesネイティブ分散推論の仕組みと採用判断を実装者目線で解説

GPUを1枚積んだノードでvLLMを起動するところまでは、多くのチームがすでに通過しています。詰まるのはその次で、ポッドを横に並べてもKVキャッシュが分断されてスループットが伸びない。llm-dは、この「単一ノード向けの推論エンジンをクラスタ全体で1つの基盤として動かす」層を埋めるオープンソースのスタックです。2026年3月にCNCF Sandboxへ採択され、Red Hat・Google Cloud・IBM Researchらが共同で寄贈しました。この記事では内部構造、プリフィルとデコードを分ける仕組みが効く条件、vLLM単体やマネージド推論APIとの費用差、導入を見送るべき規模条件までを整理します。

まとめ：llm-dの採用条件とvLLM単体で足りる分岐点

• llm-dの正体：推論エンジンそのものではなく、vLLMやSGLangをクラスタ横断で束ねるオーケストレーション層です
• 効く条件：GPUノードが複数あり、同時リクエストが常時発生し、プロンプトの共通部分が長い環境。三つ揃って利得が出ます
• 効かない条件：GPU1〜2枚で収まる負荷、散発的なリクエスト、短い共通プレフィックス。vLLM単体が総コストで勝ちます
• 導入の重さ：Kubernetes、Gateway API、GPUスケジューリング、推論エンジン調整の4領域が同時に要ります
• 成熟度：2026年8月時点でv0.8系・CNCFの区分はSandbox。切り戻し先を残した二系統構成で始める判断が妥当です
• マネージドとの比較：逆転するのは、GPUを常時埋められる稼働率と、外部へデータを出せない機密要件がある場合です

llm-dの定義とCNCF Sandbox採択までの経緯・立ち位置の整理

vLLMやllama.cppと同じレイヤの製品だと誤解されやすいプロジェクトですが、実際には一段上の層にあります。

Kubernetesネイティブな分散推論スタックという位置づけ

公式サイトはllm-dを「an open-source, Kubernetes-native stack for distributed LLM inference」と定義しています。単一ノードで完結する推論エンジンを、Kubernetesのスケジューリングとサービス機構に載せて本番運用できる形にする部品群です。

対応するアクセラレータは、2026年8月時点の公式記載でGPU、Google TPU、Intel XPU、CPU、新興のNPUまで含みます。特定ベンダーのランタイムに縛られない設計が、CNCFへ寄贈された理由の一つでもある。公式は推奨構成を「well-lit path」と呼び、調整済みベースライン、予測レイテンシによるルーティング、プレフィックスキャッシュ対応ルーティング、階層プレフィックスキャッシュ、プリフィルとデコードの分離、MoE向けWide Expert Parallelism、フロー制御、InferencePoolの自動スケーリングの8本を挙げています。全部を一度に入れる前提ではなく、必要な経路だけ選んで積む構成です。

2026年3月のCNCF Sandbox採択と寄贈元・参加企業の顔ぶれ

CNCF公式ブログは2026年3月24日付で、llm-dのSandbox受け入れを公表しました。寄贈の中心はRed Hat、Google Cloud、IBM Researchで、CoreWeaveとNVIDIAも創設メンバーです。参加企業にはAMD、Cisco、Hugging Face、Intel、Lambda、Mistral AI、大学パートナーとしてカリフォルニア大学バークレー校とシカゴ大学が挙がっています。

読み方は二つあります。ハードウェアベンダーが競合同士で同席していることは、特定アクセラレータに寄せた実装になりにくい担保になる。一方でSandboxはCNCFの成熟度区分で最も手前の段階で、Incubating・Graduatedのような運用実績の審査は通っていません。「CNCFプロジェクトである」ことと「本番で枯れている」ことを同一視しない扱いが要ります。ライセンスはApache License 2.0です。

vLLMなど推論エンジンが担う範囲とllm-dが担う範囲の境界

vLLMは1プロセス内でPagedAttentionによるKV管理と連続バッチングを担い、GPUメモリを使い切ることに責任を持ちます。llm-dはその外側で、どのポッドへ送るか、プリフィル担当とデコード担当をどう分けるか、KVインデックスをクラスタ横断でどう共有するかを決めます。役割が重なりません。

「vLLMからllm-dへ乗り換える」という言い方は成立しません。llm-dの下ではvLLMかSGLangがモデルサーバとして動き続けます。エンジン側の内部構造はvLLMのPagedAttentionの仕組みと他エンジンとの違いで整理しているため、本記事はクラスタ側の層に絞ります。

ルーターとInferencePoolで構成される内部アーキテクチャ

構成要素は多くありません。ルーター、InferencePool、モデルサーバの三つで全体像がつかめます。

ProxyとEndpoint Picker（EPP）が分担するルーティング処理

ルーターは2つのコンポーネントに分かれます。前段のProxyは通常Envoyで、L7のリクエスト受付とルーティングの実行を担う。後段のEndpoint Picker（EPP）が判断側で、各ポッドのリアルタイムメトリクスとKVキャッシュの保持状況をスコアリングし、送り先をProxyに返します。

この分離が効くのは、LLM推論のリクエストが通常のHTTPリクエストと性質が違うからです。処理時間がプロンプト長と生成長で二桁変わり、同じポッドに送れば速いケースと、空いているポッドに送るべきケースが混在します。ラウンドロビンや最小接続数では判断材料が足りません。EPPはXGBoostモデルでITL（トークン間レイテンシ）とTTFT（初回トークン到達時間）を予測する拡張も持ちます。

InferencePoolとVariantで役割別にポッドを束ねる設計

InferencePoolは、同じベースモデルを提供するモデルサーバポッドをまとめた論理単位です。Kubernetesの標準Serviceが「同じコンテナイメージのポッド群」を束ねるのに対し、InferencePoolは「同じモデルを提供する群」を束ねます。

その内側にあるのがVariantで、ポッドラベルで表現されるサブグループです。プリフィル担当とデコード担当を分けるとき、高性能なノードと廉価なノードを混ぜるときに、この単位で区別する。マルチノードにまたがる1モデルの配置にはKubernetesのLeaderWorkerSetを使います。自動スケーリングはHPAやKEDAに加え、Workload Variant Autoscalerという専用コントローラがVariant単位の増減を扱います。

Gateway API Inference Extension実装が持つ互換性の意味

llm-dは独自プロトコルではなく、Kubernetes Gateway APIの推論向け拡張（Gateway API Inference Extension）を実装しています。実務上の意味が大きい設計判断です。

証明書管理やトラフィック分割など、既存のGateway API準拠の設定がそのまま推論トラフィックにも効きます。将来llm-d以外の実装へ移る場合も、リソース定義の互換性が残る可能性が高いでしょう。社内基盤がまだIngressベースなら、llm-dの前にGateway APIへの移行が先に来ます。

Prefill/Decode分離と階層KVキャッシュが効く条件

速さを稼ぐ仕掛けは配置とキャッシュの2系統で、効く条件がはっきり分かれます。

プリフィルとデコードを別ポッドに分ける仕組みとスケール単位の変化

LLMの推論は性質の異なる2段階でできています。プロンプト全体を読み込むプリフィルは計算量が支配的で、GPUの演算器を使い切ります。1トークンずつ生成するデコードはメモリ帯域が支配的で、演算器は余る。同じポッドで両方を回すと、どちらかの資源が常に遊びます。

llm-dは両者を別のポッド、別のVariantとして配置し、独立にスケールさせます。長文の要約が多い用途ならプリフィル側を厚く、生成が長い用途ならデコード側を厚くできる。Red Hat Developerの解説記事（2025年11月時点）は、既定設定のまま分けるだけでも概ね25%の改善が出ると記載しています。ただし分離はポッド間のKV転送を新たに生むため、ノード間ネットワークが細いクラスタでは利得が相殺されます。

プレフィックスキャッシュ対応ルーティングとKVインデックスの働き

同じシステムプロンプトを共有する社内アシスタントのような用途では、先頭数千トークンが毎回同一です。この部分のKVを計算済みのポッドへリクエストを寄せられれば、プリフィルの大半を省けます。llm-dはクラスタ全体のKVインデックスを持ち、EPPがそれを見て送り先を決めます。

効き方はプロンプト構造に強く依存します。共通プレフィックスが2,000トークンあり生成が200トークンの用途なら大きく効きますが、毎回異なる短文が飛ぶ用途ではインデックス管理の負荷だけが残る。導入判断の前に、プロンプト先頭がどれだけ共通しているかを実測してください。KVキャッシュ自体の仕組みはKVキャッシュがLLM推論を高速化する仕組みで扱っています。

CPU・ディスクへの階層KVオフロードで変わるバッチ許容量の上限

GPUメモリは有限で、KVが乗り切らないと同時実行数を絞るか、捨てて再計算するかの二択になります。llm-dはGPU、CPU、ディスクの階層へKVを段階的に退避させる経路を持ちます。

退避先が遅いほど読み戻しコストは上がりますが、再計算より安く済む領域があります。長いコンテキストを何度も参照する用途では効き、短文を大量にさばく用途では効果が薄い。NVMe SSDのランダム読み出し性能が効くため、GPUノードのローカルストレージ構成も設計要素になります。

公式が公表する改善幅と、そのまま自社に当てはめられない前提条件

公式サイトはoutput throughput 3倍、TTFT 2倍、tokens/sec最大70%向上、throughput 30%改善といった数値を掲げています。これらは構成・モデル・ワークロードごとの個別測定であり、単一環境で全部が同時に出るわけではありません。

確認すべき前提は三つ。モデル規模（多くは大規模MoEや70B級で、7B級では分散の利得が縮む）、同時リクエスト数（低負荷ではオーバーヘッドが勝つ）、ノード間の接続方式です。比較対象が素のKubernetes Service＋vLLMである点も見落とされがちで、調整済みの単一ノード構成と比べた差はこれより小さくなります。

vLLM単体・マネージド推論APIとの費用・運用負荷・機密要件の比較

動くかどうかより、費用と運用負荷で決まる判断です。三択の分岐点を水準で示します。

vLLM単体で足りる規模と、llm-dが効き始めるトラフィック水準

GPUが1枚、あるいは1ノードに収まる範囲なら、llm-dを入れる理由はほぼありません。分散の対象がないからです。ポッドを2〜3個に増やす段階でも、単純なServiceによる負荷分散で足ります。

効き始めるのは、GPUノードが4台以上あり、ピーク時に全ノードが埋まり、プロンプトの共通部分が長い環境です。この水準に届かないうちに導入すると、Envoy、EPP、InferencePool、Variantと監視対象が増えるだけで、レイテンシは逆に悪化する。基盤選定そのものはLLM推論の仕組みと推論基盤の選び方を先に読むと、llm-dの位置が把握しやすくなります。

TensorRT-LLMやSGLangなどエンジン側の改善策との併用関係

速度を上げる手段はクラスタ層だけではありません。量子化、投機的デコーディング、カーネル改善といったノード内の手段が、投資対効果で先に来る場合が多くあります。

まずエンジン単体でGPUを使い切れているかを確認し、足りないときにクラスタ層へ進むのが安全です。NVIDIA GPUに寄せた構成ならTensorRT-LLMによる推論高速化の仕組みと採用判断で扱った手段が先行候補になる。llm-dの下でvLLMやSGLangを動かす限り、エンジン側の改善はそのまま乗ります。

マネージド推論APIと自前運用のコスト構造・機密要件の分岐点

自前運用はGPUの時間課金、マネージドAPIはトークン課金で、損益分岐は稼働率で決まります。GPUを常時7割以上埋められないなら、自前運用は割高になりやすい。

数字が拮抗する場合、判断を分けるのは機密要件です。学習データへの二次利用を許容できない情報や、国内保管が契約で求められる情報を扱うなら、稼働率に関係なく自前運用側に倒れます。機密制約がなく稼働率も読めないなら、マネージドAPIで始めて実績が積み上がってから移す順序が無駄になりません。

導入前提となるクラスタ要件・必要スキルと運用コストの実務見積り

難所はllm-d自体の設定ではなく、その手前で要求される基盤の状態です。

必要となるKubernetes構成要素とアクセラレータ側の要件

前提となるのは、稼働中のKubernetesクラスタ、Gateway API Inference Extension対応のGateway実装（EnvoyベースのProxy）、GPUをスケジューリングできるデバイスプラグイン、モデル配布に耐えるストレージ帯域です。マルチノードで1モデルを動かすならLeaderWorkerSetのCRDも入ります。

アクセラレータ側では、プリフィルとデコードを分ける構成でノード間のKV転送が発生するため、汎用のクラウドVMネットワークでは帯域が律速になることがあります。分離構成を本気で使うなら、高帯域のノード間接続を持つインスタンスタイプを選ぶか、まずは分離なしのベースラインから始める判断になる。CNCFはクラスタ側にAI向け要件を定義した認証制度も設けており、自社基盤の水準確認に使えます。

検証クラスタから本番移行までの導入ステップと各段階での確認事項

いきなり本番クラスタへ入れる進め方は手戻りが大きくなります。

1. 単一ノードのvLLMでベースラインを測る。ここでのTTFT・スループット・GPU使用率が、以降すべての比較基準になります
2. 検証クラスタにGateway実装とInferencePoolを入れ、分離なしの構成で同じ負荷をかけて劣化がないか確認する
3. プレフィックスキャッシュ対応ルーティングを有効化し、自社の実プロンプトでキャッシュヒット率を測る
4. ヒット率が想定に届いた場合のみ、プリフィルとデコードの分離へ進む
5. 本番へは既存経路を残した二系統で入れ、トラフィックを段階的に寄せる

3のヒット率が想定を下回った時点で撤退するのが、この手順の要点です。利得の相当部分がキャッシュ再利用に依存するため、ここが伸びない環境では4以降へ進んでも投資は回収できません。

運用に必要なスキルセットと、社内に足りない場合の体制の埋め方

要求されるのは、Kubernetesの運用、Gateway APIとEnvoyの設定、GPUノードのスケジューリングとドライバ管理、推論エンジンの調整という4領域です。1人で全部を持つ人材は多くありません。実務では基盤側とモデル側で2名以上が現実的な最小構成になります。

社内にKubernetesのGPU運用経験がないまま始めると、llm-dの問題なのかクラスタの問題なのか切り分けられず、障害対応が長引く。GPUノードを含むクラスタ設計から運用移管までを外部と組む選択肢もあり、当社ではAWS・Google Cloud・Azureのインフラ構築として推論基盤の設計・構築を受託しています。初期構築だけ外部に出し、運用は内製へ引き継ぐ進め方も取れます。

llm-dを採用しない方がよい条件と、導入前に潰しておく前提

以下に当てはまるなら、llm-dの導入は先送りしたほうが総コストで有利です。

単一ノードで収まる負荷にllm-dを載せると過剰になる境界線

同時リクエストがピークでも10件に届かず、GPUが1〜2枚で足りているなら、llm-dは過剰です。増える運用対象は、Envoy、EPP、InferencePoolとVariantの定義、KVインデックスとその監視項目。得られるのは、使い切れていないGPU間の負荷分散だけになります。

この規模で速度に不満があるなら、原因はモデルサイズか量子化設定にあることがほとんどです。まずGPU使用率を確認し、80%に届かないならそこを埋める調整が先に来ます。

GPU台数とノード間ネットワークが足りないまま導入して失敗する型

よくある失敗が、GPUノードを2台しか持たない状態で分離を有効化するケースです。片方1台ずつになるため、どちらかが詰まると全体が止まる。冗長性が消え、可用性は分離前より下がります。

もう一つが、ノード間が汎用のネットワークしかないクラスタでの分離構成です。KV転送が経路上で待たされ、分離で稼いだ計算効率を通信遅延が食う。この2つは設定ではなく前提の問題なので、チューニングでは解けません。GPUを追加調達できないなら、分離なしのベースラインとプレフィックスキャッシュ対応ルーティングだけに絞る判断が妥当です。

v0.8系という成熟度の受け止め方と、採用可否を分ける線引き

2026年8月時点でリリースタグはv0.8.1、CNCFの区分はSandboxです。メジャーバージョンに到達しておらず、マイナー更新で構成の書き方が変わる可能性が残ります。実運用では、バージョン固定とアップグレード検証の工数を最初から見込んでおく必要があります。

とはいえ、寄贈元がRed Hat・Google Cloud・IBM Researchで、参加企業に主要なアクセラレータベンダーが揃う状況は、放棄リスクの点では軽い部類でしょう。線引きの目安はこうなります。社内向けアシスタントや検証段階のプロダクトなら採用してよい。停止が売上に直結する外部サービスの唯一の推論経路にするのは見送る。二系統で切り戻し先を残せるなら、後者でも試す価値はあります。

よくある質問

判断が分かれやすい論点を5つに絞って答えます。

llm-dはvLLMの代わりに使うものですか？

代替ではありません。llm-dはvLLMやSGLangを下位のモデルサーバとして置き、その上でルーティングとポッド配置を担う層です。導入してもvLLMは動き続けます。比較すべきなのは「vLLM単体構成」と「llm-d＋vLLM構成」で、両者を直接並べる形にはなりません。エンジン側の改善とクラスタ側の分散は並行して効きます。

llm-dはGPUが1枚でも動きますか？

技術的には動きますが、利点はほとんど得られません。中核の機能は複数ポッド間のルーティング、プリフィルとデコードの分離配置、クラスタ横断のKV共有で、いずれも分散先がなければ働きません。GPU1枚ならvLLM単体で起動し、量子化や連続バッチングの設定を詰めるほうが効きます。GPUノードが4台以上になってから検討する順序を勧めます。

llm-dの導入にKubernetesの知識はどれくらい必要ですか？

CRDの追加、Gateway実装の設定、GPUデバイスプラグインの管理、ポッドのラベル設計まで自力で扱える水準が要ります。マネージドKubernetesでも、この部分は利用者側の責任範囲に残る。加えてEnvoyの挙動理解と推論エンジンの調整が必要です。本番運用の経験がないチームが最初の題材に選ぶ対象ではありません。

llm-dはOpenAI互換APIとして呼び出せますか？

モデルサーバとして動くvLLMがOpenAI互換のエンドポイントを提供し、llm-dはその前段にゲートウェイを置く構成のため、呼び出し方は基本的に変わりません（2026年8月時点の公式ドキュメントの構成）。既存のOpenAI SDKからは接続先URLの差し替えで移行できる想定です。ルーティング用の拡張ヘッダなど固有の要素を使う場合は個別対応が入ります。

llm-dとKServeはどちらを選べばよいですか？

択一ではありません。KServeはモデルのデプロイやバージョン管理を扱う上位のコントロールプレーンで、llm-dはその下でLLM特有の分散配置とルーティングを担う層です。公式もllm-dを「KServeのような上位コントロールプレーンと、vLLMのような下位エンジンの間を埋めるもの」と位置づけています。KServeで運用中なら、置き換えではなく下層に足す検討になります。

関連記事

• vLLMとは？仕組みと他エンジンとの違い：llm-dの下で動くモデルサーバ側の内部構造
• LLM推論とは？高速化の手法と基盤の選び方：選択肢を横並びで比較したい場合の総論
• KVキャッシュとは？仕組みとメモリ削減：階層オフロードの前提になるKVの解説
• Kubernetes AI Conformanceとは？：llm-dを載せるクラスタ側が満たすべき要件
• Text Generation Inference（TGI）とは？：モデルサーバ乗り換え時の判断材料