适用读者：要决定"推理服务怎么部署、要不要拆"的平台/架构工程师。
前置：S23-J01（prefill/decode 与两个指标）、S17（服务部署与容量）。
覆盖旧文：A-1988 → 18 点（PD 分离、DOPD、AFD、MoE 跨机与 DeepEP）。
扩展点：E-S23-003（PD 分离的收益条件）、E-S23-004（DOPD 的监控三指标）、E-S23-005（AFD 的硬件搭配判据）。
上一篇：S23-J01 · 推理的两段与两个指标：MoE、prefill/decode、TTFT/TPOT
下一篇：S23-J03 · 训推分离与协同设计。
1. 一句话结论
PD 分离的本质是"把两种负载从互相干扰变成可独立配置"：prefill 吃算力、decode 吃带宽，混部时任何一方扩容都会浪费另一方。分离后能分别调 TTFT / TPOT，代价是多了一次 KV 传输与一套调度器。
| 方案 | 收益 | 代价 |
|---|---|---|
| 混部（PD 同实例） | 部署简单、无 KV 传输 | 两种负载互相干扰；扩容只能整体扩 |
| PD 分离 | 独立优化 TTFT/TPOT；同等资源承载更多请求 | KV 传输、调度复杂、混合长度下失衡 |
| PD + 动态调度（DOPD） | 应对负载波动 | 需要监控 + 路由 + 扩缩容组件 |
| AFD（Attention/FFN 再分离） | 按硬件特性配比，降成本 | 更细的切分 → 更多通信 |
2. PD 分离与 DOPD（§2）
原文的事实链（DistServe 论文首次提出）：
- prefill 与 decode 资源需求不同 → 拆开部署（不同设备或同机不同 GPU）；
- 好处：避免相互干扰，独立优化 TTFT 与 TPOT；论文实验与大规模实践显示"同样资源承载更多请求，或同等请求响应更快"；
- 代价：混合长度请求下出现"生产者—消费者失衡"——P 实例产 KV 的速度与 D 实例消费的速度不匹配，导致部分实例过载、部分闲置；
- 解法：DOPD 动态调整 P/D 实例数量，靠"资源监控 + 请求路由 + KV 通信"三件套实现自动扩缩容。
2.1 收益条件（E-S23-003）
不是所有场景都该拆。 四条判据，全部满足才划算：
| 判据 | 满足的标志 | 不满足的后果 |
|---|---|---|
| 请求足够多 | 稳态 QPS 能填满至少一组 P 与一组 D | 拆完两边都吃不饱 |
| 输入/输出比例稳定或可预测 | 有历史分布（如平均输入 2k、输出 300） | 比例漂移 → 失衡更严重 |
| KV 传输成本可接受 | 同机/同超节点内可走高速互联 | 跨机房传 KV → 延迟吃掉收益 |
| 有调度与监控能力 | 能观测 P/D 队列深度并自动扩缩 | 手工调 → 永远滞后于负载 |
反向指标：如果 P95 的 TTFT 与 TPOT 同时偏高，混部通常是瓶颈在总容量；此时先扩容，而不是拆。
2.2 DOPD 的监控三指标（E-S23-004）
| 指标 | 含义 | 阈值示例（示意） |
|---|---|---|
| P 实例队列深度 | 待处理 prefill 请求数 | 持续 > 2× 均值 → 扩 P |
| D 实例 KV 等待时间 | decode 等 KV 就绪的时长 | P95 > TPOT 的 20% → 扩 P 或迁 D |
| KV 传输带宽利用率 | 互联是否成为新瓶颈 | > 70% → 拆分收益见顶 |
判据：扩缩容动作必须先于用户可感知的延迟劣化（即用队列深度触发，而不是等 TTFT 报警）。
3. AFD：把 Attention 与 FFN 也拆开（§3）
原文的推理链：既然 prefill/decode 能拆，decode 内部的 Attention（访存密集） 与 FFN（计算密集） 也能拆——Step-3 论文的 AFD 架构即此。
| 模块 | 瓶颈 | 适配硬件（论文示例） | 理由 |
|---|---|---|---|
| Attention | 显存带宽（读 KV） | H20 一类（带宽/成本比更优） | 不需要极限算力 |
| FFN | 算力 | H800 一类 | 大矩阵乘 |
原文还给出一个工程含义：FFN 部分可考虑国产化硬件，"打破对高端 GPU 的单一依赖"。
AFD 的硬件判据（E-S23-005）：
若 某模块 算术强度 < 硬件 roofline → 它是带宽瓶颈 → 配"带宽/价格比"高的卡
若 某模块 算术强度 > 硬件 roofline → 它是算力瓶颈 → 配"算力/价格比"高的卡
注意适用条件：AFD 的价值依赖"两类硬件价差 × 利用率提升 > 额外通信开销"。只有单一卡型时，拆开反而增加通信。
4. MoE 跨机与通信库（§4）
原文的判断：DeepSeek V3 系列约有 1.4 万个专家（全层合计），单卡/单机装不下；MoE 每次只激活少数专家，未激活专家算力闲置；跨机若用 NCCL（擅长全量密集通信）效率低，因为 MoE 只需按需传输。
| 项 | 传统做法 | MoE 专用做法 |
|---|---|---|
| 通信模式 | 全量 AllReduce/AllGather | 按需 All-to-All（路由到被激活专家） |
| 精度 | FP16/BF16 | 原生 FP8 通信（DeepEP） |
| 重叠 | 有限 | 通信-计算重叠（边传边算） |
| 网络 | InfiniBand | RoCE 也可（原文提到腾讯 TRMT 优化 RoCE 效率） |
判据：MoE 部署的第一瓶颈是互联，不是单卡算力。 选型时先算"每 token 需要搬运多少专家权重/激活"，再看互联带宽能否覆盖。
每 token 跨机传输量 ≈ 激活专家数 × 单专家参数字节 × 2（上下行，示意）
若 互联带宽 < 传输量 ÷ 期望 TPOT → 必须换拓扑或减专家并行度
5. 常见误区
| 误区 | 纠正 |
|---|---|
| "PD 分离一定更快" | 只在 §2.1 四条判据满足时更快；小流量下更慢 |
| "拆得越细越好" | 每拆一层多一跳通信；AFD 只在硬件异构时划算 |
| "NCCL 万能" | MoE 稀疏通信需要 All-to-All 优化（DeepEP 一类） |
| "MoE 省算力就等于省钱" | 省的是 FLOPs，花的是显存与互联；总成本可能更高 |
6. 自测
- 你的服务输入/输出比例稳定吗？算出 P 与 D 的配比依据。
- 若要做 PD 分离，KV 传输走哪条链路？带宽够不够"输出 token 速率 × KV/token"？
- AFD 在你的硬件条件下，额外通信开销占 TPOT 的百分之几？
7. 下一篇
S23-J03 · 训推分离与协同设计 —— RL 训练的数据由推理产生，为什么必须拆、拆完的"气泡"怎么消，以及算术强度如何反过来指导模型设计。