详细解释
预填充解码分离，简称 PD 分离，英文为 Prefill-Decode Disaggregation，是大模型在线推理架构层面的一次结构性改造。它把推理链条里计算特征截然相反的两个阶段——预填充（Prefill）与解码（Decode）——从「同一批 GPU、同一个批次里混跑」改成「放到两组独立的 GPU 节点池上分别执行」，中间用高速互联把 Prefill 算好的 KV 缓存 搬运给 Decode 池。之所以非拆不可，是因为两个阶段对硬件的诉求几乎相反：Prefill 要一次性读完整段输入 prompt、对全部输入 Token 做注意力计算，是典型的算力密集任务，吃的是 GPU 的浮点算力上限，直接决定首 Token 延迟 TTFT；Decode 每一步只生成 1 个 Token，算力根本用不满，瓶颈在于把整条请求的 KV 缓存反复从显存里读出的访存带宽，是显存带宽密集任务，决定相邻 Token 间隔 TPOT 与整体吞吐。两个阶段硬塞在同一批卡上，注定互相拖累。
具体到硬件特征差异，Prefill 的算术强度高、能有效打满 Tensor Core，适合高浮点算力的加速卡，而且它天然可批处理——多条请求的 prompt 能拼成一个大矩阵一次算完；Decode 每一步的计算量极小，大量时间花在把 KV 从高带宽显存搬进计算单元，算力利用率常常只有 5% 至 15%，它的效率取决于显存带宽而非算力。矛盾就出在同卡混跑（Colocated）时：一条 32K Token 的长 prompt 进来做 Prefill，会在一次前向里长时间独占 SM 与算力，正在流式输出的 Decode 请求只能干等，用户看到的就是「打字机卡住」，TPOT 抖动剧烈、P99 延迟分位数 飙升。PD 分离把两类计算彻底解耦到不同池：Prefill 池倾向用较小张量并行换取更多实例数、追求吞吐，Decode 池倾向用较大张量并行配合 KV 分页与量化、追求显存带宽利用率。各自拿到最合适的硬件配比，正是分离架构相较混合部署最大的结构性优势——牺牲的是一部分资源弹性与部署简洁性，换来的是延迟分布的确定性。
工业落地方面，PD 分离已从论文走向生产：DistServe（见 DistServe 论文）与 Splitwise 最早系统化提出该思路，Mooncake 等工业实践进一步验证了长上下文场景下的吞吐收益，vLLM 与 SGLang 也都提供了生产可用的 PD 分离模式（见 vLLM 官方文档）。2026 年公开档的典型收益是：长上下文、高并发场景下 TTFT 的 P99 下降 40% 至 70%，整体吞吐提升 20% 至 40%，代价是多了一跳 KV 传输与两套资源池的运维复杂度。唯元智创 的推理网关把 PD 分离与 连续批处理、分页注意力 打包成默认推理优化组合，按业务实测的 Prefill 与 Decode 消耗比例自动分配两池实例数，并在峰值时段弹性扩容 Decode 池，让企业在不自研传输与调度组件的前提下拿到稳定的长尾延迟。
Prefill 与 Decode 两阶段特征对比表
| 阶段 / 场景 | 计算特征 | 瓶颈资源 | 单次处理 Token 数 | 对延迟影响 | 典型硬件偏好 | 是否可批处理 |
|---|---|---|---|---|---|---|
| Prefill（预填充） | 算力密集，算术强度高 | GPU 浮点算力与 Tensor Core 利用率 | 一次处理整段输入，常见 1K 至 128K | 决定 TTFT 首 Token 延迟 | 高浮点算力加速卡 | 可以，多条 prompt 拼批 |
| Decode（解码） | 显存带宽密集，算力利用率低 | 显存带宽与 KV 读取速度 | 每步产出 1 个 Token | 决定 TPOT 与流式流畅度 | 高显存带宽、大显存容量卡 | 可以，靠连续批处理拼批 |
| 混合部署中的 Prefill | 同上，但会独占 SM | 触发解码请求排队 | 取决于同批最长 prompt | 同时抬高 TTFT 与 TPOT | 无差别，只能折中 | 会打断同批 Decode |
| 混合部署中的 Decode | 同上，但被 Prefill 抢占 | SM 与算力被 Prefill 挤占 | 每步 1 个 Token | TPOT P99 抖动可达数百毫秒 | 无差别 | 受长 prompt 干扰严重 |
| PD 分离后的 Prefill 池 | 专注算力密集计算 | 浮点算力可被充分打满 | 一次或分块处理输入 | TTFT 稳定、可预测 | 高浮点算力卡，实例数多 | 可以，且不受解码干扰 |
| PD 分离后的 Decode 池 | 专注显存带宽计算 | 显存带宽与 KV 容量 | 每步 1 个 Token | TPOT P99 稳定在低位 | 高带宽、大显存卡 | 可以，连续批处理打满 |
推理部署架构对比表
| 架构 | GPU 资源配比 | 长上下文 P99 稳定性 | 部署复杂度 | KV 传输开销 | 适用场景 | 典型框架支持 |
|---|---|---|---|---|---|---|
| 同卡混跑（Colocated） | 单一池，Prefill 与 Decode 共享 | 差，TPOT P99 抖动可达数百毫秒 | 低，开箱即用 | 无 | 短请求为主、低 QPS | vLLM、SGLang、TensorRT-LLM 默认 |
| Chunked Prefill 缓解 | 单一池，按 Token 预算编排批次 | 中，TPOT P99 压到 80 至 150 毫秒 | 低，改配置即可 | 无 | 单机部署、长短混合 | vLLM、SGLang 原生支持 |
| PD 分离（独立 Prefill 池 加 Decode 池） | 两套池，P 与 D 配比常见 1 比 2 至 1 比 8 | 好，TPOT P99 稳定在 40 至 80 毫秒 | 高，需高速互联与传输库 | 中，依赖 NVLink 或 RDMA | 高 QPS、长上下文、延迟敏感 | vLLM、SGLang 提供 PD 模式 |
| PD 分离 加 KV 分级存储（GPU 到 CPU 到 SSD） | 两套池 加 分级存储层 | 很好，P99 进一步下降且支持超长上下文 | 很高，需存储与调度协同 | 高，多级搬运需精细调优 | 超大规模、超长上下文 | Mooncake 等工业方案 |
| 唯元智创 默认组合 | 网关托管，按业务实测自动配比 | 好，TPOT P99 稳定在 40 至 70 毫秒 | 中，平台托管免自研 | 中，平台侧优化传输 | 企业多租户、RAG 与 Agent | 网关统一纳管 |
实战经验与避坑
-
只有 P 与 D 比例失衡、长上下文占比高时才值得上 PD 分离，短请求为主时收益可能为负：判断是否上分离，核心看两条曲线：一是 Prefill 与 Decode 的算力消耗比例，二是输入长度的分布（尤其是 P95 与 P99）。如果业务以短 prompt 为主、QPS 不高，长 prompt 极少出现，那么同卡混跑本就没有明显干扰，上 PD 分离只会白白增加一跳 KV 传输和两套资源池的运维成本，2026 年公开档的经验是这类场景分离后单位 Token 成本反而上升 10% 至 25%。反之，若 P95 输入超过 2K Token 且峰值 QPS 在 50 以上，长 prompt 频繁打断解码，分离的收益才稳定为正。务实建议是先把同卡混跑加 Chunked Prefill 的基线跑满，用真实流量回放确认「长尾延迟确实被 Prefill 干扰拖垮」之后再动分离。
-
KV 传输必须走 NVLink 或 RDMA，走 PCIe 或普通 TCP 会把收益全部吃光：这是 PD 分离翻车最常见的根因。KV 的搬运量等于层数 乘 2（Key 与 Value）乘 注意力头数 乘 头维度 乘 序列长度 乘 每元素字节数。以 70B 模型 FP8 KV 为例，每个 Token 的 KV 约 320KB 至 640KB，一条 4K Token 请求要搬 1.3GB 至 2.6GB。走 100Gbps 普通以太网，实测有效带宽往往只有 8GB 至 10GB 每秒，单条就要多等 130 毫秒以上；换 400Gbps RDMA 或 NVLink 后，同样体量只需几毫秒到十几毫秒。工程底线是让两池尽量共置同一超节点或同一机架，节点内优先 NVLink 直连，跨节点至少 RDMA 组网，并选用支持零拷贝的传输库；若机房只有 PCIe 或普通 TCP，宁可退回单机的连续批处理加分块预填充，也不要强行上分离架构。
-
Prefill 池与 Decode 池的实例配比要按业务实测，常见 1 比 2 至 1 比 8，不要照抄别人的比例：典型在线业务里 Prefill 的算力消耗约占三成、Decode 占七成，但 Prefill 更吃算力、Decode 更吃显存带宽，因此一个 Prefill 实例通常要配多个 Decode 实例。业界实测典型区间是 1 比 2 至 1 比 8，具体取决于平均输入长度与平均输出长度之比：长输入短输出的业务，Prefill 占比会升到五成以上，配比要往 1 比 1 甚至 1.5 比 1 调；短输入长输出的业务，Decode 压力更大，配比要往 1 比 6 甚至 1 比 8 调。上线前建议用 30 分钟等比压测拟合出自己业务的真实配比，并把它写进自动扩缩容策略；实测中把配比从拍脑袋的 1 比 1 调到贴合业务的 1 比 3，同一集群的 TTFT P99 常能再降 15% 至 25%，总卡数还能省 10% 左右。
-
一定要给 Decode 池留足 KV 显存预算，避免 KV 页被 Prefill 传输挤压：分离之后，Prefill 池算完的 KV 要写进 Decode 池的显存，如果 Decode 池的显存被权重与预留空间吃掉太多，KV 页就会频繁换出换入，反而增加 TPOT 抖动。经验做法是给 Decode 池按并发上限预留充足的 KV 显存，通常把可分配给 KV 的比例提到总显存的 50% 至 70%，并开启分页管理避免碎片；同时把 Prefill 传输的写入速率与 Decode 的读取速率错峰，防止同一时刻争抢显存带宽。若业务并发波动大，还要按峰值并发估算 KV 容量，宁可多留余量也别贴着上限跑，否则一次长 prompt 洪峰就可能触发显存不足与请求排队，前功尽弃。
-
分离后必须独立做两池的扩缩容与故障隔离，避免单点串扰：把两个阶段拆到不同池，意味着它们可以也应该独立伸缩——按队列深度分别对 Prefill 池与 Decode 池设置扩缩容规则，Decode 池跟随并发数变化、Prefill 池跟随输入 Token 速率变化，两者节奏不同。更重要的是故障隔离：一个池的抖动或重启不应拖垮另一个池，网关要为两池分别配置健康检查、熔断与降级策略，当 Prefill 池过载时把新请求排队或降级到混合部署实例，当 Decode 池过载时限流或缩减单请求输出上限。实测中，不做隔离的集群经常出现「Prefill 池一次扩容抖动，把 Decode 池的健康检查也带崩」的连锁故障，而做了隔离后整体可用性明显提升。
-
监控指标必须拆成 Prefill 时长、KV 传输时长、Decode TPOT 三段，否则定位不到瓶颈：分离架构把一条请求的耗时切成了三截，如果只在网关层看一个总延迟，出问题时根本不知道慢在哪一段。正确做法是分别在 Prefill 池记录 Prefill 计算时长、在传输层记录 KV 搬运时长与带宽利用率、在 Decode 池记录 TPOT 的分位数，再把三段拼成端到端视图。常见坑是「总延迟上涨」其实来自 KV 传输排队，而不是任何一段计算变慢；也可能是 Prefill 池排队导致 TTFT 上涨而 Decode 侧完全正常。只有三段拆开看，才能判断该扩容哪个池、该优化哪条链路，而不是盲目加卡。