llm-d/llm-d とは何ですか？

vLLM や SGLang の上に載るルーティング、KV キャッシュ、prefill/decode 分離のレイヤーを、Apache-2.0 の CNCF サンドボックスプロジェクトとして読む。導入判断で確認すべき境界線を整理する。

llm-d/llm-d は商用利用できますか？

できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。

llm-d/llm-d は今もメンテナンスされていますか？

されています。直近 1 日以内に新しいコミットがあります。

llm-d/llm-d はどのプログラミング言語で書かれていますか？

主に Shell です（GitHub の言語統計による）。

llm-d レビュー: Kubernetes 分散推論スタックの仕組みと採用判断

ひと目でわかる

これは何？: vLLM や SGLang の上に載るルーティング、KV キャッシュ、prefill/decode 分離のレイヤーを、Apache-2.0 の CNCF サンドボックスプロジェクトとして読む。導入判断で確認すべき境界線を整理する。
誰に向いている？: 採用すべきなのは、すでに Kubernetes 上で vLLM か SGLang を動かしていて、単一レプリカでは足りないマルチターン会話や大規模モデルを扱うチームである。逆に、単一 GPU で完結する小規模サービスや、Kubernetes を運用していない環境では、llm-d が持ち込む調整対象のほうがコストになる。
商用利用できる？: できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
今もメンテナンスされている？: されています。直近 1 日以内に新しいコミットがあります。
何の言語で書かれている？: 主に Shell です（GitHub の言語統計による）。

回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Hysen Labs 編集部 · 2026年9月10日 · llm-d/llm-d

モデルサーバーの上に何を足すのか

llm-d はモデルサーバーではない。README は vLLM と SGLang を「アクセラレータ上で大規模言語モデルを効率よく動かす」役割として位置づけ、llm-d 自身はその上に載るオーケストレーションと最適化だと説明している。つまりモデルの重みを読み込む層でも、カーネルを書く層でもない。対象読者は、すでに vLLM か SGLang を Kubernetes で動かしていて、レプリカを増やした瞬間にリクエストの振り分けと KV キャッシュの一貫性が問題になり始めた運用者である。単一プロセスで収まっている段階では、llm-d が提供するものの大半は使わない。

Intelligent Routing が振り分けの判断材料にするもの

README が挙げる四つの柱のうち最初が Intelligent Routing で、prefix-cache と負荷を考慮したバランシング、さらに実験段階の予測レイテンシに基づくスケジューリングが含まれる。round-robin との違いは、各レプリカがどのプレフィックスの KV キャッシュをすでに保持しているかをルーティングの入力にすることだ。同じシステムプロンプトや同じ会話履歴を繰り返し送るマルチターンのトラフィックでは、キャッシュが当たるレプリカへ寄せるだけで prefill の計算が消える。README は Llama 3.1 70B を 4× AMD MI300X で動かした Tesla と Red Hat のブログとして、round-robin 比で出力スループット 3 倍、TTFT 2 倍高速という数値を引用している。ただしこれは特定のモデル、特定のハードウェア、特定のトラフィック形状での結果であり、自分のワークロードで同じ比率が出る保証はどこにもない。

KV キャッシュを GPU の外へ出す設計と、その代償

二つ目の柱は Advanced KV-Cache Management で、CPU やディスクへの段階的なオフロードと、KV キャッシュ状態のグローバルな索引付けを組み合わせる。GPU メモリに載りきらない履歴を外部に逃がしつつ、どのレプリカのどこに何があるかをルーターが把握できるようにする、というのが狙いだ。README は 4× NVIDIA H100 で同時 250 ユーザーの階層型 KV オフロードが GPU のみの場合より 13.9 倍のスループットになったというブログを引用している。数字だけを見ると魅力的だが、この構成はノードの CPU メモリとディスク帯域を推論の一部として使う。オフロード先が遅ければ、キャッシュミスより遅い経路をわざわざ通ることになる。tiered なオフロードは、ホスト側のリソースを推論用に確保できるクラスタでだけ意味を持つ。

prefill/decode 分離と Wide Expert-Parallelism の前提条件

三つ目の柱は Serving Large Models で、prefill と decode を別々のワーカーに分ける構成と、高速なアクセラレータ間インターコネクト上での wide expert-parallelism が中身になる。README は DeepSeek-R1 や GPT-OSS のような大規模モデルを対象として挙げ、GPT-OSS を NVIDIA B200 で動かした AWS のブログとして標準 vLLM 比で最大 70% 高い tokens/sec、AMD MI300X 上の GPT-OSS-120B と Llama 3.3 70B で同一インフラ上の分離サービングが 10〜30% のスループット改善、という Oracle のブログも引用している。ここで見落とせないのは、分離も wide-EP もインターコネクト性能に強く依存する点だ。PCIe 接続の GPU しか持たないノードで同じ構成を組んでも、分離のオーバーヘッドが利得を食う可能性が高い。README が示すのは B200 や MI300X の構成であり、汎用の GPU ノードで再現する話ではない。

導入手順と、最初に触る設定

README は Quickstart Guide を最初の入口として案内し、多くの利用者には Optimized Baseline から始めることを勧めている。well-lit paths の各ガイドにはベンチマーク済みのレシピと Helm チャートが付属し、そこから serving を立ち上げる流れになっている。v0.7 のリリースノートによれば、ガイドは kustomize を第一とする形に移行し、optimized baseline は改名のうえ安定化された。つまりマニフェストの適用経路は kustomize と Helm の両方が関与し、バージョンによって推奨が変わる。導入時に確認すべきは、対象モデルとアクセラレータの組み合わせに対応する well-lit path が存在するかどうかだ。存在しない組み合わせでは、チャートのパラメータを自分で埋める作業が発生する。なお README のバッジは Version 0.8 を示しているが、リリース一覧には v0.9.0 が 2026-08-17 付で存在する。バッジとリリースの記載が一致していない点は、導入前に自分で確認したほうがよい。

向かないケース: 単一レプリカと Kubernetes 外の運用

llm-d が効くのは、リクエストを複数のレプリカに分ける必要があり、かつその分け方に意味が出る規模のときだ。逆に、モデルが 1 GPU に収まり、同時リクエスト数も少なく、レイテンシの内訳で prefill が支配的でないなら、ルーターを挟むこと自体がホップを増やす。Kubernetes を使っていない環境も同様で、このプロジェクトの成果物は Helm チャートと Kubernetes のマニフェストとして配布されるため、素の docker compose や systemd の上に持ってくる道は用意されていない。もう一点、Batch Processing は README 上で OpenAI 互換の Batch API と非同期処理として説明されているが、v0.7 のリリースノートでは batch gateway が experimental と明記されている。オフライン推論の本番経路として当てにするなら、experimental の表記が外れるまで待つ判断もある。

vLLM Production Stack との設計差

比較対象として素直なのは vLLM Production Stack である。あちらは vLLM をそのまま Kubernetes に配るためのルーターと Helm チャートを中心に据え、モデルサーバー側の変更を最小限に保つ。llm-d はモデルサーバーの外側に置く層を厚くし、prefix-cache の索引、階層型 KV オフロード、prefill/decode 分離、予測レイテンシに基づくスケジューリングまでを自らの責務に含める。差が出るのは、KV キャッシュの状態をルーターがどこまで知る必要があるかという点だ。キャッシュの所在をルーティングに使わないなら、llm-d の主要な利得の一部は最初から対象外になる。逆に、マルチターンで同じプレフィックスを繰り返し送るトラフィックが中心なら、この差がそのまま効いてくる。どちらを選ぶかは、モデルサーバーの設定を触りたくないか、外側のオーケストレーションに設定を寄せたいかで決まる。

Apache-2.0 とメンテナンスの読み方

ライセンスは Apache-2.0 で、リポジトリの LICENSE に準拠する。CNCF のサンドボックスプロジェクトであり、Red Hat、Google Cloud、IBM Research、CoreWeave、NVIDIA が創設に関与し、AMD、Cisco、Hugging Face、Intel、Lambda、Mistral AI などが支援を表明していると README は記載している。ただしサンドボックスは成熟度の段階を示す区分であり、API の安定性を保証するものではない。実際、v0.7 で optimized baseline の改名と kustomize 優先への移行が行われており、ガイドの構成はバージョン間で動く。アップグレードのコストは、チャートの値と kustomize のオーバーレイを追従させる作業として現れる。nightly CI が OpenShift、GKE、CoreWeave で回っているとリリースノートは述べているが、自クラスタのディストリビューションがその対象に入っているかは別に確認する必要がある。ライセンス条項の解釈については、ここでは法的助言はできない。

編集部の結論

採用すべきなのは、すでに Kubernetes 上で vLLM か SGLang を動かしていて、単一レプリカでは足りないマルチターン会話や大規模モデルを扱うチームである。逆に、単一 GPU で完結する小規模サービスや、Kubernetes を運用していない環境では、llm-d が持ち込む調整対象のほうがコストになる。導入前に確認するのは、well-lit paths の中に対象モデルとアクセラレータの組み合わせが存在するか、Helm チャートが要求する CRD と Kubernetes のバージョンが自クラスタで満たせるか、そして KV キャッシュのオフロード先に使う CPU メモリとディスクをノードに確保できるか。この三つが揃わない限り、optimized baseline の再現から始めても自環境の数値にはならない。

公式情報源

コミュニティノート