Réduire le coût par tâche et mesurer le retour sur investissement des agents sur Amazon Bedrock
Au moment de budgéter l'IA générative sur Amazon Bedrock, la plupart des équipes comparent le prix par token, alors que la facture reflète le coût d'une tâche complète : répondre à un courriel de support, extraire les champs d'une facture ou répondre à une question d'utilisateur, quel que soit le nombre d'appels au modèle nécessaires. Ce deuxième volet d'une série d'AWS fait suite à un premier consacré à la gouvernance des dépenses (attribution par balises de principaux IAM et rapports Cost and Usage Report 2.0, journalisation des invocations, trois niveaux de contrôle, revue périodique). Il détaille quatre facteurs de coût cachés que la page de tarification n'affiche pas : l'efficacité du tokenizer, qui découpe un même texte en nombres de tokens différents selon les familles de modèles ; la verbosité des sorties ; l'efficacité des boucles agentiques ; et le surcoût du raisonnement. Il propose aussi une méthode pour prouver le retour sur investissement des agents, fondée sur des références humaines, des expériences contrôlées et un tableau de bord à cinq dimensions.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
Les écarts peuvent être considérables. Un modèle affichant un prix 15 % inférieur mais exigeant 40 % de tokens supplémentaires sur des schémas structurés ou des tableaux numériques revient en réalité plus cher, et l'écart se creuse pour les textes non latins, que de nombreux tokenizers fragmentent en deux à trois fois plus de tokens que l'anglais. Les tokens de sortie coûtant généralement 3 à 5 fois plus que ceux d'entrée, un modèle qui ignore une consigne comme « renvoyer uniquement du JSON brut » fait payer du remplissage au tarif fort. Dans les workflows avec appel d'outils, chaque tour renvoie tout l'historique en entrée : quatre tours successifs coûtent bien plus qu'un passage unique. Enfin, les tokens de raisonnement sont facturés comme des tokens de sortie, si bien que 2 000 tokens de réflexion avant une réponse de 200 tokens se facturent 2 200, y compris lorsque certains modèles masquent ce raisonnement tout en le facturant.
Cette approche change la manière de décider, tant pour les ingénieurs qui actionnent les leviers d'optimisation (mise en cache, routage entre modèles, contraintes sur la sortie) que pour les responsables produit et les équipes FinOps qui doivent justifier la dépense devant la direction. Elle recommande de désactiver le raisonnement par défaut et de ne l'activer que si des évaluations révèlent un écart de qualité qui justifie son coût. Elle déplace aussi la question de fond : savoir qui a dépensé et pouvoir l'arrêter ne dit rien sur la valeur créée, d'où la nécessité de comparer l'agent aux humains qu'il assiste ou remplace, avec des groupes témoins et des indicateurs reliés à des décisions concrètes.
Le sujet s'inscrit dans le passage des expérimentations à la production, où les factures d'IA générative deviennent un poste budgétaire à part entière et où les directions financières réclament des preuves de rentabilité. L'article illustre la démarche par un exemple d'agent qui lit un courriel client de 750 mots, extrait des entités, appelle une API pour vérifier le statut d'un compte et produit un JSON strict, puis compare deux modèles sur cinq dimensions de coût, le prix catalogue n'étant que l'une d'elles. Cette logique, qui rapproche l'optimisation technique de la gouvernance financière, devrait pousser les entreprises à mesurer leurs charges de travail réelles plutôt qu'à se fier aux grilles tarifaires.