第6章：Prefill/Decode 解耦架构

Prefill 和 Decode 的计算特性截然不同(Compute Bound vs Memory Bound),混在一起会互相干扰——长 Prefill 拖慢 Decode 的 P95,Decode 也无法吃满 Prefill 阶段的算力。本章深入 PD 解耦架构:为什么需要、DistServe / Splitwise 如何实现、Goodput 与 SLO 感知调度,以及解耦带来的新问题(KV 跨节点迁移)。

📑 目录

1. PD 互扰的本质
2. PD 解耦的设计
3. DistServe:系统化论证
4. Splitwise:Phase Splitting
5. Goodput 与 SLO 调度
6. 解耦的新挑战:KV 迁移
7. P/D 资源配比推导
自我检验清单
参考资料

1. PD 互扰的本质

1.1 两阶段特性回顾

阶段	Q 序列长度	算力利用	主要瓶颈	单 token 耗时
Prefill	几百-几千	高	Compute	~10-200 ms 一次性算完
Decode	1	低	Memory	~10-50 ms 每 token

1.2 混合 Batching 的问题

Continuous Batching 把 Prefill 请求和 Decode 请求混在一个 batch 里:

Iteration 1: [Decode A][Decode B][Prefill C 4096 token]   ← C 拖了 200ms
Iteration 2: [Decode A][Decode B][Decode C 第 1 个 token]

Iteration 1 这一步,Decode A 和 B 都被迫等了 200ms——TPOT P95 飙升。

1.3 量化互扰程度

A100 上,LLaMA-7B,Decode 单步 ~30ms,Prefill 4K token ~150ms。

场景	TPOT P50	TPOT P95
纯 Decode	30 ms	35 ms
混合(20% Prefill)	50 ms	150 ms

P95 被拖慢 4-5×——这就是解耦的动机。

2. PD 解耦的设计

2.1 核心思想

把 Prefill 和 Decode 物理分到不同 GPU 池:

┌──────────────┐                ┌──────────────┐
│ Prefill Pool │ ── KV 迁移 ──> │  Decode Pool  │
│ (4 张 GPU)    │                │ (12 张 GPU)   │
└──────────────┘                └──────────────┘
       ↑                               │
   新请求                          流式输出

收益:

Prefill 池专注 compute bound,可以用更激进的 batching
Decode 池专注 memory bound,可以用更大的并发
两边互不干扰,TPOT P95 大幅改善

2.2 配比

Prefill 和 Decode 的 GPU 数比例取决于负载:

若平均输入 2000 token、输出 500 token,且
Prefill 算 2000 token 比 Decode 算 1 token 快(compute bound vs memory bound):
  P_compute_time = 100 ms
  D_compute_time per token = 30 ms
  D_total = 30 × 500 = 15000 ms

资源比 ≈ 15000 / 100 = 150
但 Prefill 一次处理多请求,实际配比常 1:3 ~ 1:5

3. DistServe:系统化论证

3.1 论文核心贡献

系统证明:解耦比混合在合理负载下 goodput 高 1.5-7×
提出基于 SLO 和负载的资源分配算法
实现了一套完整的 PD 解耦系统

3.2 架构

Router
  ↓
Prefill Workers (一个池)
  ↓ KV migration (RDMA)
Decode Workers (另一个池)

3.3 资源分配算法

DistServe 提出一个优化问题:给定 SLO(TTFT, TPOT)和负载,找出最大化 goodput 的 (P, D) 配置。

包括:

Prefill 的并行策略(TP / PP)
Decode 的并行策略
P 和 D 的实例数

实际部署时这些是离线 profile + 在线动态调整。

4. Splitwise:Phase Splitting

4.1 微软方案

类似 DistServe,Splitwise 重点关注:

不同硬件配比:Prefill 用 H100(算力),Decode 用 A100(性价比)
KV 迁移用 InfiniBand 直接 GPU-to-GPU

4.2 异构硬件优势

Prefill GPU:   H100(高算力,贵)
Decode GPU:    A100 / L40(够用,便宜)

成本可降 30-50%。这就是云厂商最关心的优化。

5. Goodput 与 SLO 调度

5.1 Goodput 定义

\text{Goodput} = \frac{\text{满足 SLO 的请求数}}{\text{时间}}

vs Raw QPS:QPS 高但 latency 飙升时,用户体验崩了 → Goodput 反而下降。

5.2 SLO 定义

SLO 项	典型值	含义
TTFT P95	< 500 ms	用户等首 token 的容忍
TPOT P95	< 50 ms	持续生成的流畅度
端到端 P99	< 5 s	极端情况兜底

5.3 SLO 感知调度

调度器要回答:“接下来这个请求,如果接进来,我能保证它满足 SLO 吗?”

能 → 接入
不能 → 拒绝 / 降级 / 路由到其他实例

这要求:

实时估算每个 worker 的剩余容量
预测新请求的 prefill 和 decode 耗时

TaiChi(2025)论文统一了”聚合”和”解耦”两种模式,根据负载动态切换,goodput 进一步提升 30-50%。

6. 解耦的新挑战:KV 迁移

6.1 问题

Prefill 算完产生几 GB 的 KV Cache,要从 Prefill GPU 传到 Decode GPU,跨节点传输是新增开销。

6.2 KV 大小

LLaMA-7B,prompt 2048 token,FP16 KV ≈ 4 GB。

6.3 传输方式

方式	带宽	4GB 传输时间
TCP (10GbE)	1 GB/s	4 s ❌
InfiniBand HDR (200Gbps)	25 GB/s	160 ms
InfiniBand NDR (400Gbps)	50 GB/s	80 ms
GPU Direct RDMA (NVLink + RDMA)	~100 GB/s	40 ms

🌟 结论:PD 解耦必须有 IB + GPU Direct RDMA,否则 KV 迁移开销会吃掉解耦带来的收益。

6.4 Layer-wise 流式传输

进一步优化:Prefill 算完一层就立刻开始传,不等全部完成——把 KV 迁移和 Prefill 计算 overlap。

Layer 1: [Prefill 算]──> [传到 Decode]
Layer 2:           [Prefill 算]──> [传到 Decode]
...

6.5 Mooncake / DistServe 实践

Moonshot 的 Mooncake 把这套思想做到极致:

KV 池作为独立服务
Prefill / Decode / KV 三层分离
长上下文场景下 KV 复用率极高

7. P/D 资源配比推导

7.1 简单模型

设:

Prefill 单请求耗时 $T_p$
Decode 单 token 耗时 $T_d$
平均输出长度 $L$
Prefill 池 $N_p$ 张卡,Decode 池 $N_d$ 张卡

要让两边吞吐均衡:

\frac{N_p}{T_p} = \frac{N_d}{T_d \cdot L}

得:

\frac{N_p}{N_d} = \frac{T_p}{T_d \cdot L}

7.2 实例

LLaMA-7B,prompt 2000 token,output 500 token:

$T_p$ = 100 ms
$T_d$ = 25 ms
$L$ = 500

\frac{N_p}{N_d} = \frac{100}{25 \times 500} = \frac{1}{125}

意思是:125 张 Decode 卡才需要 1 张 Prefill 卡——但实际由于 Prefill 可以 batch 多请求(每张卡同时处理多个),实际配比通常 1:3 ~ 1:8。

7.3 动态调整

负载随时间变化:

早高峰 prompt 长 → 多分 Prefill
长输出场景(创作、推理)→ 多分 Decode

实际系统都会做动态资源分配。

✅ 自我检验清单

📚 参考资料

论文

DistServe (Zhong et al., OSDI’24):https://arxiv.org/abs/2401.09670
Splitwise (Patel et al., ISCA’24):https://arxiv.org/abs/2311.18677
TaiChi (2025):聚合与解耦统一框架
Mooncake (Moonshot, 2024):https://arxiv.org/abs/2407.00079
DeepSpeed-FastGen:Dynamic SplitFuse:https://arxiv.org/abs/2401.08671

教程

Disaggregated Inference: 18 Months Later —— 综述文章
MLC microserving —— 跨引擎编排
方佳瑞:LLM 推理 PD 解耦深度解析 —— 知乎

系统级综述

AI Systems Performance Engineering（Chris Fregly, O’Reilly 2025）:learning.oreilly.com —— Ch9 多节点推理优化讨论 vLLM / TensorRT-LLM / Dynamo 选型与请求路由,与本章 PD 解耦的 goodput 视角互补

搜索