GPT-4 Turbo : une grande fenêtre reste une facture
GPT-4CoûtContexteProduction2023-11-0610 min
La fenêtre grandit, le prix par jeton baisse, et les factures augmentent quand même. L'explication tient dans une confusion entre capacité et budget.
Deux annonces qui se contredisent en apparence
GPT-4 Turbo porte le contexte à 128 000 jetons tout en baissant nettement le prix par jeton, et pourtant les factures des équipes augmentent. Le paradoxe s'explique en une phrase : la capacité disponible est traitée comme un budget à consommer.
Quand la fenêtre était de huit mille jetons, la contrainte imposait la sobriété. Personne n'avait le choix : il fallait sélectionner. À cent vingt-huit mille, la sélection devient optionnelle, et l'option la plus simple consiste à tout envoyer.
Le résultat est mécanique. Le prix par jeton a baissé de moitié, la consommation par requête a été multipliée par dix, et la facture a quintuplé. C'est la trajectoire que j'observe sur la majorité des systèmes que je reprends en exploitation.
Pourquoi remplir la fenêtre dégrade aussi la qualité
Au-delà d'un certain volume de contexte, ajouter des documents fait baisser la précision des réponses au lieu de l'augmenter. C'est le point contre-intuitif, et c'est celui qui convainc les équipes quand l'argument budgétaire ne suffit pas.
Le mécanisme est documenté : l'information placée au milieu d'un très long contexte est moins bien exploitée que celle placée au début ou à la fin. Vingt extraits dont deux sont pertinents produisent souvent une réponse moins bonne que les deux extraits seuls, parce que le modèle a dix-huit occasions de se tromper de source.
La conséquence pratique va à l'encontre du réflexe naturel. Face à une mauvaise réponse, la tentation est d'envoyer plus de contexte. Le bon geste est presque toujours d'en envoyer moins, mais mieux choisi.
Les quatre réglages qui tiennent la facture
- Fixer un plafond de jetons par requête dans le code, pas dans une consigne. Une limite qui n'est pas appliquée par le système n'est pas une limite.
- Mesurer le coût par appel et par fonctionnalité, au même endroit pour tous les fournisseurs. Sans cette mesure, aucune optimisation n'est instruite.
- Router les tâches simples vers un petit modèle. C'est le levier le plus fort, développé dans Mistral 7B et l'arbitrage par le routage.
- Poser une alerte sur la dérive, pas seulement sur le total. Un doublement de la consommation moyenne par requête signale un problème avant que la facture n'arrive.
Le cas de la conversation qui grossit
Une conversation qui conserve tout son historique voit son coût croître de façon quadratique, et c'est la dérive la plus fréquente en production. Chaque nouveau tour renvoie l'intégralité des tours précédents.
À dix échanges, cela reste marginal. À cent échanges dans une session de support, chaque message coûte cent fois le premier. Une poignée d'utilisateurs intensifs peut alors représenter la majorité de la facture, sans que personne ne comprenne pourquoi.
Les parades sont connues et simples : tronquer l'historique au-delà d'un nombre de tours, résumer les échanges anciens en un bloc court, ou repartir d'une session propre quand le sujet change. Aucune n'est difficile ; toutes exigent d'avoir anticipé le problème, ce qui suppose la mesure. C'est un cas typique d'observabilité des systèmes IA.
La mesure qui révèle tout en une journée
Journaliser, pour chaque appel, le nombre de jetons envoyés et le coût correspondant, puis trier par coût décroissant. Les trois premières lignes expliquent en général plus de la moitié de la facture, et elles ne sont presque jamais celles qu'on attendait.
Ce que la baisse des prix change vraiment
La baisse du prix par jeton rend viables des usages à fort volume qui ne l'étaient pas, à condition de ne pas relâcher la discipline de contexte. C'est le bon usage de cette annonce.
Des traitements par lot sur des dizaines de milliers de documents, une classification systématique du courrier entrant, un enrichissement de base documentaire : ces usages basculent du côté rentable quand le prix unitaire baisse d'un facteur deux ou trois.
Mais ce basculement suppose que le coût par unité traitée soit connu. Une équipe qui ne mesure pas ne saura pas dire si le traitement par lot est rentable, et prendra la décision au jugé. La tendance de fond est claire et durable, elle est analysée dans le prix de l'inférence s'effondre, mais elle ne dispense pas de la mesure.
Un dernier point mérite d'être posé : la baisse du prix par jeton ne s'applique pas uniformément. Les jetons d'entrée et de sortie ne coûtent pas le même prix, et le rapport entre les deux varie d'un modèle à l'autre. Un système qui envoie beaucoup et produit peu, un classifieur, un extracteur, ne profite pas de la même baisse qu'un système qui produit de longs textes. Recalculer sur son propre profil d'usage prend une heure et évite de fonder une décision sur la moyenne annoncée.
Questions fréquentes
- Faut-il utiliser toute la fenêtre disponible ?
Non. La fenêtre est une capacité, pas un budget. Remplir cent vingt-huit mille jetons coûte dix fois plus qu'une requête ciblée et donne souvent une réponse moins précise, l'information utile se diluant dans le bruit.
- Pourquoi une facture augmente-t-elle quand les prix baissent ?
Parce que la consommation par requête augmente plus vite que le prix unitaire ne baisse. Une fenêtre dix fois plus grande remplie sans discipline annule largement une division par deux du tarif.
- Comment maîtriser le coût d'une conversation longue ?
En tronquant l'historique au-delà d'un nombre de tours, ou en résumant les échanges anciens. Sans cela, le coût croît de façon quadratique et quelques utilisateurs intensifs portent l'essentiel de la facture.
- Quelle mesure mettre en place en priorité ?
Le nombre de jetons et le coût par appel, journalisés au même endroit pour tous les fournisseurs. Trier par coût décroissant révèle en une journée d'où vient la facture, et ce n'est presque jamais l'appel attendu.