专家并行

跑 MoE 模型的人都见过一个怪现象：模型总参数巨大，但每个 token 只激活一小部分，GPU 利用率却上不去。NVIDIA 技术博客点破了原因——高交互场景下，MoE 的执行时间被专家权重加载时间卡住，而不是被矩阵乘法本身。这就是 WideEP（Wide Expert Parallel）要解决的问题。 decode 阶段的带宽地狱 生成阶段每一步，路由器只挑出少数几个专家（比如 671B 里激活约 37B）。问题是：被选中的专家权重要从显存里读进来，才能做这一步计算。专家越大、越分散，每一步的权重读取量就越接近「把整个模型读一遍」。 换句话说，MoE 在 decode 阶段退化成了内存带宽问题：算力（FLOPS）严重闲置，时间全花在把专家权重从 HBM 搬到计算单元上。 WideEP 的解法 传统专家并行把所有专家放在一组卡上，每个 decode step 要跨这组卡集体通信。WideEP 反过来：把专家切分到 NVL72 机架内更多节点上并行，缩短单个专家的加载路径，用机架级 NVLink 的高带宽抵消跨卡成本。配合前面提到的 EP64DP3 这类配置，专家被摊得足够开，每步加载时间显著下降。 为什么 2026 年才规模化 这不是算法创新，是基础设施创新。没有 NVL72 这种把几十张卡做成一个统一域的机架、没有 HBM4 的容量、没有 Dynamo 把 prefill/decode 拆开各自配拓扑，WideEP 就是纸上谈兵。MoE 模型（DeepSeek-V4、Qwen3.8 这类）与机架级硬件是同步成熟的。 给实践者的提醒 如果你在自建 MoE 服务，监控面板里别只看 GPU 算力利用率，要看 decode 阶段的显存带宽饱和率。如果带宽先打满、算力空着，说明你需要的不是更多卡，而是更合理的专家切分拓扑。 另一个实务建议是按请求类型分流。计算密集的批量任务与带宽敏感的交互式生成，最好路由到不同拓扑的资源池，而不是挤在同一批卡上互相抢带宽。这与 Dynamo 的分离式思路一脉相承：把负载画像摸清楚，再决定怎么切专家。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：MoE 专家并行

NVIDIA 自家 FAQ 页挂着一个让人愣一下的数字：在 GB300 NVL72 上跑 DeepSeek-R1 671B，按 SemiAnalysis InferenceX 口径，每百万 token 成本约 4 美分。这比通用模型的 0.123 美元还低一个数量级。差异不在模型大小，而在拓扑——NVIDIA 官方示例给出的配置是：上下文阶段用 EP4DP16，生成阶段用 EP64DP3。这串缩写是 2026 年 MoE 推理最核心的工程决策。 MoE 推理的两次瓶颈 DeepSeek-R1 是混合专家（MoE）模型：总参数 671B，但每个 token 只激活约 37B。这带来两个截然不同的瓶颈。 Prefill（上下文处理）：要把整段输入过一遍网络，每个 token 路由到不同专家，计算密集，但对延迟容忍度稍高。 Decode（逐 token 生成）：每步只出一个 token，但要快速把被路由专家的权重从显存里读出来，带宽密集，对延迟极其敏感。 同一张 GPU 池子里混跑这两个阶段，会互相拖累：长上下文 prefill 堵住 decode 的排队，decode 的小批次又浪费 prefill 的算力。 EP4DP16 与 EP64DP3 在干什么 EP 是专家并行，DP 是数据并行。官方示例里，上下文阶段用 EP4DP16：4 组专家并行、16 路数据并行，偏计算效率；生成阶段切到 EP64DP3：64 路专家并行、3 路数据并行，把专家权重尽量铺开，缩短每步加载时间。 这不是简单的「切更多卡」。它要求调度层在同一请求生命周期里切换并行拓扑，把 prefill 完的 KV cache 从一组卡安全搬到另一组卡——Dynamo 的分离式路由、NVLink 的机架内带宽，都是为这件事服务的。 ...