大模型库的测试困局与契约思路

最近看到 Hugging Face 的工程师复盘了一个挺典型的案例：去年 7 月底 Transformers 给 T5 启用 PyTorch 的 SDPA 注意力后，UMT5 的解码器意外能「看到」未来 token，训练时等于偷看答案。整个过程没有任何报错，bug 在主分支里躺了将近两个月才被发现。

为什么这种问题能溜进主分支？作者给了一组很能说明问题的数字：这个库支持超过 750 种模型，主分支上光 CPU 测试就有 8.8 万多个，每天还要跑 20 多万个 GPU 测试，此外还有流水线、训练、分布式、量化和注意力 kernel 的测试。集成测试要加载真实 checkpoint 并在真实硬件上跑，如果每个 PR 都全量执行，维护成本根本扛不住。有意思的是，他们事后回放那些提交时，一个跑在 CPU 上的小号 UMT5 模型就能在每一次提交上把问题标出来。也就是说，发现这个 bug 不需要大模型、不需要昂贵算力，缺的是一套针对模型行为的契约式检查。这让我想到，很多团队迷信「测试越多越安全」，但真正有效的往往是少数几个能抓住语义错误的断言。作者提出的 Model Integration Contracts 思路，我理解就是给每个模型定义一组必须成立的行为约定，比如因果注意力不能越界、输出形状和数值范围要稳定，然后用小模型快速验证。这比堆集成测试更可持续，也更适合放进 CI。对做模型部署和微调的团队来说，这个思路可以直接借鉴：与其等线上出问题，不如先把关键行为写成可执行的契约。当然，契约本身也有维护成本，模型一多、变体一杂，谁来保证契约跟得上架构演进是个现实问题。但至少这个案例提醒我们，静默的语义 bug 比崩溃更难防，测试策略得从「跑通」转向「跑对」。