L'équipe ARC-AGI-3 fait passer son agent de 500 à 3 400 tokens par seconde

Dans la compétition ARC-AGI-3, un participant a terminé à la sixième place et en a tiré une leçon utile bien au-delà des agents de jeu. Lorsque le budget de calcul est fixé à neuf heures, le gagnant n'est pas forcément celui qui a le prompt le plus astucieux. Parfois, ce qui compte, c'est le nombre de tentatives complètes que l'agent parvient à effectuer et la qualité que l'on sacrifie pour obtenir cette vitesse.

L'auteur est parti d'environ dix lignes de jeu parallèles et d'une vitesse d'environ 500 tokens par seconde. Après un mois de travail, son serveur délivrait environ 3 400 tokens par seconde et servait simultanément 110 lignes sur un GPU de 96 Go de mémoire. Cependant, une simple accélération ne garantissait pas une hausse du résultat : certaines optimisations dégradaient discrètement les réponses du modèle, et après plusieurs heures de jeu, un plateau apparaissait.

Pourquoi les prompts n'ont presque rien apporté

Le participant a d'abord essayé l'éventail habituel d'idées : deux agents avec un juge, différentes représentations du plateau, un « photographe » dédié aux mécaniques de jeu, un modèle du monde programmatique, un essaim de conseillers et un agent au regard neuf. Presque toutes les variantes donnaient un résultat au niveau du bruit, voire le dégradaient.

L'agent de base savait déjà recevoir l'image et la représentation ASCII du plateau, lancer du Python pour l'analyse et choisir une action. Les rôles supplémentaires augmentaient la consommation de tokens sans lever la contrainte principale : l'agent avait besoin de davantage de tentatives indépendantes pour franchir 110 jeux. Dans les conditions du concours, une nouvelle belle couche de raisonnement s'avérait moins utile que quelques trajectoires menées à terme en plus.

C'est un bon test pour tout système d'agents. Si un nouveau schéma paraît plus intelligent mais n'augmente pas la part de tâches réussies sur un jeu de tests reproductible, ce n'est pas encore une amélioration, mais une hypothèse coûteuse.

Comment faire tenir 110 lignes sur une seule carte

La mémoire principale du GPU était occupée par les poids du modèle et ses 512 experts. L'état des lignes de jeu a donc été déplacé en mémoire vive, le cache KV compressé au format 4 bits, et le nombre d'experts disponibles d'abord réduit à 400. Cela a permis d'augmenter fortement le parallélisme.

Le traitement par lots des messages entrants a apporté un gain à part. Quand plusieurs jeux renvoient simultanément de nouvelles observations au modèle, il est plus rentable de les traiter ensemble : la lecture du contexte d'entrée se parallélise bien, alors que la génération de la réponse se fait de toute façon token après token. Le planificateur regroupait plusieurs requêtes pour ce traitement, réduisant le nombre de lancements coûteux.

Il y a eu aussi de petites accélérations : réentraînement du modèle brouillon pour le contexte de l'agent, suppression du recalcul superflu de l'état après troncature du contexte, portage de certaines opérations de Triton vers CUDA. Chaque mesure ne rapportait que quelques pour cent, mais ensemble elles ont multiplié le débit de plusieurs fois.

Le prix est apparu plus tard. La version à 3 400 tokens par seconde obtenait parfois moins de points que la plus lente. L'ensemble réduit d'experts et d'autres approximations modifiaient rarement le token suivant, mais sur une longue trajectoire de jeu, les petits écarts s'accumulaient.

La vitesse compte jusqu'au point de saturation

La trouvaille la plus pratique est le changement de mode à chaud. Pendant les six premières heures, l'agent travaillait vite avec 400 experts et lançait le maximum de lignes. Quand les jeux simples étaient terminés et qu'il en restait environ 70 difficiles, le système activait les 512 experts et passait à une génération de meilleure qualité. Ce mode a fait passer le résultat d'environ 50 à 54 points.

Passé un certain stade, davantage de tokens n'aidait presque plus. L'agent raflait vite les niveaux faciles, puis restait bloqué sur les difficiles : la différence entre 600 000 et 900 000 tokens par jeu devenait minime. C'est la limite pratique de la mise à l'échelle des tentatives sans amélioration du solveur lui-même.

Pour les développeurs, la conclusion est simple : ne mesurez pas seulement les tokens par seconde. Il faut au moins trois courbes : le débit, la qualité de la solution et le résultat en fonction du temps. Optimisez d'abord le nombre de tentatives utiles, puis trouvez le point de saturation et rétablissez la qualité sur la dernière portion. Et vérifiez systématiquement chaque accélération sur de longues trajectoires : une erreur microscopique, invisible dans une seule réponse, peut coûter toute la tâche.