Prefill-Decode 解耦一定能提升吞吐吗？

不一定。它的核心价值是把 TTFT 与 ITL/TPOT 分开治理，降低阶段互相干扰和尾延迟。吞吐是否提升取决于 KV 传输成本、负载形态和资源比例，vLLM 文档也明确标注 disaggregated prefill 不直接提升吞吐。

为什么长上下文场景更需要 P/D 解耦？

长上下文会放大 prefill 阶段的计算开销，并产生更大的 KV Cache。若 prefill 与 decode 混跑，新的长 prompt 容易拉高正在生成请求的 token 间隔，导致用户感知的输出卡顿。

上线前最应该压测什么？

至少要压测 TTFT、TPOT/ITL 的 p95/p99 尾延迟、KV 传输耗时、不同输入输出长度分布，以及 prefill/decode 资源比例变化（如 1:1、1:2、1:3）。还需覆盖 bursty traffic 与多轮 Agent 混合场景。

P/D 解耦和 PagedAttention 是替代关系吗？

不是。PagedAttention 主要解决单引擎内部 KV Cache 显存管理和 batching 效率，P/D 解耦解决 prefill 与 decode 两种负载的阶段隔离、资源独立扩缩和尾延迟治理。二者可共存。

Prefill-Decode 解耦实战：长上下文大模型服务的延迟治理

背景：推理优化已从「单次更快」转向「阶段隔离」

过去几年，大模型推理优化的关键词绕不开 continuous batching、PagedAttention、量化、KV Cache 复用和 Speculative Decoding。这些技术聚焦于单个推理引擎内部的吞吐、显存和 token 生成效率。

但当业务进入长上下文、RAG、代码仓库问答、多轮 Agent 和批量文档处理之后，另一个矛盾浮出水面：同一批 GPU 同时处理 prompt 预填充和逐 token 生成时，两个阶段会相互干扰。

大模型在线推理天然包含两个阶段：

阶段	特点	瓶颈
Prefill	一次性计算全部输入 token 的注意力状态，生成 KV Cache	计算密集，输入越长负担越重
Decode	基于已有 KV Cache 逐 token 生成输出	memory bandwidth 与调度稳定性

两个阶段混在同一 GPU 池时，新的长 prompt 进入会挤占正在 decode 的请求。Hao AI Lab 对 DistServe 的回顾将此概括为 prefill-decode interference：新的 prefill 要么暂停 decode，要么与 decode 混批，两者都会拉高 decode latency。vLLM 文档也明确指出，disaggregated prefilling 的目标是分别调优 TTFT 和 ITL，并控制尾部 ITL，而非简单宣称吞吐一定提升。

核心问题：TTFT 与 TPOT 不是同一个优化目标

在线 LLM 服务有两个关键用户体验指标：

TTFT（Time To First Token）：用户发出请求到看到第一个 token 的时间
TPOT / ITL（Time Per Output Token / Inter-Token Latency）：生成过程中每个 token 的间隔

两者的工程含义截然不同：

指标	敏感因素
TTFT	输入长度、prefill 算力、队列等待、prefix cache 命中率
TPOT/ITL	decode batch 大小、KV Cache 读写、显存带宽、调度抖动

把它们放在同一资源池时，调度器被迫折中——优先降低 TTFT 可能拉高解码请求的 ITL，保护 decode 又让新请求排队拉长 TTFT。

Prefill-Decode 解耦的基本思路就是：不要让两种不同负载在同一资源池争抢。把 prefill 和 decode 分别交给不同实例、不同 GPU 池，甚至不同硬件形态，通过 KV Cache 传输连接两个阶段。

这不是「多起几个服务」那么简单。真正的挑战在于：

prefill 生成的 KV Cache 必须可靠、低延迟地传给 decode
请求调度必须知道哪个 decode worker 能拿到对应 KV
prefill/decode 资源比例需根据输入输出长度和 SLO 动态规划
传输链路不能成为新瓶颈

核心原理：把一次请求拆成两个可独立扩缩的阶段

一个典型的 P/D 解耦请求流程：

1. API Gateway / Router 接收请求
         ↓
2. Scheduler 按输入长度、SLO、缓存命中 → 送入 Prefill Worker
         ↓
3. Prefill Worker 计算隐藏状态和 KV Cache
         ↓
4. KV Connector 将 KV Cache 传输给 Decode Worker
         ↓
5. Decode Worker 读取 KV Cache → 逐 token 生成
         ↓
6. Router 将结果流式返回用户

vLLM 的 disaggregated prefilling 给出了清晰的工程模型：运行两个 vLLM 实例（一个 prefill instance，一个 decode instance），通过 Connector、LookupBuffer 和 Pipe 完成 KV Cache 的传输与匹配。这本质上是把 LLM serving 从一个推理引擎升级为一个小型分布式系统——收益来自隔离，成本也来自分布式。

为什么 2025–2026 年这条路线变得重要

2025 年后，P/D 解耦不再是学术论文里的架构设想。Hao AI Lab 在 2025 年 11 月的回顾中指出，几乎所有生产级 LLM serving 框架都开始拥抱某种形式的 disaggregation，包括 NVIDIA Dynamo、SGLang、vLLM、LMCache 和 Mooncake。

2026 年的研究进一步把问题推向资源规划和跨集群形态：

SLO-Aware Compute Resource Allocation 把问题形式化为：在总吞吐、SLO、输入输出长度分布约束下，如何决定 prefill 和 decode 的资源数量
Large-Scale LLM Inference with Heterogeneous Workloads 从排队网络和调度控制角度讨论异构负载下的 prefill/decode 竞争
Prefill-as-a-Service 探索将长上下文 prefill 外置到独立集群，再将 KV Cache 传回本地 decode 集群

这些工作共同说明一个趋势：LLM 推理优化的单位正在从 kernel、单卡、单实例，上升到资源池、网络和调度策略。

工程落地：从单实例演进到 P/D 解耦

第一步：先把指标拆开

不要一上来就改架构。先把现有服务的观测拆成以下几组：

TTFT：按输入长度分桶（0–1K、1K–4K、4K–16K、16K+）
TPOT/ITL：按输出长度和并发量分桶
p95/p99 尾延迟：单独观察，不只盯平均值
队列时间：prefill queue time 与 decode queue time 分开记录
资源指标：GPU utilization、memory bandwidth、KV Cache 占用与命中率

只有当你确认「长 prompt 或 bursty prefill 正在拉高 decode 尾延迟」时，P/D 解耦才有明确的收益目标。

第二步：先做逻辑解耦，再做物理解耦

早期不要急于跨节点传输 KV。建议在同节点、同高速互联域内先做 prefill/decode worker 分离，降低工程变量：

单实例 continuous batching
chunked prefill 缓解长 prompt 对 decode 的冲击
同节点 P/D 分离，使用高带宽链路传 KV
多节点 P/D 分离，引入 KV-aware router
KV Cache 存储层或多级缓存，支持跨实例复用
异构资源池：计算型资源偏 prefill，带宽型资源偏 decode

vLLM 文档提示：chunked prefill 在合适 chunk size 下可达到类似控制 tail ITL 的效果，但实际调参并不容易；disaggregated prefilling 更可靠，但标注为 experimental，且不直接提升吞吐。

第三步：把 KV Cache 当作一等公民

P/D 解耦的关键资产不是请求体，而是 KV Cache。一旦拆分，KV Cache 从进程内状态变成跨 worker 传输的数据面。必须设计四件事：

维度	关键问题
KV 标识	请求/prefix/batch 的 KV 如何命名、查找、过期
KV 路由	decode worker 如何知道从哪里读取 KV
KV 传输	走 NVLink、InfiniBand、PCIe、以太网还是混合层级
KV 生命周期	何时释放、失败后如何清理、是否允许多请求复用

LMCache 把 KV Cache 暴露在 LLM engine 接口层，将引擎从「独立 token processor」转向「以 KV Cache 为存储与通信媒介的 engine 集合」。这对企业级部署尤其重要——真实业务中 prompt prefix 往往高度重复（系统提示词、工具说明、文档模板、Agent 轨迹前缀）。

第四步：资源比例不要拍脑袋

P/D 解耦后最常见的问题：prefill 池和 decode 池各放多少 GPU？

答案取决于业务流量分布。一个简化估算模型：

prefill_load ≈ request_qps × avg_input_tokens / prefill_tokens_per_second
decode_load  ≈ request_qps × avg_output_tokens / decode_tokens_per_second

然后用 p95 输入长度、p95 输出长度、SLO 约束进行修正。长上下文业务的长度分布通常是重尾的，少量超长请求就可能决定尾延迟表现。2026 年的 SLO-Aware P/D resource allocation 研究也采用「理论建模 + 实测 benchmark」的路径：先估算，再通过 TTFT、TPOT 等 SLO 约束校正。

适用场景

P/D 解耦更适合以下几类业务：

长上下文 RAG：检索片段 + 系统提示词 + 用户问题拼接后 prompt 可达数千到数万 token，prefill 成本高且波动大
代码仓库问答与代码生成：长输入和长输出并存，TTFT 和 TPOT 都要关注
多轮 Agent：携带系统提示词、工具描述、历史轨迹和中间结果，prefix cache 和 append-prefill 都影响架构选择
多租户推理平台：不同租户的输入输出长度、SLO、价格模型差异大，P/D 解耦支持更细粒度的资源隔离与弹性伸缩
超大规模 GPU 集群：数百甚至上千 GPU 时，统一资源池放大调度干扰，P/D 解耦允许按阶段独立扩缩

不适用或需谨慎的场景

输入短、输出短、QPS 不高的业务：单实例 continuous batching + PagedAttention + prefix cache 可能已足够
网络条件弱的场景：KV Cache 传输会成为瓶颈
缺乏基础观测能力的团队：没有 TTFT、TPOT、队列时间和 KV 传输耗时的拆分，就无法定位问题根因

常见误区

误区	真相
P/D 解耦一定提升吞吐	vLLM 文档明确标注不提升吞吐，核心价值是尾延迟治理
拆两个服务就是 P/D 解耦	必须处理 KV Cache 的传输、匹配、生命周期和失败恢复
只按平均长度规划资源	长上下文业务看 p90/p95/p99，均值掩盖长尾
忽略多轮 append-prefill	多轮中并非每次都需要完整 prefill，PPD Disaggregation 研究指出某些 turn 2+ 可在 decode 节点本地处理

上线检查清单

指标与压测

按输入长度、输出长度、租户、模型类型拆分 TTFT
单独监控 TPOT/ITL 的 p50/p95/p99
记录 prefill queue time、decode queue time、KV transfer time
覆盖 bursty traffic、长上下文、短问短答、多轮 Agent 的混合压测
做过资源比例 sweep（如 1:1、1:2、1:3）

KV Cache

KV key 可追踪，有 TTL 和清理机制
prefill 成功但 decode 失败时 KV 不泄漏
decode worker 重启后可重新拉取或放弃对应 KV
KV 传输失败时有重试/降级/失败策略

调度与路由

Scheduler 知道请求的输入长度、预估输出长度和 SLO
Router 是 KV-aware 的
有长 prompt admission control 和租户级限流
避免 decode worker 被瞬时 prefill KV 洪峰压垮

发布与回滚

支持灰度到部分模型或租户
保留原 colocated serving 回滚路径
可在 Dashboard 中对比解耦前后的 TTFT、TPOT 和 GPU 利用率

一个可落地的参考架构

Client / SDK → API Gateway → SLO-aware Router
                                  ↓
                Prefill Pool ← → KV Transfer / KV Store ← → Decode Pool
                                                              ↓
                                                     Streaming Response
                                       ↑
                                  Observability

关键模块职责：

API Gateway：认证、租户识别、请求大小限制、流式响应管理
SLO-aware Router：根据输入长度、租户等级、模型、缓存命中决定路由
Prefill Pool：偏计算密集，可选用适合 prompt processing 的并行策略
KV Transfer / KV Store：负责 KV 的传输、缓存、复用、过期和清理
Decode Pool：偏稳定生成和带宽利用，重点保护 TPOT/ITL
Observability：对 TTFT、TPOT、KV transfer、队列、失败率做全链路追踪

对于中小规模团队，第一版优先在同机房、同高速网络域内做最小闭环，验证尾延迟收益后再逐步引入多级 KV 缓存和异构资源池。

结论：P/D 解耦是延迟治理架构，不是单点性能开关

Prefill-Decode 解耦的价值不在于把服务拆得更复杂，而在于承认大模型推理的两个阶段具有不同的资源画像和不同的用户体验指标。

当业务进入长上下文、多轮 Agent、多租户和高并发阶段，单一 GPU 池很容易在 TTFT、TPOT、吞吐和成本之间互相牵制。P/D 解耦提供了一种更可控的架构：让 prefill 专注处理上下文，让 decode 专注稳定生成，让 KV Cache 成为连接两者的一等数据面。

但它也带来新的工程成本。上线前必须回答三个问题：

你的尾延迟问题是否真的来自 prefill/decode 干扰？
你的 KV Cache 传输链路是否足够快、可观测、可恢复？
你的资源比例是否基于真实输入输出长度和 SLO 压测，而不是经验猜测？

如果答案是肯定的，P/D 解耦会成为长上下文 LLM 服务从「能跑」走向「稳定、可扩展、可控成本」的关键架构。

主要参考资料

vLLM Documentation, Disaggregated Prefilling: https://docs.vllm.ai/en/latest/features/disagg_prefill/
Hao AI Lab, Disaggregated Inference: 18 Months Later: https://haoailab.com/blogs/distserve-retro/
Li et al., SLO-Aware Compute Resource Allocation for Prefill-Decode Disaggregated LLM Inference: https://arxiv.org/abs/2603.04716
Lin et al., Large-Scale LLM Inference with Heterogeneous Workloads: https://arxiv.org/abs/2602.02987
Zhang et al., SPAD: Specialized Prefill and Decode Hardware for Disaggregated LLM Inference: https://arxiv.org/abs/2510.08544
Cheng et al., LMCache: An Efficient KV Cache Layer for Enterprise-Scale LLM Inference: https://arxiv.org/abs/2510.09665
Qin et al., Prefill-as-a-Service: https://arxiv.org/abs/2604.15039
Li et al., Not All Prefills Are Equal: PPD Disaggregation for Multi-turn LLM Serving: https://arxiv.org/abs/2603.13358