摘要：NVIDIA 在 2026 年 6 月 15 日发布了关于 MoE 训练融合内核的技术文章，重点不是单个算子的跑分，而是把 GLU 激活、量化、Grouped GEMM、CUDA Graph、Transformer Engine 和 Megatron Core 串成一条更少同步、更少内存搬运的训练路径。对研发团队来说，这篇文章的价值在于提醒我们：MoE 模型的效率问题，已经从“有没有足够 GPU”进入到“内核、框架、通信和调度是否协同设计”的阶段。

背景：MoE 扩大了模型容量，也放大了系统复杂度

Mixture of Experts（MoE）已经成为大模型扩展的重要路线。它的核心思路是：模型总参数量可以很大，但每个 token 只激活部分专家，从而在相对可控的计算预算内提高模型容量。

问题也随之出现。MoE 的训练链路不再是简单的 dense MLP 堆叠，而是包含 token routing、按专家分组、Grouped GEMM、激活函数、低精度量化、跨 GPU 通信和反向传播等多个环节。任何一个环节暴露出 CPU 同步、额外显存读写或 kernel launch 开销，都会吞掉理论上的稀疏收益。

NVIDIA 这次发布的重点，是用 CuTe DSL 编写一组面向 dense 与 MoE MLP 的融合内核，并通过 cuDNN Frontend、Transformer Engine 和 Megatron Core 暴露给上层框架。官方给出的数据包括：融合内核相对非融合路径可获得 1.3x 到 2x 的 kernel 级速度提升；在特定 DeepSeek-V3 预训练配置中带来 8% 端到端提升；在 GPT-OSS 预训练配置中带来最高 93% 的端到端提升。

技术要点一：把 GLU 激活融合进 GEMM epilogue

现代大模型常用 SwiGLU、GeGLU 等 GLU 变体。它们通常会把 FC1 的输出拆成 input 与 gate 两部分，再做门控乘法。如果按朴素实现，GEMM 结果需要先写回全局显存，激活函数再读取中间张量，最后再写回输出。

这类操作的瓶颈不一定是算力，而是内存访问。Tensor Core 可能在等数据搬运，GPU 利用率被拉低。

NVIDIA 的方案是重排权重布局，让同一个 thread block 在 GEMM epilogue 阶段就能同时访问 input 和 gate 两部分，然后直接完成 SwiGLU/GeGLU/sReLU 等激活计算。这样可以减少中间张量的全局显存读写，把原本分散的操作压进一个更硬件友好的执行单元。

对工程实践的启发是：如果团队在做自研训练框架或深度改造 Transformer block，不能只看模型结构图上的算子数量，还要看这些算子之间是否会制造额外的 memory round-trip。MoE 的很多性能损耗，往往就藏在这种“看起来很小”的中间张量里。

技术要点二：减少 CPU 介入，让 MoE 迭代更适合 CUDA Graph

MoE 的另一个难点是动态性。每个专家处理多少 token，通常要在运行时才能知道。传统 grouped GEMM 往往需要 CPU 获取 shape 信息并发起多个 kernel launch，这会引入 host-device 同步和 CPU 侧调度开销。

NVIDIA 这次强调的 sync-free MoE，是让 GroupGEMM 内核在 GPU 内存中跟踪每个 group 的 token 数，尽量减少 CPU 对单次迭代的介入。这样做的直接收益是：完整训练迭代更容易被 CUDA Graph 捕获，从而减少 launch overhead，并让 GPU 执行路径更稳定。

这对研发团队尤其重要。很多团队在做推理或训练优化时，会优先看单个 kernel 的耗时，但 MoE 的真实瓶颈经常是“很多小同步 + 很多动态 launch”叠加出来的系统性开销。要优化 agent、长上下文或 MoE 训练，profiling 粒度需要从单算子扩展到完整 iteration timeline。

技术要点三：把低精度量化也并入融合路径

低精度训练已经成为提升吞吐的重要手段。NVIDIA 文章中特别提到 MXFP8 和 NVFP4 相关路径：激活函数之后通常还要进行量化、转置或 amax 统计，为后续低精度 GEMM 做准备。

如果这些步骤单独执行，就会再次读写 BF16 中间结果，形成额外 memory pass。新的融合内核把量化、转置、缩放、clamp、bias 等操作放进 GEMM 或反向传播的融合路径中，减少内存带宽消耗，也减少 Tensor Core 空转。

这说明低精度优化不能只理解为“把 dtype 从 BF16 换成 FP8/FP4”。真正决定收益的，是低精度数据流是否贯穿了 kernel、框架和模型并行策略。如果量化前后不断落回高精度中间张量，理论收益很容易被内存带宽吃掉。

研发视角：这对大模型工程意味着什么

第一，MoE 的优化正在从算法层进入全栈协同阶段。模型结构、权重布局、kernel fusion、CUDA Graph、通信 overlap 和框架 API 需要一起设计。只在 PyTorch 层面替换模块，往往拿不到完整收益。

第二，框架抽象层正在变得更关键。NVIDIA 已经把这些能力接入 cuDNN Frontend v1.23.0+，并通过 Transformer Engine v2.15+ 与 Megatron Core 26.04-alpha.rc2+ 暴露。对大多数团队来说，优先路径不是自己写 CUDA kernel，而是跟进这些底层库和训练框架的版本能力。

第三，benchmark 要看端到端。文章中的 kernel 级提升和端到端提升并不总是线性对应。DeepSeek-V3 配置中是 8%，GPT-OSS 配置中可到 93%，差异本身就说明：不同模型、并行策略、通信占比和 CPU overhead，会极大影响优化收益。

实践建议

如果你负责大模型训练或基础设施，可以从四个方向验证这类优化是否值得接入：

1. 用 profiler 拆分 MoE block 的时间线，重点看 activation、quantization、transpose、Grouped GEMM 和通信 overlap。
2. 检查训练栈版本，确认 cuDNN Frontend、Transformer Engine、Megatron Core 是否已经支持相关融合路径。
3. 对比开启与关闭融合内核时的端到端 tokens/s，而不是只看单 kernel latency。
4. 在评估 FP8/FP4 训练时，同时关注精度、收敛、显存带宽和数据布局转换成本。

风险与限制

这类优化高度依赖硬件、模型结构和框架版本。官方数据通常来自特定配置，不能简单外推到所有 MoE 模型。对于小规模训练、非 NVIDIA 栈、JAX 或自定义框架，接入成本也可能高于收益。

另外，融合内核会提高调试复杂度。算子边界变少后，定位数值误差、溢出、精度退化或性能抖动会更难。研发团队在生产环境启用前，仍然需要保留可回退路径和足够细的验证指标。

结论

NVIDIA 这篇文章的核心信号是：MoE 训练效率已经进入“全栈细节决定上限”的阶段。未来的大模型训练优化，不只是堆更多 GPU，也不是简单改 dtype，而是把 kernel fusion、低精度、动态调度、CUDA Graph 和模型并行策略组合起来。

对于研发团队，最务实的动作是：持续跟进 cuDNN Frontend、Transformer Engine、Megatron Core 等基础库，把 profiling 从单算子扩展到完整训练迭代，并用端到端吞吐验证每一次底层优化是否真正转化为训练效率。

参考来源

• NVIDIA Technical Blog：Boosting MoE Training Throughput with Advanced Fusion Kernels，2026-06-15
  https://developer.nvidia.com/blog/boosting-moe-training-throughput-with-advanced-fusion-kernels/
• NVIDIA cuDNN Frontend 文档
  https://docs.nvidia.com/deeplearning/cudnn/frontend/latest/
• NVIDIA Transformer Engine
  https://github.com/NVIDIA/TransformerEngine
• NVIDIA Megatron Core
  https://github.com/NVIDIA/Megatron-LM