前言¶
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 示例集群入手验证，再逐步替换现有手工编排的推理栈。
