AI 生成的内容可能会对信息做不完整的总结。请核实重要信息。了解更多
随着大语言模型（LLM）推理工作负载复杂度不断上升，单一的整体式服务进程开始触及其上限。Prefill 和 decode 阶段在计算特征上存在根本差异，但传统部署却强制它们使用同一套硬件，导致 GPU 利用不足，扩缩容也不够灵活。
解耦式服务通过将推理流水线拆分为 prefill、decode 和 routing 等不同阶段来解决这一问题。每个阶段都作为独立服务运行，可以按各自需求分配资源并扩缩容。
本文将概述解耦式推理如何在 Kubernetes 上部署，探讨生态中的不同解决方案及其在集群中的执行方式，并评估它们开箱即用提供了什么能力。
聚合式与解耦式推理有何不同？
在深入讨论 Kubernetes 清单之前，先理解 LLM 的两种推理部署模式会更有帮助：在聚合式服务中，单个进程（或紧密耦合的一组进程）负责从输入到输出的整个推理生命周期。解耦式服务则会将流水线拆分为 prefill、decode 和 routing 等不同阶段，并让它们作为独立服务运行（见下方图 1）。
聚合式推理
在传统的聚合式部署中，单个模型服务器（或并行配置中的协同服务器组）负责处理完整的请求生命周期。用户提示词进入后，服务器会对其进行分词，运行 prefill 构建上下文，以自回归方式生成输出 token（decode），然后返回响应。所有过程都发生在单一进程或紧密耦合的 pod 组内。
这种方式在概念上很简单，也适用于很多用例。但这意味着硬件需要在两种根本不同的工作负载之间切换：Prefill 是计算密集型任务，更受益于高浮点运算能力（FLOPS）；而 decode 受内存带宽限制，更依赖大容量且高速的内存。
解耦式推理
解耦式架构会将这些阶段拆分为不同服务：
为什么要解耦？有三个原因尤为突出：
NVIDIA Dynamo 和 llm-d 等框架实现了这种模式。接下来的问题是：如何在 Kubernetes 上编排它？
为什么调度是 Kubernetes 上多 pod 推理性能的关键
部署多 pod 推理工作负载（无论是模型并行的聚合式模型，还是解耦式模型）只是完成了一半。调度器如何在集群中放置 pod 会直接影响性能；如果把一个 Tensor Parallel（TP）组的 pod 放在同一机架，并通过高带宽的 NVIDIA NVLink 互连，快速推理和网络瓶颈之间的差别可能就此产生。这里最重要的是三项调度能力：
这三项能力决定了像 KAI Scheduler 这样的 AI 调度器如何基于应用的调度约束来放置 pod。此外，AI 编排层还必须判断哪些内容需要进行 gang scheduling，以及在何时进行。例如，当 prefill 独立扩容时，必须有机制决定新 pod 应构成一个具备最小可用性保障的 gang，同时又不影响现有 decode pod。因此，为了确保 AI 工作负载在运行时具备最佳条件，编排层和调度器需要在整个应用生命周期中紧密协作，处理多层级自动扩缩容、滚动更新等事项。
这正是更高层工作负载抽象发挥作用的地方。像 LeaderWorkerSet（LWS）和 NVIDIA Grove 这样的 API，允许用户以声明式方式表达其推理应用的结构：有哪些角色、它们之间如何关联、应如何扩缩容，以及哪些拓扑约束最重要。API 的 operator 会把这些应用层意图转换为具体的调度约束（包括 PodGroups、gang 要求、拓扑提示），从而决定何时创建哪些 gang。
KAI Scheduler 随后承担满足这些约束的关键角色，解决“如何做”的问题：gang scheduling、分层 gang scheduling，以及拓扑感知放置。本文使用 KAI 作为调度器，不过社区中也有其他调度器支持其中部分特性。读者可以通过 Cloud Native Computing Foundation（CNCF）生态进一步了解更广泛的调度方案。
部署解耦式推理
解耦式架构包含多个角色，每个角色都有不同的资源特征和扩缩容需求。由于解耦式流水线中的每个角色都是独立工作负载，因此使用 LWS 的一个自然方法，是为每个角色分别创建一个独立资源。
Prefill worker（4 个副本，2 路 Tensor Parallelism）：
Decode worker（2 个副本，4 路 Tensor Parallelism）：
Router（标准 deployment，不需要 leader-worker 拓扑）：
每个角色都作为独立资源进行管理。你可以分别对 prefill 和 decode 进行扩缩容，并按不同节奏更新它们。
需要注意的是，调度器会把 prefill worker 和 decode worker 视为彼此独立的工作负载。调度器可以成功放置它们，但并不知道它们共同构成了一条完整的推理流水线。在实践中，这意味着几件事：
最后一点值得特别指出。推理框架迭代很快，且并不总能保证不同版本之间向后兼容，因此旧版本上的 prefill pod 与新版本上的 decode pod 可能无法通信。模型加载也需要时间，而 prefill 和 decode worker 经常以不同速度进入 ready 状态。在不同步的发布过程中，这可能会造成暂时失衡：许多新的 decode pod 已经就绪，但新的 prefill pod 很少，反之亦然。在一切都追上之前，这会让你的推理流水线出现瓶颈。
这些模式是可行的。只是协调工作发生在 Kubernetes 原生机制之外：可能位于推理框架的路由层、自定义自动扩缩容器、定制 operator 中，甚至是手动完成。另一个选择是使用 Grove 的 API，它采用了不同做法，把这种协调移入 Kubernetes 资源本身。
它会在一个 PodCliqueSet 中表达所有角色：
Grove operator 会为每个角色管理 PodClique，并协调它们之间的调度、启动和生命周期。下面这个 YAML 有几点值得注意：
应用这个清单后，你可以检查 Grove 创建的所有资源：
会看到 1 个 PodCliqueSet、3 个 PodClique（每个角色 1 个）、1 个用于协调调度的 PodGang，以及与各角色副本数匹配的 pod。startsAfter 依赖关系通过 init container 强制实现：Prefill 和 decode pod 会等待 router 就绪后才启动其主容器。
扩缩容解耦式工作负载
一旦解耦式工作负载开始运行，扩缩容就成为核心运维挑战。Prefill 和 decode 的瓶颈不同；团队可能希望基于首 token 时间（TTFT）独立自动扩缩容 prefill worker，基于 token 间延迟（ITL）独立自动扩缩容 decode worker，以便在满足服务级别协议（SLA）的同时尽量降低 GPU 成本。
在实践中，解耦式扩缩容分为三个层级：
不同工具分别处理不同层级。
推理框架如何协调扩缩容
推理框架会在应用层通过自定义自动扩缩容器处理扩缩容，这些自动扩缩容器能够看到推理特有指标。llm-d 的 workload variant autoscaler（WVA）通过 Prometheus 监控每个 pod 的 KV cache 利用率和队列深度，并使用备用容量模型来决定何时增减副本。WVA 并不直接扩缩 deployment，而是把目标副本数作为 Prometheus 指标输出，再由标准 HPA 或基于 Kubernetes 的事件驱动自动扩缩容（KEDA）执行，从而使扩缩容动作仍保持在 Kubernetes 原生机制之内。
NVIDIA Dynamo planner 采用了不同的方法：它原生理解解耦式服务，分别运行针对 TTFT 和 ITL SLA 的 prefill 与 decode 扩缩容循环。它利用时间序列模型预测即将到来的需求，根据分析得到的每 GPU 吞吐曲线计算所需副本数，并在两个角色之间执行全局 GPU 预算约束。
这种全局可见性很重要，因为在实际中，prefill 与 decode 之间存在一个会随请求模式变化而变化的最优比例。如果只把 prefill 扩到 3 倍、却不扩 decode，多出来的输出将无处可去，decode 会成为瓶颈，KV cache 传输也会开始排队。应用层自动扩缩容器能够处理这一点，因为它们能看见完整流水线；而针对单个资源的 Kubernetes 原生 HPA 并不会天然保持跨资源的比例关系。
使用独立 LWS 资源扩缩容
当每个角色各自对应一个 LWS 时，你可以分别对其扩缩容：
标准 HPA 可以分别针对每个 LWS，也可以由外部自动扩缩容器（如 Dynamo planner 或 llm-d 的 autoscaler）做出协调决策并同时更新两者。协调逻辑存在于 autoscaler 中，而不在 Kubernetes 资源本身。
使用 Grove 扩缩容
Grove 将按角色扩缩容整合进了单一资源中。每个 PodClique 都有自己的副本数和可选的 autoScalingConfig，因此 HPA 可以基于各角色指标独立管理它们：
operator 会新增 prefill pod，而保持 router 和 decode 不变：
6 个 prefill pod、2 个 router pod、2 个 decode pod，变化的只有 prefill。
对于内部使用多节点 Tensor Parallelism 的角色，PodCliqueScalingGroup 可确保多个 PodClique 作为一个整体共同扩缩容，同时保持它们之间的副本比例。例如，在一种配置中，每个 prefill 实例由 1 个 leader pod 和 4 个 worker pod 组成：
当 replicas: Two 时，这会创建 2 个完整的 prefill 实例：2 x（1 个 leader + 4 个 worker）= 共 10 个 pod。minAvailable: One 这一保证意味着系统不会缩减到少于 1 个完整的 Tensor Parallel 组。
把该组从 2 个副本扩到 3 个副本时，会新增第 3 个完整实例，同时保持 1:4 的 leader-to-worker 比例：leader-to-worker 比例：
leader 和 worker clique 会作为一个整体共同扩缩容；新增副本（prefill-2）包含 1 个 pleader pod 和 4 个 pworker pod，符合这一比例。同时会为第 3 个副本创建新的 PodGang，以确保它能进行 gang scheduling。
开始使用
无论你是在运行单条解耦式流水线，还是在整个集群中运行数十条，这方面的基础构件都在逐步形成，社区也在以开放方式推进建设。本文中的每种方法，都代表了从简洁性到一体化协调这一光谱上的不同位置。
正确选择取决于你的工作负载、团队的运维模式，以及你希望由平台处理多少生命周期管理、又希望由应用层处理多少。
更多信息可查看这些资源。
如果你将参加 2026 年在阿姆斯特丹举办的 KubeCon EU，欢迎到 241 号展位参加我们的会议，我们将介绍一套端到端的开源 AI 推理栈。你也可以查看 Grove Deployment Guide，并在 GitHub 或 Discord 上提问。我们也希望了解你如何看待在 Kubernetes 上进行解耦式推理。
