把「反向要算多少」当成可调的变量
10 月 27 日，京东一支位于北京的团队在 arXiv 提交论文 LRMoE（arXiv:2610.37720），瞄准的是 MoE 训练里一个和参数量无关的瓶颈：反向传播。在典型的专家并行设置里，每个 token 会被路由到少数几个专家，而这些 token-专家对要通过 all-to-all 通信在 GPU 之间搬运。麻烦在于路由是数据相关的——少数热门专家突然收到大量 token，其余专家却空闲着。论文打了个比方：一个 MoE 层和一次集合通信，都按最慢的那个参与者收尾，于是最忙的 GPU 成了拖油瓶，集群其余部分只能干等。
已有的系统大多走「重新分配」这条路：搬动专家、复制专家、动态调整摆放位置。论文列举了 FasterMoE、FlexMoE、SmartMoE、SYMI、LAER-MoE、UltraEP 等代表性工作，但认为这条路已经触到天花板——多出来的专家副本，恰恰吃掉了本该用于缓解显存压力的显存，和它们想要保护的 token 相关缓冲区直接打架。在固定显存预算下，不缩减工作量只重新分配，总需求仍可能超过集群实际能服务的上限。
一个能分解的贡献分数
LRMoE 的核心动作，是把「反向要算多少」当成一个调度变量，而不是前向路由顺手交出的固定结果。具体拆成两个阶段：前向仍然跑完整的路由与计算，保留全部被路由的工作，所以前向精度不受影响；但在专家前向开始前，控制器会先观察每个专家分到的路由需求，给它定一个反向保留配额。只有当梯度真正回流时，系统才决定哪些具体的 token-专家对去填满这些配额。
为了决定「保留谁」，论文定义了一个负载重标定度量（Load Recalibration Metric, LRM）。对一个路由对 u = (t, e)，它对某个受保护专家投影的权重梯度的贡献是一个外积 G_u = (α_u g_t) φ_u^T。因为这个乘积是秩一的，丢弃该对所引起的扰动的平方 Frobenius 范数可以因式分解成三项：R_u = α_u² · ||g_t||² · ||φ_u||²。其中路由强度 α_u² 是 token 在前向中被分配给该专家的权重，反向信号 ||g_t||² 是后续计算传回的梯度大小，专家状态 ||φ_u||² 是保存下来的投影输入的大小。论文特别强调第三项最容易被忽略：两个路由对可能带着几乎相同的上游梯度范数，却带着很不相同的路由权重或保存激活，用只看梯度的规则会把它们当成可互换的，但实际对专家权重更新的影响并不相同。
选对了还不够，压实才真正省显存
光做选择本身并不省钱。论文专门用一节讲这个陷阱：如果丢弃的行只是被零掩码、张量形状保持不变，那么 GEMM 的维度和显存占用几乎纹丝不动，什么都没省下来。真正有效的是物理压实——把保留下来的梯度行和它们对应的保存激活，重新打包进连续的、按专家划分的缓冲区，再用实际保留行数驱动可变大小的 grouped GEMM，不做任何填充。每个专家只处理自己保留下来的行，而不是在零填充的行上做计算。
论文里的示意图把后果画得很具体：原本专家负载是 [4, 2, 3]，压实后变成 [3, 1, 2]。某个专家如果压缩后的工作量刚好能装进一张 GPU，它就不再需要物理副本。被改变的是冗余副本的数量，以及随之而来的参数显存、临时缓冲区和通信量；逻辑上的专家集合完全没动。
八张 Hopper 上的实测
实验在八张 NVIDIA Hopper GPU、EP8、PyTorch 2.11.0、CUDA 13.0、BF16 精度下完成，模型是 Qwen3-30B-A3B 与 GLM4.5-106B-A12B，序列长度 8192，每卡微批次为 4。所有对比方法在相同的 80 GiB 每卡显存预算、50 次预热加 1000 次测量迭代下跑相同的受控张量。基线包括 Megatron-LM 的固定归属策略、原生 UltraEP，以及一份独立的 SYMI（NSDI 2026）实现。在收敛表现上，数字接近无损。
关键的结果落在训练时间上：在 Qwen3-30B-A3B 与 GLM4.5-106B-A12B 上，LRMoE 把达到固定损失目标所需的累计 MoE 层训练时间，较 SYMI 降低了 21.2% 到 44.8%。换句话说，在不靠堆副本、不牺牲精度的前提下，它把训练负担从「复制专家」转向了「精算每个梯度该不该留」。
为什么值得关注：把训练负担从复制专家转向精算
随着 Qwen3、GLM4.5 这类稀疏 MoE 架构在 2026 年持续扩张，路由不均衡和商品级 GPU 节点上的显存压力，仍是高效训练绕不开的两道坎。LRMoE 锁定的正是这一类场景：显存受限、单纯靠复制专家行不通、又必须小心地重算或丢弃反向需求以保护模型质量。它给出的思路不是更多副本，而是把反向需求当作可规划、可度量的对象来调度。
从工程意义看，这套方法对在中低端集群上训练大 MoE 的团队尤其中肯：同样的显存预算里，少一份副本就多一份可用容量。当推理侧已经在卷效率，训练侧的办法也在从「加机器」慢慢走向「算得准」——LRMoE 是这条路上的一个具体注脚。