Prefill / Decode 分离：两种负载分开，怎样交接请求

01 · 两个阶段，为什么会互相干扰

Prefill一次处理已知提示词，通常有较大的token计算块；Decode在普通自回归模式下逐步读取历史KV，为各请求生成下一token。长Prefill插入正在Decode的执行轮次，可能使已有请求的输出间隔变长。两阶段最佳批量、并行度和内存预算也可能不同。

PD分离把两个阶段放到不同worker或资源池。模型里的Attention与MLP仍要算；变化的是谁执行、怎么排队、在哪里保存KV，以及两个执行者怎样交接。它属于系统执行优化。

依据：DistServe · 面向goodput的Prefill/Decode分离原始论文 ↗ · vLLM · 实验性PD分离与connector ↗

02 · 一个请求究竟怎样走过P与D

教学示意 · 不代表硬件实测

请求进入 → 路由到P worker
P：执行提示词Prefill，得到各层KV与首个生成token
交接：预留D侧缓存 → 传输KV及请求状态 → 确认可读
D：输入首个生成token，读取提示词KV → 预测第二个token
D：继续逐步Decode → 完成/取消 → 释放请求资源

例如提示词位置0–3，Prefill计算完后采样出A。此时KV只包含已经前向过的提示词，A通常还没有被写入KV。D必须拿到A，并在位置4执行其前向，才能预测B。不能把“输出首token”和“首token已进KV”当成一件事。

具体实现可由P先流式返回首token，也可等D准备好再对外输出，甚至采用不同边界约定。下面的算例明确选择P返回首token、D生成第二token；部署时必须核对后端的边界。

依据：Transformers · How Caching Works ↗ · CANN商用版8.5.0 · 单边通信库的PD分离应用 ↗

03 · 传的不是文本，而是可继续执行的状态

交接对象	为什么需要
各层历史KV	D需要已处理位置的K/V；一般不是只传最后一层。
已处理长度、位置及块映射	避免错误位置、漏读、跨请求读或重写历史。
下一步输入token	在本例中是P已采样的首tokenA。
模型/适配器/缓存格式身份	两侧权重、位置处理、dtype和KV解释要兼容。
请求与生成状态	请求ID及代次、采样配置、停止条件、约束状态；随机状态由采样归属方案决定。

P和D可有不同TP规模，但KV分片和头归属需要转换或重分布；原始设备地址也不能直接当成另一进程的有效块表。传输元数据说明源块和目标落点，运行时建立两侧可用映射。KV布局不兼容时，增加转换成本。

依据：Dynamo · Disaggregated Serving ↗ · vLLM · 实验性PD分离与connector ↗

04 · 算清一份KV跨池的成本

普通GQA教学模型：32层、8个KV头、每头128元素、2B/元素、4096个位置，完整KV为512MiB。有效网络通路25GiB/s时，一次完整传输的字节下界是20ms；8GiB/s则为62.5ms。这个账本排除了压缩、分片、协议、排队和转换。

在多TP rank上分摊这些字节，只有独立可用网络资源足够时才可能缩短关键路径。共同出口仍受总带宽限制。长上下文可能省掉P/D混部干扰，同时也带来更多KV传输，二者需要一起量化。

05 · 首token更早，不代表第二个token立刻跟上

自设时序：P计算40ms、D每步4ms、交接协调2ms。混部方案另有30ms排队/干扰等待；分离方案假设P/D无额外排队，但有512MiB/25GiB/s的20ms传输。混部首token70ms、第二token74ms；分离首token40ms、第二token66ms，首个生成间隔反而为26ms。

这里移除的30ms等待是明确的教学假设，不是分离必然省下的固定时间。若混部没有额外等待，第二token在44ms，而分离仍为66ms。后续D独立运行是否更稳定，需要多请求负载验证。

省掉的等待，够不够支付KV传输？

KV大小 MiB有效带宽 GiB/s混部额外等待J ms

P计算40 ms、D一步4 ms、分离协调2 ms。P先返回首token，整份KV随后交接；分离无额外排队，混部J只发生在P开始前。无压缩/流水/资源争用，不代表同资源实测。

仅报告TTFT会遗漏交接停顿；平均TPOT可能掩盖首个间隔与尾部异常。最好同时记录首token、第二token、各间隔分位数，以及传输开始/完成时刻。

06 · P:D比例不是一个固定最佳数字

长输入多、输出短时，P需求可能更高；短输入、输出长且并发多时，D持续占用与KV容量可能更关键。P/D并行策略、量化和设备配置可分别调优，但两侧重复的模型权重、独立池空闲和D侧KV容量都要计资源成本。

粗略稳定性条件可写成“到达的Prefill工作小于P池可完成工作，生成工作小于D池容量”；每个请求长度不同，真实调度不能只数请求个数。扩容P不解决D的KV不足，扩容D也不解决P的排队。

信号	可能的调整方向
P队列长期增长、D空闲	检查P算力/分块/副本，避免只给D加资源。
D活跃KV满、P仍接单	把准入与D容量联动，检查生成长度和可用并发。
传输排队增加	检查共同出口、并发迁移、源/目标缓冲与路由距离。
两池轮流闲置	检查请求长度分布与配比，评估混部/条件分离方案。

依据：Dynamo · Disaggregated Serving ↗ · DistServe · 面向goodput的Prefill/Decode分离原始论文 ↗

07 · 正确交接比“复制完KV”多一步

教学示意 · 不代表硬件实测

ticket = reserve_decode_capacity(request_id, generation_id, kv_bytes)
run_prefill(request)
transfer = send_kv_and_state(ticket, compatible_metadata)
# 保留源KV与目标槽，直到传输和设备访问满足完成条件
wait_until_required_blocks_ready(transfer)
commit_decode_ownership(ticket)
start_decode(next_token, processed_length, target_block_table)
# 失败/取消时按请求代次清理；不要复活已取消请求。

先预留D侧容量，避免P算完却无处交接。维护传输ticket和请求代次，处理取消、重复通知、worker重启与超时；旧代次的完成消息不能提交到新请求。源块要等传输读完才能回收，目标块要等D访问结束才能复用。

阅读现成实现时，可沿vLLM connector接口或Dynamo的路由/传输元数据进入；NIXL是数据传输抽象入口，不能把它与某个集合AllReduce接口混为一谈。教学脚本模拟所有权与状态，真实启动按框架版本官方示例配置。

依据：vLLM · 实验性PD分离与connector ↗ · Dynamo · Disaggregated Serving ↗ · PyTorch 2.14 · CUDA stream、等待与内存生命周期 ↗

08 · 与哪些基线比较，才知道分离是否值得

固定总设备数量或资源成本，比较混部连续批处理、合适Chunked Prefill和PD分离。
使用同请求到达轨迹与输入/输出长度分布，报告吞吐及满足TTFT/间隔目标的请求吞吐。
报告两池队列、KV容量、设备利用、权重副本和网络字节；不要以增加设备后的总吞吐证明每设备提速。
验证完整/分离结果，覆盖不同TP布局、前缀缓存、模型版本、取消与回迁失败。

vLLM的实验性分离说明强调延迟调优，并未把吞吐提升作为保证；DistServe等研究关注特定资源和延迟约束下的goodput。不同实现结论不能泛化为“所有场景都更快”。

依据：vLLM · 实验性PD分离与connector ↗ · DistServe · 面向goodput的Prefill/Decode分离原始论文 ↗

09 · NVIDIA 与昇腾都需要传输与状态协议

NVIDIA阅读路径可从Dynamo/NIXL和对应引擎connector进入；昇腾CANN文档给出单边通信库在PD分离中的KV传输及链路管理用途。两侧都需检查格式、TP布局、Host/Device缓冲及完成语义；不能仅凭“支持PD”比较端到端性能。

依据：CANN商用版8.5.0 · 单边通信库的PD分离应用 ↗ · Dynamo · Disaggregated Serving ↗

Prefill采样出了A，提示词KV里有没有A？D的第一个输入是什么？
如果混部额外等待为0，交互例子中分离为什么更慢？
怎样防止已取消请求的旧传输完成通知，让D重新开始生成？

流程位置与关联方法

这个方法可能出现在多个位置；计算线包含模型计算与算子实现，执行线包含运行时、内存和通信。

I-B0 · 服务初始化与预热 I-B4 · 准备输入与管理 KV I-B5 · 执行计算与必要的通信

资料与核查范围

原理依据以原始论文和官方文档为主；算例与时间线是教学推导。文档核查日期：2026-10-10。引用 main / latest 文档时，实际接口以安装版本为准。

代码为接入片段或教学伪代码；本页没有声称完成 NVIDIA / 昇腾硬件实测。