编纂｜Panda

「快！」

说到索尼克，不论是刺猬索尼克还是音速索尼克，各人的第一印象多半就是「快」，而「快」也是此刻很多 AI 模型和利用优化的一大主题指标
。

近日，由普林斯顿大学 Tri Dao（FlashAttention 的一作）和加州大学伯克利分校 Ion Stoica 辅导的一个结合钻研团队也做出了一个超快的索尼克：SonicMoE

一作 Wentao Guo 的推文，他目前在普林斯顿大学就读推算机科学博士

据介绍，SonicMoE 能在英伟达 Blackwell GPU 上以峰值吞吐量运行！并且运算机能超过了 DeepSeek 之前开源并引发巨大轰动的 DeepGEMM
。

有趣的是，DeepSeek 前些天还在 DeepGEMM 库中开源了新的技术 Mega MoE，即巨型 MoE—— 从名字也能看出来，这与 SonicMoE（音速 MoE）显然是两个分歧的方向，我们也等待能看到「」与「」这两个方向的更直接的对比
。

下面我们就基于官方技术博客，单一相识下 SonicMoE
。

博客地址：https://tridao.me/blog/2026/sonicmoe-blackwell/代码库：https://github.com/Dao-AILab/sonic-moe论文地址：https://arxiv.org/abs/2512.14080

MoE 与它的隐患

要理解 SonicMoE 解决的是什么问题，先得意识一种在主导前沿 AI 的架构设计 —— 混合专家模型（Mixture of Experts，MoE）
。

细粒度 MoE 架构

设想一家医院
。面对每一位患者，医院不会让所有科室同时出动，而是吓咨全科医生判断，再分诊给最相宜的专科
。MoE 架构的逻辑与此类似：模型内部有大量「专家」子网络，每一个输入的信息片段（即 token，能够理解为文字或词语）只会被路由到其中一幼部门专家处置，而不是流经所有参数
。

这样做的益处不言而喻：用相对较少的推算量，撑起了一个参数规模重大的模型

2024 年颁布的 Mixtral 8x22B，以及近期的 DeepSeek V3.2、Kimi K2.5、Qwen3 等明星模型，都是 MoE 架构的忠诚拥趸
。依照模型缩放法令，专家越「细粒度」（即每个专家越幼、数量越多），模型在一致推算量下的阐发往往越好
。因而在短短两年间，MoE 专家的粒度提升了整整 9 倍，每次激活的专家比例则降至原来的十二分之一
。

然而，价值也随之而来
。

尺度 MoE 实现前向传布的工作流程
。π 是存储路由元数据的二进造掩码
；粕虬凳灸诤颂烨
。蓝色框是 HBM 中的变量
。红色标签暗示在正向 / 反向传布过程中缓存的激活值
。紫色框是最终输出
。全局内存中每个变量旁边的橙色框暗示对应 Qwen3-235B-A22B-Thinking-2507 MoE 模型在处置 32k 个 token 时的张量大幼比例
。

尺度 MoE 实现的反向激活梯度传递工作流程
。

当专家越来越多、越来越「细」，训练这样的模型会遭逢两堵越来越高的墙：

第一堵墙是显存
。在训练神经网络时，前向传布的中央了局必须被保留下来，以便反向传布时推算梯度
。对于细粒度 MoE 来说，这些中央了局（激活值）的规模与专家粒度成正比 —— 专家越细，显存占用越大，最终会逼近 GPU 显存的物理极限
。

第二堵墙是内存带宽
。GPU 的机能取决于两个维度：算力（每秒能做几多次运算）和带宽（每秒能搬几多数据）
。当专家足够细时，每个专家处置的数据量太少，GPU 的算力根正本不及被填满，大量功夫都花在了从内存「搬运」数据上
。这正是所谓「内存瓶颈」
。对于典型的 Qwen3 细粒度 MoE，其单元推算量的内存接见强度比等参数量的通常模型逾越 12 倍
。

现有的开源训练工具（如 ScatterMoE 和 MoMoE）对这两个问题都存在显著不及，尤其是随着模型越来越细粒度，差距愈发显著
。而SonicMoE正是为此而生
。

SonicMoE 的每一层激活影象占用空间（左图）即便在专家粒度（嵌入维度 / 专家中央维度）增长时也维持不变，并且与现有的 MoE 训练核 ScatterMoE 和 MoMoE 相比，SonicMoE 能够实现 1.87-4.04 倍的相对加快
。

主题创新：一次算法级的重新设计

SonicMoE 的关键洞察，乍听单一，却必要深厚的系统级思想能力想到：问题的本原在于，现有 MoE 训练框架在中央了局的存储上过于「慷慨」—— 它们把太多一时数据写入了显存，而这些数据本能够不存
。

传统步骤在执行 MoE 的前向传布和反向传布时，会在每个推算阶段之间将中央张量（即矩阵大局的中央数据）写入 GPU 的高带宽内存（HBM）
。这就好比一个厨师每炒完一路中央步骤，就把食材装盘放进冰箱，下一步再取出来持续 —— 频仍的存取自身就是大量功夫的浪费
。

SonicMoE 的前向推算工作流程以及与 PyTorch 中尺度 MoE 实现的比力
。这里还比力了两种步骤的激活内存和 IO 成本
。

SonicMoE 的算法重设计从底子上扭转了这一流程，主题有两点：

第一，激活内存与专家粒度解耦

在训练反向传布中，SonicMoE 通过重新设计推算挨次，齐全预防了缓存任何与专家规模成比例的中央张量
。

具体来说，它将正本必要缓存的「下投影输出」等关键中央量，通过重排矩阵乘法的收缩挨次来解除 —— 不再存储中央了局，而是在必要时通过聪明的推算蹊径直接推导出所需梯度
。

这使得 SonicMoE 的每层激活内存占用，在专家粒度大幅增长时维持恒定，相当于一个一样激活参数量的浓密模型
。

这一改进无需任何额表的矩阵重推算价值，正面回覆了此前业界一向以为「鱼和熊掌不成兼得」的问题
。

第二，IO 感知的算子融合

SonicMoE 将正本分散成多个 GPU 核函数（kernel）的操作大量融合在一路
。

例如，「Gather 融合」技术让数据搬运操作在矩阵乘法推算核的执行过程中同步实现，而不是作为单独步骤先把数据重排好再交给矩阵乘法 —— 这不仅省去了一次齐全的内存读写，还利用了 GPU L2 缓存的部门性优势，让缓存射中率从约 66% 提升至约 75%，进一步降低了接见慢速 HBM 的频率
。

此表，SwiGLU 激活函数的推算也被融入矩阵乘法的尾声（epilogue）阶段，在数据还驻留在寄放器时当场实现，无需额表的内存读写
。

在最关键的反向传布核函数（dH kernel）中，SonicMoE 还进一步利用 GPU 的异步执行个性，将数据搬运的期待功夫与矩阵运算重叠起来
。

SonicMoE 的 dH 工作流程图的语义与尺度 PyTorch MoE 多核实现等效，同时 SonicMoE 显著降低了 IO 成本
。

实测了局显示，即便该核函数的 HBM 数据流量增长了 24%，张量主题（Tensor Core）的利用率仅降落约 10%—— 内存开销险些被算力齐全「吸收」
。

能够利用最新的 NVIDIA 硬件个性来暗藏 SonicMoE 的 dH 内核中的 IO 延长，并大幅削减整体运行功夫
。

软件抽象层 QuACK：让创新能跨代迁徙

SonicMoE 还有一个容易被忽视的工程亮点：钻研团队开发了一套名为QuACK的统一软件抽象层，将所有 MoE 矩阵乘法核函数统一为「主循环 + 可定造尾声」的共同结构
。

两个使用 QuACK 实现的 SonicMoE 内核
。左侧：内核工作流程图
。中央：QuACK 尾声混合类，其中每个内核重写 epi_visit_subtile（dH 为 88 行代码，上投影前向为 21 行代码）
。右侧：SonicMoE 的简化内核启动挪用
。

这样的设计意味着，当 GPU 从上一代 Hopper 架构（H100）升级到最新的 Blackwell 架构（B200/B300）时，硬件特有的优化只必要在极少数处所做部门批改，主题算法逻辑无需重写
。

Tri Dao 与 Ion Stoica 团队之所以能急剧将 SonicMoE 移植到英伟达最新旗舰 Blackwell GPU 并达到峰值吞吐，很大水平上正是受益于这一前瞻性的软件架构
。

尝试了局

钻研团队在英伟达最新 B300 GPU 上，以六个真实开源 MoE 模型配置为基准进行了全面测评，涵盖从 7B 到 685B 参数的分歧规模，蕴含 OLMoE、Qwen3-235B、DeepSeek V3.2 等当下最受关注的 MoE 架构
。

B300 上 6 种真实 MoE 配置的前向（左）和后向（右）TFLOPS
。从左到右顺次为：OLMoE-1B-7B-0125、gpt-oss-20b、Kimi-Linear-48B-A3B-Base、Qwen3-Next-80B-A3B-Thinking、Qwen3-235B-A22B-Thinking-2507 和 DeepSeek-V3.2-Exp
。Triton 官方示例不支持后向传布，Qwen3-Next-80B 的前向传布也不支持 K=10
。

SonicMoE 与基线模型在 B300 上针对 7B OLMoE 规模 MoE（T=32768，d=2048，n=1024，E=64，K=8）的运行时辰解情况
。

了局相当显著：

与同样针对 Blackwell GPU 优化、由 DeepSeek 开发的 DeepGEMM 基准相比，SonicMoE 在前向传布上均匀逾越54%，在反向传布上均匀逾越35%—— 而 DeepGEMM 自身已是业界公认的高机能实现；与 Triton 官方 MoE 示例相比，SonicMoE 前向传布快21%与目前学术界和工业界宽泛使用的 ScatterMoE、MoMoE 等训练框架相比，SonicMoE 的速杜着势往往达到 近两倍甚至更高
。

从核函数级此外运行时辰析来看，SonicMoE 的加快重要来自两个方面：其一，Gather 融合解除了独立的数据搬运核函数，这是最重要的加快起源；其二，更快的分组矩阵乘法实现（得益于 Blackwell 独有的 CLC 调度器和 2CTA MMA 技术）贡献了额表约 10% 的提升
。

在激活内存方面，当专家粒度从 Mixtral 时期提高到 Kimi K2.5 量级时，传统规划的每层激活内存会线性膨胀，而 SonicMoE 的占用则维持不变
。这对于在有限显存中训练更细粒度的将来模型，意味着更大的操作空间
。

SonicMoE 很快，同时还有更深层的意思：当硬件的进取受造于物理法规逐步放缓，软件层面的创新正越来越多地表演起「平权者」的角色
。

SonicMoE 的论文标题是「硬件高效、软件可扩大的细粒度 MoE 蓝图」—— 这个「蓝图」二字，或许正是钻研团队想传递的信号：这不只是一个工具，而是一种能够被复造和继承的设计哲学
。

SonicMoE 目前已在 GitHub 和 PyPI 开源，支持 H100 和最新 B200/B300 GPU，将来打算扩大至专家并杏注MXFP8/FP4 精度支持，以及下一代英伟达 Rubin GPU
。

在内存和算力日益稀缺的今天，这种创新极具价值，终于这是在为整个 AI 生态节俭真金白银的成本
。

你更看好 DeepSeek 的 Mega MoE 还是今天介绍的 SonicMoE？