Pourquoi l'IA agentique semble coûteuse même lorsque la tarification des modèles semble correcte
De nombreuses plaintes concernant les coûts des agents publics ne sont pas vraiment des plaintes modèles. Ce sont des plaintes d'exécution. Lorsqu'une équipe déclare que « l'IA agentique est trop chère », le véritable multiplicateur est généralement un contexte répété, des instructions surdimensionnées, des lectures de fichiers complets, des boucles de confirmation et des appels d'outils en série qui semblent raisonnables une étape à la fois et absurdes lorsqu'ils sont comptés par tâche réussie.
Il s'agit d'un problème de flux de travail avant d'être un problème de fournisseur
Le signal le plus clair est venu d'un live r/AI_Agents discussion: les constructeurs décrivent des invites système géantes, des lectures de fichiers complets, des chaînes d'outils en série et des boucles de « simple vérification » qui empilent les coûts sur la même tâche avant que le modèle ne produise quelque chose de digne de décision. Ce n’est pas une histoire de référence. C'est une histoire de conception d'exécution.
Ce même schéma apparaît ailleurs. Dans un séparé fil r/LangChain, le mode d'échec était des fichiers d'identité répétés et des descriptions d'outils injectées à chaque boucle. Dans un fil r/LocalLLaMA, les déchets sont apparus comme orientation repo avant même que la tâche ne commence. Différents outils, même économie.
Qu'est-ce qui rend réellement la pile chère
La partie la plus coûteuse n’est souvent pas une simple invite géante. C’est le même coût payé encore et encore :
Collecte de contexte répétée. Consignes répétées. Les mêmes fichiers sont relus après chaque petite branche du flux de travail. Les appels d'outils qui auraient pu être groupés, mais ont été sérialisés. Boucles de confirmation qui permettent au harnais de se sentir en sécurité tandis que le budget symbolique continue de fuir.
C'est pourquoi le « bon marché par jeton » peut encore se transformer en un système coûteux. Le prix par jeton est une entrée. Le coût par tâche réussie est le nombre d’opérations qui compte réellement.
Quelles équipes devraient mesurer ensuite
Si vous souhaitez trouver le véritable multiplicateur, arrêtez de mesurer uniquement les dépenses des fournisseurs et commencez à mesurer les exécutions de tâches. Donnez à chaque exécution un identifiant de tâche. Suivez le contexte de la première touche, le contexte de la dernière touche, le nombre d'appels d'outils, la taille des charges utiles statiques répétées, les tentatives et si l'artefact final était suffisamment utile pour être conservé. Une fois que cela existe, les modèles de déchets cessent généralement de se cacher.
C'est ici __TRH_PH_0__ convient le mieux : non pas comme une promesse que chaque flux de travail deviendra comme par magie moins cher, mais comme un moyen d'analyser où l'utilisation se développe avant que la qualité du résultat ne le justifie.
La prochaine étape pratique
Choisissez un flux de travail qui semble déjà coûteux. Exécutez-le une fois avec la journalisation activée. Cartographiez les jetons dépensés pour la configuration, la navigation, les charges utiles répétées, les tentatives et le travail final utile. Supprimez ensuite une charge utile répétée, une boucle de contrôle et une lecture inutile de l'exécution suivante. Cela vous apprendra généralement plus qu’une autre feuille de calcul de comparaison de modèles.