DeepSeek EP 方案的抉择：Prefill 与 Decode 之间的 Insight

Nov 8, 2026

部署 MoE 模型时，专家并行（EP）的规模要在 prefill 和 decode 两个阶段分别确定。DeepSeek 在 DeepInfer 中给两个阶段选择了相反的规模：prefill 在显存放得下的前提下取最小的 EP，通常是 EP2 到 EP8；decode 则开到 EP64 到 EP128。本文从“每个专家每步分到多少 token”出发，解释这一选择背后的原因。

本文依据 DeepInfer 的部署文档和 DeepSeek V4.1-Flash 的模型配置，只讨论 MoE 层：384 个路由专家，每个 token 选 6 个，另有 1 个共享专家，hidden 5120，专家中间维度 2304，专家权重为 FP4。硬件取 B200 的规格（FP8 稠密算力 4.5 PFLOPS，显存带宽 8 TB/s，NVLink 单向 900 GB/s），文中的时间都是按峰值估算的每层每卡耗时。

概要

EP 规模变化时的守恒量：每张卡的计算量。 每张卡处理的 token 数 $T$ 固定时，它平均要算的行数是 $7T$ （6 个路由专家加 1 个共享专家），与 EP 无关。
EP 规模变化时的变化量：具体有三个量。 一是每个专家每步分到的行数：每张卡上的专家变少，同样的 $6T$ 行集中到更少的专家上，读一次权重能分给更多行，读权重的时间随之减少。二是每个 token 的通信份数：6 个专家分散到更多张卡上，要传的份数随之增加，逐渐接近 6 份，通信时间随之变长。三是专家负载不均：每张卡上的专家变少，负载偏高的专家多出来的那部分，更难被同卡的其他专家摊平，最忙的卡比平均更慢，其他卡都要等它。
两个阶段的差别只在读权重的时间。 每个 token 的通信份数和专家负载不均的程度只取决于 EP，与每卡的 token 数 $T$ 无关，所以同一个 EP 下，两个阶段的通信占计算的比例相同，最忙的卡比平均慢多少也相同。每个专家的行数却正比于 $T$ ：prefill 每卡约 3.2 万个 token，EP4 时每个专家已有约 2,000 行，读权重只占计算时间的十几分之一；decode 每卡只有 256 个 token，EP8 时每个专家只有 32 行，读权重的时间是计算的 4 倍。
Prefill 和 Decode 各自的需求决定了 EP 的规模。 在 B200 上，每个专家的行数超过约 150 行，读权重就不再是瓶颈，再加大 EP 也省不下时间。Prefill 在 EP4 时每个专家已有约 2,000 行，加大 EP 只会增加通信、加重专家负载不均，所以在显存允许的范围内取最小值。Decode 在 EP8 时每个专家只有 32 行，时间主要花在读权重上，EP32 时也只有 128 行，要加到 EP64 才能越过 150 行，所以取 EP64 到 EP128，并依靠 NVLink 域承担增加的通信，依靠 EPLB 缓解专家负载不均。

一、从 DeepInfer 思考 EP 规模的选择

DeepInfer 的部署文档对并行方式的说明很简短：prefill 使用 EP2 到 EP8，在显存允许的范围内取最小值；decode 使用 EP64 到 EP128，在可用 GPU 允许的范围内取最大值。两个阶段运行的是同一个模型、同一组专家，选择却正好相反。

一种常见的解释是，decode 每步的计算量小，所以可以分到更多卡上；prefill 的通信量大，所以要少分几张。这个解释默认了一个前提：EP 越大，每张卡分到的计算越少。本文先指出这个前提并不成立，再把 EP 的影响分成两类来看：改变 EP 时保持不变的守恒量，以及随之改变的变化量。

二、EP 规模变化时的守恒量：每张卡的计算量

DeepInfer 的注意力采用数据并行，DP 与 EP 的大小相同，每张卡处理自己那部分请求，持有 $T$ 个 token，形状为 [T, 5120]。gate 为每个 token 从 384 个路由专家中选出 6 个。token 按目标卡发出，每张卡收下选中本卡专家的行，按专家分组做两次矩阵乘，再把结果送回来源卡，与共享专家的输出相加。

$T$ 由每张卡上的请求决定，加卡并不会让它变小，官方的性能曲线也是按每卡的请求数对齐比较的。在这个前提下，整个 EP 组每层产生 EP × T × 6 行，路由均匀时平均分到每张卡的是

\frac{EP \times T \times 6}{EP} = 6T

行，再加上共享专家的 $T$ 行，共 $7T$ 行。EP 在式中被约去：从 EP8 增加到 EP64，每张卡要做的有效计算保持不变。一行经过一个专家约需 70.8 MFLOP，decode 每卡 256 个 token 时每层约 28 µs，prefill 每卡 32,768 个 token 时约 3.6 ms。

这里守恒的是平均每卡的有效计算。路由不均匀时，最忙那张卡会多算一些，这正是下一节要讨论的专家负载不均；分组矩阵乘在专家行数很少时还要补零对齐，实际执行的运算会略多于有效计算，这在 decode 的小 EP 下更明显，但不改变本文的结论。

既然 EP 不能减少计算，它的作用就只能从它改变的那些量里找。

三、EP 规模变化时的变化量：行数、通信份数与专家负载不均

每个专家的行数：决定读权重的时间

EP 改变的是这 $6T$ 行如何分到专家上。每张卡持有 384 / EP 个专家，每个专家每步分到的行数为

r = \frac{EP \times T \times 6}{384}

以 decode 每卡 256 个 token 为例，EP8 时每张卡有 48 个专家，每个专家只有 32 行；EP64 时每张卡有 6 个专家，每个专家有 256 行。

$r$ 的意义在于，专家权重每一步都要从显存读取一次， $r$ 决定了读一次权重能被多少行复用。一个专家的参数量记为 $P$ ，算 $r$ 行需要 $2Pr$ 次运算，读取权重需要搬运 $Pb$ 字节， $b$ 是每个参数的字节数。令两者耗时相等， $P$ 被约去，得到权重复用阈值：

r^{*} = \frac{b}{2} \times \frac{\text{算力}}{\text{显存带宽}}

V4.1 的专家权重为 FP4，连同缩放因子约 0.53 字节每参数，代入 B200 的规格， $r^{*} \approx 0.265 \times 562.5 \approx 150$ 行。这里只计了权重，把每行激活的读写也算上，阈值约为 180 行，不影响下文的结论。 $r$ 高于 $r^{*}$ 时，专家矩阵乘受算力限制；低于 $r^{*}$ 时，时间主要花在读权重上。 $r / r^{*}$ 近似等于计算时间与读权重时间之比，加大 EP 的作用，就是把 $r$ 推过 $r^{*}$ ，让读权重的时间降到计算以下。

图 1：每个专家每步的行数随 EP 的变化。prefill 每卡 32,768 个 token，decode 每卡 256 个 token；虚线为权重复用阈值。

图 1 中两条线的斜率相同，都随 EP 线性增长，但高度相差 128 倍。prefill 在 EP2 时就已远在阈值之上；decode 要到 EP 约为 38 时才越过阈值。

每个 token 的通信份数：决定通信时间

一个 token 的 6 个专家里，平均有 $6 \times (EP - 1) / EP$ 个在别的卡上。每个 token 要传几份，取决于实现是否按卡去重，两种做法都有实际的实现。不去重时，每个“token–专家”对各传一份，DeepEP 的 V1 低延迟模式和 Mega MoE 都是这样：

c_{\text{不去重}} = 6 \times \left(1 - \frac{1}{EP}\right)

按卡去重时，发往同一张卡的只传一份，到了再展开，DeepEP 的 V1 普通模式和 V2 direct 模式是这样：

c_{\text{去重}} = (EP - 1) \times \left[1 - \left(1 - \frac{1}{EP}\right)^{6}\right]

每份数据在 dispatch 时约 5.4 KB（FP8），在 combine 时约 10.2 KB（BF16）。通信时间正比于 $T \times c$ ，计算时间正比于 $7T$ ，两个式子里都没有 $T$ ，所以无论是否去重，通信与计算之比都与 $T$ 无关，只取决于 EP 和链路带宽。

图 2：每个 token 的通信份数随 EP 的变化。

两种做法的 $c$ 都随 EP 单调增加，并趋近 6；去重带来的节省却随 EP 增大而迅速消失，EP4 时能少传近一半（4.50 对 2.47），EP64 时只少 4%。所以去重在 prefill 的小 EP 下很有价值，到 decode 的大 EP 下几乎没有作用；反过来说，Mega MoE 不去重，在 decode 中几乎不吃亏，在 prefill 中则要多付一些通信。DeepInfer 在 NVLink 域内使用的是 Mega MoE，下文的数值按不去重计算。

专家负载不均：决定最忙的卡比平均慢多少

所有卡要在 combine 时汇合，一层的耗时由最忙的卡决定。设某个专家的负载是平均值的 $h$ 倍，它所在卡的负载与平均值之比为

lb = 1 + \frac{h - 1}{384 / EP}

每卡的专家越多，单个专家负载偏高的影响越容易被摊平。 $lb$ 同样与 $T$ 无关，只取决于 EP。

阶段	EP	$r$	$r / r^{*}$	通信 / 计算	$lb$ （ $h = 10$ ）
Prefill	2	1,024	6.8	0.47	1.05
Prefill	4	2,048	13.7	0.71	1.09
Prefill	8	4,096	27	0.83	1.19
Decode	8	32	0.21	0.83	1.19
Decode	32	128	0.86	0.92	1.75
Decode	64	256	1.7	0.93	2.5
Decode	128	512	3.4	0.94	4

表 1：EP 改变的三个量。通信 / 计算按 Mega MoE 不去重、NVLink 计。prefill 每卡 T = 32,768，取 DeepInfer benchmark 的默认值；decode 每卡 T = 256，取官方曲线上每卡 64 个请求、每个请求每步验证 4 个 token 的配置。

表 1 中 EP8 的两行最能说明问题：两个阶段的通信与计算之比和 $lb$ 完全相同， $r / r^{*}$ 却相差两个数量级。通信和专家负载不均只随 EP 变化，每个专家的行数随 EP × T 变化。图 3 把这一点画了出来：通信与计算之比只有一条线，两个阶段共用；读权重与计算之比是两条线，彼此平行，相差 128 倍。

图 3：读权重时间、通信时间与计算时间之比随 EP 的变化。

四、两个阶段的取舍

把读权重、通信和计算三项放在一起，就能看出每种组合下谁最慢。图 4 按每卡的 $T$ 和 EP，标出计算、读权重和通信三项中耗时最长的一项。左图在 NVLink 域内：prefill 的官方配置落在计算受限的区域，decode 的官方配置刚好越过读权重受限的区域。右图把链路换成每卡 100 GB/s 的网卡，几乎所有组合都变成通信最慢，这也是两个阶段都留在 NVLink 域内的原因。

图 4：每种 EP 与每卡 T 的组合下，三项中最慢的一项。左为 NVLink 900 GB/s，右为跨节点、网卡 100 GB/s；P、D 为官方的 prefill 和 decode 配置。

Prefill：读权重已不是瓶颈，取最小 EP

Prefill 每卡每步处理数万个 token，EP4 时 $r$ 已是阈值的十几倍，读权重的时间只有计算的十几分之一。继续加大 EP，能节省的读权重时间很有限，通信与计算之比却从 0.71 升到 0.83（按卡去重时也从 0.39 升到 0.61），专家负载不均的影响也在变大；官方实测的 prefill moe_lb 在 EP2 时为 1.045，EP4 时为 1.074。因此 prefill 在显存允许的范围内取最小的 EP，下限取决于每张卡能否放下 384 / EP 个专家的权重。

Decode：读权重是瓶颈，加大 EP 直到它降到计算以下

Decode 的 $T$ 由并发数和延迟要求决定，每卡只有 256 个 token。EP8 时 $r$ 只有 32 行，读权重约需 117 µs，计算只需 28 µs。 $T$ 无法增大，能把 $r$ 推过阈值的只有 EP：EP 从 8 增到 64，读权重的时间降到约 19 µs，低于计算时间。部署文档对 Wide-EP 的解释也正是这一点：它大幅减少了 MoE 专家部分每步的显存流量。官方曲线也反映了这一点（图 5），每卡 64 个请求时，EP64 每卡约 15.7K tok/s，每个用户约 246 tok/s；EP8 分别约为 12.6K 和 198。

图 5：DeepInfer 官方的 decode 曲线，从 README 的图中读出，为近似值。

$r$ 越过 $r^{*}$ 之后，读权重已降到计算以下，再加大 EP 也省不下时间：计算保持在 28 µs，通信和专家负载不均却继续加重。按本文的估算，这个交点在 EP32 与 EP64 之间，官方推荐的 EP64 到 EP128 正好在它之后不远。在这个范围内，通信与计算之比约为 0.93，每层还要与 63 张以上的卡同步，一个负载为平均值 10 倍的专家就能让 $lb$ 达到 2.5。因此 decode 需要放在 64 到 128 卡的 NVLink 域内，并依赖 EPLB 复制负载高的专家、定期重排，官方实测的 decode moe_lb 为 1.090。

每卡 T

阈值 ≈ 150 行

计算

读权重

通信

图 6：每层每卡的三项时间（B200，NVLink 900 GB/s）。圆点是每个专家分到的行数，横轴按对数刻度。

在图 6 中可以自己验证这两种取舍： $T$ 取 32K 时，无论 EP 取多少，三项中都是计算最长； $T$ 取 256 时，随着 EP 从 8 增大，读权重的时间迅速下降，直到 $r$ 越过阈值，此后通信与计算接近，继续加大 EP 已省不下时间。

五、阈值随硬件和精度的变化

阈值 $r^{*}$ 只由权重精度和硬件的算力带宽比决定。图 7 列出了几种常见组合：FP4 权重的字节数是 FP8 的一半，阈值也减半，这是 V4.1 在 B200 上只需约 150 行的原因；如果激活也用 FP4，算力翻倍，阈值又回到约 300 行。H20 的算力相对显存带宽很低，阈值只有约 37 行。

图 7：不同 GPU 与权重精度下的权重复用阈值，按公开的稠密峰值和显存带宽计算。

令 $r = r^{*}$ ，可以得到 decode 越过阈值所需的最小 EP：

EP_{\min} = \frac{r^{*} \times 384}{6 \times T}

每卡 256 个 token 时，B200 上的 FP4 专家约需 EP38，H100 上的 FP8 专家约需 EP74，H20 上约需 EP9。同样的模型和负载，在 H20 上把 EP 开到 8 到 16 就基本越过了阈值，继续加大 EP 能省下的时间很有限；在 H100 上则要开得比 B200 更大，而一台 H100 机器只有 8 张卡，EP74 必须跨节点，通信又会变成新的瓶颈，情形与图 4 右侧类似。换到别的模型时，把 384 和 6 换成它的路由专家数和每个 token 选择的专家数即可。

六、估算与实际情况的差距

前面的数字都按理想情况估算：算力和显存带宽取峰值，路由完全均匀，通信可以完全藏在计算后面，并且只看 MoE 层。实际系统在每一项上都会打折扣，但这些折扣大多改变数值，不改变比较的方向。

矩阵乘和显存读写都达不到峰值。阈值 $r^{*}$ 取决于两者之比，算力跑到峰值的七成、带宽跑到八成五时，阈值约为 120 行；计入每行激活的读写，又会把它抬高约两成。阈值在 120 到 180 行之间浮动，decode 越过它所需的 EP 在 30 到 45 之间：EP8 远远不够，EP64 足够，结论不变。

路由也不会完全均匀。专家负载不均让最忙的卡多算、多收，计算和通信按同样的倍数放大，两者之比不变；官方开启 EPLB 后实测的放大倍数在 1.045 到 1.090 之间，影响有限。

通信也不一定能完全藏在计算后面。每层的同步和启动都有一段固定开销，与要传多少数据无关。prefill 每层的计算约 3.6 ms，这段开销可以忽略；decode 每层的计算只有约 28 µs，它的占比就不小了，而且参与同步的卡越多越明显，这也是 decode 的 EP 停在 64 到 128、不再继续加大的原因之一。

最后，本文只看 MoE 层。官方曲线上，decode 每卡 64 个请求时一步约 13 ms，MoE 层只占其中一部分，其余是注意力和大量与批量无关的固定开销。所以本文的数字适合用来判断不同 EP 下谁是瓶颈、EP 该往哪个方向调，不能直接当作每步的实际耗时；官方 EP64 与 EP8 的实测差距，方向与本文的推导一致。注意力和这些固定开销如何影响 EP 的选择，留待后续分析。

小结

Prefill 与 decode 的 EP 选择看似相反，遵循的却是同一个规律：EP 不改变每张卡的计算量，只改变每个专家的行数、通信份数和专家负载不均。每个专家的行数随 EP × T 变化，决定读权重的时间；通信份数和专家负载不均只随 EP 变化。

Prefill： $T$ 足够大， $r$ 早已越过阈值，加大 EP 只会增加通信、加重专家负载不均，所以取显存允许的最小值。
Decode： $T$ 受并发和延迟限制，只能用 EP 把 $r$ 推过阈值，直到读权重的时间降到计算以下，所以取 64 到 128，并以 NVLink 域承担增加的通信，以 EPLB 缓解专家负载不均。

这个判断并不只适用于 V4.1。DeepSeek 在 V3/R1 的推理系统中把 decode 的 EP 开到 144，给出的理由同样是让每个专家分到足够大的 batch；NVIDIA 在 GB200 NVL72 上推行 Wide-EP，MegaScale-Infer 把注意力和专家拆到不同的 GPU 上汇聚 token，出发点也相同。换到别的模型和硬件，用第五节的两个式子，就能大致判断 EP 该往哪个方向调。

参考

DeepInfer, Inference deployment Q&A
DeepInfer, README: Performance benchmarks
DeepSeek, Day 6: DeepSeek-V3/R1 Inference System Overview
NVIDIA, Scaling Large MoE Models with Wide Expert Parallelism on NVL72 Rack Scale Systems
Zhu et al., MegaScale-Infer: Serving Mixture-of-Experts at Scale with Disaggregated Expert Parallelism