Réduire les coûts d’inférence des agents IA
Découvrez comment Cloudflare a réduit de 68 % le coût de ses revues de code par IA, sans sacrifier la qualité. Méthodes, chiffres et limites à retenir.
Comment Cloudflare a réduit de 68 % la facture de son agent IA
Au printemps, chez Cloudflare, une revue de code automatisée revenait en moyenne à 1,19 $. À la fin de l'été, la moyenne était montée à 2,46 $, sans changement majeur côté système. Pour comprendre pourquoi, l'équipe a analysé les appels aux modèles, les tokens consommés et le rôle du cache. Et surtout : elle a trouvé un levier clair.
Après ajustements, le coût moyen est retombé à 0,77 $, soit -68 % par rapport aux semaines les plus chères. Sur le même laps de temps, la durée médiane d'une revue est passée de 4 min 9 s à 1 min 32.
Ce type de résultat dit quelque chose d'important (et souvent négligé) dans les projets d'IA générative : la facture ne dépend pas uniquement du prix affiché par million de tokens. La manière dont l'agent construit son contexte, multiplie ses appels et répartit le travail entre modèles pèse tout autant. Et réduire la facture, oui - mais sans sacrifier la capacité à repérer les vrais problèmes.
Voici ce que Cloudflare a fait, les chiffres qu'ils ont mesurés, et les précautions utiles si vous voulez répliquer le raisonnement dans un agent IA en production.
Pourquoi le coût d'une revue avait presque doublé
Le coût moyen des revues de code a augmenté progressivement : 1,22 $ en mars, 1,44 $ en juin, 1,74 $ en juillet, puis 2,32 $ en août, selon la série retenue pour comparer les journées. Une plus grande part des changements difficiles (ceux qui passaient par le niveau de revue le plus intensif) a joué, mais ce n'est pas la principale explication.
Le vrai tournant, c'était les modèles utilisés.
Début août, Cloudflare a déplacé ses agents vers des modèles Anthropic. Les évaluations internes disaient que la performance sur cette tâche s'améliorait, mais le coût par tâche a grimpé : de 1,38 $ à 2,03 $. L'agent chargé de vérifier les standards internes, par exemple, est passé d'environ 0,25 $ à 0,88 $ après son passage sur Claude Opus 4.7.
Le choix n'était pas forcément « mauvais ». Si un modèle plus performant trouve plus de défauts utiles, ça peut valoir le surcoût. Le problème, c'est qu'ils n'ont pas regardé le coût global derrière l'amélioration : le nombre de tokens consommés par revue a plus que triplé, de 0,91 million à 2,99 millions. Et même avec un taux de cache élevé, ça ne compensait pas.
La facture ne dépend pas uniquement du prix par token
Avant les optimisations, l'argent se répartissait entre les tokens générés, les écritures dans le cache et les lectures du cache. Les sorties représentaient ~23 % du coût, les écritures ~43 %, et les lectures ~34 %. Dit autrement : une grosse partie de la facture venait du contexte fourni au modèle - y compris du contenu déjà « repassé » via des appels précédents.
En moyenne, une revue de qualité sollicitait le modèle 16,6 fois. Sur la session, l'agent écrivait 72 000 tokens dans le cache et en relisait 1,08 million. Chaque appel rebrassait une partie de la conversation précédente. Résultat : le coût grossissait surtout avec le nombre d'appels et la taille du contexte répété.
C'est un point que j'ai tendance à répéter à chaque fois qu'on parle d'agents : un prix unitaire bas ne garantit pas une facture basse. Si votre architecture renvoie trop de contexte, relance trop souvent au même endroit ou répète des appels, un modèle « moins cher » peut finir plus coûteux qu'un modèle plus cher utilisé de façon plus ciblée.
Une hausse qui s'est installée
Cette hausse s'explique aussi par l'évolution des usages. Quand les modèles progressent, on leur confie des changements plus volumineux et plus complexes. Plus de demandes finissent alors dans les niveaux de revue les plus approfondis. Et donc, pour optimiser, il faut partir du produit réel : comparer uniquement des tarifs de fournisseurs ne suffit pas.
Cloudflare avait aussi remplacé une première version de son système par une nouvelle. Avant le déploiement complet, ils ont fait tourner les deux versions en parallèle sur des dépôts de test. Les décisions d'approbation tombaient pareil dans 98 % des demandes de fusion évaluées. La nouvelle version était aussi ~13 % plus rapide sur les revues complètes, avec les mêmes modèles.
Le message : sans comparaison propre avant/après sur un périmètre comparable, on attribue facilement une baisse de coût au « mauvais » endroit. Ici, la séparation gains « système » vs gains « modèles » a clarifié le diagnostic.
Le cache de prompts : le premier levier d'optimisation
Les sessions de l'agent partageaient énormément de contenu : définitions d'outils, instructions générales, règles communes. Pourtant, les premières requêtes ne retrouvaient un préfixe en cache que dans 14 à 26 % des cas. Autrement dit : le cache existait, mais il n'était pas exploité là où il aurait dû l'être.
La cause était liée à la construction du prompt. Cloudflare plaçait les instructions communes dans un bloc mélangé avec des éléments variables (par exemple le répertoire de travail ou la date). Le point de cache était placé à la fin de ce bloc. Or, comme une partie changeait d'un dépôt à l'autre, la « partie commune » n'était pas réutilisable efficacement entre sessions.
L'équipe a donc modifié la structure pour isoler la portion identique et placer le point de cache à sa fin. Ils ont aussi retiré de cette zone tout ce qui risquait de varier d'un travail à l'autre. Après le changement, la proportion de premières requêtes utilisant le cache est montée entre 91 % et 99,5 %.
Comprendre le fonctionnement du cache de préfixe
Dans ce mécanisme, le cache porte sur un préfixe : le contenu doit être présent au début de la conversation. Deux prompts peuvent contenir les mêmes informations quelque part - si ce n'est pas au même endroit et dans le même ordre, le cache ne s'activera pas.
Dans le cas de Cloudflare, les définitions d'outils et les instructions générales étaient de bons candidats. Les détails propres au dépôt (ou à la demande de fusion) devaient arriver ensuite.
Il y a aussi une contrainte pratique : le cache a un coût. Dans la configuration décrite, écrire une entrée coûtait 1,25× le tarif d'une entrée normale, tandis que la lire revenait à 0,1×. Et les entrées expiraient après cinq minutes si elles n'étaient pas relues. Donc, il faut organiser les appels pour que l'écriture initiale soit suivie de lectures - plutôt que de mettre en cache un contenu qui ne servira qu'une fois.
Pour compléter, voir la documentation d'Anthropic sur le prompt caching. Les conditions et tarifs changent selon les fournisseurs et les régions : vérifiez toujours avant de généraliser.
Partager le contexte entre plusieurs agents
Ensuite, Cloudflare a harmonisé la première requête de trois spécialistes : qualité du code, sécurité et performance. Ils envoyaient d'abord les mêmes outils, les mêmes règles partagées et le même changement de code, avant d'ajouter chacun leurs instructions propres. Concrètement : un agent écrivait le préfixe en cache, et les deux autres le lisaient.
Ce montage a fait gagner environ 9 centimes par revue et par agent concerné. Mais il avait un coût opérationnel : les deux autres agents devaient attendre que la réponse de l'agent « cache » commence à être diffusée. Cloudflare leur accordait jusqu'à 20 secondes d'attente.
C'est typiquement le genre de compromis qui compte : une optimisation n'est intéressante que si l'économie justifie la latence ajoutée. Ici, le délai restait borné et l'effet sur les coûts était mesurable. Sur un parcours utilisateur plus sensible aux temps de réponse, le même choix pourrait être moins pertinent.
Moins d'appels et des modèles mieux choisis
Le cache a été le levier le plus visible. Mais une partie des économies vient aussi de changements plus « discrets » sur le fonctionnement des agents.
Beaucoup de pistes visaient une forme de gaspillage simple : des appels qui ne servaient à rien. Par exemple, certains sous-agents pouvaient « voir » un outil réservé à l'agent principal pour publier le commentaire final. Dans 57 à 76 % des sessions, ils tentaient de l'utiliser, se faisaient bloquer, puis redémarraient un nouvel appel pour continuer. En retirant cet outil de leur périmètre, Cloudflare a supprimé ces appels inutiles et réduit d'environ 2 900 tokens les définitions envoyées dans chaque requête de sous-agent.
D'autres changements ont ciblé la façon de lire le code et de gérer les tâches :
- lire en parallèle le contexte commun et les fichiers modifiés, au lieu de demander un fichier par tour, quand la taille des données le permettait ;
- ne pas relancer certains spécialistes si le changement analysé ne leur apportait rien de nouveau ;
- arrêter l'agent après la publication du résultat, plutôt que lui demander un résumé supplémentaire que personne ne consultait ;
- distinguer un délai d'exécution dépassé d'une panne fournisseur, pour éviter de relancer inutilement le même travail ;
- arrêter les tâches annulées, y compris quand l'environnement n'envoie pas correctement le signal d'annulation au processus.
Pris un par un, ces ajustements paraissaient modestes. Ensemble, ils ont retranché environ 0,20 $ par revue. C'est souvent comme ça que les coûts baissent en production : pas par une « astuce » magique, mais en supprimant une série de frictions répétées à grande échelle.
Réduire les appels sans perdre le contrôle du travail
Chercher « le moins d'appels possible » n'est pas toujours la bonne direction. Parfois un appel supplémentaire vaut le coup : consulter un fichier pertinent, ou vérifier une hypothèse risquée. La question utile est plutôt : quels appels changent réellement la décision ou améliorent le résultat ?
Cloudflare a aussi testé plusieurs combinaisons de modèles et de niveaux d'effort. Sur un même modèle, certaines combinaisons finissaient les revues complètes environ 20 % plus vite. L'équipe a simplifié la configuration, puis a comparé des modèles « en répartition aléatoire » plutôt que de s'appuyer sur une impression générale de leurs performances.
Dans un autre test, un modèle Sonnet plus récent a coûté moins cher par revue que la version précédente, alors même que le prix par token restait identique. La différence venait donc d'une consommation plus faible : moins de tokens, et moins d'appels. Pour le contrôle qualité du code, le nouveau modèle en niveau d'effort moyen a réalisé en moyenne 1,7 appel, contre 6,2 auparavant sur la configuration comparée. Plus de la moitié des sessions se terminaient après un seul appel.
Bref : le prix par token ne raconte qu'une partie de l'histoire. Les modifications de code représentaient environ 0,65 $ des économies, contre 1,06 $ pour les changements de modèle et de niveau d'effort. Au final, le coût total passait de 2,43 $ à 0,77 $ par revue, mais l'équipe précise que la comparaison par périodes ne correspond pas à une expérience statistique contrôlée.
Réduire les coûts sans confondre économie et qualité
Un agent qui coûte moins cher mais ne détecte plus les vrais problèmes n'est pas « optimisé ». Il est juste moins utile.
Cloudflare a donc suivi des indicateurs de qualité, parce que le volume de commentaires n'est pas suffisant pour dire si le système progresse. Après les changements, les spécialistes sécurité et performance ont produit moins de signalements critiques ou d'avertissement. Le spécialiste qualité du code, en niveau d'effort élevé, en a aussi produit moins que fin août.
Une baisse peut vouloir dire que le modèle rate des défauts. Elle peut aussi signifier qu'il a arrêté de signaler des détails mineurs, des doublons, ou des problèmes dont la gravité était exagérée. La nuance compte.
Mesurer l'utilité des alertes, pas seulement leur volume
L'équipe a regardé si les développeurs modifiaient les lignes visées après une revue. Avant les optimisations, les auteurs intervenaient sur 34 % des signalements sérieux du spécialiste qualité du code. Après, on est monté à 59 %. Donc : moins d'alertes, mais celles qui restaient menaient plus souvent à une action.
Le nombre de signalements ayant mené à un changement restait du même ordre pour ce spécialiste : 132 par 1 000 revues après changements, contre 145 avant, soit une différence jugée dans la marge d'incertitude. Pour les quatre spécialistes combinés, le chiffre passe de 229 à 321 par millier de revues.
Mais cette mesure a ses limites : changer du code ne prouve pas que l'alerte était « juste ». Un développeur peut modifier pour d'autres raisons. Pour mieux trier, Cloudflare a ajouté une vérification supplémentaire : deux modèles ont évalué à l'aveugle un échantillon de 657 signalements, et un troisième a arbitré les désaccords. Résultat : séparation entre alertes importantes, mineures, incorrectes, en doublon ou impossibles à vérifier.
Sur le nombre d'alertes importantes par revue, la valeur reste proche (0,28 avant, 0,30 après). En revanche, les signalements critiques ou d'avertissement jugés trop sévères ont reculé de 70 %. Une partie de la baisse venait donc du bruit en moins et d'une surévaluation de la gravité qui a diminué - pas forcément d'un vrai défaut ignoré.
Les résultats changent selon la tâche et le niveau d'effort
Les effets ne sont pas uniformes. Le contrôle qualité du code en niveau d'effort élevé semble avoir gardé la capacité à repérer les problèmes importants, tout en générant moins de bruit. À l'inverse, le niveau moyen a entraîné beaucoup moins de signalements qui débouchaient sur une modification dans la comparaison aléatoire.
Du coup, Cloudflare a conservé le niveau élevé pour ce spécialiste, malgré le coût plus haut.
Le spécialiste performance, resté en niveau moyen, a perdu des alertes importantes selon l'évaluation des modèles. Pour la sécurité, la baisse mesurée a été plus limitée et pas statistiquement significative. Ces différences justifient de nouveaux tests à niveau d'effort élevé, plutôt qu'une conclusion définitive.
Il faut aussi tenir compte des limites des données : certains groupes n'avaient que 35 à 66 alertes, la période « après » était courte, et les modèles utilisés pour juger peuvent se tromper. En pratique, plusieurs signaux convergents donnent des indications, mais pas une preuve absolue. Pour les domaines sensibles (sécurité, conformité), il vaut mieux garder une évaluation continue.
Le gain de vitesse, lui, est net. La durée médiane passe de 4 min 9 s à 1 min 32, et le 99e percentile de 15 min 20 s à 4 min 41. La part des revues dépassant cinq minutes tombe de 37,9 % à 0,7 %. En clair : moins de temps d'attente pour les équipes, un bénéfice opérationnel qui ne se voit pas directement dans la facture de tokens.
Conclusion : optimiser à partir des traces réelles
Le cas de Cloudflare ne prouve pas qu'un fournisseur ou un modèle est toujours moins cher que les autres. Ce qu'il montre, c'est qu'un agent en production doit être optimisé à partir de son comportement réel : nombre d'appels, taille des contextes, taux de lecture du cache, sorties générées, délais et qualité des résultats.
Pour commencer :
- vérifiez si la première requête de chaque session lit effectivement un préfixe en cache ;
- repérez les appels qui ne changent ni la décision ni le résultat ;
- comparez plusieurs modèles et niveaux d'effort sur une tâche représentative, avec des critères de qualité définis avant de tester.
La règle simple : ne cherchez pas forcément le modèle le moins cher ; cherchez le coût minimal pour obtenir un résultat suffisamment fiable.
Pour creuser les chiffres et les choix techniques, vous pouvez lire l'analyse originale publiée par Cloudflare.