Transformers propõe Model Integration Contracts para pegar bugs de modelos antes de chegarem à main

O caso que motivou a proposta é simples e incômodo. Em 30 de julho de 2026, o Transformers habilitou o SDPA do PyTorch para o T5. O efeito colateral: o decoder do UMT5 passou a enxergar tokens futuros e, no treino, podia espiar a resposta que deveria prever. Nada quebrou, e o bug ficou na main por quase dois meses. Um forward pass comum passaria sem alarme.

O problema de fundo é custo. A biblioteca cobre mais de 750 tipos de modelo, com mais de 88 mil testes em CPU na main e mais de 200 mil testes em GPU por dia. Testes de integração com checkpoints reais em PRs exigiriam GPUs ocupadas o dia inteiro. A saída é um fixture: modelo reduzido a partir da configuração do checkpoint real, com camadas menores e em menor número, mas com todos os tipos de camada, e com tokenizer e processor intactos. No estudo, o fixture do UMT5 tem 66 MB de pesos, contra 1.227 MB do original. Um Model Integration Contract junta fixture fixado, usage path em Markdown e baselines revisados por humano. Na reexecução sobre cinco meses de commits, o fixture do UMT5 sinalizou a regressão até a correção, em 28 de setembro. Os log-probabilities dos labels divergiram em 1,22 e a loss em cerca de 0,20. O contrato precisava usar SDPA, o caminho padrão, porque só a variante eager não pegava o bug. A etapa do runner do contrato T5 levou 13,4 segundos em CPU.

Para quem mantém bibliotecas de modelos ou fine-tuna arquiteturas próprias, a leitura é que o teste barato só vale se passar pelo mesmo código do checkpoint real. Os próprios autores admitem limites: o job de MIC na CI do Transformers, em 1 de novembro de 2026, reporta falhas sem bloquear PRs, e ainda não se sabe a taxa de falsos alarmes nem o custo da revisão de baselines.