Bug em modelo UMT5 faz Transformers mudar estratégia de testes

Tecnologia

Equipe do Transformers adapta métodos de teste após identificar falha no modelo UMT5 que afetou a previsão de tokens.

Leia também: OpenAI aumenta em 4x recompensas e paga até US$172 mil por bugs

Um bug no modelo UMT5, que deixou o decodificador acessar tokens futuros durante o treinamento sem provocar travamentos, levou a equipe da biblioteca Transformers a reformular a estratégia de testes e a adotar modelos reduzidos e contratos formais de integração para detectar regressões em modelos de inteligência artificial.

Bug silencioso expôs fragilidade dos testes tradicionais

A falha surgiu em 30 de julho de 2026, quando a atenção por produto escalar (SDPA) foi habilitada para a família T5 no PyTorch. Como efeito colateral, o decodificador do UMT5 passou a “espiar” tokens futuros enquanto treinava, enxergando partes da resposta que deveria prever. “Nada travou, e o bug ficou no main por quase dois meses”, descreveu a equipe do Transformers.

O problema só foi identificado em 28 de setembro de 2026, de forma retroativa, ao se refazer a linha do tempo de commits da biblioteca. Até então, a falha tinha passado ilesa pela extensa suíte de testes do projeto, que hoje soma mais de 88 mil testes em CPU e cerca de 200 mil em GPU, cobrindo não só modelos, mas também pipelines, treinamento, execução distribuída, quantização e kernels de atenção.

A experiência expôs um limite importante dos testes tradicionais de passagem direta (forward pass): o UMT5 bugado conseguia carregar, rodar e produzir saídas aparentemente normais, mesmo com o erro na lógica de atenção. Só análises mais finas, de probabilidades e perdas de treinamento, mostraram que algo estava errado.

Modelos reduzidos viram peça central dos testes

Para lidar com a escala do projeto — hoje com suporte a mais de 750 tipos de modelos — e com o custo de rodar toda a suíte a cada mudança, os mantenedores decidiram encolher os modelos usados nos testes de integração. Nasceram assim as fixtures, versões reduzidas construídas a partir da configuração real de um checkpoint, com menos camadas e dimensões menores, mas preservando todos os tipos de camada da arquitetura, além dos arquivos originais de tokenização e processamento.

No caso do UMT5, o modelo experimental usado como fixture consumiu apenas 66 MB de pesos, contra 1.227 MB do checkpoint original. “O modelo UMT5 experimental usou 66 MB de pesos; o checkpoint original tem 1.227 MB — estudo de CPU”, registra a equipe ao descrever a abordagem. Esse encolhimento permite que testes de integração sejam executados rapidamente em CPU comum, sem depender de baterias de GPUs dedicadas em tempo integral.

O mesmo princípio é aplicado a modelos gigantes, que muitas vezes nem cabem nas GPUs padrão de ambientes de integração contínua. Em um exemplo recente, o Llama 4 Scout teve sua versão de 108,6 bilhões de parâmetros reduzida para um fixture de 44,7 milhões de parâmetros, mantendo a estrutura essencial da arquitetura, como tipos de camada, pilhas de visão e linguagem e estilo de roteamento em camadas de especialistas (MoE).

Como funcionam os contratos de integração de modelo

Sobre essas fixtures, a equipe criou o conceito de contrato de integração de modelo, ou MIC (Model Integration Contract), um padrão para empacotar os testes de forma reprodutível. Cada MIC é estruturado em três partes: o caminho de uso (como o modelo será de fato utilizado), os valores de referência (baselines) a serem comparados e o mapeamento entre esse uso e a arquitetura coberta.

Na prática, o contrato afirma que, se o caminho de uso for executado sobre a fixture, as saídas — como IDs de tokens gerados, perdas de treinamento, gradientes e atualização de pesos — devem bater com os baselines registrados. O contrato não vale para um checkpoint isolado, mas para uma arquitetura e um modo de uso específicos; diferentes checkpoints compatíveis podem compartilhar a mesma fixture, cada um guardando seus próprios resultados esperados.

Um exemplo citado pela equipe é o contrato da família SmolLM, que gera respostas para prompts como “The capital of France is” e compara, token a token, a saída com uma resposta gravada. O contrato também verifica se a perda de treinamento permanece dentro de uma faixa esperada, se os gradientes são finitos e se um passo de otimizador de fato altera os pesos do modelo.

Replay mostrou alcance da regressão no UMT5

Com os MICs e as fixtures prontos, os mantenedores refizeram meses de histórico do Transformers, congelando contratos e aplicando-os a commits antigos. O pequeno UMT5 reduzido passou a sinalizar a regressão em todas as revisões entre a introdução do bug e a correção, exibindo diferenças significativas em log-probabilidades e perda de treinamento em relação às referências revisadas.

Segundo a análise, as log-probabilidades associadas aos rótulos se desviaram dos baselines em cerca de 1,22, enquanto a perda de treinamento aumentou em torno de 0,20. Esses números, pequenos à primeira vista, indicam um comportamento estatisticamente diferente, compatível com um modelo que acessa informações que não deveria ver.

Um detalhe técnico foi decisivo: o contrato usou a atenção SDPA, o caminho padrão de atenção configurado no código. “O contrato usado SDPA, o caminho de atenção padrão. Rodar só a variante eager não detectou o bug — análise de regressão”, apontou a equipe. Em outras palavras, o fixture só funciona como guarda-chuva de regressões se percorrer exatamente o mesmo caminho de código que o checkpoint real percorre em produção.

Para validar a sensibilidade do teste, os desenvolvedores ainda simularam o cenário oposto: reverteram a correção em um branch de prova na integração contínua. O MIC voltou a falhar com as mesmas diferenças observadas no replay. No relatório, os responsáveis destacam que a etapa principal (runner) do contrato T5 selecionado levou 13,4 segundos para rodar em CPU, desconsiderando o tempo de configuração. “O passo do runner do contrato T5 levou 13,4 segundos em CPU, excluindo a configuração — teste de CI”, detalharam.

Entenda o contexto

Ferramentas como Transformers, construídas sobre o PyTorch, são hoje base para aplicações de processamento de linguagem natural, assistentes virtuais, sistemas de recomendação e automatização em larga escala. Bugs sutis em arquiteturas de atenção podem não derrubar serviços, mas distorcer previsões, enviesar respostas e comprometer a confiabilidade de produtos inteiros sem dar sinais explícitos de falha.

Ao mesmo tempo, o ritmo de desenvolvimento é acelerado, com centenas de contribuições que alteram kernels, camadas, formatos de peso e APIs. Rodar toda a suíte — mais de 88 mil testes em CPU e 200 mil em GPU — a cada pull request é impraticável, por custo e tempo. A consequência é que regressões complexas podem chegar ao código principal e só serem vistas depois, em execuções agendadas ou em produção.

O uso de fixtures e MICs tenta equilibrar esse cenário: oferece uma camada intermediária de testes de integração rápida, com modelos pequenos, mas suficientemente fiéis para expor mudanças indesejadas em probabilidades, perdas e trajetórias de treinamento. Sem substituir os testes completos, os contratos dão uma “chance justa” de barrar problemas antes que se consolidem na base de código.

Receita de fixtures ganha refinamento

O primeiro método de encolher modelos era simples: reduzir dimensões internas e manter menos camadas. Na prática, a receita se mostrou insuficiente para arquiteturas mistas, em que diferentes tipos de atenção convivem. Em um cenário desse tipo, manter apenas duas camadas pode significar que as duas usam, por exemplo, atenção deslizante, enquanto as camadas de atenção plena desaparecem, deixando partes críticas do código real sem cobertura.

A nova receita passou a ter quatro passos (não detalhados publicamente em um único trecho), com regras para preservar a diversidade de tipos de camada e para manter o formato original dos arquivos de peso. Esse último ponto garante que o código de conversão e carregamento executado quando um usuário abre um checkpoint real também seja exercitado nos testes com fixtures.

Em modelos multimodais como o Llama 4 Scout, o encolhimento é cuidadoso: a pilha de visão foi reduzida de 34 para 2 camadas, e a de linguagem, de 48 para 4, mantendo estilos de encaminhamento e características-chave da arquitetura. O objetivo não é salvar performance absoluta, mas garantir que as rotas de código de interesse continuem presentes, só que em escala menor.

Automação com tmic e uso de IA no ciclo de testes

Para facilitar a adoção da metodologia, os mantenedores criaram a ferramenta de linha de comando tmic, responsável por automatizar a criação de contratos e fixtures. Ao apontar um checkpoint de origem, a CLI constrói o modelo reduzido, gera o esqueleto do contrato e registra baselines localmente, submetendo cada etapa à revisão do desenvolvedor.

LLMs entram em cena como assistentes nesse fluxo: são usados para rascunhar o código de uso e o manifesto do contrato, que depois passam por revisão humana. Alterações nas expectativas — por exemplo, quando uma atualização legítima modifica ligeiramente as saídas — também exigem validação manual antes de serem aceitas. A ferramenta pode ser executada em máquinas locais, sem envio automático de dados, e a cobrança do uso de modelos externos fica vinculada à conta do usuário.

Esses contratos são então publicados e versionados em conjuntos específicos, associando cada MIC a revisões congeladas de código e pacotes. Cada execução de CI registra qual revisão foi usada, o que facilita a reprodução exata de falhas no futuro.

Impacto para a comunidade e próximos passos

O caso do UMT5 já produz efeitos no ecossistema Transformers e PyTorch. A biblioteca passou a rodar um job dedicado de MIC na integração contínua, que hoje apenas reporta falhas sem bloquear automaticamente a entrada de pull requests. Os mantenedores avaliam, com base em dados futuros, se esses contratos devem se tornar critério obrigatório para aprovar mudanças.

Outra frente em curso é a ampliação da cobertura: ainda há lacunas em famílias de modelos e em modos de uso, como tipos específicos de geração, treino distribuído ou caminhos multimodais. Quando uma regressão escapa e é descoberta por outros meios, a equipe inclui o caminho de uso ausente em um novo contrato, reexecuta o replay nas versões problemática e corrigida e incorpora o aprendizado à receita de fixtures.

A metodologia também abre espaço para que integradores externos contribuam. Desenvolvedores que usam checkpoints hospedados em repositórios públicos podem criar seus próprios MICs, seguindo a receita de fixtures e o fluxo do tmic, e submeter caminhos de uso representativos. A intenção declarada dos mantenedores é, no futuro, ligar as páginas originais de modelos a seus respectivos contratos, oferecendo um ponto de partida testado para quem pretende colocar essas arquiteturas em produção.

Na prática, se a estratégia se consolidar, a comunidade de IA tende a conviver com menos bugs comportamentais em modelos de linguagem e visão, maior transparência sobre o que foi de fato testado em cada lançamento e um padrão mais elevado de reprodutibilidade — ainda que à custa de maior complexidade no desenho e manutenção dos próprios testes.