前言¶
2026 年，大模型推理早已不是「起一個 Deployment、掛一個 Service」就能收工的事。Prefill 與 Decode 兩階段特性不同、KV Cache 佔用隨上下文長度動態變化、多模型與 LoRA 並存——這些現實讓傳統 Round-Robin 負載均衡在 GPU 集羣裏頻繁出現「有的卡空轉、有的卡排隊」的窘境。
雲原生社區給出的方向很明確：把 LLM 推理當作 Kubernetes 的一等公民來調度。CNCF 旗下 Volcano 社區在 2026 年 1 月發佈了 Kthena；NVIDIA 則在 2025 年 11 月開源 Grove，並與 KAI Scheduler 形成互補。與此同時，CNCF Sandbox 項目 KAITO 也在持續演進，三者在「模型部署—流量路由—GPU gang 調度」各層各守其位，平臺工程團隊終於有機會用聲明式 YAML 搭出一套統一的 K8s AI 基礎設施層。
本文基於官方博客與 GitHub 倉庫交叉覈實，梳理這條生態鏈各自解決什麼問題、如何協同，以及落地時值得關注的細節。
爲什麼 K8s 上的 LLM 推理調度這麼難¶
在深入具體項目之前，先把痛點說清楚。根據 CNCF 對 Kthena 的介紹，生產級 LLM Serving 至少面臨四類挑戰：
- 資源利用率低：KV Cache 的動態內存佔用讓 GPU/NPU 壓力波動很大，傳統負載均衡感知不到這些特徵，容易造成資源碎片與請求排隊並存。
- 延遲與吞吐的權衡：推理分 Prefill（計算密集）和 Decode（內存帶寬受限）兩階段，耦合調度難以分別優化；業界普遍採用 Prefill-Decode（PD）分離，但路由與調度仍復雜。
- 多模型管理困難：企業往往同時服務多個模型版本、LoRA 適配器，公平調度、優先級與動態路由很難在一套網關裏統一表達。
- 與 K8s 生態脫節：不少方案是獨立系統，運維團隊需要額外維護一套控制面。
這四個問題，恰好對應了 Kthena（路由與編排）、Grove（多組件生命週期）、KAI Scheduler（GPU gang 與拓撲感知）各自的主戰場。
Kthena：Volcano 生態裏的推理「智能大腦」¶
Kthena 是 Volcano 的子項目，定位爲 Kubernetes 原生的 LLM 推理路由、編排與調度系統。它不替代 vLLM、SGLang 等推理引擎，而是在引擎之上提供一層智能編排，與 K8s 深度集成。
架構：控制面與數據面分離¶
Kthena 由兩個核心組件構成：
- Kthena Router：高性能多模型路由器，作爲所有推理請求的入口，按 ModelRoute 規則將流量分發到後端 ModelServer。
- Kthena Controller Manager：控制面，通過 CRD 協調工作負載生命週期，負責 ServingGroup、Prefill/Decode 角色編排、拓撲感知親和、Gang 調度、滾動更新與故障恢復。
主要 CRD 包括 ModelServing（分層工作負載）、ModelBooster（開箱即用模板）和 AutoScalingPolicy（彈性伸縮策略）。
分層工作負載：ModelServing → ServingGroup → Role¶
Kthena 引入層次化工作負載模型。一個複雜的 PD 分離部署，可以聲明爲單個 ModelServing 資源，內部包含多個 ServingGroup，每個 Group 再細分爲 Prefill、Decode 等 Role。Gang 調度保證同一 ServingGroup 內的 Pod 作爲原子單元一起調度，避免「只起了 Prefill、Decode 還在 Pending」導致的死鎖。
PD 分離的核心邏輯是：計算密集的 Prefill 任務路由到算力更強的節點，內存帶寬受限的 Decode 任務路由到 HBM 更充裕的節點，兩者可獨立擴縮容，動態調整 Prefill/Decode 比例。
KV Cache 感知路由¶
這是 Kthena 最具辨識度的能力之一。Router 提供可插拔的調度插件，包括 Least Request、Least Latency、KV Cache Awareness、Prefix Cache Awareness、LoRA Affinity 和 Fairness Scheduling。
KV Cache 感知插件的工作方式（據 Kthena 官方文檔）：
- 每個 vLLM Pod 旁部署 Kthena Runtime sidecar，訂閱 vLLM 的 ZMQ
kv-events流，將 token block 哈希寫入 Redis。 - Router 在請求到達時查詢 Redis，優先將請求路由到已有匹配 KV Cache 的 Pod，減少重複 Prefill 計算。
在 4096 token 長系統提示詞場景下，CNCF 博客公佈的基準測試顯示，「Least Request + KVCacheAware」相比隨機路由：吞吐量提升約 2.73 倍，TTFT（首 Token 時間）降低約 73.5%，端到端延遲降低超過 60%。短提示詞場景差距會縮小，但對多輪對話和模板化 Prompt 負載，KV Cache 感知仍有決定性優勢。
支持的推理引擎與 KV 傳輸¶
Kthena 通過統一 API 抽象支持 vLLM、SGLang、Triton/TGI 等引擎。PD 分離模式下，Prefill Pod 與 Decode Pod 之間需要傳遞 KV Cache 狀態，Kthena 支持三種連接器後端：
| 連接器 | 特點 |
|---|---|
| LMCache | 內存級，同節點或 RDMA，延遲最低 |
| MoonCake | 分佈式跨節點，具備容錯能力 |
| NIXL | 輕量 NCCL 方案，GPU Direct |
應用層無需感知具體傳輸實現，Runtime Agent 會自動處理。
快速體驗：ModelBooster 模板¶
對於常見模型，Kthena 提供 ModelBooster 模板，內置 PD 分離等主流部署模式，自動生成路由與生命週期資源。複雜場景再下沉到 ModelServing 做細粒度控制。
GitHub 倉庫：volcano-sh/kthena
官方文檔：kthena.volcano.sh
Grove：用一份 CR 描述整個推理系統¶
如果說 Kthena 側重「請求怎麼路由、模型怎麼編排」，NVIDIA Grove 則聚焦「多組件推理系統怎麼作爲一個整體來擴縮、調度與恢復」。
Grove 於 2025 年 11 月隨 NVIDIA Dynamo 模塊化發佈，完全開源，倉庫位於 ai-dynamo/grove（NVIDIA 官方 GitHub 組織下亦有鏡像）。
從「N 個 Pod 副本」到「一組組件的協同」¶
現代推理部署往往包含 Prefill、Decode、Vision Encoder、KV Router 等多個角色，Agentic 流水線更是多個模型實例協作。Grove 的設計動機，就是把「協調一組組件作爲一個邏輯系統」這件事，從腳本和自定義 Controller 裏解放出來，用一份 Custom Resource 聲明完畢。
Grove 提供三層層次化 CR：
- PodClique：具特定角色的 Pod 組（如 prefill-leader、prefill-worker、decode-leader、decode-worker），各自獨立配置與擴縮邏輯。
- PodCliqueScalingGroup：緊密耦合、必須一起擴縮的 PodClique 組合，例如一個 prefill leader 與其 worker 共同構成一個模型實例。
- PodCliqueSet：頂層工作負載定義，指定啓動順序、擴縮策略與 gang 調度約束，確保所有組件一起啓動或一起失敗。
層次化 Gang 調度與拓撲感知¶
傳統 Gang 調度是「全有或全無」，但 PD 分離場景需要更靈活的策略：至少保證一個 Prefill 實例和一個 Decode 實例同時就緒，同時允許 Prefill 與 Decode 按不同比例獨立擴縮。
Grove 通過生成 PodGang 資源（Scheduler API 的一部分），將工作負載需求翻譯爲調度約束。每個 PodGang 封裝最小副本保證、網絡拓撲打包偏好與 spread 約束。在 GB200 NVL72 等架構上，將相關 Prefill 與 Decode Pod 調度到同一 NVLink 域，可顯著降低 KV Cache 傳輸延遲。
Grove 還實現了多級自動擴縮：單個組件級、組件組級、整個服務副本級，三層擴縮互相感知——例如 Prefill worker 擴容可能觸發 Decode 容量調整。
與 KAI Scheduler 的配合¶
Grove 本身不負責 Pod 落位，它需要集羣裏有一個理解 PodGang 的調度器。KAI Scheduler 正是爲此而生：持續監聽 PodGang 資源，應用 gang 調度邏輯，在 GPU 拓撲感知與集羣局部性約束下做放置決策。Grove 定義「要什麼」，KAI 決定「放哪裏」。
KAI Scheduler：GPU 集羣的 gang 調度引擎¶
KAI Scheduler 是 NVIDIA 開源的 Kubernetes 原生 AI 調度器（Apache 2.0 許可證），源自 Run:ai 平臺，面向大規模 GPU 集羣。
核心能力包括：
- Gang Scheduling：通過 PodGroup CRD，保證一組相互依賴的 Pod 要麼全部調度成功，要麼全部等待，避免分佈式任務部分啓動、GPU 空轉。
- 層次化 PodGroup（Hierarchical PodGroups）：支持嵌套 SubGroup，爲 Prefill/Decode 等多層組件分別指定拓撲約束與 gang 閾值，適配 Grove/Dynamo 這類複雜流水線。
- 拓撲感知調度（TAS）：根據機架、NVLink 域等物理拓撲做放置優化。
- 公平隊列與優先級搶佔：多租戶場景下按配額分配 GPU，高優先級推理任務可搶佔低優先級批處理作業。
2025 年 11 月，KAI Scheduler 與 Grove 完成集成；KAI 的 PodGrouper 插件可直接消費 Grove 生成的 PodGang，將其映射爲 KAI PodGroup 並設置 MinAvailable 等字段。
GitHub 倉庫：NVIDIA/KAI-Scheduler
KAITO：CNCF 裏的模型部署 Operator¶
在「調度與路由」之外，KAITO（Kubernetes AI Toolchain Operator）負責把模型本身部署到集羣裏。它於 2024 年 10 月進入 CNCF Sandbox，最新版本爲 v0.11.0（2026 年 7 月發佈）。
KAITO 通過 Workspace CRD 簡化模型部署：指定 HuggingFace 模型 ID，Operator 自動估算 GPU 內存需求、選擇合適節點規模，並與 Karpenter 等節點自動供應器集成。當前推理引擎以 vLLM 爲主，支持 LoRA 適配器，默認啓用 KV Cache offloading。
2026 年 v0.11.0 的重要更新包括：
- MultiRoleInference：原生支持 Prefill/Decode 分離部署。
- InferenceSet 升至 v1beta1：副本管理與自動擴縮更成熟，可與 KEDA 聯動。
- ProductionStack 可選子 chart：基於 llm-d 參考棧，集成 Istio 網關、KV-cache 感知路由與 KEDA 指標驅動擴縮。
KAITO 還通過 Gateway API Inference Extension 創建 InferencePool 與 EPP（Endpoint Picker），實現與外部網關的 KV Cache 感知路由對接。
GitHub 倉庫：kaito-project/kaito
生態分層：誰管什麼¶
把上述項目放在一張邏輯圖裏，職責邊界就很清晰：
| 層次 | 代表項目 | 主要職責 |
|---|---|---|
| 模型部署 | KAITO | 模型權重拉取、vLLM 參數預設、節點供應 |
| 工作負載編排 | Grove / Kthena | 多組件生命週期、PD 分離、啓動順序 |
| 流量路由 | Kthena Router | 多模型路由、KV Cache 感知、限流與灰度 |
| GPU 調度 | KAI Scheduler / Volcano | Gang 調度、拓撲感知、公平隊列 |
Kthena 與 Grove 在 PD 分離、Gang 調度、拓撲感知上有能力重疊，但出發點不同：Kthena 從 Volcano 批調度經驗出發，強調推理路由與 ModelServing 統一 API；Grove 從 NVIDIA Dynamo 多組件推理架構出發，強調 PodCliqueSet 一站式聲明與 KAI Scheduler 深度集成。平臺團隊可以根據現有技術棧選型，也可以分層組合——例如 KAITO 負責模型落地，Kthena 負責流量治理，KAI Scheduler 負責 GPU 放置。
動手試試：Kthena PD 分離最小示例¶
以下 YAML 片段展示 Kthena ModelServing 聲明 PD 分離部署的基本結構（字段名參考官方文檔，實際部署前請對照當前版本 CRD）：
apiVersion: inference.volcano.sh/v1alpha1
kind: ModelServing
metadata:
name: llama-pd-serving
spec:
model: meta-llama/Llama-3.1-8B-Instruct
engine: vllm
servingGroups:
- name: pd-group-0
roles:
- name: prefill
replicas: 2
resources:
limits:
nvidia.com/gpu: "1"
template:
spec:
containers:
- name: vllm
image: vllm/vllm-openai:latest
args:
- --kv-events-config
- '{"enable_kv_cache_events":true,"topic":"kv-events"}'
- name: decode
replicas: 4
resources:
limits:
nvidia.com/gpu: "1"
配合 Kthena Router 的 kvcache-aware 插件與 Redis 協調層，即可在長上下文場景下獲得可觀的 TTFT 改善。完整示例可參考官方倉庫中的 gpu-kvcache-aware.yaml。
Grove 側，用戶只需提交一份 PodCliqueSet，Operator 會自動生成 PodCliques、PodCliqueScalingGroups、Service、HPA 以及 PodGang，後續調度交給 KAI Scheduler 完成。具體 Helm 安裝步驟見 NVIDIA Grove 技術博客。
寫在最後¶
2026 年的 K8s AI 推理生態，正在從「各團隊各自拼 YAML」走向「分層組件、聲明式協同」。Kthena 把 KV Cache 感知路由和 PD 分離調度帶入 Volcano 統一框架；Grove 與 KAI Scheduler 則爲多節點、多組件推理提供了拓撲感知的 Gang 調度能力；KAITO 繼續降低模型部署門檻。
對平臺工程團隊而言，值得關注的不是「選哪一個」，而是「在哪一層引入哪一塊能力」——路由層、編排層、調度層各司其職，才能把 GPU 利用率、TTFT 和多模型治理真正做到生產可用。上述項目均爲開源，建議從官方文檔與 GitHub 示例集羣入手驗證，再逐步替換現有手工編排的推理棧。
