llm-d：把 vLLM 與 SGLang 之上的推論編排層裝進 Kubernetes

llm-d 要解的不是模型跑不動，而是模型跑得起來卻撐不住

vLLM 與 SGLang 這一層解決的是「如何在加速器上有效率地執行大型語言模型」。llm-d 的 README 把自身定位在這一層之上：它提供的是 orchestration 與最佳化，用來服務高規模的真實流量。這個切分很重要，因為它決定了 llm-d 的失敗模式與模型伺服器完全不同。模型伺服器掛掉是推論中斷，llm-d 設定錯誤則是推論還在跑、只是跑得比預期慢，而且慢的原因藏在路由決策與快取命中率裡。

目標讀者是已經進入生產階段的平台團隊。README 反覆出現 production deployments、real-world benchmarks、well-tested guides 這類措辭，並列出 Red Hat、Google Cloud、IBM Research、CoreWeave、NVIDIA 為創始成員，專案本身是 CNCF sandbox。從 repository 的 primary language 是 Shell 可以看出，這個專案相當大一部分的內容是部署腳本與 Helm 疊層，而不是應用程式碼。

它處理的具體問題可以從四個主題反推：前綴快取感知的負載平衡、KV cache 的分層卸載、大型模型的 prefill/decode 拆解與 wide expert-parallelism、以及多租戶下的流量控制與 SLO 導向自動擴縮。這四件事在單一 vLLM 實例裡都做不了，因為它們本質上需要跨副本的全域視野。

從 Gateway API 到 KV cache：請求進入叢集之後走了哪條路

依 README 的描述，llm-d 的智能路由建立在 prefix-cache 與 load-aware balancing 之上，另外還有實驗性的 predicted latency-based scheduling。這意味著請求不是被隨機或輪詢地丟給某個推論 pod，而是先判斷這個請求的前綴是否已經存在某個副本的 KV cache 裡，再決定送往哪裡。輪詢在這裡是錯的，因為同一個前綴重新計算的成本遠高於把請求導向已經算過的副本。

進階 KV-Cache 管理則是把「有效工作集」放大。README 的說法是透過 tiered offloading 到 CPU 或 disk，加上對 KV cache 狀態的精確全域索引。這裡的關鍵詞是全域索引：如果沒有全域視野，卸載到 CPU 的快取對其他副本而言等於不存在，多輪對話的命中率就上不去。

大型模型的處理走另一條路。README 提到用 prefill/decode disaggregation 與 wide expert-parallelism 來服務 DeepSeek-R1、GPT-OSS 這類模型，並依賴快速加速器互連。拆解的邏輯是把計算特性差異極大的兩個階段放到不同的資源池：prefill 吃算力、decode 吃記憶體頻寬與延遲敏感度。README 引用的合作方部落格指出，在 NVIDIA B200 上對 GPT-OSS 使用拆解式推論可達最高 70% 的 tokens/sec 提升，在 AMD MI300X 上對 GPT-OSS-120B 與 Llama 3.3 70B 則為 10% 到 30%。這些數字來自合作方發布的評測，不是本站在受控環境重現的結果。

營運面則是 flow control 與 SLO-aware autoscaling，README 強調其依據是 real-time inference signals，而不是 CPU 或 GPU 使用率這類代理指標。

部署入口是 well-lit paths 與 Helm chart，不是單一 binary

README 沒有給出安裝指令，它把使用者導向 Quickstart Guide，並明確建議多數人從 Optimized Baseline 這條 well-lit path 開始。這是理解這個專案部署成本的第一個線索：llm-d 不是一個你 kubectl apply 完就結束的東西，而是一組經過驗證的配方。

README 對 well-lit path 的定義是 benchmarked recipes 加上 Helm charts，目的是讓使用者快速以生產常見的最佳實務開始服務。也就是說，部署單位是「路徑」而不是「元件」：你選定一條路徑，套用對應的 Helm chart，得到一組包含路由與模型伺服器設定的組合。v0.7 的 release note 提到 guides 遷移為 kustomize-first，這代表自訂部署的起點是 kustomize overlay，而不是直接改 chart 的 values。

驗證方式則指向 Prism，README 稱其為可重現的基準測試平台。對於需要說服內部採用的人來說，Prism 的意義大於 README 上的效能數字，因為它是你自己重跑一次的地方。

需要提醒的是，這份素材沒有提供具體的 Helm repo 位址、chart 名稱或 CRD 的欄位清單，因此無法在此列出可直接複製的安裝命令。實際的資源名稱與 config key 必須以 llm-d.ai 上的 Quickstart 與各條 well-lit path 頁面為準。

Shell 為主的 repository 意味著升級會踩到 YAML，而不是 API

repository 的 primary language 是 Shell，這件事對維護成本的影響比它看起來大。應用程式碼的升級通常有型別與編譯期保護，YAML 與腳本疊層的升級沒有。當 llm-d 從 v0.8.0 走到 v0.8.1 再走到 v0.9.0，變動可能落在 Gateway API 資源、InferencePool 這類自訂資源、或 Helm chart 的 values 結構上，而這些都不會有編譯器提醒你。

release 節奏可以從素材看出輪廓：v0.8.0 與 v0.8.1 相隔兩天，屬於修補；v0.9.0 與 v0.8.1 相隔約七週。對照 v0.7 的 release note 內容（optimized baseline 重新命名並穩定化、guides 遷移為 kustomize-first、nightly CI 擴展到 OpenShift、GKE、CoreWeave、predicted-latency scheduling 進入 GA、batch gateway 仍為實驗性），可以看出每個 minor 版本都同時動了部署介面與功能面。

這對維運的意涵是：你不能把 llm-d 當成安裝一次就放著的元件。升級前要對照該版本的 release note 逐項檢查 guides 的變更，特別是當你已經在 baseline 之上做了 kustomize overlay 的時候。nightly CI 覆蓋的三個環境是 OpenShift、GKE、CoreWeave，若你跑在別的地方，等於是在驗證覆蓋範圍之外。

授權是 Apache-2.0，README 亦標示 FOSSA 狀態。Apache-2.0 允許商業使用與修改，並包含專利授權條款；具體的合規義務（例如標示變更、保留聲明）應由法務確認，本文不提供法律意見。

它不是模型伺服器的替代品，也不適合小規模部署

最清楚的誤用是把 llm-d 當成 vLLM 的替代。README 的措辭是 llm-d 在 model servers 之上提供 orchestration，這表示 vLLM 或 SGLang 仍然是你實際跑模型的那一層。如果你移除模型伺服器只留 llm-d，得到的是一組沒有東西可以路由的路由器。

第二個誤用是規模不足時採用。llm-d 的主要價值來自跨副本的全域決策：前綴快取命中、KV cache 全域索引、prefill 與 decode 分池。當你只有一個推論副本，這些機制沒有可比較的對象，前綴感知路由退化為單點，分層卸載的收益也因為沒有其他副本競爭而改變性質。README 引用的 13.9 倍吞吐提升是在 4 張 NVIDIA H100、250 個並行使用者的條件下取得，這個數量級本身就是採用門檻的提示。

第三個限制來自硬體與模型的組合。README 的效能敘述分散在 AMD MI300X、NVIDIA B200、H100、H200、Intel XPU、Google TPU 等不同平台上，而這些是合作方各自在其硬體上得到的結果。well-lit path 的意義正是把「已驗證的組合」收斂成清單，清單外的組合不是不能跑，而是沒有經過同樣的驗證。

還有一個容易被忽略的失敗模式：predicted latency-based scheduling 在 v0.7 才進入 GA。在此之前它屬於實驗性功能，而 README 對其描述仍帶著 experimental 的語氣。如果你的延遲目標很緊，卻把排程策略押在這個機制上，等於把 SLO 綁在一個剛脫離實驗階段的元件。

與其自己寫一個前綴感知的負載平衡器

最直接的替代方案不是另一個專案，而是自己動手：在 vLLM 前面放一個標準的 Kubernetes Service 或 Ingress，用輪詢或最少連線數做分配。這個做法在單一模型、流量平穩、對話輪次短的情境下完全夠用，而且沒有任何額外的 CRD 要維護。

差別在於決策依據。輪詢與最少連線數看的是連線層的狀態，看不到某個副本的 KV cache 裡已經有什麼。llm-d 的 prefix-cache-aware routing 則是把快取狀態納入路由決策。README 引用 Tesla 與 Red Hat 的評測指出，在 4 張 AMD MI300X 上跑 Llama 3.1 70B 時，前綴快取感知路由相比輪詢可達 3 倍輸出吞吐與 2 倍更快的 TTFT。這個差距的來源不是模型跑得更快，而是重複計算被省掉了。

另一個方向是直接用模型伺服器內建的多副本能力，或使用 KServe 這類模型服務框架。README 引用的其中一篇部落格標題即為 KServe 與 llm-d、vLLM 的組合，這暗示兩者並非互斥：KServe 處理模型部署的生命週期，llm-d 處理推論流量的編排。如果你已經有 KServe，問題不是換掉它，而是判斷 llm-d 這一層是否值得加上去。判斷標準回到前面提過的規模門檻：多副本、多輪對話、長前綴重複率高，才有明顯差異。

批次推論是另一條路，但還在實驗階段

README 把 Batch Processing 列為五個核心主題之一（前四項為路由、KV cache、大型模型服務、營運），提供 OpenAI 相容的 Batch API 與非同步處理，用來提高硬體利用率。這條路徑的邏輯與線上服務相反：線上服務最佳化的是延遲，批次最佳化的是吞吐與利用率，因此對路由延遲的敏感度低得多。

但 v0.7 的 release note 把 batch gateway 標為 experimental。對於離線推論這種通常可以容忍重跑的工作負載，實驗性標籤的風險相對可控；但如果你的批次工作有嚴格的完成時限，這個標籤就必須納入評估。

值得一提的是，llm-d 把批次與線上服務放在同一個堆疊裡，意味著兩者可以共用同一組加速器資源。這是個有吸引力的設計，但也表示資源隔離要靠 Kubernetes 的排程與 llm-d 的 flow control 來達成，而不是靠實體隔離。多租戶環境下，這一點需要實測而不是假設。

編輯結論

llm-d 適合已經在 Kubernetes 上跑 vLLM 或 SGLang、而且流量規模足以讓路由與 KV cache 策略產生差異的團隊；如果你的推論服務只有單一模型副本、或團隊沒有能力維護 Gateway API 與 Helm 疊出來的 CRD 組合，直接使用模型伺服器自己的 serving 入口會更省事。採用前先確認三件事：你的加速器與模型組合是否落在 well-lit paths 已驗證的清單內、你的 Kubernetes 是否已具備 Gateway API 與對應的 InferencePool 資源、以及 nightly CI 覆蓋的 OpenShift、GKE、CoreWeave 三者中是否有你實際的執行環境。這三項若有一項落空，llm-d 帶來的調校成本會高於它省下的調校成本。

官方來源

1. License: Apache-2.0
2. llm-d/llm-d on GitHub
3. Project website
4. README
5. Releases