El equipo de Hugging Face, que mantiene la biblioteca Transformers, explica cómo un fallo pasó inadvertido durante casi dos meses en la rama principal del proyecto. La biblioteca activó para T5 la atención scaled dot-product de PyTorch, conocida como SDPA. Como efecto colateral, el decodificador de UMT5 podía acceder a tokens futuros. Durante el entrenamiento, el modelo podía así consultar la respuesta que debía predecir. Ningún proceso se detuvo ni dio error, de modo que el problema no se detectó de inmediato. Una pasada hacia delante normal habría funcionado sin problemas, por lo que las comprobaciones habituales no lo señalaban.
Transformers soporta más de 750 tipos de modelos y su batería de pruebas es enorme: al menos 88.000 pruebas en CPU sobre la rama principal y al menos 200.000 pruebas en GPU en una ejecución diaria. Las pruebas de modelos son solo una parte, ya que también cubren pipelines, entrenamiento, ejecución distribuida, cuantización y kernels de atención. Las pruebas de integración cargan checkpoints reales y ejercitan la API del modelo en hardware real. Ejecutarlas todas en cada pull request obligaría a mantener muchas GPU ocupadas durante todo el día, algo poco práctico. Una ejecución programada puede encontrar una regresión cuando el cambio ya está en main.
La alternativa consiste en reducir el modelo en lugar de la prueba. Se construye un fixture: un modelo pequeño creado a partir de la configuración del checkpoint real, con menos capas y más estrechas, pero con todos los tipos de capa que tiene. Los ficheros de tokenizador y procesador se copian sin cambios, y el fixture se publica una sola vez para reutilizarlo. Las pruebas de integración rápidas se ejecutan después sobre un runner de CPU económico. En el estudio de CPU, el fixture experimental de UMT5 usaba 66 MB de pesos, frente a los 1.227 MB del checkpoint original. El método también sirve para modelos muy grandes que no caben en los runners de GPU habituales, pero cuyos fixtures sí se ejecutan en CPU.
Para empaquetar este enfoque, el proyecto propone transformers-mic, un estándar de pruebas llamado Model Integration Contract. Cada contrato tiene tres partes: un fixture, una ruta de uso ejecutable en Markdown que muestra algo que la gente hace con el modelo, como generar texto o un paso de entrenamiento, y unas líneas base con las salidas registradas y revisadas por una persona. El contrato se cumple si ejecutar la ruta de uso sobre el fixture sigue dando esas líneas base. Un contrato cubre una arquitectura y una ruta de uso, no un único checkpoint, así que varios checkpoints compatibles pueden compartir fixture. Los contratos se publican en el repositorio huggingface-mic.
Para comprobar el método, el fixture de UMT5 se reprodujo sobre cinco meses de commits de Transformers. Detectó la regresión desde su introducción el 30 de julio de 2026 hasta su corrección el 28 de septiembre. Las diferencias con la línea base revisada fueron de 1,22 en las log-probabilidades de las etiquetas y de unos 0,20 en la pérdida de entrenamiento. Un detalle resultó clave: el contrato usaba SDPA, la ruta de atención por defecto, mientras que ejecutar solo la variante eager no detectaba el fallo. Al revertir la corrección en una rama de prueba del CI de Transformers, la comprobación falló con las mismas diferencias, y el paso del runner de CPU duró 13,4 segundos sin contar la preparación.
El primer intento fue sencillo: reducir las dimensiones y mantener menos capas. Pero no bastó con arquitecturas mixtas, porque conservar dos capas no sirve si ambas usan atención deslizante y desaparecen las de atención completa. Por eso la receta tiene cuatro pasos: reducir la configuración manteniendo cada tipo de capa, conservar el preprocesado sin cambios, construir y validar los pesos, y congelar y registrar el resultado. Como ejemplo a gran escala, el fixture de Llama 4 Scout pasó de 108,6 mil millones de parámetros a 44,7 millones, con la pila de visión reducida de 34 capas a 2 y la de lenguaje de 48 a 4, conservando los tipos de capa comprobados y el estilo de enrutado MoE.
La herramienta tmic crea el contrato y construye el fixture. Para un modelo nuevo, un LLM redacta el código de uso y el manifiesto, y después las ejecuciones en CPU y GPU miden las líneas base candidatas. Los autores subrayan que el LLM redacta pero no aprueba: cualquier cambio en las expectativas requiere revisión humana. Los fixtures no sustituyen a las pruebas de integración completas, aunque en los pull requests ofrecen la oportunidad de detectar errores antes de que lleguen a la rama principal.