清华团队提出八卦炉 2：万卡集群 MoE 训练显存自适应调度
把重计算和卸载从启动前写死的静态配置，改成运行时逐算子实时决策，用算子级调度把 MoE 显存尖峰压在设备上限内，不用重启任务。
MoE（混合专家，一种让每个 token 只激活部分专家网络的大模型架构）训练的显存尖峰会让整个万卡任务崩掉重跑。清华翟季冬团队提出八卦炉 2：在门控计算完成、专家计算开始前的窗口里按真实负载逐算子决定保存、重计算还是卸载（把激活值从显存放回内存），无需停机改配置。128 到 12,288 张海光 DCU 上平均吞吐提升 1.14×，MFU（模型算力利用率）最高 35%。
正文摘录
.jpg) 大模型训练已经跑到万卡集群规模，显存始终是那道隐形的门槛。 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，整个分布式任务直接挂掉。