Prefill/Decode 分离

Prefill/Decode 分离(PD Disaggregation)= 把一次推理请求的两个阶段拆到不同类型的实例上:Prefill 阶段一次并行处理整段 prompt,是矩阵-矩阵运算(GEMM),计算密集、并行度高,GPU 算力利用率高;Decode 阶段逐 token 生成,每步只有 1 个 token 的矩阵-向量运算(GEMV),是带宽密集——每步都要读完整套权重但只产出 1 个 token,GPU 利用率低。分离后 Prefill 实例负责把 prompt 算成 KV Cache,再通过高速网络(RDMA/InfiniBand)把 KV 传给 Decode 实例,Decode 实例专职按批做低延迟生成。调度侧: 两类实例独立扩缩容,Decode 实例按已占用 KV 大小/序列长度做负载均衡(而非连接数),支持 token 级调度与 KVC 传输管线化。

高并发在线服务(混合长 prompt 与长输出的对话/Agent 场景),要求同时压低 TTFT 与 ITL;vLLM/SGLang 原生支持 PD 分离,DeepSeek 等头部厂商线上即用此架构;面试高频“Prefill 和 Decode 为什么瓶颈不同”“PD 分离解决什么”。

合在一起部署时,Prefill 突发(大 prompt 批量涌入)会占满 GPU 算力,把正在 Decode 的请求的 TTFT/ITL 拖垮,两类负载互相干扰且调度目标冲突。分离后: ① 各自按算力/带宽特征选型与扩缩容,GPU 利用率提升;② TTFT 由 Prefill 实例决定、ITL 由 Decode 实例决定,延迟指标独立可调;③ 长尾与突发由 Prefill 池吸收,Decode 池保持稳定——代价是额外的网络 KV 传输与更复杂的调度。

为什么 Prefill 是计算密集而 Decode 是带宽密集(GEMM vs GEMV,每步读全量权重只产 1 个 token)?用 Roofline 模型解释两者的瓶颈不同。

PD 分离的架构: KV Cache 如何从 Prefill 实例传到 Decode 实例(网络/异步管线化);分离后引入的新瓶颈是什么?

Decode 实例的负载均衡为什么按已占 KV 大小/序列长度,而不是连接数或请求数?长短请求混合时如何避免不平衡?

TTFT 与 ITL(TPOT)分别由哪个阶段决定?PD 分离如何让两者独立优化,合部部署时为何互相牵制?

PD 分离与连续批处理、chunked prefill 的关系: chunked prefill 为何是“软分离”的替代方案,各自取舍是什么?