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 的机架内带宽，都是为这件事服务的。
为什么普通用户也该懂
如果你的产品在调用类 MoE 模型的 API，账单里那个便宜价格，本质是别人替你做了这层拓扑切分。一旦你想自建 MoE 推理，直接用稠密模型那套「单池混跑」的部署方式，成本会比官方报价贵出几倍——这就是 4 美分背后的工程壁垒。
还有一个常被忽略的变量是路由抖动。MoE 每个 token 路由到不同专家，批次内专家重叠度直接决定通信开销。把请求按任务类型聚批、让同批请求尽量命中相似专家，能显著减少跨卡通信——这属于不花钱就能拿到的优化，却最依赖调度层的工程成熟度。