Context window des LLM et tokenisation : moteurs de latence et de coût

La tokenisation découpe le texte en tokens, les plus petites unités de traitement d'un LLM ; la fenêtre de contexte est le nombre maximal de tokens qu'un modèle peut traiter ensemble par requête. Pour les agents IA, toutes deux déterminent directement le coût et la latence, car chaque étape de l'agent renvoie au modèle l'intégralité du contexte accumulé. Quand on exploite des agents en production, c'est avec ces deux grandeurs qu'on pilote l'essentiel des coûts courants et du temps de réponse.

• Les tokens sont l'unité de facturation et de traitement. Le coût et la latence dépendent du nombre de tokens, pas du nombre de caractères. Un texte allemand génère en général plus de tokens par mot qu'un texte anglais.
• La fenêtre de contexte est limitée. Les agents multi-étapes la remplissent vite, car chaque étape traîne avec elle le prompt système, tout l'historique et tous les résultats d'outils. Le volume de tokens facturé par exécution croît donc de façon plus que proportionnelle.
• Un contexte plein n'est pas un meilleur contexte. Avec des entrées très longues, la qualité baisse de manière mesurable (Lost-in-the-Middle). La gestion du contexte est donc à la fois un levier de coût et de qualité.

Ce que sont les tokens et pourquoi ils déterminent les coûts

Un LLM ne traite pas du texte brut, mais des tokens. Le tokeniseur découpe le texte d'entrée en unités qui correspondent le plus souvent à un fragment de mot, à un mot court entier ou à un signe de ponctuation. Le modèle calcule exclusivement avec ces tokens, et tous les fournisseurs facturent au token, séparément pour l'entrée (ce qui entre) et la sortie (ce qui est généré).

Dans la pratique, deux propriétés sont décisives. Premièrement, la densité de tokens dépend de la langue : les longs mots composés, les trémas et les terminaisons flexionnelles font qu'en allemand, le même contenu nécessite souvent plus de tokens qu'en anglais. L'ampleur de l'écart dépend du tokeniseur du modèle, et celui-ci peut changer même chez un même fournisseur : selon Anthropic, le tokeniseur introduit avec Claude Opus 4.7 génère environ 30 % de tokens de plus que son prédécesseur pour le même texte. Pour les charges de travail en langue allemande, cela signifie : même tâche, plus de tokens consommés, des coûts plus élevés et une fenêtre de contexte remplie plus vite.

Deuxièmement, la sortie coûte généralement bien plus cher que l'entrée. Sur les modèles disponibles sur le marché, le prix de sortie se situe typiquement entre trois et six fois le prix d'entrée. Chez certains modèles workhorse bon marché, l'écart est plus faible ; chez les modèles frontier, il se situe plutôt dans le haut de la fourchette. Un agent qui produit des réponses longues et détaillées coûte donc cher de façon disproportionnée par rapport au volume de tokens de sortie.

Comment fonctionne la fenêtre de contexte

La fenêtre de contexte est le nombre maximal de tokens qu'un modèle peut voir ensemble dans une requête, entrée et sortie générée comprises. Tout ce que le modèle doit prendre en compte pour une réponse doit tenir dans cette fenêtre : instruction système, historique de conversation, documents injectés, définitions d'outils et résultats d'outils.

La taille des fenêtres a fortement augmenté ces dernières années. Les modèles frontier actuels offrent des contextes très grands : Claude Opus 5.5 et Gemini 3.1 Pro fonctionnent avec environ 1 million de tokens, Mistral Large 3 avec 256K. Parmi les modèles open-weight, Llama 4 Scout (avril 2025) atteint jusqu'à 10 millions de tokens (toutes les données : octobre 2026). Une fenêtre plus grande repousse la limite stricte, mais ne rend pas gratuit le fait de traîner du contexte. Deux effets demeurent : le coût et la latence augmentent avec la longueur de l'entrée, et la qualité des réponses se dégrade sur les entrées très longues.

La croissance du contexte chez les agents multi-étapes

Un appel de chat isolé ne pose pas de problème de coût. Le problème naît avec le schéma agentique : un agent ne résout pas une tâche en un seul appel, mais en de nombreuses étapes (planifier, appeler un outil, évaluer le résultat, appeler l'outil suivant, et ainsi de suite). À chacune de ces étapes, l'intégralité de l'historique est renvoyée en entrée, car le modèle est sans état et ne retient rien.

On en arrive au schéma économique central des agents : une consommation de tokens qui croît de façon plus que proportionnelle. Si l'étape 1 compte encore 2 000 tokens d'entrée, l'étape 2 déjà 5 000, l'étape 3 ensuite 9 000 et ainsi de suite, la consommation de tokens facturée sur l'exécution ne s'additionne pas de manière linéaire, mais bien plus que proportionnellement, car chaque étape traîne le contexte accumulé de toutes les étapes précédentes. Chaque sortie d'outil supplémentaire (une réponse d'API, un document parcouru, un résultat de recherche) agrandit le contexte de toutes les étapes suivantes. Les sorties d'outils longues sont ici le facteur de coût silencieux le plus fréquent.

La latence suit la même logique. Le temps jusqu'au premier token et le temps de réponse total augmentent avec la longueur de l'entrée, car le modèle doit lire tout le contexte avant de répondre. Un agent qui transporte 80 000 tokens de contexte vers la fin d'une longue exécution est sensiblement plus lent à chaque étape qu'au début, et ce précisément au moment où l'utilisateur attend déjà.

Dégradation : Lost-in-the-Middle avec un contexte plein

Une idée fausse répandue veut que, si la fenêtre est assez grande, on puisse simplement tout y mettre. C'est vrai techniquement, mais pas en termes de qualité. Les LLM exploitent plus fiablement les informations situées au début et à la fin d'une longue entrée que celles du milieu, un effet connu sous le nom de Lost-in-the-Middle. Plus le contexte est long, plus le risque augmente que l'information décisive soit moins bien pondérée ou se perde.

Pour les agents, c'est doublement important. D'une part, un agent remplit souvent son contexte d'un historique sans rapport avec l'étape en cours. D'autre part, un contexte surchargé peut amener le modèle à ignorer des instructions plus anciennes ou des résultats d'outils précoces situés au milieu de l'historique. La qualité des réponses baisse alors, bien que l'espace disponible suffise techniquement. Plus de contexte ne signifie donc pas automatiquement plus de performance ; passé un certain point, un contexte plus réduit mais mieux sélectionné donne de meilleurs résultats.

Les notions clés et leurs implications pour les agents

Exemple de calcul : des tokens aux coûts

Un agent de support traite une demande en 6 étapes. À chaque étape, il renvoie l'intégralité du contexte. Hypothèse simplifiée pour l'évolution de l'entrée : 2 000, 5 000, 9 000, 14 000, 20 000, 27 000 tokens, soit environ 77 000 tokens d'entrée au total. Il génère en plus environ 500 tokens de sortie par étape, soit environ 3 000 tokens de sortie au total.

Faisons le calcul avec trois niveaux de prix. Par simplification, le nombre de tokens est le même pour les trois modèles ; selon le tokeniseur, il varie pour une même tâche. Le tableau utilise les prix catalogue pour 1 million de tokens (entrée/sortie, données d'octobre 2026) publiés par Anthropic, Mistral et DeepSeek :

Une exécution isolée semble bon marché. Mais avec 50 000 exécutions de ce type par mois, on arrive à environ 18 400 dollars américains avec le modèle frontier, contre environ 2 150 dollars avec le modèle souverain européen et environ 1 300 dollars avec le modèle workhorse bon marché. Pour DeepSeek, le tableau indique le tarif en heures de pointe ; en dehors, le prix est divisé par deux. Claude Fable 5.1, qu'Anthropic destine au raisonnement exigeant, coûte 10 $ / 50 $, soit 2,5 fois le prix d'Opus 5.5 (Anthropic). Extrapolé, cela représenterait environ 46 000 dollars par mois. Le facteur entre les niveaux frontier et workhorse se situe, selon le modèle, entre 8 et 100 (données d'octobre 2026). Deux enseignements : premièrement, chez les agents, c'est l'entrée traînée d'étape en étape qui domine le budget, pas la sortie. Deuxièmement, le choix du modèle pour chaque sous-étape est un levier de coût considérable.

S'y ajoute une majoration pour les contextes longs. Gemini 3.1 Pro, par exemple, devient plus cher au-delà de 200 000 tokens : le prix d'entrée double et le prix de sortie augmente lui aussi nettement (4 $ / 18 $ au lieu de 2 $ / 12 $ pour 1 million de tokens, données d'octobre 2026). Laisser le contexte d'un agent dépasser ce seuil sans contrôle, c'est payer davantage de tokens, et chacun à un tarif plus élevé.

Contre-stratégies : garder un contexte réduit et ciblé

Tout l'art de l'ingénierie d'agents consiste à ne donner au modèle, à chaque étape, que ce dont il a réellement besoin. Trois stratégies, combinables entre elles :

• Compression du contexte et synthèse. Les étapes anciennes sont condensées en un bref résumé au lieu de traîner l'historique complet. Les longues sorties d'outils sont réduites au résultat. Cela diminue à la fois les tokens d'entrée, la latence et le risque de Lost-in-the-Middle.
• La récupération ciblée plutôt que le texte intégral (RAG). Au lieu de charger des bases de connaissances ou des documents entiers dans le prompt, on n'injecte via une recherche que les extraits pertinents. Le contexte reste réduit et la pertinence des résultats augmente, car le modèle n'est pas distrait par des éléments hors sujet.
• Routage de modèles et prompt caching. Les sous-tâches simples (classification, extraction, mise en forme) tournent sur des modèles workhorse ou open-weight bon marché ; les modèles frontier, coûteux, sont réservés aux étapes complexes. Le prompt caching réduit aussi le coût des parties de contexte récurrentes et stables, comme les prompts système.

En complément : limiter délibérément la sortie (des réponses courtes et structurées plutôt qu'une prose interminable) et réduire les résultats d'outils à l'essentiel. Ensemble, ces mesures décident si un agent, élégant en phase pilote, reste aussi rentable en production.

Pour les agences et les décideurs B2B

La tokenisation et la fenêtre de contexte sont les deux principaux leviers de rentabilité d'un agent IA. Pour budgéter une solution à base d'agents, il faut calculer les coûts non pas par requête, mais par exécution multi-étapes complète, extrapolée au volume mensuel attendu, croissance disproportionnée du contexte comprise. Pour les agences, la valeur du conseil consiste à épargner à leurs clients la mauvaise surprise d'un agent bon marché en pilote qui devient, sous charge, d'un coût ou d'une lenteur imprévisibles. Blck Alpaca aide les entreprises de toute l'Europe à concevoir des architectures d'agents qui intègrent dès le départ la gestion du contexte, le routage de modèles et la récupération ciblée. Résultat : des coûts prévisibles, une latence acceptable et une qualité de réponse stable en production.