公開2026.08.10更新2026.10.24 Kubernetes・コンテナ

llm-dとは？1.0の新機能とKubernetes分散推論の仕組み・導入手順と採用判断【2026年10月】

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

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

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

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

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

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

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

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

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

CNCF公式ブログは2026年3月24日付で、llm-dのSandbox受け入れを公表しました。プロジェクト自体は2025年5月に始まり、寄贈の中心はRed Hat、Google Cloud、IBM Researchで、CoreWeaveとNVIDIAも創設メンバーです。参加企業にはAMD、Cisco、Hugging Face、Intel、Lambda、Mistral AI、大学パートナーとしてカリフォルニア大学バークレー校とシカゴ大学が挙がっています。1.0の発表時点では、コントリビューターは500名超、参加組織は25以上とされました。

読み方は二つあります。ハードウェアベンダーが競合同士で同席していることは、特定アクセラレータに寄せた実装になりにくい担保になる。一方で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の仕組みと他エンジンとの違いで整理しているため、本記事はクラスタ側の層に絞ります。

llm-d 1.0（2026年10月20日リリース）で追加された機能と移行時の注意

v0.10系から1.0への更新は、番号の繰り上げだけではありません。本番で複数チームが同じ基盤を共有する場面を想定した機能がまとめて入りました。内容はGitHubのv1.0.0リリースノートで確認できます。

マルチテナントのQoSを担うフロー制御と過負荷時の受け付け制御

1.0の目玉は、優先度と公平性を考慮したフロー制御です。有償プランのリクエストを優先し、飽和したときは低優先度の要求を保留または破棄して、上位のSLOを守る動きができます。過負荷時の受け付けには確率的な間引きや、エージェントの会話ターンに応じた優先度付けが加わりました。

Google Cloudの発表では、Mistral AIが商用ティアごとの優先度帯をこの仕組みで強制していると紹介されています。社内で複数部署が1つのGPUプールを共有する構成なら、部署単位のクォータと組み合わせて「バッチ処理が対話を押し出す」事故を防げる。設定は flowControl 配下に集約されたため、0.x系で書いた設定は移行時に見直しが要ります。

ルーターの冗長化とDisaggregatedSetによる無停止更新の仕組み

0.x系では、ルーター（EPP）自体が単一障害点になりやすい構成でした。1.0ではホットスタンバイによる高可用性が入り、ルーターの更新中もリクエストを受け続けられます。

もう一つがDisaggregatedSetです。プリフィル担当とデコード担当のプールを1つの論理単位として扱い、両者の比率を崩さずにローリング更新します。片側だけ先に新版へ入れ替わってKVの受け渡しが噛み合わなくなる、分離構成特有の更新事故を避ける仕組みです。土台はLeaderWorkerSetで、1.0のガイドはLeaderWorkerSet v0.11.1以上と、Helmの enableDisaggregatedSet=true 指定を前提にしています。Kubernetes標準の更新方式との違いはローリングアップデートの仕組みと設定値と比べると把握しやすくなります。

エージェント向けのセッション対応ルーティングとResponses API対応

コーディングエージェントのように、同じ会話を何十ターンも続ける用途向けの変更も入りました。セッションの状態を記録するプラグインとセッションアフィニティにより、次のターンを前回のコンテキストをキャッシュしているポッドへ寄せます。OpenAIのResponses APIで使う previous_response_id にも対応しました。

Google Cloudは、Ironwood（TPU 7x）上のエージェント型コーディング負荷で、プレフィックス対応ルーティングとホストメモリへのオフロードにより、素のKubernetes Service比で中央値TTFTを85%以上削減し、総スループットを2.4倍にしたと公表しています（2026年10月時点の同社測定）。比較対象が調整なしの構成である点は、後述の改善幅と同じ注意が要ります。

TPU・GKE統合の拡充と、ベンチマーク公開基盤Prismの使いどころ

Google Cloud側では、llm-dのルーターをマネージドで動かすGKE Inference Gatewayが1.0に対応し、TPUとGPUのノードプールを同じエンドポイントの背後に並べる構成が検証済みHelmチャートとして提供されています。PyTorchモデルを書き換えずにTPUで動かすTorchTPUとの統合も進みました。GKE自体の構成はGKEのAutopilot／Standardの違いと料金モデル、TPUの世代差と料金はTPUとGPU・CPUの違いとTorchTPU対応で扱っています。

公開ベンチマークを横並びで比べられるPrismも公開されました。自社のモデル規模とアクセラレータに近い構成の結果を先に見ておくと、検証で狙う改善幅の当たりを付けられます。ただし掲載値は各社の構成での測定なので、最終判断は自社の実プロンプトで取り直した数字で行ってください。

0.x系から1.0へのアップグレード時に確認する3つの変更点

リリースノートに「破壊的変更」の見出しはありませんが、既存環境で手を入れる箇所はあります。

LeaderWorkerSetをv0.11.1以上へ上げる。これ未満ではプリフィル・デコード分離のガイドがほぼ動かないと明記されています
フロー制御の設定を flowControl 配下へ移す
ルーター設定APIがv1へ昇格したため、独自に書いた設定ファイルの互換を確認する

AMD GPU向けの独自イメージ（llm-d-rocm）は非推奨となり、上流のvLLMイメージへ寄せる方針です。同梱されるvLLMのベースイメージはアクセラレータごとに版が異なるため、使うイメージのタグを個別に確かめてから上げてください。

ルーターと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を使い、1.0ではその上にDisaggregatedSetが載りました。自動スケーリングはHPAやKEDAに加え、Workload Variant Autoscalerという専用コントローラがVariant単位の増減を扱います。

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

llm-dは独自プロトコルではなく、Kubernetes Gateway APIの推論向け拡張（Gateway API Inference Extension）を実装しています。実務上の意味が大きい設計判断です。1.0のリリースノートでは、組み合わせる同拡張の版は1.6系と記載されています。

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

クイックスタートで検証クラスタにllm-dを入れて動かす手順

構造を理解したら、まず検証クラスタで動かして手触りを確かめるのが近道です。ここでは公式クイックスタート（2026年10月時点・release-1.0ブランチ）の流れを、実行順に並べます。既定ではNVIDIA GPU上のvLLMで Qwen/Qwen3-32B を2レプリカ起動します。

検証環境で必要な前提ツールとリポジトリ取得・環境変数の設定コマンド

手元に kubectl と helm、GPUノードを持つクラスタへの接続、Hugging Faceのアクセストークンを用意します。リポジトリを取得し、ガイドが参照する環境変数を読み込みます。

export branch="release-1.0"
git clone https://github.com/llm-d/llm-d.git && cd llm-d && git checkout ${branch}
export REPO_ROOT=$(realpath $(git rev-parse --show-toplevel))
source ${REPO_ROOT}/guides/env.sh
export GUIDE_NAME="quickstart"
export NAMESPACE=llm-d-quickstart

ルーター起動までに必要なCRD・名前空間・シークレットの作成手順

Gateway API Inference ExtensionのCRDを入れ、名前空間とトークンのシークレットを作ってから、ルーターをスタンドアロンモードでHelmから入れます。${GAIE_URL} や ${ROUTER_STANDALONE_CHART} は先ほど読み込んだ env.sh が設定します。

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/${GAIE_URL}/v1-manifests.yaml
kubectl create namespace ${NAMESPACE} --dry-run=client -o yaml | kubectl apply -f -

export HF_TOKEN=<Hugging Faceのトークン>
kubectl create secret generic llm-d-hf-token \
  --from-literal="HF_TOKEN=${HF_TOKEN}" \
  --namespace "${NAMESPACE}" \
  --dry-run=client -o yaml | kubectl apply -f -

helm install ${GUIDE_NAME} \
  ${ROUTER_STANDALONE_CHART} \
  -f guides/recipes/router/base.values.yaml \
  -f guides/optimized-baseline/router/optimized-baseline.values.yaml \
  -n ${NAMESPACE} --version ${ROUTER_CHART_VERSION}

モデルサーバを展開してOpenAI互換APIへテストリクエストを送る

モデルサーバ（vLLM）をKustomizeで展開し、ポッドの起動を待ってからクラスタ内の一時シェルで推論を投げます。

kubectl apply -n ${NAMESPACE} -k guides/optimized-baseline/modelserver/gpu/vllm/base/
bash ${REPO_ROOT}/guides/scripts/wait-for-pods-ready.sh -l llm-d.ai/guide=optimized-baseline -n ${NAMESPACE}

export IP=$(kubectl get service ${GUIDE_NAME}-epp -n ${NAMESPACE} -o jsonpath='{.spec.clusterIP}')
kubectl run curl-debug --rm -it \
  --image=cfmanteiga/alpine-bash-curl-jq \
  --namespace="$NAMESPACE" \
  --env="IP=$IP" \
  -- /bin/bash

# 一時シェルの中で実行
curl -X POST http://${IP}/v1/completions \
  -H 'Content-Type: application/json' \
  -d '{"model": "Qwen/Qwen3-32B", "prompt": "How are you today?"}' | jq

応答が返れば、ルーター経由でvLLMまでリクエストが届いた状態です。片付けは helm uninstall ${GUIDE_NAME} -n ${NAMESPACE} と名前空間の削除で済みます。この調整済みベースラインが、後述の導入ステップで「分離なしの構成」として比べる基準になります。32B級を2レプリカ載せるだけのGPUメモリが要るため、検証環境の手配はモデルを小さく差し替える前提で見積もってください。

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

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

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

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

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

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

同じシステムプロンプトを共有する社内アシスタントのような用途では、先頭数千トークンが毎回同一です。この部分のKVを計算済みのポッドへリクエストを寄せられれば、プリフィルの大半を省けます。llm-dはクラスタ全体のKVインデックスを持ち、EPPがそれを見て送り先を決めます。1.0の発表では、Snapがこの仕組みでプレフィックスキャッシュのヒット率を最大75〜80%まで上げたと紹介されました。

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

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

GPUメモリは有限で、KVが乗り切らないと同時実行数を絞るか、捨てて再計算するかの二択になります。llm-dはGPU、CPU、ディスクの階層へKVを段階的に退避させる経路を持ちます。1.0時点では、vLLMのOffloadingConnector、Mooncake、SGLangのHiCacheを使い、アクセラレータメモリ、ホストメモリ、SSDや共有ファイルシステムの順に退避させる構成です。

退避先が遅いほど読み戻しコストは上がりますが、再計算より安く済む領域があります。長いコンテキストを何度も参照する用途では効き、短文を大量にさばく用途では効果が薄い。Google Cloudは70B級モデル・入力5万トークンの条件で、ホストメモリだけに退避する構成よりManaged Lustreを加えた多層構成のほうがTTFTを約40%改善したと公表しています。NVMe SSDのランダム読み出し性能や共有ストレージの帯域が効くため、GPUノードのストレージ構成も設計要素になります。

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

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

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

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割以上埋められないなら、自前運用は割高になりやすい。

観点	llm-d＋自前GPU	vLLM単体	マネージドAPI
課金	GPU時間課金	GPU時間課金	トークン課金
低稼働時	割高	割高	安い
高稼働時	安くなりやすい	中間	割高
データの所在	自社クラスタ内	自社クラスタ内	外部事業者
運用対象	K8s＋GW＋エンジン	エンジンのみ	ほぼなし
スケール上限	ノード追加で拡張	1ノード	事業者の枠
優先度制御	1.0で標準搭載	自前で実装	契約プラン次第

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

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

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

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

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

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

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

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

単一ノードのvLLMでベースラインを測る。ここでのTTFT・スループット・GPU使用率が、以降すべての比較基準になります
検証クラスタにGateway実装とInferencePoolを入れ、分離なしの構成で同じ負荷をかけて劣化がないか確認する（前章のクイックスタートがこの段階に当たります）
プレフィックスキャッシュ対応ルーティングを有効化し、自社の実プロンプトでキャッシュヒット率を測る
ヒット率が想定に届いた場合のみ、プリフィルとデコードの分離へ進む。1.0ではDisaggregatedSetで両プールを一体管理する
複数の利用部署やプランが同じ基盤に乗るなら、フロー制御で優先度を設定する
本番へは既存経路を残した二系統で入れ、トラフィックを段階的に寄せる

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を追加調達できないなら、分離なしのベースラインとプレフィックスキャッシュ対応ルーティングだけに絞る判断が妥当です。

1.0系という成熟度の受け止め方と、運用条件で採用可否を分ける線引き

2026年10月時点でリリースタグはv1.0.0、CNCFの区分はSandboxです。GitHubのリリース履歴では、6月下旬のv0.8、8月中旬のv0.9、9月下旬のv0.10を経て、約4か月で1.0に達しました。ルーター設定APIがv1へ昇格したことで、マイナー更新のたびに構成の書き方が変わるリスクは0.x系より下がっています。それでもCNCFの成熟度審査は済んでおらず、実運用ではバージョン固定とアップグレード検証の工数を最初から見込んでおく必要があります。

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

よくある質問

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

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

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

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

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

llm-d 1.0になって本番で使える段階になりましたか？

条件付きで前進しました。1.0でルーター設定APIがv1に昇格し、ルーターの冗長化とDisaggregatedSetによる無停止更新が入ったため、0.x系で懸念だった設定の変わりやすさと単一障害点は軽くなっています。一方、CNCFの区分は2026年10月時点でSandboxのままです。社内向けや二系統で切り戻せる構成なら本番投入を検討してよく、外部サービスの唯一の推論経路にするのは運用実績が積み上がってからが無難です。

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

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

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

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