Flaky MellumModelTest.test_load_balancing_loss — the only copy without @is_flaky

快速结论：这个报错出现在 Transformers 合并队列（merge queue）运行 MellumModelTest.test_load_balancing_loss 时，断言对 aux_loss 的标量比较失败（Expected 2.0 but got 2.037735939025879），并导致 PR 被移出队列。优先排查该测试是否缺少 @is_flaky(max_attempts=2) 装饰器——它是八个同源副本中唯一没有该装饰器的一份。

适用环境：Issue 已确认的信息包括：仓库为 huggingface/transformers，测试文件为 tests/models/mellum/test_modeling_mellum.py（第 71 行断言），失败发生在 GitHub Actions 合并队列运行中（run 32273200040）。Issue 未给出操作系统、Python、CUDA、PyTorch、显卡等版本信息，此处不补写。

最快修复方案：暂无确认的一步修复方案。Issue 讨论中有人开过 #48139，做法是补上 @is_flaky(max_attempts=2)（需先 import is_flaky），但该 PR 已被作者本人关闭——原因是按仓库 AGENTS.md 要求，不得在未经 Issue 作者或维护者明确同意的情况下替他人开 PR。该修复未被合并，因此只能作为“可优先尝试”的方向。

注意事项：补 @is_flaky(max_attempts=2) 只是让测试重试，并没有放宽断言本身；Issue 中明确表示“放宽容差是另一个决定”，所以容差 ±0.03 仍未修改。此外，如果由非 Issue 作者提交该修改，需先在本 Issue 线程中获得作者（@subin9）或维护者的明确许可。

问题场景

在 huggingface/transformers 仓库中，针对 Mellum 模型的测试用例 MellumModelTest.test_load_balancing_loss 在合并队列（merge queue）运行时失败，失败结果直接把对应 PR 从队列中驱逐。该测试用于检查 MoE 类的负载均衡辅助损失（load balancing / aux loss），其断言期望某个标量约为 2.0，容差为 ±0.03。

仓库中另有七个模型测试带有同一测试的副本（其函数体标注为 # Copied from Qwen3-Moe），这些副本大多带有 @is_flaky(max_attempts=2) 装饰器，而 Mellum 这一份是唯一没有的，因此偶发失败时没有重试机会。

报错原文

tests/models/mellum/test_modeling_mellum.py:71: AssertionError: Scalars are not close!
Expected 2.0 but got 2.037735939025879.

原因分析

该断言比较的 aux_loss 对初始化随机数（init RNG）敏感。Issue 讨论中有人用同样的构造路径遍历了 300 个初始化种子，得到的 aux_loss 落在 1.998362–2.022192 区间，而断言允许的容差是 ±0.03（即约 1.97–2.03）。也就是说，本地扫种得到的上界已经用掉了约 0.022 的容差预算，合并队列里出现的 2.0377 恰好越过同一容差边界。这说明失败不是一次性偶发，而是确实存在初始化敏感性。

最可能的原因：Mellum 这份测试副本在添加模型时漏加了 @is_flaky(max_attempts=2)，导致偶发越界时直接判失败，而没有像其他七个副本那样自动重试。

环境排查

确认测试文件位置与行号：tests/models/mellum/test_modeling_mellum.py:71。
确认该测试函数上是否带有 @is_flaky(max_attempts=2) 装饰器，并与 Qwen3-MoE 的同源副本对比。
确认失败发生在哪个运行环境（Issue 中为 GitHub Actions 合并队列 run 32273200040）。
Issue 未提供 Python、CUDA、PyTorch、显卡或依赖版本，需要时请在对应 CI 运行日志中自行核对，本文不代为假设。

解决步骤

打开 tests/models/mellum/test_modeling_mellum.py，定位第 71 行附近的 test_load_balancing_loss。
比对该测试与其他七个同源副本（尤其是它标注 # Copied from Qwen3-Moe 的 Qwen3-MoE 版本）的装饰器差异，确认 Mellum 这份缺少 @is_flaky(max_attempts=2)。
可优先尝试的修复：在该测试上补 @is_flaky(max_attempts=2)，并使文件顶部 import 相应符号（Issue 中描述的“两行修复”：import is_flaky + 装饰）。
不要顺带放宽断言容差——Issue 中明确把“放宽容差”作为另一个独立决定处理。
注意提交流程：如你不是该 Issue 的作者，需先在本 Issue 线程中获得作者（@subin9）或维护者的明确许可再开 PR，否则可能被按 AGENTS.md 关闭（#48139 即因此被作者本人关闭）。

验证方法

在修复分支上重复运行该测试（例如本地或 CI 中执行 test_load_balancing_loss），确认加入 @is_flaky(max_attempts=2) 后偶发失败可被重试兜住；同时确认断言与容差未被改动。若再次在合并队列中运行，应不再出现该测试因偶发越界而驱逐 PR 的情况。若希望在本地复现初始化敏感性，可参考讨论中的做法：用相同的构造路径遍历多个初始化种子，观察 aux_loss 分布是否接近容差边界。