Hugging Face ha propuesto los contratos de integración de modelos (MIC), una forma de ejecutar comprobaciones ligeras en modelos de Transformers durante las solicitudes de cambios. El objetivo es detectar regresiones antes de que lleguen a la base de código principal, sin tener que ejecutar el conjunto completo de pruebas de integración en GPU con cada cambio.

La propuesta surge a raíz de un error relacionado con la atención de T5. El 30 de julio de 2026, Transformers habilitó la atención de producto punto escalado de PyTorch para T5, lo que también permitió que el decodificador de UMT5 atendiera a tokens futuros durante el entrenamiento. El problema permaneció en la rama principal hasta que se corrigió el 28 de septiembre. Cuando el equipo reprodujo las confirmaciones intermedias, una pequeña muestra de UMT5 ejecutada en CPU señaló la regresión.

Transformers admite más de 750 tipos de modelos. Su rama principal tiene más de 88.000 pruebas en CPU, mientras que una ejecución diaria incluye más de 200.000 pruebas en GPU. Las pruebas de integración completas cargan puntos de control reales y ejercitan los modelos en hardware real, pero ejecutarlas todas en cada solicitud de cambios exigiría mantener las GPU ocupadas todo el día. Además, las pruebas programadas pueden detectar un problema solo después de que haya llegado a la rama principal.

Los MIC abordan esa disyuntiva probando muestras más pequeñas, construidas a partir de configuraciones de puntos de control reales. Estas conservan los distintos tipos de capas de un modelo, pero utilizan menos capas y de menor tamaño; los archivos del tokenizador y del procesador permanecen sin cambios. Las muestras se publican una sola vez y se reutilizan en pruebas de integración rápidas en CPU. En el estudio de UMT5, los pesos de la muestra ocupaban 66 MB, frente a los 1.227 MB del punto de control de origen. El método también puede cubrir modelos muy grandes que no caben en los ejecutores GPU estándar.

Cada contrato consta de tres partes: una muestra fijada, un ejemplo ejecutable de una tarea del modelo y líneas base de resultados registradas a partir de una ejecución considerada correcta y revisadas por una persona. La comprobación se supera cuando el ejemplo ejecutado con la muestra coincide con esas líneas base. Un contrato está vinculado a una arquitectura y a una ruta de uso, en lugar de a un solo punto de control, lo que permite que puntos de control compatibles compartan una muestra y conserven sus propios resultados esperados.

Los ejemplos pueden probar más que si un modelo se carga y completa una pasada hacia delante. Por ejemplo, un contrato de SmolLM genera texto a partir de una instrucción y compara los ID de los tokens resultantes con una respuesta registrada. También comprueba la pérdida de entrenamiento, verifica que los gradientes sean finitos y confirma que un paso del optimizador modifica los pesos. En las solicitudes de cambios, CI selecciona los contratos según los archivos modificados.

La reproducción de UMT5 mostró por qué importa la ruta probada: las log-probabilidades de las etiquetas diferían en 1,22 respecto a la línea base revisada, y la pérdida de entrenamiento, en aproximadamente 0,20. El contrato utilizó SDPA, la ruta de atención predeterminada; probar solo la variante de atención eager no habría detectado el problema. Al revertir la corrección en una rama de prueba de CI de Transformers, se reprodujo el fallo; el paso del ejecutor del contrato de T5 seleccionado tardó 13,4 segundos en CPU, sin contar la configuración.

La receta para construir las muestras también se ha adaptado a arquitecturas mixtas. Reduce las dimensiones del modelo y conserva distintos tipos de capas, incluidas combinaciones como atención deslizante y completa, o capas densas y de mezcla de expertos. Mantiene los recursos de preprocesamiento, como el vocabulario y los tokens especiales, y conserva el formato original de los archivos de pesos para que el código de conversión de puntos de control también se ejercite. Las construcciones se validan para comprobar que generan resultados adecuados y finitos, y después se congelan con líneas base revisadas para las plataformas y precisiones admitidas.

La escala de la reducción se ilustra con una muestra de Llama 4 Scout: sus 108.600 millones de parámetros pasan a ser 44,7 millones, a la vez que se conservan los tipos de capas comprobados y el estilo de enrutamiento MoE. La herramienta de línea de comandos tmic crea contratos y muestras. En el caso de modelos nuevos, un LLM puede redactar el código de uso y el manifiesto, pero las personas deben revisar las expectativas modificadas. El flujo de trabajo local permite construir y probar un contrato sin subirlo.

El equipo también comparó pesos aleatorios de muestras con pesos entrenados con unos pocos ejemplos. En un estudio con fallos sintéticos, las muestras aleatorias de Whisper detectaron 18 de los 24 problemas inyectados, mientras que las muestras entrenadas con un pequeño conjunto de ejemplos detectaron los 24. Los autores advierten que esto no demuestra cuál de los métodos es mejor en la práctica: las pruebas utilizaron fallos sintéticos, y ambas versiones pasaron por alto un error de decodificación asistida que sí expuso el punto de control real de Whisper. El método actual conserva los pesos aleatorios cuando superan la validación y recurre al sobreajuste cuando se necesita mayor sensibilidad o resultados legibles.

Al 1 de noviembre de 2026, el trabajo MIC de CI de Transformers informa de los fallos, pero no bloquea las solicitudes de cambios. El equipo afirma que aún debe medir cuántos errores reales detectan las comprobaciones, con qué frecuencia generan falsas alarmas y cuánto trabajo requieren las revisiones de las líneas base. La cobertura sigue siendo parcial, y el proyecto prevé añadir rutas de uso cuando las regresiones revelen lagunas. Las pruebas existentes se mantendrán hasta que se haya contabilizado su cobertura.

Fuentes: Hugging Face Blog.