Contexte et problème

Le 30 juillet 2026, la mise à jour de l’attention à produit scalaire (SDPA) de PyTorch pour le modèle T5 a introduit un bug : le décodeur d’UMT5 pouvait accéder aux tokens futurs, ce qui lui permettait de « voir » la réponse à prédire pendant l’entraînement. Aucun plantage n’est survenu et la régression est restée dans la branche principale pendant près de deux mois, jusqu’à sa correction le 28 septembre 2026. Le même défaut a été détecté par un petit modèle UMT5 exécuté sur CPU, qui a signalé l’anomalie sur chaque commit concerné.

Le framework Transformers gère plus de 750 types de modèles et possède une suite de tests massive : plus de 88 000 tests CPU et plus de 200 000 tests GPU sont lancés quotidiennement. Exécuter l’ensemble de ces tests à chaque pull‑request serait prohibitif en ressources GPU, d’où la nécessité d’une méthode de détection précoce plus légère.

Mécanisme des contrats d’intégration

Le projet transformers‑mic propose un Model Integration Contract (MIC) composé de trois éléments : un fixture (modèle réduit publié une fois et épinglé), un usage path (exemple Markdown exécutable, par ex. génération de texte) et des baselines (sorties attendues validées par un humain). Le contrat reste valide tant que l’exécution du usage path sur le fixture reproduit les baselines.

Le fixture est construit à partir de la configuration du checkpoint réel, en réduisant les tailles cachées, le nombre de têtes d’attention et la profondeur, tout en conservant chaque type de couche présent (attention glissante, MoE, etc.). Le poids du fixture UMT5 expérimental occupe 66 Mo contre 1 227 Mo du checkpoint original. Le même principe s’applique aux très grands modèles : le rapport de réduction Llama 4 Scout montre la compression de 108,6 milliards de paramètres à 44,7 millions, avec la pile vision passant de 34 à 2 couches et la pile texte de 48 à 4.

Mise en œuvre et résultats

Lors de la réexécution des MIC figés sur cinq mois de commits, le petit fixture UMT5 a détecté la régression dès son apparition le 30 juillet 2026 et a continué à la signaler jusqu’à la correction du 28 septembre 2026. Les écarts mesurés étaient de 1,22 sur les log‑probabilités et d’environ 0,20 sur la perte d’entraînement. Le runner du contrat T5 a mis 13,4 secondes sur CPU (hors phase d’installation) pour reproduire le problème.

Le processus de création du fixture comprend : (1) réduction de la configuration tout en conservant les types de couches, (2) conservation inchangée du tokenizer et du processeur, (3) génération ou entraînement de poids aléatoires puis validation des sorties, pertes et gradients, (4) gel et enregistrement des poids avec mesures de référence sur une version connue du framework. Le format original des poids est conservé afin de tester le code de conversion chargé lors du chargement d’un checkpoint réel.

inputs = tokenizer("The capital of France is", return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=4, do_sample=False)
new_tokens = outputs[:, inputs["input_ids"].shape[1]:]
print(tokenizer.batch_decode(new_tokens, skip_special_tokens=True))

Limites et perspectives

Les MIC ne remplacent pas les tests d’intégration complets ; ils offrent une première ligne de défense sur les PR en détectant les régressions qui passent un simple passage avant‑propagation. Un contrat ne fonctionne que si le usage path utilise le même chemin d’attention que le checkpoint réel ; dans le cas du bug SDPA, la variante eager attention n’aurait pas détecté l’anomalie.

La dépendance à des fixtures pré‑construits implique un coût de stockage et la nécessité de mettre à jour les MIC lorsqu’une architecture évolue. De plus, les modèles très hétérogènes requièrent des règles spécifiques pour préserver la compatibilité des couches réduites. Malgré ces contraintes, la stratégie permet de réduire drastiquement le temps de CI tout en maintenant une couverture suffisante pour attraper des erreurs subtiles comme le décodage anticipé d’UMT5.