Hugging Face: un test de 66 MB caza bugs de IA

Un bug silencioso que sobrevivió dos meses en Transformers

El 30 de julio de 2026, Transformers habilitó la atención scaled dot-product (SDPA) de PyTorch para T5. El efecto secundario fue que el decodificador de UMT5 quedó capacitado para atender tokens futuros: durante el entrenamiento podía mirar la respuesta que se suponía debía predecir. Nada se cayó, ningún test se puso en rojo y el error permaneció en la rama main casi dos meses, hasta su corrección el 28 de septiembre de 2026.

Para un equipo que entrena o hace fine-tuning con checkpoints de la familia T5, ese es el peor escenario posible: una degradación silenciosa de la calidad del modelo que no dispara ninguna alerta. Esa historia es el punto de partida de transformers-mic, el estándar que Hugging Face propone para detectar regresiones en cada pull request sin mantener una flota de GPUs encendida todo el día.

Por qué los tests de integración no alcanzan

Transformers soporta más de 750 tipos de modelos. Su suite de pruebas es enorme: más de 88.000 tests de CPU en main y más de 200.000 tests de GPU en una corrida diaria. Los modelos son solo una parte del trabajo: también se testean pipelines, entrenamiento, ejecución distribuida, cuantización y kernels de atención.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El problema es dónde se ejecuta todo eso. Los tests de integración cargan checkpoints reales y ejercitan la API sobre hardware real, así que correrlos completos en cada PR exigiría tener muchas GPUs ocupadas de forma permanente. Cuando una corrida programada encuentra una regresión, el código ya puede llevar días o semanas en main. Con UMT5 pasó exactamente eso: el bug entró el 30 de julio y se corrigió el 28 de septiembre.

La propuesta de Hugging Face invierte el orden: en lugar de acelerar el test, encoger el modelo.

Qué es un Model Integration Contract (MIC)

La técnica consiste en construir un fixture: un modelo pequeño creado a partir de la configuración del checkpoint real, con menos capas y más angostas, pero conservando todos los tipos de capa que tiene el original, y con los archivos de tokenizer y processor intactos. Se publica una sola vez y se reutiliza.

Los números del caso UMT5 explican el ahorro: el fixture pesa 66 MB, frente a los 1.227 MB del checkpoint de origen. Sobre esa base corren los fast integration tests en un runner de CPU barato. La misma lógica sirve para modelos gigantes que no caben en los runners estándar de GPU: su versión reducida sí corre en CPU.

Un MIC tiene tres partes:

Un fixture: el modelo encogido, publicado una vez y fijado a una revisión concreta.
Una ruta de uso: un ejemplo ejecutable en Markdown de algo que la gente realmente hace con el modelo, como generar texto o correr un paso de entrenamiento.
Unas baselines: las salidas registradas al ejecutar ese ejemplo, revisadas por una persona.

El contrato se cumple si al ejecutar la ruta de uso sobre el fixture siguen apareciendo las mismas baselines. Un contrato cubre una arquitectura y una ruta de uso, no un checkpoint aislado: varios checkpoints compatibles pueden compartir el mismo fixture, cada uno con sus propios resultados esperados. Todo se publica en el repositorio huggingface-mic.

En el caso de SmolLM, el contrato genera a partir de prompts como The capital of France is y compara los token IDs obtenidos con una respuesta grabada. Además del texto, compara la pérdida de entrenamiento, verifica que los gradientes sean finitos y comprueba que un paso del optimizador cambie los pesos.

La infraestructura tiene una pieza clave para la reproducibilidad: un dataset en el Hub fija cada MIC a una revisión congelada junto con las versiones de los paquetes usadas para grabar sus baselines, y cada corrida de CI registra la revisión que utilizó. En un PR, los MICs se eligen según los archivos que toca el parche.

La prueba de fuego: cinco meses de commits

Hugging Face reprodujo los MICs congelados sobre cinco meses de commits de Transformers. El fixture pequeño de UMT5 marcó la regresión desde su introducción, el 30 de julio de 2026, hasta su arreglo, el 28 de septiembre de 2026: las log-probabilidades de las etiquetas se desviaban 1,22 de la baseline revisada y la pérdida de entrenamiento alrededor de 0,20.

Hay un detalle que vale para cualquier equipo que diseñe tests: el contrato usaba SDPA, la ruta de atención por defecto. Si solo se hubiera corrido la variante eager, el bug habría pasado sin ser visto. Un fixture solo sirve si atraviesa el mismo código que el checkpoint real.

Como verificación adicional, revirtieron el arreglo en una rama de prueba dentro del CI de Transformers. El chequeo falló con las mismas diferencias y el paso del runner del contrato de T5 tardó 13,4 segundos en CPU, sin contar el setup.

Cómo se construye un fixture en cuatro pasos

Encoger la configuración. Se parte de un checkpoint real y se reducen tamaños ocultos, cabezas de atención y profundidad, manteniendo los distintos tipos de capa (mezclas de atención deslizante y completa, o de capas densas y MoE). Algunas arquitecturas necesitan reglas extra para que sus componentes sigan siendo compatibles.
No tocar el preprocesamiento. Se conservan vocabulario, tokens especiales y dimensiones de entrada, y se copian los archivos de tokenizer y processor byte a byte. Cargar y preprocesar también es parte de lo que se quiere testear.
Construir y validar los pesos. Se prueban pesos aleatorios con semilla y se cambian las entradas para confirmar que el modelo responde. Si no responde, se lo entrena sobre el lote pequeño de ejemplos del contrato. Se recarga el modelo guardado y se verifica que salidas, pérdida y gradientes sean finitos.
Congelar y registrar. Se guardan los pesos aceptados y se miden salidas repetibles sobre una versión conocida como buena. Las baselines se revisan por plataforma y precisión antes de publicar un snapshot fijado, que el CI reutiliza en lugar de reconstruir el fixture en cada PR.

El reporte de encogimiento de Llama 4 Scout muestra cómo se ve esto en un modelo grande: 108.600 millones de parámetros se convierten en 44,7 millones, el stack de visión pasa de 34 capas a 2 y el de lenguaje de 48 a 4, conservando los tipos de capa y el estilo de ruteo MoE.

La herramienta de línea de comandos se llama tmic y arma el contrato y el fixture. Para un modelo nuevo, un LLM redacta el código de uso y el manifiesto, y corridas de CPU y GPU miden las baselines candidatas. El LLM redacta; no aprueba. Cambiar una expectativa exige revisión humana.

Pesos aleatorios u overfitting: la duda abierta

No todos los modelos se comportan igual con pesos aleatorios. El fixture de Whisper apenas reaccionaba a los cambios en el audio: corría, pero como test del camino de audio era inútil. La solución fue entrenarlo con unos pocos tonos asociados a palabras como red y green, no para enseñarle reconocimiento de voz, sino para que los cambios en el audio se reflejaran en las salidas.

En el estudio de inicialización de pesos, los fixtures aleatorios de Whisper detectaron 18 de 24 fallos inyectados; los entrenados por sobreajuste detectaron los 24. Aun así, el resultado no zanja cuál es mejor: eran fallos sintéticos, y todavía no apareció una regresión real detectada solo por la versión sobreajustada. Ambas versiones dejaron pasar un bug de decodificación asistida que sí expuso el checkpoint real.

La regla que aplican hoy es pragmática: pesos aleatorios cuando pasan los chequeos, sobreajuste cuando se necesita más sensibilidad o respuestas legibles. Entrenar toma segundos, pero es un paso más que puede no converger y una cosa más que mantener.

Qué significa esto para tu startup

La lección no es exclusiva de Hugging Face. Cualquier equipo que despliegue modelos en producción enfrenta el mismo riesgo: un cambio en una librería o en un kernel de atención que altera el comportamiento sin lanzar errores.

Reduce tus propios checkpoints. Si haces fine-tuning de un modelo abierto, crea una versión miniatura con la misma arquitectura y una ruta de uso real (generar, clasificar, correr un paso de entrenamiento) y córrela en cada PR. Un fixture de decenas de MB cabe en el runner más barato de tu CI.
Congela baselines revisadas por humanos. Guardar la salida esperada y versionarla junto con las dependencias es lo que convierte un test en un contrato. Sin baseline revisada, solo tienes un script que se ejecuta.
Testea la ruta que usas en producción. El caso UMT5 lo demuestra: si tu test corre con atención eager y tu servicio usa SDPA, tu test no está cubriendo nada relevante.
Prueba el flujo antes de comprometerte. El CLI permite ejecutarlo solo en tu máquina, sin subir nada: tmic run org/model --local-only --fixtures-only --no-history --bill-to ''. Requiere instalar transformers-mic[runtime] y autenticarse con hf auth login.

Conviene mirar el estado del proyecto con expectativas calibradas. Al 1 de noviembre de 2026, el job de MIC en el CI de Transformers reporta fallos sin bloquear los PRs. Todavía no está medido cuántos bugs reales detecta en PRs (y no solo en repeticiones históricas), con qué frecuencia genera falsas alarmas ni cuánto trabajo insumen las revisiones de baselines. La cobertura también es parcial, tanto en familias de modelos como en las APIs que la gente usa de verdad.

No se encontraron datos adicionales verificables sobre la adopción de transformers-mic fuera de la publicación de Hugging Face, así que por ahora conviene tratarlo como un estándar en fase de validación: vale la pena copiar el patrón, no necesariamente la herramienta.