返回 AI 基础设施 思维导图
中文·English
🖥️ AI 基础设施ID: prefill-decode-split

Prefill/Decode 分离

Prefill/Decode Disaggregation
🎯核心定义
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 传输与更复杂的调度。
🎯5 个高频面试考点 (Exam Points)
1
为什么 Prefill 是计算密集而 Decode 是带宽密集(GEMM vs GEMV,每步读全量权重只产 1 个 token)?用 Roofline 模型解释两者的瓶颈不同。
2
PD 分离的架构: KV Cache 如何从 Prefill 实例传到 Decode 实例(网络/异步管线化);分离后引入的新瓶颈是什么?
3
Decode 实例的负载均衡为什么按已占 KV 大小/序列长度,而不是连接数或请求数?长短请求混合时如何避免不平衡?
4
TTFT 与 ITL(TPOT)分别由哪个阶段决定?PD 分离如何让两者独立优化,合部部署时为何互相牵制?
5
PD 分离与连续批处理、chunked prefill 的关系: chunked prefill 为何是“软分离”的替代方案,各自取舍是什么?
📖 关联深度指南:📄 high-concurrency-ai-system
更新于 2026-08-12
🎯
检验攻克程度:针对「Prefill/Decode 分离」专属刷题排雷
做单选排雷题、推导选项机制,答错自动收录进专属错题本。
🚀 开始本考点专项刷题
上一个知识点KV 缓存优化下一个知识点弹性伸缩与成本优化

🔗 更多 AI 基础设施 知识点卡片

激活显存估算Agent 运行时(跨模块)检查点与故障恢复集群调度 Ray/K8s