Hugging Face 用缩小模型在 CPU 上捕捉回归：UMT5 注意力漏洞潜伏近两个月的教训

2026年7月30日，Transformers 库为 T5 模型启用了 PyTorch 的缩放点积注意力（SDPA）。这个改动本身没有引入错误，但它有一个副作用：UMT5 的解码器从此可以 attend 到未来的 token。在训练时，模型能偷看自己本该预测的答案。程序没有崩溃，没有任何测试失败，这个 bug 在 main 分支上安静地潜伏了将近两个月。

问题不在于测试不够多。Transformers 支持超过 750 种模型，测试套件包括 88,000 多个 CPU 测试和 200,000 多个 GPU 测试，覆盖流水线、训练、分布式执行、量化和注意力内核。但集成测试需要加载真实 checkpoint 并在真实硬件上运行，全部跑一遍意味着让大量 GPU 整天忙碌，这在每个 PR 上不现实。等到定时任务发现回归时，代码可能已经合入 main。

Hugging Face 团队的应对思路是缩小模型本身。他们构建一种称为"fixture"的东西：从真实 checkpoint 的配置出发，减少层数和宽度，但保留模型拥有的每一种层类型，以及不变的分词器和处理器文件。这个缩小模型发布一次，之后反复使用。团队在廉价 CPU 上对它运行"快速集成测试"。UMT5 的 fixture 权重只有 66 MB，而源 checkpoint 是 1,227 MB。

这套方法被打包为"模型集成合约"（Model Integration Contract，简称 MIC），由三个部分组成：fixture（缩小模型）、usage path（一个可运行的示例，比如生成文本或执行训练步骤）、baselines（运行该示例时记录的输出，经人工审核）。合约成立的条件是：在 fixture 上运行 usage path 仍然产出与 baselines 一致的结果。合约覆盖的是架构和用法路径，而非单个 checkpoint——兼容的 checkpoint 可以共享一个 fixture，但各自保留自己的预期结果。

缩小模型并非简单地砍掉尺寸。最初的配方只是减小维度、减少层数，但这对于混合架构不够用：如果保留的两层都是滑动注意力而全注意力层消失了，测试就失去了意义。现在的配方有四步：缩小配置（减少隐藏大小、注意力头数和深度，保留不同层类型包括滑动与全注意力的混合、稠密与 MoE 层的混合）；保持预处理不变（保留词表、特殊 token 和输入维度，逐字节复制分词器和处理器文件）；构建并验证权重（尝试随机权重，改变输入检查模型是否响应，不响应就训练，重新加载检查输出、损失和梯度是否有限，拒绝失败的构建）；冻结并记录（保存权重，在已知良好的 Transformers 版本上测量可重复的输出，人工审核各平台和精度的基线，发布固定快照）。

一个关键细节决定了这个 fixture 能否捕捉到 UMT5 的 bug：合约使用的是 SDPA，即默认的注意力路径。如果只跑 eager attention 变体，就会漏掉这个 bug。fixture 只有在走和真实 checkpoint 相同的代码路径时才有用。团队重放了五个月的 Transformers commit，UMT5 fixture 从 7 月 30 日引入到 9 月 28 日修复，在每一个受影响的 commit 上都标记出了回归——标签对数概率与审核基线相差 1.22，训练损失相差约 0.20。

在权重初始化方面，团队面临随机与过拟合的选择。随机 Whisper fixture 对音频变化的响应很弱，能跑起来但测试效果差。于是他们在少量"音调对应单词"的样本上过拟合，不是为了教它语音识别，只是让音频变化在输出中可见。在注入故障的对比实验中，随机权重 fixture 捕捉到 24 个故障中的 18 个，过拟合 fixture 全部捕捉到。但两种版本都漏掉了一个真实 Whisper checkpoint 暴露的辅助解码 bug。团队目前的策略是：随机权重通过检查时就保留，需要更好灵敏度或可读答案时才过拟合。