A 30 de julho de 2026, o Transformers ativou para o T5 a atenção scaled dot-product (SDPA) do PyTorch. Este efeito secundário permitiu que o descodificador do UMT5 consultasse os tokens futuros, ou seja, a resposta que deveria prever, durante o treino. Nada falhou, e o bug permaneceu na branch main durante quase dois meses. A Hugging Face apresenta Model Integration Contracts (MIC), um formato de testes baseado em modelos pequenos, que permitiu detetá-lo durante uma repetição dos commits.
O Transformers suporta mais de 750 tipos de modelos, e a sua suite de testes é considerável: mais de 88 000 testes CPU na branch principal, e mais de 200 000 testes GPU numa execução diária. Os testes de integração carregam checkpoints reais e usam a API dos modelos em hardware real. Executá-los em cada pedido de alteração monopolizaria um grande número de GPU durante todo o dia, o que não é realista. Uma regressão pode, portanto, atingir a branch principal antes de ser detetada por uma execução programada.
Reduzir o modelo em vez de testar o grande
A abordagem consiste em criar uma fixture, ou seja, um modelo pequeno construído a partir da configuração do checkpoint real, com menos camadas, mais estreitas, mas de todos os tipos presentes no modelo original. Os seus ficheiros de tokenizer e processador permanecem inalterados. Esta fixture é publicada uma vez e depois reutilizada, e os testes rápidos são executados nela num simples processador CPU. No estudo CPU da equipa, a fixture experimental do UMT5 pesava 66 MB, contra 1 227 MB para o checkpoint de origem. Este método aplica-se também aos modelos muito grandes, alguns dos quais não cabem nas GPU padrão, mas cuja fixture funciona em CPU.
Os testes vão além do simples carregamento e de uma passagem de inferência. O bug do UMT5 teria passado essa passagem sem dificuldade. As fixtures não substituem os testes de integração completos, mas dão uma oportunidade de detetar os erros antes da sua chegada à branch principal.
Um MIC inclui três elementos: a fixture, um usage path (um exemplo executável, como a geração de texto ou uma etapa de treino) e baselines, as saídas registadas durante a execução desse exemplo e validadas por um humano. O contrato é respeitado se a execução na fixture produzir sempre essas saídas de referência.
O retorno sobre o bug do UMT5
A equipa repetiu MICs congelados sobre cinco meses de commits do Transformers. A fixture do UMT5 sinalizou a regressão desde a sua introdução, a 30 de julho de 2026, até à sua correção, a 28 de setembro. As probabilidades logarítmicas das etiquetas diferiam da referência validada em 1,22, e a perda de treino em cerca de 0,20. Um detalhe contou: o contrato usava SDPA, o caminho de atenção por defeito. A execução da única variante de atenção « eager » não revelava o bug. Durante uma demonstração numa branch de teste da CI do Transformers, a correção tendo sido anulada, a verificação falhou com os mesmos desvios, e a etapa do runner T5 demorou 13,4 segundos em CPU, excluindo instalação.
Gerar os contratos com agentes
Uma ferramenta de linha de comandos, tmic, cria o contrato e constrói a fixture. Para um novo modelo, um LLM redige o código de uso e o manifesto, depois execuções CPU e GPU medem as baselines candidatas. Segundo a equipa, o LLM redige mas não aprova: qualquer modificação das expectativas necessita de validação humana. O relatório de redução do modelo Llama 4 Scout ilustra este método: 108,6 mil milhões de parâmetros tornam-se 44,7 milhões, a parte visual passa de 34 para 2 camadas e a parte linguística de 48 para 4.
Para os modelos de teste, a equipa comparou pesos aleatórios a pesos treinados em alguns exemplos. No estudo sobre a inicialização dos pesos, as fixtures Whisper aleatórias detetaram 18 falhas injetadas em 24, contra 24 em 24 para as fixtures treinadas. Estas falhas eram sintéticas, e ambas as versões falharam um bug de descodificação assistida revelado pelo checkpoint real do Whisper.
A 1 de novembro de 2026, o job MIC da CI do Transformers sinaliza as falhas sem bloquear os pedidos de alteração. A questão de o tornar bloqueante permanece em aberto, por falta de medidas sobre o número de bugs reais detetados e de falsos alertas.
