Google intègre le fuzzing dans l'autotuner XLA et débusque 142 bugs silencieux du compilateur sur TPU

Quand un compilateur plante avec une erreur, vous le remarquez. Quand il produit silencieusement des nombres erronés, vous ne le découvrez qu'après une semaine d'entraînement, lorsque la loss se comporte bizarrement et que la facture du cluster est déjà arrivée. Ce sont précisément ces bugs silencieux que l'équipe de Google analyse dans son travail XLA from the Trenches, et leur solution est étonnamment pragmatique.

Pourquoi les bugs silencieux sont pires que les plantages

XLA transforme le graphe de calcul d'un modèle en code machine pour TPU. En chemin, il fusionne des opérations en gros noyaux (fusion), répartit les données dans les registres vectoriels et la mémoire, et applique des dizaines d'autres optimisations. Chacune peut être correcte isolément et échouer dans une combinaison rare de formes, de types et de paramètres.

Les tests statiques de la CI vérifient des cas imaginés à l'avance. Même des millions de tests de ce genre ne couvrent pas toutes les combinaisons issues des modèles réels. Le bug ne se manifeste d'ailleurs pas par un plantage : tout s'exécute, tout est rapide, mais le résultat est légèrement faux. Pour l'entraînement d'un grand modèle, le coût d'une telle erreur se chiffre en millions de dollars.

Comment ça fonctionne

L'idée clé est de ne pas bâtir une infrastructure de vérification distincte et coûteuse, mais de se greffer sur ce qui fonctionne déjà. L'autotuner de performances teste chaque jour différentes variantes de compilation d'un même noyau pour trouver la plus rapide. Les auteurs ont ajouté à cette boucle une comparaison des résultats : la sortie de chaque variante est confrontée à celle du noyau fusionné par défaut. En cas d'écart, l'une des variantes est mal compilée.

Si le soupçon porte sur un bug à l'intérieur du graphe, le système compare aussi le résultat à une référence non fusionnée, où les opérations s'exécutent séparément. On peut ainsi déterminer si la fusion est bien en cause.

Intervient ensuite un isolateur en deux étapes. Un simple découpage du noyau en morceaux masque souvent le bug, car le problème réside précisément dans la version fusionnée. L'isolateur lit donc pas à pas les registres vectoriels matériels à l'intérieur même du noyau fusionné et repère l'instruction où les valeurs divergent pour la première fois. Les auteurs recourent en outre à la génération de programmes synthétiques et à un essaim d'agents IA qui rédigent des correctifs pour les problèmes détectés.

Ce qui a été trouvé

Sur les clusters TPU de Google, le système a aidé à corriger plus de 142 bugs échappés à la CI. La répartition est intéressante : 43 % d'entre eux ne se trouvaient pas dans les transformations de haut niveau du graphe, mais dans les générateurs de code bas niveau pour les registres vectoriels et la mémoire. Autrement dit, ça cassait là où les tests classiques au niveau du graphe ne regardent presque jamais.

Limites et enseignements

A vrai dire, ce travail présente des faiblesses. Les 142 bugs sont comptabilisés en un seul chiffre, sans ablations par composant : on ignore donc quelle partie du système apporte le plus, du fuzzing, de l'isolateur ou des agents. Les courses mémoire non déterministes, c'est-à-dire les véritables heisenbugs, restent hors du champ de la méthode. Enfin, la comparaison avec le noyau par défaut suppose que ce dernier soit correct, ce qui n'est pas toujours le cas.

L'enseignement pratique dépasse largement les TPU. Si vous disposez d'un autotuner, d'un compilateur JIT ou de tout mécanisme qui parcourt des implémentations équivalentes d'une même opération, vous payez déjà pour calculer plusieurs réponses sur les mêmes entrées. Ajouter une vérification des résultats avec une tolérance au bruit numérique coûte peu, et elle détecte précisément les erreurs que personne ne verrait. Pour les équipes qui entraînent de grands modèles sur leur propre pile, c'est l'un des moyens les moins coûteux d'attraper les défauts avant qu'ils n'engloutissent le budget.