Hugging Face 提出模型集成契约：用小模型在 CPU 上提前发现 Transformers 回归

模型能跑起来，不代表计算路径没有出错

11月3日，Hugging Face 工程师 Tarek Ziadé 介绍模型集成契约 Model Integration Contracts，简称 MIC。它针对模型库的一类维护难题：代码改动没有让程序崩溃，却可能悄悄改变注意力、训练损失或生成结果，普通的加载与前向执行检查不一定能及时发现。

文章以 UMT5 为例。团队回溯发现，7月30日的一次注意力实现改动，使其解码器在训练时能够看到未来 token；问题直到9月28日才修复。这里的未来 token 指训练序列中本不该提前访问的位置，不是模型具备了预测真实未来的能力。

缩小的是计算体量，关键架构和预处理仍要保留

MIC 选择从真实检查点的配置生成较小模型，减少宽度和层数，但保留不同类型的层，以及原有的 tokenizer 和 processor 文件。这样便能在较便宜的 CPU 环境运行接近实际使用方式的集成检查，而不是每次都加载完整的大模型。

这种缩小不能机械地只取前几层。混合架构可能同时包含滑动窗口与完整注意力，或稠密层与混合专家层；如果删掉某一类组件，测试就绕开了原本需要保护的代码路径。原文因此把结构保留、输入预处理与权重保存格式都纳入构建要求。

契约由测试模型、使用示例和人工基线组成

团队提出的契约包含三部分：固定发布的小型测试模型、可执行的 Markdown 使用路径，以及经过人工审核的预期输出。使用路径不仅能做文本生成，还可检查训练损失、梯度是否有限、优化器更新是否确实改变权重，避免只测出一个模型对象能够被成功创建。

这些预期结果需要绑定环境与版本。官方介绍的 fleet 数据集记录契约的冻结版本和生成基线时使用的软件包版本，每次持续集成也记录采用的 fleet 版本。这样发现差异后，维护者可以重放同一组输入和预期，而不是面对不断变化的测试目标。

UMT5 回放说明有效，也说明必须选对执行路径

团队用固定契约回放 Transformers 的历史提交，小型 UMT5 测试在问题引入到修复之间持续报出差异。关键在于它执行了默认的 SDPA 注意力路径；只运行 eager 变体则会错过同一个问题。这一案例说明测试是否经过真实使用的分支，比单纯增加测试次数更关键。

原文还展示了在证明分支上撤销修复后重新触发失败的结果，所选测试在 CPU 上的执行步骤用时13.4秒，不含环境准备。这是该演示条件下的测量，不能解释成所有模型检查都只要十几秒，也不是完整持续集成流程的总时间。

Agent 可以起草契约，改变预期仍由人审核

配套 CLI 可以辅助生成契约、构建测试模型并记录基线，新模型的示例与清单可由语言模型起草。作者特别区分了起草与批准：预期结果发生变化仍需要人工审查。否则，测试系统可能把一次错误输出重新记录为正确答案，失去回归检查的意义。

文章提供本机尝试流程，并说明新模型起草可通过 Inference Providers 调用模型、计费到用户自己的账户。因而本机生成和执行测试不等于全部步骤零成本；使用者还应核对实际配置、调用范围及账户计费。公告没有承诺这一流程适用于所有架构。

当前是补充防线，尚未取代真实权重测试

截至原文说明的11月1日，MIC 在 Transformers 持续集成中报告失败，但尚不阻塞拉取请求。团队仍需衡量它能在新改动中抓到多少真实问题、误报频率，以及人工审核基线的维护成本。覆盖范围也仍然只是模型家族和使用接口的一部分。

作者还坦承，小型 Whisper 测试无论采用随机权重还是小样本过拟合权重，都漏掉了真实检查点能够暴露的辅助解码问题。因此 MIC 的定位是让部分问题更早浮现，完整集成测试仍保留；不能把小型测试通过写成模型所有能力或数值行为已经得到全面验证。

继续阅读