核心摘要
分离式推理服务把 LLM 的 Prefill 和 Decode拆分为可独立扩缩容的工作池。它可以隔离首 Token 延迟与 Token 间延迟压力，并为不同阶段选择不同硬件或并行方式；代价是新增 KV Cache 传输、阶段感知路由、兼容性和恢复关键路径。它是一种 SLO 架构，不是自动提升吞吐的开关。
Prefill 与 Decode 为什么不同
自回归推理包含两个主要阶段：
| 阶段 | 工作 | 典型压力 | 用户侧指标 |
|---|---|---|---|
| Prefill | 处理全部输入 Token 并建立 KV 状态 | 提示词长度、计算、批处理 | 首 Token 延迟（TTFT） |
| Decode | 每步为活跃序列生成一个 Token | KV 读取、显存带宽、并发 | Token 间延迟（ITL/TPOT） |
聚合式引擎由同一 Worker 处理两个阶段，突发长提示词可能占用计算并拖慢正在生成的请求。分离式架构让专用 Prefill Worker 吸收提示词处理，Decode Worker 继续流式输出。
KV 传输是关键路径
Decode 必须获得 Prefill 产生的 Attention 状态才能继续。不同推理后端可能复制 KV Block、暴露远程内存，或使用后端专用传输协议。
传输成本随模型层数、KV Head、Head 维度、精度和提示词长度增长，网络拓扑与数据局部性非常关键。如果部署原计划使用高速传输，却静默回退到 TCP，TTFT 与吞吐可能比聚合式基线更差。
需要验证：
- 不同模型和输入长度区间的传输字节数；
- 传输排队与耗时；
- 生产环境实际选择的传输协议；
- 模型修订、张量并行、Block Size 和 KV 格式兼容性；
- 取消请求与 Worker 故障后的清理；
- Decode 容量不足时的背压。
NVIDIA Dynamo 文档明确把高速 KV 传输作为前置验证项，并警告传输可能主导性能。这是核心工程边界，不是最后才调的参数。
路由与调度
路由器协调两个容量池，应优化满足 SLO 的 Goodput，而不是只选择最短队列。
prefill_score =
estimated_prefill_time(input_tokens, worker_profile)
+ prefill_queue_delay
decode_score =
active_sequences
+ expected_output_pressure
+ kv_transfer_cost(prefill_worker, decode_worker)
路由输入可以包括：
- 输入长度与预期输出长度；
- 租户优先级和延迟 SLO；
- Prefix 或 KV 局部性；
- Worker 队列、显存和故障状态；
- 传输拓扑；
- 模型与 Adapter 兼容性。
模型预测的输出长度不能作为硬分配事实，系统还要依赖请求限制、历史分布和运行时预算。
聚合式与分离式如何选择
| 工作负载 | 聚合式默认方案 | 分离式候选 |
|---|---|---|
| 短输入、短输出 | 更简单且通常更快 | 传输开销可能占主导 |
| 长输入、短输出 | Prefill 可能阻塞 Decode | 很适合测试隔离收益 |
| 短输入、长输出 | Decode 占主导 | 独立扩展 Decode 可能有效 |
| 低并发 | 组件更少 | 工作池可能利用不足 |
| 高混合并发 | 阶段干扰明显 | 独立工作池可改善 Goodput |
| 网络能力有限 | 无传输依赖 | 跨节点 KV 移动风险高 |
先建立使用连续批处理和 Prefix Cache 的优化聚合式基线。只有测量到阶段干扰或扩容不对称后，再引入分离式架构。
与其他推理优化的关系
分离式架构可以组合但不能替代：
- 连续批处理： 在 Worker 内高效调度活跃序列；
- Prefix Cache： 复用重复提示词前缀的 KV 状态；
- KV 感知路由： 根据缓存局部性选择 Worker；
- Chunked Prefill： 在活跃 Decode 中穿插处理提示词分块；
- 推测解码：验证草稿 Token，减少 Decode 步数；
- 量化与并行：改变模型计算和显存特征。
每项机制都可能改变分离式架构的收益。例如高效 Prefix Cache 会减少 Prefill 工作，推测解码则会改变 Decode 需求。启用后应重新估算容量。
容量规划
确定工作池比例前先测量请求分布：
prefill_load = 每秒请求数 * 平均 Prefill 秒数
decode_load = 每秒请求数 * 平均 Decode 秒数
最少 Prefill Worker ≈ prefill_load / 目标利用率
最少 Decode Worker ≈ decode_load / 目标利用率
这只是起点。平均值会掩盖长上下文突发，应按输入/输出长度分桶并观察尾延迟。使用真实到达轨迹、故障和 SLO 约束测试多个 xP:yD 比例。
持续监控：
- 按输入长度分组的 TTFT p50/p95/p99；
- 按并发分组的 ITL 或每 Token 时间；
- 请求吞吐与满足 SLO 的 Goodput；
- Prefill/Decode 队列时间和利用率；
- KV 传输耗时、字节数和错误率；
- 取消清理与显存泄漏；
- 每个成功请求成本。
故障处理
分离式架构增加了部分失败状态：
| 故障 | 必要行为 |
|---|---|
| Prefill 成功但 Decode 不可用 | 有界排队或失败，并释放 KV 状态 |
| KV 传输失败 | 只在安全时进行类型化重试，避免重复流 |
| Decode Worker 流式中途故障 | 终止，或仅按预先设计的协议恢复 |
| 客户端取消 | 同时传播到两个工作池并清理传输 |
| 路由器丢失状态 | 使用请求身份与幂等清理 |
| 版本不兼容 | 在传输前拒绝，而不是完成昂贵 Prefill 后失败 |
不要在每次错误后盲目重做 Prefill。重试可能让 GPU 工作翻倍、泄漏 KV 分配或产生重复流式输出。必须定义请求身份和清理责任方。
基准测试方案
比较聚合式与分离式部署时保持以下条件一致：
- 模型修订、量化、分词器与采样参数；
- 输入/输出长度分布；
- 并发与到达过程；
- Prefix Cache 策略；
- 硬件数量与成本口径；
- 延迟 SLO 和取消行为。
覆盖稳态、突发、长提示词、Decode 密集、Worker 丢失和网络降级场景。报告满足 SLO 的 Goodput，而不只是最大 Token/s。生成更多 Token 却违反 TTFT 或 ITL 的配置，对该服务不是改进。
生产决策清单
只有满足以下条件才采用分离式架构：
- 阶段级 Trace 证明 Prefill/Decode 存在干扰；
- 两个阶段确实需要不同扩容或并行方式；
- 具备高速、可观测的 KV 传输；
- 路由器能执行兼容性与背压；
- 故障清理和取消已通过测试；
- SLO Goodput 或成本优于基线。
如果复杂度没有带来可测量的 SLO 收益，就继续使用聚合式服务。
KV Cache 推理指南解释被传输的状态；LLM 推理指南覆盖批处理、显存和服务指标。
常见问题
Prefill 与 Decode 可以使用不同 GPU 吗？
如果服务栈支持兼容的模型状态和传输，则有可能。异构硬件会增加调度、数值兼容、容量和运维复杂度，必须测试精确配置。
分离式推理会降低 TTFT 吗？
它可以减少干扰和排队，但 KV 传输会增加延迟。只有节省的 Prefill 竞争超过路由与传输开销，TTFT 才会改善。
必须使用 RDMA 吗？
概念上不强制，但大规模跨节点 KV 移动通常需要 RDMA 或同等高速网络才能保持竞争力。应验证真实传输协议和回退行为。
Prefix Cache 如何影响设计？
Prefix Cache 可以减少 Prefill 计算，并让路由器偏向已有 KV 状态的 Worker。它可能降低远程 Prefill 需求，也可能提高 KV 感知调度价值。
vLLM 分离式 Prefill 适合所有生产负载吗？
不适合。不同版本的支持范围、拓扑、Connector 行为和运维成熟度不同。应遵循实际部署版本文档并实测，不能从“存在该功能”推导普遍生产就绪。
参考资料
- NVIDIA Dynamo Disaggregated Serving，访问于 2026-07-28。
- NVIDIA Dynamo 设计文档，访问于 2026-07-28。
- vLLM Disaggregated Prefilling，访问于 2026-07-28。