机器之心文章10-28中文

SC26 顶会论文：八卦炉 2—— 让万卡集群学会临场应变

约 10 分钟约 2,499 字

推荐理由八卦炉二讨论大规模训练集群的动态调整机制，适合基础设施团队理解资源变化、调度与训练连续性之间的工程取舍。

读前速览

4 个要点

清华大学翟季冬教授团队发布 BaGuaLu-2，通过运行时自适应的激活显存供给机制，解决了 MoE 万卡集群训练中的显存尖峰与 OOM 问题，实现了零配置下的吞吐量提升。

MoE 训练中的显存尖峰源于专家负载的动态不均衡。
虽然长期负载均衡有效，但极少数迭代中 token 会集中涌向少数专家，导致激活显存瞬间飙升，引发 OOM 并导致昂贵的分布式任务重启。
BaGuaLu-2 实现了运行时自适应的显存供给策略。
系统在门控计算后的窗口期根据真实负载实时决策，不再采用整层静态配置，而是对不同算子分别选择保存、重计算或卸载，以最小组合满足显存预算。
通过双批次融合调度将额外开销降至最低。
利用流水线空隙，通过轻量级动态规划将重计算和卸载操作与原有计算通信重叠，使决策开销在 10ms 以内，对整体迭代时间影响可忽略。
在大规模国产算力集群上验证了显著的吞吐提升。
在 12，288 张海光 DCU 的万卡规模下，平均 MFU 达到 32.9%~35%，吞吐量相比 Megatron-Kuai 等基线有明显增益。

完整摘要

针对 MoE 架构在大规模集群训练中因专家负载不均导致的显存尖峰（OOM）痛点，清华大学翟季冬教授团队提出了 BaGuaLu-2 系统。该系统通过 Flexible Activation Provisioning 机制，在门控计算完成后、专家计算开始前的关键窗口期，实时决策不同算子的激活策略（保存、重计算或卸载）。结合可扩展的成本模型与双批次融合调度技术，BaGuaLu-2 能将额外开销隐藏在硬件空泡中。在万卡智算中心实测中，该系统在 1.04 万亿参数规模下平均吞吐比基线提升 1.14×，有效平衡了显存安全与算力利用率。

机器之心 2026-10-28 12:03 北京

运行时自适应化解显存尖峰，无需修改配置，代码已开源

机器之心发布

大模型训练已经跑到万卡集群规模，显存始终是那道隐形的门槛。

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 万亿参数，集群从 128 到 12,288 张海光 DCU（BW1000）。相比 Megatron-Kuai 和 AdaPipe，平均提升 1.14× 和 1.13×（已含 OOM 重启损失）。12,288 卡下总吞吐 2.012 EFLOPS，平均 MFU 32.9%，最高 35%。