为什么低延迟 Decode 优先选 EP8 × DP4

这张图展示的是MoE 模型在推理Inference部署时最核心的架构选型与调优决策树。以32 张 GPU假设单机 8 卡共 4 台机器为例它阐述了如何在EP专家并行和DP数据并行之间做权衡特别是针对低延迟 Decode解码阶段的落地方案。1. 核心矛盾NVLink 极速 vs. IB 跨机延迟为什么 EP 开得越大不一定越好关键在于物理网络层级单机内 8 卡NVLink/NVSwitch通信带宽极高如 900 GB/sAll-to-All 延迟极低。跨机 32 卡InfiniBand / RoCE 网卡通信带宽相比 NVLink 打折且经过交换机网络延迟Latency显著增加。2. 三种配置方案对比配置方案跨卡范围A2A 通信介质单 Expert GEMM 尺寸 (mem_eme​)优点缺点 / 风险EP8 × DP4(首选方案)| 限制在单机 8 卡内 |全 NVLink极速 | 较小 | 延迟极低拥有 4 个独立请求副本抗并发能力强 | 权重在 4 个 DP 副本里各存了一份GEMM 较小 ||EP16 × DP2| 跨 2 台机器 |NVLink IB 网卡| 中等 | 显存占用减少mem_eme​变大GPU 算力利用率提高 | A2A 开始走跨机网卡通信延迟陡增 ||EP32 × DP1| 跨 4 台机器 |全网卡跨机| 最大 | 显存占用最少GEMM 算力利用率最高 | 同步域太庞大网络长尾延迟P99容易爆表 |3. 为什么低延迟 Decode 优先选EP8 × DP4在大模型推理的Decode 阶段逐字生成 Token延迟极度敏感用户对每 Token 生成延迟TPOT非常卡顿敏感。Batch Size 通常不大不像 Prefill 阶段那样有海量 Prompt TokenDecode 阶段的总体 Token 数有限。如果盲目把 EP 扩大到 16 或 32尽管 GEMM 的计算效率高了一点点比如省了 1~2 ms但跨机 IB 网卡的 All-to-All 通信延迟却增加了 5~10 ms最终“通信增加的时间”远大于“计算节省的时间”整体延迟反而变烂。因此只要单机 8 卡EP8能装下模型权重首选绝对是EP8 × DP4把 A2A 死死封印在单机 NVLink 内部。4. 图底部的“最终测量”指标面试/调优 Profiling 检查表当你在真实环境中跑 Benchmark 压测时这张图列出了压测必须监控的核心指标业务延迟指标首 Token 延迟 (TTFT)Prefill 阶段的性能。每 Token 延迟 (TPOT / Time per Output Token)Decode 阶段的流畅度。P50 / P99 延迟长尾延迟P99 爆表通常是因为跨机 A2A 网络抖动或专家负载不均。系统 Bottleneck 拆解Dispatch/Combine 时间通信耗时。如果这个时间占比30%30\%30%说明 EP 开大了或网络卡了。Expert GEMM 时间纯计算耗时。最热 Expert / rank负载不均Load Imbalance。如果某个 Expert 成了热点会导致全卡等待它算完Straggler Effect。