SECTEUR · LA MACHINE · WILLIAM LEEMANS
Le coût et la latence
Lecture ~8 min
L’Étape précédente a posé ce qu’est un contexte : un unique document, reconstruit intégralement à chaque appel, puis jeté.
Ce document a deux prix. Il coûte de l’argent, et il coûte du temps — pas le même temps selon qu’on le lit ou qu’on y répond. Et les deux se règlent au même endroit, qui n’est ni le modèle ni le fournisseur : c’est la façon dont vous rangez ce document.
Pourquoi cinquante tours ne coûtent pas cinquante requêtes ?
Parce que rien ne reste entre deux appels, donc tout repart : instructions, historique, fichiers ouverts, résultats d’outils. Une session d’agent de cinquante tours coûte cinquante fois un contexte qui grossit à chaque tour, et la somme n’a rien d’intuitif.
Deux malus se cumulent dans cette courbe, et c’est ce qui rend les sessions interminables mauvaises des deux côtés : le coût monte pendant que l’attention se dilue.
Autrement dit, repartir d’une session fraîche avec un contexte reconstruit est souvent moins cher que de s’acharner. C’est une décision de budget autant qu’une décision de qualité, et c’est la première fois que les deux vont dans le même sens.
Lire ou écrire : qu’est-ce qui coûte le plus ?
Écrire, largement — mais c’est lire qui vous fait attendre. Un appel se déroule en deux temps qui n’ont ni la même vitesse ni le même prix, et le premier ne produit rien de visible.
Le premier temps lit. Le modèle avale tout le contexte en un seul passage, pour construire l’état à partir duquel il pourra écrire. C’est lui qui fixe le délai avant le premier token. Le second écrit, et il est strictement séquentiel : chaque token de sortie est un passage complet du modèle, refait de bout en bout, après quoi le token produit rejoint l’entrée du passage suivant. On les appelle le prefill et le décodage.
Les deux se chronomètrent, et il suffit de faire grossir le contexte pour voir lequel des deux en dépend.
De 76 à 3 084 tokens envoyés, le contexte est multiplié par 40,6 et l’attente par 30,8. Le débit d’écriture, lui, ne bouge pas : la lecture se fait en bloc, l’écriture token par token.
De 76 à 3 084 tokens envoyés — un contexte multiplié par quarante — l’attente avant le premier token passe de 79 à 2 436 millisecondes, et elle monte à chaque palier. Le débit d’écriture, sur la même plage, ne bouge pas : une centaine de tokens par seconde d’un bout à l’autre. Deux courbes, une qui grimpe et une plate, et c’est toute la mécanique du coût d’un appel.
Les deux traces de l’Étape 1 le disaient déjà en plus petit : le prompt y est lu à 241 et 662 tokens par seconde selon qu’il fait 12 ou 37 tokens, la réponse écrite à 50 et 61 dans les deux cas. La lecture se fait en bloc, donc plus il y a de tokens à lire, mieux le coût fixe s’amortit : c’est pour ça que l’attente n’est multipliée que par trente là où le contexte l’est par quarante. L’écriture, elle, ne s’amortit jamais. Un token de plus, un passage de plus.
Deux conséquences en sortent, et elles se prennent en écrivant le prompt.
- Le délai avant le premier token monte avec la taille du contexte, pas avec celle de la réponse. Un fichier ouvert « au cas où » n’est pas seulement plus cher : il se paye en attente, à chaque tour restant, avant même que le premier caractère apparaisse.
- La sortie coûte plus cher que l’entrée, au tarif comme à la montre. Demander de la concision n’est donc ni une politesse ni un tic de style : c’est la seule économie qui se décide entièrement dans le prompt.
Reste une question que cette Étape ne tranche pas : pourquoi ce premier temps est-il si long, alors qu’il ne produit rien ? « Prefill, décodage, cache » montre ce que le modèle construit pendant cette lecture, et pourquoi il ne peut pas commencer à écrire avant de l’avoir terminée.
Comment marche le cache de préfixe ?
En reconnaissant un début strictement identique, token pour token — ou en ne reconnaissant rien du tout. Il n’y a pas d’entre-deux, et c’est tout l’enjeu.
Les fournisseurs atténuent la relecture avec ce cache : ce qui a déjà été lu au tour précédent n’est pas relu, l’état construit dessus est réutilisé, et cette part du contexte est facturée à une fraction du tarif. C’est ce que chiffre la case « Cache de prompt » de la figure calculée, en tête de l’Étape.
Le gain de temps, lui, se mesure. Basculez la courbe mesurée ci-dessus sur « Préfixe déjà en cache » : à 3 084 tokens de contexte, la lecture tombe de 2 436 à 12 millisecondes — 3 083 tokens repris du tour précédent, un seul évalué. Et cette dizaine de millisecondes ne bouge pas avec le contexte : c’est une dizaine à 76 tokens comme à 3 084. Deux ordres de grandeur séparent un contexte relu d’un contexte reconnu, et ce qui décide de l’un ou de l’autre, c’est vous.
Le gain porte sur la lecture, et sur elle seule : rien de ce que le cache réutilise ne dispense d’un passage complet du modèle par token écrit. Le commutateur le montre plutôt qu’il ne l’affirme — les deux chiffres sont relevés sur la même passe, et quand celui de gauche s’effondre, celui de droite reste autour d’une centaine de tokens par seconde.
J’aime bien l’image du marque-page : il ne vous fait gagner du temps que si personne n’a réécrit les pages d’avant. Un seul mot changé au chapitre premier, et vous relisez tout.
C’est très exactement la règle, et elle ne se négocie pas : le préfixe réutilisé doit être strictement identique, depuis le tout premier token. Une virgule corrigée à la ligne 3 de vos instructions, un horodatage inséré en tête, une liste de fichiers réordonnée, un résumé qui remplace les dix premiers tours — à partir du premier octet qui diffère, tout ce qui suit est relu et refacturé plein tarif.
Cette condition-là se mesure aussi, et c’est la troisième position du commutateur de la figure : le préfixe cassé. La capture rejoue le même point une troisième fois, avec une espace insérée en tête : un octet, qui ne change ni le sens du document ni sa longueur — il fait toujours 3 084 tokens, et un seul d’entre eux diffère, le premier. Tokens repris du tour précédent : zéro, contre 3 083 à la passe d’avant. Le temps avant premier token remonte à 2 441 millisecondes, c’est-à-dire au prix d’un contexte jamais vu : sur la figure, la barre que le cache avait fait disparaître revient exactement où elle était.
Ce qu’il faut retenir de ce relevé n’est pas le facteur — il dépend de la longueur du contexte, et le retenir vous apprendrait un chiffre au lieu d’une règle. C’est que le compte tombe à zéro. Il n’y a pas de dégradé entre « tout réutilisé » et « rien réutilisé », et l’octet qui fait basculer de l’un à l’autre peut ne rien vouloir dire, ni se voir.
D’où deux règles, qui sont des règles de rangement et non des optimisations.
- Le stable en tête. Instructions, conventions, documents de référence : tout ce qui ne bougera pas de la session va au début, dans un ordre fixé. Ce qui bouge — la demande du moment, les résultats d’outils — vient après.
- On ne réécrit jamais l’historique. Éditer un tour passé, réordonner, compacter par le milieu : c’est le geste dont le gain est le plus visible et le prix le plus invisible. On ajoute à la fin, ou on repart d’une session propre.
LE CRAFTOMANCER
Un fichier d’instructions qui contient la date du jour, un compteur ou une liste de fichiers ouverts invalide le cache à chaque tour. C’est le genre de ligne qu’on ajoute pour rendre service et qui se paye sur toute la session, en argent et en attente, sans que rien ne le signale.
Que coûtent les tokens de raisonnement ?
Le tarif de sortie, plein pot, et de l’attente — même quand l’interface ne vous les montre pas.
Certains modèles produisent, avant leur réponse, une longue suite de tokens de délibération : hypothèses, retours en arrière, vérifications. Ce sont des tokens de sortie comme les autres — un passage complet du modèle chacun — et la plupart des interfaces les replient, les grisent, ou ne les affichent pas du tout.
Sur une même demande, un modèle qui délibère peut donc écrire beaucoup plus de tokens qu’il n’en montre, et vous faire attendre bien plus longtemps avant la première ligne visible. Le réglage qui contrôle cet effort est un réglage de coût autant qu’un réglage de qualité : il se choisit par tâche, et sur du travail mécanique il se paye sans rien rendre.
Ces tokens ont un second effet, qui n’est pas de cet ordre : une trace longue et méthodique peut se dérouler impeccablement à partir d’une prémisse fausse, et sa longueur se lit alors comme du sérieux. C’est une question de vérification, et elle est traitée avec les autres en limites et hallucinations.
En pratique
- Rangez avant d’ajouter : le stable en tête, le volatil à la fin. Ça ne coûte rien à écrire et ça se rembourse à chaque tour.
- N’éditez pas l’historique en cours de session. Ajoutez à la fin, ou repartez d’un contexte propre.
- Demandez la concision quand la réponse n’a pas besoin d’être longue. C’est du coût, pas du style.
- Avant d’ouvrir un fichier « au cas où », rappelez-vous qu’il sera relu et réattendu à chaque tour restant.
- Choisissez l’effort de raisonnement par tâche, et vérifiez ce qu’il vous facture quand vous ne le voyez pas.
Pourquoi le premier token est-il si lent ?
Cette Étape décrit les deux temps d’un appel par ce qu’ils vous coûtent. « Le modèle de bout en bout » décrit ce qui s’y passe. Deux de ses sections reprennent exactement d’ici :
- Prefill, décodage, cache — ce que la lecture du contexte construit, ce que le cache en garde d’un tour à l’autre, et pourquoi l’écriture ne peut pas aller plus vite qu’un passage par token.
- Ce qui rend un passage tenable — ce que les modèles récents changent pour que ce passage tienne sur un long contexte, et pourquoi la vitesse de sortie varie selon ce qui est écrit.
Vérifiez votre modèle
Cinq questions pour voir si la mécanique tient. Cliquez une réponse : le verdict s’affiche.
jack in — choisissez votre réponse
Vous collez 800 lignes de logs JSON dans le contexte « au cas où ». Côté coût, c’est…
Le temps avant le premier token dépend surtout…
Demander explicitement une réponse concise, c’est…
Au milieu d’une session, vous corrigez une phrase en tête de votre fichier d’instructions. Conséquence…
Les tokens de raisonnement d’un modèle qui « réfléchit » avant de répondre…