大模型推理部署解剖：PD 分离、AF 分离，和 micro-batch 流水线到底在优化什么

同一个开源权重，你自己跑每秒几十 token，商业 API 能便宜稳定地服务成千上万人——差距不在模型，在部署架构。理解现代推理架构，要从”推理其实不是一种负载，而是两种”这个事实开始。

一、Prefill 与 Decode：两种完全不同的负载

一次推理请求分两个阶段：

• Prefill（预填充）：一次性并行处理 prompt 的全部 token，算出第一层的 KV 并生成第一个 token。这是矩阵-矩阵乘，计算密集型——GPU 算力（FLOPS）是瓶颈，显存带宽大量闲置
• Decode（解码）：逐 token 生成，每一步都要把全部模型权重从显存读一遍，只为算一个 token。这是矩阵-向量乘，显存带宽密集型——算力大量闲置

两个阶段对应的用户体验指标也不同：

TTFT（首 token 延迟）≈ Prefill 耗时      → 用户"等多久才开始出字"
TPOT（每 token 耗时）≈ Decode 单步耗时   → 用户"出字流不流畅"

混部的问题：把两种负载塞在同一批 GPU 上，要么按 Prefill 配资源（Decode 阶段算力浪费），要么按 Decode 配（Prefill 排队），而且长 prompt 的 Prefill 会突然插队，拉高所有人正在进行的 Decode 延迟——吞吐和延迟两头都做不好。

二、PD 分离：让两种负载各用各的卡

PD 分离（Prefill-Decode Disaggregation）的思路直白：Prefill 集群和 Decode 集群分开部署，各自按负载特征配比资源；Prefill 节点算完 KV Cache 后，通过高速网络把 KV 传给 Decode 节点接力生成。

拆开之后出现了一系列独立优化空间：

• 独立配比：Prefill 池堆算力、Decode 池堆显存和带宽，资源利用率各自拉满
• 独立调度：TTFT 和 TPOT 可以分别做 SLA 保证（DistServe 论文的核心贡献就是证明分离部署能在同等资源下服务更多请求且不违约延迟目标）
• KV 缓存分层：Moonshot 的 Mooncake 架构把 KV Cache 池化共享，热门前缀（系统提示词、多轮对话历史）的 KV 直接复用、连 Prefill 都省掉——本站收录的 Kimi 条目记录其缓存命中率达到 90% 量级，这是 PD 分离之上再叠一层的典型收益

代价是 KV 传输开销（长上下文的 KV 动辄几十 GB，参考本栏目 MLA 一文的缓存账——MLA 架构在这里同样有结构性优势：要传的 KV 小 57 倍）和调度复杂度。

三、AF 分离：拆得更细的下一步

PD 分离按”阶段”拆，AF 分离（Attention-FFN Disaggregation）按”算子”拆：同一层内，Attention 计算（访存模式受 KV Cache 支配）和 FFN 计算（权重密集、适合大 batch）分到不同的设备池，各自用更合适的并行策略和 batch 形态。

对 MoE 模型这个方向尤其有吸引力：FFN 里的专家部分可以做专家并行（EP），Attention 部分做数据/张量并行，两种并行策略不再互相迁就。目前 AF 分离还属于业界前沿探索（头部推理框架和头部厂商都在试水），工程复杂度高于 PD 分离，但它代表了推理架构的演进方向：拆分的粒度越来越接近硬件特征的本质差异。

四、DualPipe 与 micro-batch：把通信藏进计算里

如果说 PD/AF 分离是”空间上拆”，流水线技术就是”时间上叠”。先看它要解决什么：

模型大到单卡装不下时，要按层切到多张卡上（流水线并行）。朴素的切法是整批数据流过卡 1 → 卡 2 → ……，任一时刻只有一张卡在干活，其余空等——空等时间叫流水线气泡（bubble）。

micro-batch 切分是消气泡的基本手段：把一个大批次切成 m 个 micro-batch，像工厂流水线一样错峰流动，设备利用率从 1/阶段数 提升到接近满载。在此基础上还有一个更大的敌人：MoE 模型层间的 all-to-all 通信（token 要被发往分布在各机的专家，见本栏目 MoE 一文），通信时段 GPU 又在干等。

**DualPipe（DeepSeek-V3 训练时采用）**的做法是双向流水线 + 细粒度重叠：

• 从流水线两端同时注入 micro-batch（正向反向各一队），让一张卡上的前向计算与另一队的反向计算在时间上交错
• 把每个 micro-batch 的计算切成更细的块（注意力、专家分发通信、MLP、专家合并通信），在计算块的间隙穿插执行通信块——通信被”藏”在计算背后，气泡被双向交错基本填满

需要厘清一个常见误读：DualPipe 是训练侧的流水线方案，不是推理方案；但”micro-batch 切分 + 计算/通信重叠”的思想在推理侧同样无处不在——continuous batching（请求级动态组批，让 Decode 永远有大 batch 可跑）、chunked prefill（把长 Prefill 切块插进 Decode 批次，避免长 prompt 阻塞出字）都是同一思想在推理调度上的投影。

五、一张表总结

技术	拆分维度	优化目标	代价
PD 分离	按推理阶段	资源按负载特征配比，TTFT/TPOT 各自可保证	KV 跨节点传输、调度复杂度
AF 分离	按算子类型	Attention/FFN 各自用最优并行策略	前沿探索，工程复杂度高
micro-batch 流水线	按时间	消除流水线气泡	调度逻辑复杂
DualPipe	时间+双向	把 all-to-all 通信藏进计算	训练框架深度定制

六、对使用者的意义

• 评估推理框架时问的应该是这些问题：是否支持 PD 分离部署？continuous batching 和 chunked prefill 有没有？MoE 的专家并行和通信重叠做到什么程度？
• 自部署 MoE 大模型（如即将放出权重的 Kimi K3，本站收录条目记载官方建议 8×A100/H100 起步）：先看框架的 MoE 通信优化，再看显存账
• API 的成本结构：PD 分离 + KV 缓存复用 + MoE/MLA 架构的组合，解释了头部厂商 API 价格战的底气来自工程而非烧钱

---

📋 来源与核验记录：

• DistServe（PD 分离的 SLA 分析）：arXiv:2401.09670
• DeepSeek-V3 技术报告（DualPipe 双向流水线与计算/通信重叠）：arXiv:2412.19437
• Mooncake 缓存命中率（约 90%）与 K3 部署建议（8×A100/H100）：本站 Kimi 收录条目，数据核验日期 2026-07-24
• AF 分离部分为业界方向性综述，未引用单一论文，特此标注