La consommation de token est un vaste sujet sur lequel on n'est pas tous d'accord.
Jensen Huang, CEO de Nvidia veut pousser à une consommation excessive. Mais lui prêche pour sa paroisse et c'est un peu ce qui me dérange dans son discours.
Et je l'ai déjà dit mais je pense surtout que la consommation de token s'optimise et que ça ne fait pas sens de surconsommer pour rien.
Imaginez, si toutes les fois où vous pouvez faire un calcul de tête qui serait bien plus rapide, aurait moins de friction, vous vous étiez servi d'une calculatrice.
Je veux dire... Si on me demande la racine carré de 256, je ne sors pas de calculatrice et je ne perds pas de temps. Et bien en IA c'est pareil, du moins ça devrait l'être.
IBM Research a publié un billet qui compare son système ALTK-Evolve à ACE sur AppWorld. Le désaccord ne porte pas sur ce qu'un agent apprend, mais sur ce qu'on lui renvoie.
2 systèmes d'accord sur presque tout
Les 2 approches partent du même constat : quand un agent échoue sur une tâche multi-étapes, ce n'est presque jamais par manque de connaissance.
Il pagine mal une API, il résout la mauvaise entité, il renvoie une valeur qu'on ne lui demandait pas.
ACE et ALTK-Evolve transforment donc les trajectoires passées en leçons réinjectées à l'inférence, sans toucher aux poids ni passer par du labelling humain. Et les deux refusent explicitement de compresser ces leçons en résumé propre, ce qu'ACE appelle le brevity bias.
La vraie divergence est sur la livraison
ACE injecte son playbook complet à chaque étape, identique quel que soit le modèle ou la tâche. IBM traite la livraison comme un curseur : un noyau fixe de guidelines à fort support, étendu par une poignée sélectionnée pour la tâche en cours. Les mêmes leçons sont disponibles des deux côtés, mais l'un envoie tout, l'autre envoie ce que le modèle peut réellement absorber.
C'est là que la facture bouge.
Les chiffres annoncés
| Modèle | Système | TGC / SGC | Tokens/tâche |
|---|---|---|---|
| DeepSeek-V3.2 | ACE | 80.4 / 73.2 | 634K |
| DeepSeek-V3.2 | ALTK-Evolve | 89.3 / 80.4 | 263K |
| gpt-oss-120b | ACE | 54.8 / 35.7 | 777K |
| gpt-oss-120b | ALTK-Evolve | 56.0 / 37.5 | 116K |
Mais ces chiffres, c'est IBM qui les a produits des 2 côtés
Les résultats d'ACE présentés ici ne viennent pas du papier ACE, ils viennent de runs internes IBM sur leur propre harness.
La démarche est défendable (le papier ACE tourne sur DeepSeek-V3.1, pas V3.2) mais ça reste un benchmark auto-reporté où l'auteur configure aussi son concurrent.
À leur crédit, IBM le documente : les deux baselines sans mémoire diffèrent (72.0 contre 79.8 TGC), les résultats sont en pass@1 sur un seul run, et sur gpt-oss-120b ils qualifient eux-mêmes le 56.0 contre 54.8 d'égalité, avec un rerun retombé à 54.8.
Ce que je retiens quand même
Le point qui m'intéresse n'est pas le classement, c'est la métrique.
Comparer 116K et 777K tokens pour la même tâche, c'est exactement le raisonnement en coût par tâche que je défends depuis un moment, et ça ne se lit nulle part sur une grille de prix au million de tokens.
Un contexte injecté à chaque étape se paie à chaque étape, et sur un agent qui boucle 20 fois, ça devient le poste dominant.
La lib est sur GitHub, le rapport technique est sur arXiv, je n'ai rien testé moi-même : je regarde ce que ça donne quand quelqu'un d'extérieur reproduit la comparaison.
