Sonar-MoE 在反向传播中更新专家，MoE 训练峰值显存降约两成

11月3日周二 02:30论文AI 评分 72/100arXiv cs.AI

AI 聚合

本条为 AI 依据下方公开信源自动整理生成的摘要，不构成转载，可能存在偏差，请以原文为准。整理者：贝果科技 AI 资讯助手。

这篇论文提出 Sonar-MoE，把原本用于稠密模型的 optimizer-in-backward 做法搬到 MoE 的批量专家张量上：每个专家张量在反向传播过程中就完成更新，梯度随即释放，GPU 上不再同时保留超过一层的专家梯度。作者在 bf16 下微调 OLMoE-1B-7B 与 Granite-3.1-3B-A800M，并测试两种专家 kernel 后端，峰值显存下降 19% 到 22%；在不启用专家梯度裁剪时，更新结果与标准训练逐位一致，留出集损失与各基线的差距在 0.003 以内。相比带全局范数裁剪的标准训练，每步耗时还少 17% 到 23%。作者指出，按整批张量而非单个专家更新是速度优势的来源，否则同等显存下会慢 20% 到 72%。

全文梳理

AI 摘要依据下方信源原文自动整理，非原文转载

显存占用为何随专家增长

MoE 模型的绝大部分参数位于专家内部，而常规训练流程会把每个专家的梯度一直留在 GPU 显存里，直到优化器执行更新步骤。这意味着显存开销随专家数量与单个专家的规模同步上升，模型越大，这部分占用越突出。Sonar-MoE 的切入点正是这段梯度驻留期：它把更新动作提前到反向传播过程中完成，专家张量一旦算出梯度就立即更新并释放，因此显存中同时存在的专家梯度不超过一层。这一思路并非全新，作者将其从稠密模型上的 optimizer-in-backward 迁移到了 MoE 的批量专家张量场景。

实测的显存与速度数据

实验选取 OLMoE-1B-7B 与 Granite-3.1-3B-A800M 两个模型，在 bf16 精度下微调，并分别搭配两种专家 kernel 后端，以检验结论是否依赖特定实现。结果显示峰值显存下降 19% 到 22%。速度方面，与采用全局范数裁剪的标准训练相比，每一步耗时缩短 17% 到 23%。作者特别说明，收益来自以整批张量为单位执行更新，而不是逐个专家处理；若改成后者，在显存相同的情况下会出现 20% 到 72% 的减速，这也解释了为何批量张量是该方法保持速度的关键。

数值一致性与适用范围

在正确性上，作者报告在不使用专家梯度裁剪时，Sonar-MoE 的更新结果与标准训练逐位相同，留出集损失与全部基线的差距控制在 0.003 以内，说明显存优化没有以牺牲训练质量为代价。与对所有参数统一采用 optimizer-in-backward 的方案相比，Sonar-MoE 在显存和速度上与之持平，同时仍能对稠密参数执行裁剪，保留了这一训练技巧的可用性。论文未在摘要中给出更大规模模型或更多后端组合的结果，相关结论的边界仍需结合原文实验部分判断。

为什么值得看

MoE 显存瓶颈直接决定能训多大模型；这里给出可复现的显存与速度收益，且数值与原训练一致。

微调MoEGPU论文

信源1 家

[1]arXiv cs.AI一手信源Sonar-MoE: In-Backward Expert Updates for Memory-Efficient Mixture-of-Experts Training

关键事实

Sonar-MoE 在反向传播阶段更新每个专家张量并立即释放其梯度，使 GPU 不同时持有多于一层的专家梯度[1]
在 bf16 下微调 OLMoE-1B-7B 和 Granite-3.1-3B-A800M、使用两种专家 kernel 后端时，峰值显存降低 19% 到 22%[1]
不启用专家梯度裁剪时，其更新与标准训练逐位相同，留出集损失与所有基线相差不超过 0.003[1]
相比带全局范数裁剪的标准训练，每步耗时减少 17% 到 23%[1]
按整批张量更新而非逐个专家更新，避免了同等显存下 20% 到 72% 的减速[1]

Sonar-MoE 在反向传播中更新专家，MoE 训练峰值显存降约两成

全文梳理

显存占用为何随专家增长

实测的显存与速度数据

数值一致性与适用范围

为什么值得看

信源1 家

关键事实

相关 · 论文

Axiom Math 融资 16 亿美元，为 AI 数学构建可验证基础

BEAKER：面向自动驾驶化学实验室的具身智能基准发布

FrontierPhysics 基准发布：56 项任务考察智能体端到端物理研究

HALO 人形机器人系统：仿真训练实现零样本真机迁移，成功率 91%