清华翟季冬团队八卦炉2论文被SC26录用

机器之心发布 大模型训练已经跑到万卡集群规模，显存始终是那道隐形的门槛。 MoE 架构把大模型推到了万亿参数级别，也埋下了一颗定时炸弹：显存尖峰。某个微批次的 token 一旦集中涌向少数专家，激活显存瞬间飙升，一张卡 OOM，整个分布式任务直接挂掉 —— 几百步白跑。 重计算、激活卸载都是常用手段，但问题在于静态配置。激进配置平时 MFU 30%，尖峰必崩，一次冷重启 284 秒；全层重计算稳是稳，MFU 直接掉到 24.6%，算力长期闲置。怎么选都亏。 能不能让系统自己跟着显存压力走 —— 平稳时全速跑，尖峰来了临时加码，过去了再收回来？ 清华大学翟季冬教授团队的答案是八卦炉2（BaGuaLu-2 ），相关论文已被SC26录用。运行时自适应，零配置干预 —— 门控算完、专家算之前这个窗口里，系统根据真实负载实时决策，不同算子分别选择保存、重计算或卸载，把显存峰值压在设备上限以内。不用停任务，不用改配置。 万卡智算中心实测：128 到 12,288 张海光 DCU，188B 到 1.04 万亿参数，平均吞吐比基线高 1.14×，12,288 卡下总吞吐 2.012 EFLOPS，平均 MFU 32.9%、最高 35%。 论文链接：https://arxiv.org/abs/2610.23064 一、问题背景：MoE 训练中的显存尖峰痛点 如果你训练过 MoE 模型，大概率遇到过这种情况：训练跑了几百个迭代都很平稳，突然某个微批次里 token 集中涌向少数几个专家，激活显存瞬间飙升，一张卡 OOM，整个分布式任务直接挂掉。 问题出在 “选择” 本身 MoE 的核心是路由器为每个 token 选择少数专家执行。现代负载均衡方法能抑制长期的专家拥塞，但无法预知当前批次的具体内容。实测数据：97.1% 的迭代中专家负载不均衡率低于 1.2×，但 2.9% 的异常迭代中最高达到 2.6×。就是这极少数迭代，反复打断训练进程。 流水线让问题更严重 流水线预热阶段只有前向、没有反向释放激活，多个微批次的激活同时驻留设备。如果其中一个批次把大量 token 路由到当前设备的少数专家，额外的 MoE 激活叠加在已驻留激活之上，局部偏斜直接变成设备级 OOM。 静态配置的两难 重计算和卸载是常用工具，但传统做法是在启动前写死配置。激进配置正常阶段 MFU 30.0%，但尖峰必 OOM，一次冷重启 284 秒；全层重计算的保守配置 MFU 降到 24.6%，算力长期闲置。无论怎么选，都在浪费资源。 图 1：MoE 负载尖峰会推高激活显存，静态策略不得不在 OOM 重启和保守运行之间反复切换。 二、设计思路：运行时自适应，零配置干预 八卦炉 2 的核心思路很直接：显存压力在变，策略也应该跟着变。平稳时少做干预保留高吞吐，尖峰时临时加强缓解，尖峰过去自动恢复 —— 不终止任务，不修改配置，不重启。这套机制叫 Flexible Activation Provisioning（灵活激活显存供给）。 图 2：平稳阶段采用较轻的显存缓解，尖峰到来时临时加大力度，显存曲线始终被控制在设备上限之内。 ① 激活显存建模：可扩展的成本模型 系统把保存激活、重计算、卸载放进同一个成本模型，同时估算显存收益和时间开销，并考虑额外操作能否与原有计算通信重叠。同样大小的卸载，发生在不同流水线位置，暴露在关键路径上的时间可能完全不同。多模型多配置下，平均预测误差仅 1.56%。模型设计为可扩展，方便接入新的算子和策略。 ② 自适应供给：算子级精细控制 决策点选在一个关键窗口：MoE 门控计算完成后、专家计算开始前。此时真实负载已知，风险尚未落地，仍有时间临时加强重计算或卸载。策略不再以整层为单位，不同算子分别选择保存、重计算或卸载，只选满足预算的最小组合。系统还会追溯激活来源，排除那些不同精度重复保存、一个卸载另一个仍驻留的冗余组合。 图 3：系统根据当前流水线状态和 MoE 负载，依次完成激活显存建模、自适应供给与双批次融合执行。 ③ 双批次融合：动态规划调度，开销可忽略 重计算和卸载不是免费的，直接排在关键路径上就是用吞吐换安全。八卦炉 2 利用流水线空隙 —— 稳定阶段设备上同时存在当前前向、当前反向、前一前向卸载和下一反向恢复，这些操作属于不同微批次，保持依赖顺序即可交错执行。系统用轻量级动态规划重排计算流和通信流，把额外工作塞进硬件空泡；连续算子合并、预算状态缓存，大多数迭代直接复用调度结果。最终决策开销低于 10 ms，而一次迭代超过 18 秒。 图 4：先通过动态策略压低显存峰值，再交错调度相邻批次，将额外计算和数据搬运藏入硬件空泡。 三、实测效果：多规模验证，代码已开源 全规模性能领先 在某万卡智算中心，模型从 188B 到 1.04 万亿参数，集群从 12

来源只提供摘要，完整内容请打开原文。