coût par token

En profondeur

Quatre asymétries expliquent la plupart des surprises. La sortie est facturée nettement plus cher que l’entrée, ce qui rend coûteuses les réponses longues et les raisonnements détaillés. L’entrée déjà vue peut être mise en cache et payée une fraction du prix, à condition d’avoir composé le prompt pour cela. Les images consomment un grand nombre de tokens. Et les modèles de raisonnement facturent leurs étapes intermédiaires, même invisibles, ce qui multiplie le coût d’un facteur difficile à prévoir puisqu’il varie d’une exécution à l’autre.

La bonne unité de pilotage n’est donc pas le prix au million de tokens mais le coût par tâche réussie. Ce chiffre intègre ce qui compte vraiment : le nombre d’appels, la longueur du contexte transporté, les reprises après échec, et le taux d’échec lui-même, puisqu’une tâche ratée a coûté sans rien produire. Deux systèmes affichant le même modèle et le même tarif peuvent différer d’un ordre de grandeur sur cette mesure, et c’est elle qui décide de la viabilité d’un service.

Les leviers efficaces sont peu nombreux et se rangent par ordre de rendement. Ne pas appeler le modèle quand une règle simple suffit reste le premier. Employer un petit modèle pour trier et n’escalader vers un grand que sur les cas difficiles vient ensuite. Puis réduire ce qu’on transporte, en évitant de renvoyer un historique entier à chaque tour. Enfin, structurer le prompt pour le cache. À l’inverse, changer de fournisseur pour quelques pour cent de tarif est presque toujours le levier le moins rentable, et il coûte du temps d’équipe.