PD 分离,就是把大模型"处理输入"和"逐步生成回答"这两道工序,交给不同的 GPU 资源来做。 P 是 Prefill,D 是 Decode。
可以把它想成餐厅:一组人专门备菜,另一组人专门炒菜。 两种工作节奏不同,分工后更容易安排资源。
先看大模型回答问题时发生了什么。比如你发给它一篇长文章,说:"帮我总结一下。"
阶段
模型在做什么
你看到的现象
P:Prefill,预填充
处理文章、问题和聊天历史,把后续生成要用的中间计算结果存下来
通常还在等待回答开始
D:Decode,解码
根据已有上下文,一个接一个生成 token,可以粗略理解为一小段文字
回答逐渐出现在屏幕上
这里的"处理输入"和"生成回答"是方便理解的说法:模型在生成过程中也一直进行计算,并不是读完以后就已经想好了完整答案。
为什么要把它们分开?
假设同一组 GPU 正在给用户 A 持续输出回答,这时用户 B 突然提交了一篇特别长的文章。GPU 要腾出资源处理 B 的输入,A 的输出就可能出现停顿,像打字打到一半突然卡住。
PD 分离后,P 组处理新输入,D 组继续生成已有回答,能减少这两类工作互相干扰。它尤其有利于控制"回答过程中偶尔卡很久"的情况,也方便分别优化"多久开始回答"和"后续输出是否流畅"。
流程大致是:
xml
```mermaid
flowchart LR
A["用户提交文章和问题"] --> P["P 组 GPU<br/>处理输入"]
P -->|"传递 KV Cache<br/>已算好的上下文数据"| D["D 组 GPU<br/>逐步生成回答"]
D --> U["用户看到流式回答"]
```
中间交接的 KV Cache,可以理解成"已经算好的上下文笔记"。 它不是一份文字摘要,而是一批数值数据。D 组拿到这些数据,就能接着生成,省去重新计算整段输入的工作。
分开以后,还能根据业务调整配比:长文章请求多,就增加 P 侧资源;生成长回答的压力大,就增加 D 侧资源。两边通常都需要加载模型权重,具体各用多少张卡由模型大小和部署方式决定。
但 PD 分离不保证更快、更省钱。 两组 GPU 之间传 KV Cache 要花时间,资源分配不均还可能导致一边忙、一边闲。它主要解决的是多人并发时的干扰和延迟稳定性;一般高输出 比如32k输入 16k输入的任务pd分离有较高的单位产出