L'algorithme de détermination du prix de chaque token : dans les coulisses du moteur de raisonnement LLM de 2026

Mise à jour : août 2026.

Si, en 2023-2024, la question la plus brûlante concernant l’IA était « quel modèle est le plus performant ? », dès le début de l’année 2026, la question la plus coûteuse est devenue : combien coûte l’exécution d’un token, et qui propose les coûts les plus bas. Ce n’est plus une question de matériel — tout le monde peut s’acheter un GPU. Ce qui distingue désormais les gagnants des perdants, c’est une couche algorithmique très spécifique située entre le modèle et la puce : la manière d’organiser la mémoire, de planifier les tâches, d’anticiper et de rationaliser les opérations.

Ce qui est étonnant en 2026, c’est que les prix des API continuent de baisser alors que la mémoire et les GPU atteignent des prix records. Cette différence s’explique en grande partie par les algorithmes présentés ci-dessous.

À la racine : une requête en deux phases, deux nœuds opposés

Pour comprendre pourquoi toute une série de techniques apparemment disparates ont vu le jour simultanément, il faut prendre conscience d’une réalité physique : la production de textes comporte deux phases aux caractéristiques totalement différentes.

Phase de préremplissage — modèle lisant l'intégralité de la prompt. L'ensemble des tokens étant chargé simultanément, le GPU peut effectuer des multiplications matricielles de grande taille et fonctionner à près de sa pleine capacité : il s'agit d'une phase de goulot d'étranglement au niveau des calculs, dont le coût augmente avec la longueur et, en particulier, celui de l'attention augmente proportionnellement au carré de la longueur.

Étape de décodage — modèle générant les tokens un par un, le suivant dépendant du précédent, ce qui ne permet aucune parallélisation. À chaque étape, il faut relire l'ensemble des poids actifs depuis la mémoire HBM uniquement pour générer un seul token : avec un modèle comportant plusieurs dizaines de milliards de paramètres, cela représente des dizaines de gigaoctets de données lues pour un seul token, alors que le nombre de calculs réellement nécessaires est infime. Résultat : sur les petits lots, le GPU n’utilise que quelques pour cent de sa puissance de calcul, le reste étant consacré à l’attente de la mémoire.

En réalité, tout cet article n'est que la conséquence d'une seule phrase : lors de la phase de décodage, les calculs sont en excès tandis que la bande passante fait défaut. Tous les algorithmes d'accélération de l'inférence consistent à réduire ce qui est en excès pour compenser ce qui manque.

KV-cache : lorsque le modèle nécessite un petit système d'exploitation

Pour éviter de recalculer l’attention pour l’ensemble du passé à chaque étape, le modèle conserve le vecteur-clé et la valeur de chaque token déjà traité — c’est ce qu’on appelle le cache KV, qui transforme le contexte long en mémoire : chaque nouveau token ajoute un élément, et ce cache doit être stocké dans l’HBM, où il partage l’espace avec les poids eux-mêmes.

L'approche naïve consiste à allouer à chaque requête un bloc de mémoire contigu suffisant pour sa longueur maximale — ce qui entraîne une fragmentation considérable, la majeure partie de la mémoire étant réservée sans être utilisée. PagedAttention résout le problème exactement comme un système d’exploitation gère la mémoire virtuelle : il divise le cache KV en blocs fixes, dispose d’une table de correspondance entre les emplacements logiques et les blocs physiques, et alloue la mémoire progressivement en fonction des besoins. Pas besoin de contiguïté, pratiquement aucune fragmentation, et surtout : lorsque deux requêtes partagent la même partie initiale, elles partagent le même bloc, exactement comme dans le « copy-on-write ».

C'est de cette idée de segmenter le contenu qu'est née la solution la plus économique dans la pratique : la mise en cache des préfixes. Les invites système, les descriptions d'outils, les pièces jointes, l'historique des conversations… Dans une application réelle, les éléments répétitifs constituent la majeure partie des entrées. Il suffit de hacher le contenu de chaque bloc puis de consulter la table pour éliminer en grande partie la phase de préremplissage lors de l’appel suivant. C’est la raison pour laquelle les grands fournisseurs affichent des tarifs distincts pour les entrées déjà mises en cache, généralement environ dix fois moins chères. En d’autres termes : une structure de données est devenue une ligne à part entière dans la grille tarifaire.

En 2026, ce cache sera hiérarchisé entre la mémoire vive du serveur et le SSD, et le routeur devra savoir sur quelle machine se trouve le cache afin d’acheminer la requête vers celle-ci — l’équilibrage de charge de type « répartition uniforme » n’est plus la bonne option, car envoyer une requête vers une machine inoccupée mais dépourvue de cache coûte plus cher que de la mettre en file d’attente sur une machine disposant d’un cache.

Planification : regroupement continu des lots et fractionnement des préremplissages

Le regroupement de plusieurs requêtes en un seul cycle d’exécution permet de partager le coût de la lecture des poids : une seule lecture suffit pour l’ensemble du lot. Mais l’ancien mode de regroupement (attendre que le lot soit complet, lancer l’exécution, attendre que tout le lot soit traité) est source de gaspillage : les requêtes courtes doivent attendre que les requêtes longues soient terminées. Le « continuous batching » planifie au niveau de chaque étape de génération de jetons : dès qu’une requête est terminée, elle quitte immédiatement le lot, et l’espace libéré est comblé par une nouvelle requête à l’étape suivante. Le simple fait de modifier l’algorithme de planification a permis de multiplier le débit par plusieurs fois en conditions réelles, sans toucher au modèle.

Le problème qui subsiste réside dans deux phases qui se chevauchent : une longue instruction de préremplissage monopolise le GPU pendant plusieurs centaines de millisecondes, ce qui bloque toutes les requêtes en cours de décodage. Le « chunked prefill » découpe le préremplissage en petits morceaux intercalés entre les étapes de décodage, sacrifiant un peu du temps d’attente pour le premier caractère au profit d’une fluidité globale — la frontière entre l’algorithme et la stratégie commerciale s’estompe.

Réfléchir puis vérifier : se débarrasser de ce dont on n'a pas besoin pour acheter ce qui manque

Si le décodage comporte un excès de calculs mais manque de bande passante, vérifier cinq tokens en une seule passe n’est pratiquement pas plus coûteux que d’en vérifier un seul — car dans les deux cas, il faut lire exactement le même nombre de poids. C’est là tout le principe du décodage spéculatif.

Mécanisme : un modèle préliminaire peu coûteux propose les quelques jetons suivants ; le grand modèle effectue un seul passage pour vérifier l'ensemble de la chaîne ; les jetons qui correspondent sont acceptés, le premier jeton non conforme est rejeté et le processus recommence. La subtilité réside dans l’étape de vérification qui utilise un échantillonnage ajusté, de sorte que la distribution des résultats soit identique à celle obtenue en exécutant le grand modèle normalement. Il ne s’agit pas d’une approximation au détriment de la qualité — c’est pourquoi cette option est activée par défaut sans qu’il soit nécessaire de demander l’autorisation.

En 2026, les modèles de prévision ne seront plus des modèles distincts : au lieu de former un petit modèle séparé, on intégrera directement une tête de prédiction multi-tokens au sein même du grand modèle, ou on utilisera une tête de prévision légère pour lire directement l'état interne du modèle. La lignée EAGLE-3 et ses variantes de prédiction multi-tokens ont été intégrées à la branche principale de vLLM, SGLang et TensorRT-LLM dès le début de l'année ; le nombre moyen de tokens reçus se situe entre deux et trois par itération.

Mais il faut le dire clairement : les avantages diminuent à mesure que le lot s'étoffe. Plus le lot est volumineux, plus le GPU approche de sa capacité maximale de calcul, et il n’y a plus de marge pour la surestimation ; le taux d’acceptation chute également lorsque le contexte est très long. Il s’agit donc d’un outil utile pour réduire la latence et optimiser les heures creuses, et non d’un remède miracle pour augmenter le débit de manière inconditionnelle.

Le véritable bond en avant de 2026 : attention, ne manquez aucun token

Tout ce qui précède concerne l'optimisation opérationnelle : le modèle reste inchangé. Le changement le plus important prévu pour début 2026 est plus profond : on modifie l'architecture même pour empêcher le KV-cache de continuer à grossir. Trois axes sont actuellement développés en parallèle :

• Compression des KV en un état latent. Au lieu de stocker l’intégralité des clés et des valeurs pour chaque tête d’attention, celles-ci sont projetées sur un vecteur latent bien plus petit, puis décompressées lors du calcul — l’approche de l’attention latente multi-têtes réduit considérablement la taille du cache sans perte notable de qualité.
• L’attention clairsemée est apprise. Chaque nouveau token n’a pas besoin d’examiner l’intégralité de l’historique ; un index peu coûteux sélectionne un petit groupe de tokens pertinents, puis l’attention n’est calculée que sur ce groupe. Contrairement aux « fenêtres glissantes » de l’ancienne génération, cette sélection est ici entraînée avec le modèle et non pas régie par des règles rigides définies par l’utilisateur.
• C’est la combinaison avec l’attention linéaire qui est la plus surprenante. La plupart des couches sont remplacées par une forme de régression gated, chaque couche conservant un état de taille fixe au lieu d’un cache infini, et une couche d’attention complète est insérée toutes les quelques couches afin de préserver la précision de la mémoire. Le rapport de trois couches linéaires pour une couche complète est apparu dans de nombreuses familles de modèles ouverts au cours du premier semestre 2026.

L'importance économique de cette troisième approche est considérable. Avec l'attention traditionnelle, le contexte doublant, chaque étape de décodage nécessite une lecture deux fois plus longue — le coût par token augmente donc avec la longueur de la conversation. Comme la majeure partie de la couche est constituée d'une régression à état fixe, le coût par token reste pratiquement constant quelle que soit la longueur. C’est précisément lorsque le modèle d’inférence et l’agent commencent à générer des sessions de plusieurs centaines de milliers de tokens que la différence entre disposer ou non d’un modèle économique se fait sentir.

Il n'est peut-être pas nécessaire de le préciser : en supprimant des tokens pour faciliter la lecture, on court toujours le risque de passer à côté d'un token important. Les tests de réactivité précis dans des contextes longs restent le domaine où ces architectures sont le plus minutieusement examinées, et les méthodes de mesure actuelles ne font pas l'unanimité.

Séparation des tâches : préremplir un bloc, décoder un bloc

Si deux phases nécessitent deux types de ressources opposés, les confiner dans une même machine revient à les forcer toutes deux à faire des compromis. En 2026, la séparation du préremplissage et du décodage est devenue la configuration par défaut à grande échelle : un groupe de machines se charge uniquement du préremplissage, génère un cache KV, puis le transfère via un réseau haut débit vers un groupe de machines dédié au décodage. Chaque partie choisit sa propre configuration parallèle et sa propre taille de lot, s'adaptant indépendamment en fonction du rapport entre les prompts longs et courts de la charge réelle.

À cela s’ajoute la mise en parallèle à grande échelle des experts pour le modèle MoE. Le MoE n’active qu’une petite partie des paramètres pour chaque token, mais si tous les experts sont répartis sur plusieurs GPU, le volume de lecture reste considérable. En répartissant les experts sur des dizaines de GPU reliés par des liaisons à très haut débit — du type des baies rack GB200/GB300 NVL72 —, chaque GPU n'héberge alors que quelques experts, ce qui réduit considérablement le volume de poids à lire pour chaque token et multiplie le débit par GPU par rapport à une exécution sur une seule machine.

Rubrique économique : les quatre chiffres qui se cachent derrière le prix de chaque jeton

Le coût d'un token, pour le dire sans détour, correspond au loyer horaire du GPU divisé par le nombre de tokens que ce GPU produit chaque heure. Le numérateur est déterminé par le marché du matériel et est sous pression ; toute la couche algorithmique située au-dessus n’a pour seule fonction que d’augmenter le dénominateur — tout en respectant l’engagement de latence, car un débit obtenu en faisant attendre les utilisateurs n’est pas commercialisable. Dans le secteur, on appelle cela le « goodput ». Les quatre leviers, classés par ordre de rentabilité :

• Taux de réussite du cache de préfixes — la solution la moins coûteuse et la plus négligée. Une instruction système stable, qui place les parties invariantes en tête, permet de réduire considérablement les coûts d’entrée sans modifier une seule ligne du modèle.
• Taille de lot efficace. Les lots volumineux répartissent uniformément le coût de lecture des poids, mais nécessitent davantage de cache KV alors que la mémoire HBM est limitée. Il convient de réduire la précision des clés-valeurs à FP8, ou de compresser les clés-valeurs via l’architecture ; ces deux approches permettent indirectement d’augmenter la taille de lot — c’est pourquoi la quantification des clés-valeurs relève de la catégorie des algorithmes de réduction de coût et non de celle de la compression de données.
• Nombre de tokens générés à chaque exécution. On peut supposer que ce nombre passera de un à deux ou trois.
• Quantité de poids à lire pour chaque jeton. Le MoE, combiné à des experts en largeur de champ, s’attaque directement à ce point — c’est le levier présentant la plus grande marge.

Il y a une conséquence à laquelle peu de gens prêtent attention : le modèle de déduction génère beaucoup plus de tokens en sortie qu’en entrée, ce qui déplace le centre de gravité des coûts du préremplissage vers le décodage. Cela signifie que tout ce qui est optimisé pour le décodage — bande passante, petites tables clé-valeur, inférence, MoE — prend soudainement une importance bien plus grande qu’il y a deux ans, tandis que l’optimisation du préremplissage perd de son importance. L’infrastructure de 2026 est en train d’être repensée autour de cette évolution.

Prévisions

• L'attention redevient la norme. D'ici fin 2026, la plupart des nouveaux modèles ouverts utiliseront une forme hybride entre une couche linéaire/clairsemée et une couche d'attention complète ; l'attention complète deviendra l'exception, réservée aux petits modèles ou aux contextes courts.
• Les modèles de pré-entraînement disparaîtront des profils de déploiement. Les têtes de prédiction à plusieurs tokens seront entraînées et fournies avec leurs poids intégrés au modèle, plutôt que d’être configurées manuellement par l’opérateur.
• L’unité de mesure des performances passe du GPU au rack. Le chiffre comparable sera le nombre de tokens par seconde par rack à un niveau de latence garanti — car la déphasage et le parallélisme à grande échelle n’ont de sens que lorsqu’ils sont calculés à l’échelle du cluster.
• Le cache devient un niveau de stockage à coût distinct. Cache préfixé hiérarchisé HBM → RAM → SSD, partagé entre plusieurs machines, avec un routage conscient du cache ; la tarification de l’API continue de se fragmenter en fonction de l’état du cache plutôt que d’un prix d’entrée unique.
• Une petite désillusion en matière de mesure. Plus les systèmes réduisent le nombre de jetons pour réaliser des économies, plus il est facile d’observer une controverse majeure concernant le fait que les scores sur des contextes de longue durée masquent les pertes réelles lors des tâches de récupération précises.

Point à retenir : au cours des deux dernières années, la majeure partie de la réduction des coûts liée à l’IA n’est pas due à de nouvelles puces, mais à une diminution du nombre d’accès à la mémoire par token. Tous les algorithmes cités ci-dessus — pagination, cache de préfixes, regroupement continu des lots, prédiction puis vérification, attention clairsemée et linéaire, séparation de phases, répartition des experts — sont autant de façons différentes d’exprimer cette même idée. Ceux qui comprennent que le goulot d’étranglement réside dans la bande passante et non dans le calcul parviennent à optimiser efficacement ; ceux qui ne le comprennent pas achètent davantage de GPU et continuent de payer le prix fort.