InfraDev évalue les agents de code sur 36 modifications d'infrastructure IA

Une évaluation des modifications d'infrastructure, pas seulement de fragments de code

InfraDev est un benchmark conçu pour évaluer si les agents de code peuvent implémenter des modifications complexes dans l'infrastructure de l'intelligence artificielle. Sa proposition se concentre sur des tâches qui couvrent plusieurs fichiers et qui doivent fonctionner dans des environnements multi-GPU, au lieu de se limiter à des noyaux isolés ou à des tâches mono-GPU.

La distinction est importante car une modification peut sembler correcte dans une petite fonction et, pourtant, échouer lors de son intégration dans un système d'entraînement ou d'inférence. Dans ces systèmes interviennent des interfaces, un état partagé, des dépendances et des ressources de calcul. Le benchmark tente d'évaluer une partie de cette complexité au moyen de tâches inspirées de modifications réelles, mais ses résultats décrivent les performances sur cet ensemble concret, et non la capacité générale d'un agent à maintenir n'importe quel système de production.

36 tâches basées sur des projets utilisés pour développer des modèles

L'ensemble comprend 36 tâches construites à partir de demandes de tirage (pull requests) de Megatron-LM, vLLM et verl. Les domaines couverts sont l'entraînement des modèles, l'inférence et l'apprentissage par renforcement. Dans chaque cas, l'objectif est de réimplémenter une modification réelle, et non simplement de compléter un exercice de programmation indépendant.

Cette origine lie les tests à un logiciel d'infrastructure existant, mais ne transforme pas les 36 tâches en un échantillon exhaustif des modifications qui peuvent survenir dans ces projets. Le résumé disponible ne permet pas de conclure que tous les types de travail, d'architectures ou de configurations matérielles sont représentés. Par conséquent, la variété des projets et des domaines sert de contexte pour interpréter le test, et non comme preuve d'une couverture universelle.

Des tests cachés pour détecter les défaillances non couvertes par les tests officiels

InfraDev combine des tests cachés, appelés probes, avec une instruction qui spécifie les interfaces utilisées par ces tests sans révéler la solution. L'intention est de vérifier des exigences qui peuvent être absentes des tests originaux des projets et de réduire le risque qu'une réponse paraisse valide uniquement parce qu'elle passe une vérification incomplète.

Le résumé du travail souligne une différence pertinente : les probes ont rejeté 32 % des soumissions qui avaient réussi tous les tests officiels. Cette donnée montre que, dans les tâches évaluées, réussir la batterie officielle ne suffisait pas toujours à satisfaire les exigences supplémentaires du benchmark. Cela ne démontre pas que les tests cachés sont infaillibles ni que toutes les modifications réelles peuvent être qualifiées de manière complète par cette méthode.

Le meilleur résultat a été de résoudre 38,9 % des tâches

Dans l'évaluation décrite, six modèles de pointe ont été testés et le meilleur a résolu 38,9 % des tâches. De plus, lorsque les instructions se limitaient aux descriptions originales des demandes de tirage, aucun modèle n'a résolu une seule tâche. Le contraste suggère que la manière de présenter les interfaces et les exigences peut influencer ce que les agents parviennent à accomplir dans ce benchmark.

Le chiffre de 38,9 % n'équivaut pas à un taux de réussite dans tous les travaux d'ingénierie d'infrastructure. Il se réfère aux tâches et aux conditions d'évaluation d'InfraDev, telles que décrites dans le prépublication. Le résumé de la source n'offre pas ici un détail suffisant pour comparer par soi-même chaque modèle, tâche et projet ; par conséquent, il ne convient pas d'interpréter le maximum comme un classement général des agents.

Les erreurs structurelles et d'état étaient fréquentes

L'analyse des défaillances du travail indique que les erreurs structurelles et celles liées à l'état prédominaient. Il souligne également que les tests écrits par les agents eux-mêmes vérifiaient rarement des aspects comme la mémoire, le temps d'exécution ou le trafic. Ce sont des observations sur les tâches et les réponses analysées, et non une démonstration que ces défaillances caractérisent de la même manière tous les agents ou projets.

Le travail informe également que la transformation de ces constats en une compétence pour agents a augmenté de 10,5 points de pourcentage le taux de résolution d'un modèle de pointe sur les tâches de Megatron-LM. La donnée est spécifique à ce modèle et à cet sous-ensemble ; elle ne permet pas d'affirmer que l'amélioration se reproduira dans d'autres projets ou systèmes. Un environnement d'exécution partagé est également décrit, réduisant le stockage de 52 % à 57 % et le temps de compilation de 13 % à 14 % sur Megatron-LM et vLLM.

Un prépublication offrant un test concret, pas une validation universelle

InfraDev est présenté dans un article hébergé sur arXiv, identifié comme version 1 et soumis le 27 octobre 2026. La source consultée est le résumé du travail lui-même ; elle ne confirme pas qu'il a passé une révision par les pairs ni n'apporte de preuve d'une réplication indépendante. Par conséquent, ses chiffres doivent être compris comme des résultats communiqués par les auteurs dans ce prépublication.

Le benchmark offre une approche plus proche des tâches d'infrastructure réelle qu'un test limité à des noyaux ou à une seule GPU, mais la preuve disponible ne résout pas à elle seule les questions de représentativité, de couverture ou de performance dans des déploiements différents. Sa conclusion la plus solide est limitée : sous les tâches et les conditions décrites, les modèles évalués ont rencontré des difficultés importantes, et les tests supplémentaires ont détecté des défaillances que les tests officiels ne capturaient pas.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.