算子优化的新闻里，最扎眼的数字往往活不过端到端测试。2026 年 10 月 29 日，Prime Intellect 工程师 Mario Sieg 发布了可训练融合算子 Prime Mega MoE，主打卖点是前向传播最高 3.11 倍加速。如果穿透被资讯站弹窗污染的二手报道，直接看官方技术长文与 GitHub 仓库，你会发现一幅更真实的图景：单层前向的惊艳跑分，一旦放进百卡 H200 集群的完整训练步，实际吞吐提升会收敛到 1.32 至 1.34 倍；而且最核心的底层训练算子目前仍是闭源分发。
从 3.11 倍到 1.32 倍的性能漏斗
先把账本摊开。混合专家模型（MoE）在分布式训练开启专家并行（EP）时，Token 要在不同 GPU 之间动态分发和聚合。传统做法靠连续的 All-to-All 集合通信配分组矩阵乘法（Grouped GEMM），显卡大量时间花在通信等待和显存读写上。此前 DeepSeek 开源了面向推理前向传播的融合 MoE 实现及 DeepGEMM，而 Prime Mega MoE 的核心贡献，是在此基础上补齐了通信与计算重叠的反向传播算子。
为了看清这个算子的真实水位，必须把单层微基准测试和端到端完整训练步拆开对照。官方对比的 Prime-RL 基线采用编译后的 PyTorch all-to-all 通信加 DeepGEMM FP8 专家计算，单层测试环境为单节点 8 张 NVIDIA H200（EP=8，每卡 16,384 tokens，128 专家 top-8 路由，FP8 精度）。
| 测试模型与场景 | Prime-RL 基线耗时 | Prime Mega MoE 耗时 | 实际加速比 |
|---|---|---|---|
| Qwen3-30B-A3B 单层前向 | 12.0 ms | 3.9 ms | 3.11x |
| Qwen3-30B-A3B 单层反向 | 15.4 ms | 8.2 ms | 1.87x |
| Qwen3-30B-A3B 单层含激活检查点 | 39.3 ms | 15.9 ms | 2.47x |
| Qwen3-235B-A22B 单层前向 | 20.7 ms | 9.5 ms | 2.17x |
| Qwen3-235B-A22B 单层反向 | 30.5 ms | 24.6 ms | 1.24x |
| Qwen3-235B-A22B 单层含激活检查点 | 71.9 ms | 43.7 ms | 1.64x |
| Qwen3-30B-A3B 32卡端到端训练步 | 2.78 s (TorchTitan 3.07 s) | 2.08 s | 1.34x (对比 TorchTitan 1.48x) |
| Qwen3-235B-A22B 128卡端到端训练步 | 12.72 s (TorchTitan 14.98 s) | 9.65 s | 1.32x (对比 TorchTitan 1.55x) |
为什么 3.11 倍落到端到端只剩 1.32 倍？第一道折损在反向传播本身。反向不仅要传激活梯度，还要算权重梯度，计算密度更高，通信被掩盖的空间显著收窄，235B 模型上的单层反向加速直接掉到了 1.24 倍。第二道折损在完全激活检查点（2×前向+反向）以及注意力层、FSDP 跨卡同步等非 MoE 开销的稀释。即便如此，在百卡 H200 规模上把单步耗时砍掉约 24% 至 25%，已经是实打实的算力省钱利器。
跑分背后的理想假设与闭源软肋
看清了漏斗，接下来要挑一挑测试条件里的刺。
我不太买账的是单层基准测试里的两个前提：它采用了均匀随机路由（identical random routing），并且直接剔除了路由器（Router）本身的开销。做过 MoE 训练的人都清楚，真实语料下的 Token 分布极度偏斜，热门专家会被塞爆，冷门专家在空转。均匀随机路由相当于在没有交通堵塞的理想沙盘里测最高车速；一旦进到真实长程训练，木桶效应取决于负载最重的那张卡，峰值加速比大概率还要再打折扣。
理想路由测出的是实验室上限，尾延迟才是生产环境的生死线。
更现实的阻碍在于代码交付方式。虽然 Prime Intellect 把上层集成代码放进了开源的 Prime-RL 仓库，但查阅其 GitHub 文档会发现，prime-mega-moe 实际上是一个闭源的 DeepGEMM 分支。用户必须通过替换非公开的 deep_gemm wheel 预编译包，才能拿到公共版本缺失的训练算子。
此外，这次端到端测试只跑了 20 个训练步（预热 5 步后取第 6 至 20 步平均值），既没有和 MegaBlocks、ScatterMoE 等主流开源方案同台比拼，也没有给出梯度数值误差容忍度或长周期的 Loss 收敛曲线对比。对于动辄烧掉上百万美元的预训练团队来说，看不见底层 CUDA 源码的黑盒算子，一旦在几千步后出现 Loss 尖峰，连定位数值溢出的抓手都没有。
算子下沉时代的硬件死锁暗礁
哪怕你不在乎闭源，想在集群里跑通这套算子，也得先跨过一串硬性门槛。它要求专家并行度 EP 必须大于 1，运行时 JIT 编译强依赖 CUDA nvcc 13；模型结构上只支持无偏置（bias）的门控专家，隐藏层维度必须被 256 整除，中间层维度必须被 128 整除；精度则严格锁死在 SM90+ 上的 BF16、SM100（Blackwell）上的 MXFP8 以及 SM90（Hopper）上的分块 FP8。
更值得基础架构工程师警惕的，是持久化算子带来的资源争抢。2026 年 10 月 26 日合并的 GitHub PR #4188 披露并修复了一个严重缺陷：当并发的 FSDP/NCCL 集合通信超出持久化 Mega MoE 算子预留的 SM（流式多处理器） 资源时，整个训练任务会直接死锁。团队最后的修复方案是强制根据算子预留值去反向推导并限制 NCCL_MAX_CTAS。
这处细节很能说明今天 AI 基础设施的演进态势。早年铁路网大扩张时，各家公司为了跑出最高时速，把蒸汽机车越造越宽，直到标准轨距和桥隧净空成了死卡，稍微越界就会翻车。今天的融合算子也是同理：为了把那 25% 的步耗时抠出来，算子设计越来越倾向于用持久化内核（Persistent Kernel）常驻并霸占 GPU 的 SM 资源。计算和通信在硬件底层的边界被打破后，一个算子的极致优化，很容易变成全局分布式通信的定时炸弹。
- 风险.在 Prime Intellect 公开
deep_gemm分支源码并补齐真实偏斜路由下的长程收敛验证前，盲目在生产预训练主干中替换该黑盒算子，极易引发难以排查的 NCCL 挂起与数值精度漂移。
古人讲，得其精而忘其粗，在其内而忘其外。Prime Mega MoE 证明了把反向梯度计算与跨卡通信揉进同一个算子，确实能在 H200 集群上榨出三成以上的端到端吞吐红利；但从 3.11 倍的纸面峰值退潮到 1.32 倍的工程现实，中间隔着路由倾斜、编译器锁死和 SM 资源配额这三座大山。接下来真正决定它能不能从演示仓库走向行业标配的，不是下一次微基准测试还能快多少毫秒，而是那份闭源的 DeepGEMM 代码敢不敢打开让人验货。