文章

Prefill-Decode Disaggregation：LLM 推理为什么要把 Prefill 和 Decode 拆开

本文系统拆解 Prefill-Decode Disaggregation 的工程原理、TTFT 与 ITL/TPOT 的指标边界、KV cache 传输成本、调度策略和上线 Checklist，帮助判断 LLM 推理服务何时应该从统一实例走向分离式架构。

为什么 LLM 推理需要拆开两个阶段

很多团队部署 LLM 服务时，会把一个请求完整交给同一个推理实例处理：先读入 prompt，生成第一个 token，再逐 token 生成后续结果。这种架构简单，但在长 prompt、高并发和严格延迟目标下，很容易出现不稳定延迟。

原因在于 LLM 推理天然分成两个阶段：Prefill 和 Decode。

Prefill 负责处理输入 prompt，并为所有输入 token 计算 KV cache。它通常发生一次，适合大规模并行计算，计算量随输入长度增长。

Decode 负责逐 token 生成输出。它会持续读取已有 KV cache，并追加新 token 的 KV。它通常持续多轮，更容易受内存带宽、batch 调度和尾延迟影响。

如果两个阶段共享同一组 GPU，长 prompt 的 prefill 任务可能插入正在进行的 decode 批次中，导致用户看到的输出 token 间隔突然变长。这就是很多流式对话系统中「前几个 token 正常，后面突然卡顿」的根源之一。

一句话理解 Prefill-Decode Disaggregation

Prefill-Decode Disaggregation，简称 PD 分离，就是把 prompt 处理和 token 生成拆到不同推理实例或 GPU 池中：

User Request -> Router -> Prefill Worker: process prompt and produce KV cache -> KV Cache Transfer -> Decode Worker: generate output tokens

它的目标不是简单让系统架构更复杂，而是把两个不同瓶颈的阶段分开优化。

  • Prefill: optimize TTFT and prompt throughput
  • Decode: optimize ITL / TPOT and stable streaming generation

这也是为什么 PD 分离经常出现在长上下文、Agent、RAG、代码生成、推理模型和多租户推理平台中。

核心知识结构

可以把 PD 分离拆成 6 个工程模块。

1. Prefill：一次性处理上下文

Prefill 阶段读取完整 prompt，包括 system prompt、用户问题、历史消息、RAG 文档、工具描述等。它会计算 prompt token 对应的 KV cache。

它的关键指标是 TTFT（Time To First Token），也就是从请求进入系统到第一个 token 输出的时间。

2. Decode：持续生成输出 token

Decode 阶段每次生成一个或少量 token，需要不断读取历史 KV cache。它的关键指标是 ITL（Inter-Token Latency）或 TPOT（Time Per Output Token），也就是 token 与 token 之间的生成延迟。

对流式聊天、代码补全和语音交互来说，decode 稳定性往往比平均吞吐更重要。

3. KV Cache Transfer：分离架构的核心成本

Prefill worker 生成的 KV cache 必须交给 decode worker。这个传输可能发生在同机 GPU、跨 GPU、跨节点或 RDMA 网络上。

如果 KV cache 传输太慢，PD 分离带来的收益会被抵消。

4. Router：请求不再只是负载均衡

PD 架构下的 router 不只是把请求发给某个模型实例。它需要选择 prefill worker、选择 decode worker、协调 KV cache 位置，并记录请求状态。

5. Scheduler：分别优化两个阶段

统一实例里，prefill 和 decode 共享一个调度器。PD 分离后，prefill 调度器可以优先处理长 prompt 或短 prompt，decode 调度器可以优先保护流式输出稳定性。

6. SLO：从 tokens/s 转向 goodput

PD 分离的目标不是最大化裸吞吐，而是在 TTFT 与 ITL/TPOT 约束下，最大化满足延迟目标的请求数，也就是 goodput。

为什么统一调度会产生干扰

统一实例部署看起来像这样：

GPU Instance: Batch A decode step → Batch B decode step → New request prefill → Batch A decode step → Another long prefill → Batch B decode step

问题是 prefill 和 decode 的资源形态不同。

Prefill 需要对完整输入并行计算，长 prompt 会形成较大的计算任务。Decode 每一步计算量较小，但需要稳定地读取权重和 KV cache，一旦被 prefill 插队，用户侧就会看到 token 输出间隔变长。

因此，统一调度会导致两类问题：

  • TTFT 与 ITL 互相牵制：优化 prefill 可能影响 decode，保护 decode 又可能推迟新请求首 token。
  • 尾延迟放大：平均 latency 看起来还行，但 P90/P99 ITL 出现尖刺。

PD 分离的价值就是把这种资源冲突显式拆开。

典型 PD 分离流程

一个生产级 PD 分离请求流程通常如下：

  1. Client 发送请求到 Router
  2. Router 选择 Prefill Worker
  3. Prefill Worker 处理 prompt 并生成 KV cache
  4. KV cache 被传输或注册给 Decode Worker
  5. Decode Worker 接管请求并逐 token 生成
  6. Router 或 Gateway 向客户端返回流式输出
  7. Metrics 系统记录 TTFT、ITL、TPOT、KV transfer time 和 SLO 命中情况

这套流程真正的难点不在第 3 步，而在第 4、5、7 步。也就是：cache 怎么交接，decode 怎么稳定接管，指标怎么证明架构真的变好。

PD 分离不等于一定更快

这是最容易被误解的地方。

PD 分离会减少 prefill 与 decode 的干扰，但也会引入新的成本：

  • KV cache transfer cost
  • router orchestration cost
  • extra service hops
  • prefill/decode ratio imbalance
  • debugging and failure recovery complexity

因此，判断 PD 是否适合，不能只看 tokens/s。更合理的判断方式是按 workload 分类。

更适合 PD 分离的场景

  • 输入 prompt 长，输出中等或较长
  • 并发下 ITL/TPOT 尾延迟明显抖动
  • 业务有明确 TTFT 与 ITL SLO
  • RAG 或 Agent 请求包含大量上下文
  • 不同请求长度差异大，统一调度难以稳定
  • 有 RDMA、高速互联或同机高效 KV 传输能力

不一定适合 PD 分离的场景

  • prompt 很短，输出很短
  • 单机低并发，延迟波动不明显
  • KV cache 传输成本高于阶段干扰收益
  • 团队还没有完善的 trace、metrics 和回退机制
  • 只追求离线批量吞吐，而不是在线 SLO

指标体系：从 TTFT 到 Goodput

上线 PD 分离前，至少要把指标拆开看。

指标说明
TTFTTime To First Token，衡量用户多久看到第一个 token。Prefill worker、router、KV cache handoff 都会影响它
ITL / TPOTInter-Token Latency 或 Time Per Output Token，衡量流式输出是否稳定。PD 分离最常见的目标就是降低尾部 ITL
KV Transfer Time记录 KV cache 从 prefill worker 到 decode worker 的传输耗时。它决定 PD 分离的收益上限
Queue Time分别统计 prefill queue 和 decode queue。很多系统的问题不是模型慢，而是某一侧 worker 堆积
P/D Ratio记录 prefill worker 与 decode worker 的资源比例。固定比例不一定适合混合长度请求
Goodput满足 SLO 的有效请求吞吐。它比 raw throughput 更适合在线推理服务

一个简化指标结构如下：

metrics:
  ttft_ms:
    p50: 320
    p90: 780
    p99: 1400
  itl_ms:
    p50: 28
    p90: 55
    p99: 120
  kv_transfer_ms:
    p50: 18
    p90: 41
  slo_attainment:
    ttft_under_1s: 0.94
    itl_under_80ms: 0.97
  goodput_rps: 42

架构选择：Aggregated、Disaggregated 还是 Hybrid

生产架构不一定非黑即白。

架构特点优点缺点
Aggregated ServingPrefill 与 Decode 在同一实例里运行简单，无 KV cache 跨实例传输高并发和长 prompt 下容易发生阶段干扰
Disaggregated ServingPrefill 与 Decode 使用不同实例或 GPU 池阶段隔离，TTFT 与 ITL/TPOT 可独立优化系统复杂，引入 KV cache transfer 成本
Hybrid Serving部分请求走统一实例，部分请求走 PD 分离灵活，按 workload 动态切换路由和调度逻辑更复杂

Hybrid 方案更符合真实生产环境，因为不同 workload 对 TTFT 与 TPOT 的约束不同。短请求可能留在 aggregated 模式，长上下文请求可能进入 disaggregated 模式。

生产落地 Checklist

上线前建议逐项检查：

  • 是否按请求类型统计 prompt length 与 output length 分布
  • 是否分别记录 TTFT、ITL/TPOT，而不是只看 tokens/s
  • 是否验证 prefill 插队导致的 decode 尾延迟问题真实存在
  • 是否测量 KV cache transfer time
  • 是否评估不同 prefill/decode GPU 配比
  • 是否有 router 层 trace，能定位请求停在哪个阶段
  • 是否有 prefill queue 与 decode queue 的独立监控
  • 是否有 decode worker 失败后的请求恢复策略
  • 是否有 KV cache 传输失败后的重试或降级方案
  • 是否保留 aggregated fallback
  • 是否用真实 prompt/output 分布压测，而不是只用固定 synthetic case
  • 是否以 SLO attainment 和 goodput 作为主要验收指标

结论

Prefill-Decode Disaggregation 的本质不是「把服务拆成更多模块」，而是承认 LLM 推理的两个阶段有不同瓶颈：

  • Prefill 关注上下文处理和 TTFT
  • Decode 关注持续生成和 ITL/TPOT
  • KV cache transfer 决定拆分成本
  • Scheduler 和 Router 决定收益是否真实兑现

对工程团队来说，最重要的判断标准不是 PD 分离听起来是否先进，而是你的 workload 是否已经出现 prefill 与 decode 干扰。

如果没有明确 SLO、没有尾延迟问题、没有 KV cache 传输能力，PD 分离可能只是增加复杂度。

如果你的系统已经面对长上下文、高并发、流式输出抖动和严格在线延迟要求，那么 PD 分离就不只是优化项，而是从单实例推理走向生产级推理平台的重要架构分界线。

常见问题

Prefill-Decode Disaggregation 一定会提升吞吐量吗？
不一定。它主要用于拆开 TTFT 与 ITL/TPOT 的优化目标，降低阶段间干扰。实际吞吐是否提升取决于 prompt 长度、输出长度、并发、KV cache 传输和 GPU 配比。
为什么 Prefill 和 Decode 适合分离？
Prefill 通常更偏计算密集，负责处理完整输入并生成 KV cache；Decode 通常更偏内存带宽密集，逐 token 生成并反复读取 KV cache。两者资源瓶颈不同，统一调度容易互相干扰。
生产环境落地 PD 分离最容易踩什么坑？
最常见问题是只看 tokens/s，不看 TTFT、ITL/TPOT、尾延迟、KV cache 传输时间、prefill/decode 实例比例和失败回退路径。
特效配置