L'algorithme de détermination du prix de chaque token : dans les coulisses du moteur d'inférence 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, la planification, l’anticipation et la simplification des tâches.

Ce qui est surprenant en 2026, c'est que le prix de l'API continue de baisser alors que la mémoire et les GPU atteignent des prix record. 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 — le modèle lit 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 presque à 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, plus précisément, 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 constituent un moyen de réduire ce qui est en excès pour compenser ce qui fait défaut.

KV-cache : lorsqu'un modèle a besoin d'un petit système d'exploitation

Pour éviter de recalculer l’attention sur l’ensemble du contexte 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 fonctionne exactement comme un système d’exploitation résolvant le problème de 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 effectue l’allocation de manière progressive en fonction des besoins. Pas besoin de continuité, 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 segmentation 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écurrents 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 (RAM) du serveur et le SSD, et le routeur devra savoir sur quelle machine se trouve le cache afin d’acheminer la requête vers cette machine-là — 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 une seule exécution permet de partager le coût de la lecture des poids : une seule lecture suffit pour tout le 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 traité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 entremêlés aux étapes de décodage, sacrifiant légèrement le temps d’attente du 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 agir : 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 jetons en une seule exécution ne coûte pratiquement pas plus cher 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 analyser 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 dans la branche principale de vLLM, SGLang et TensorRT-LLM dès le début de l’année ; le nombre moyen de tokens traités se situe entre deux et trois par itération.

Mais il faut être franc sur ses limites : les avantages s'amenuisent à 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 prédiction excédentaire ; 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 relève de 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 cache KV 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’attention latente multi-têtes réduit considérablement la taille du cache sans perte notable de qualité.
• L’attention clairsemée est entraînée. 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 la génération précédente, cette sélection est entraînée avec le modèle lui-même, et non selon des règles fixes définies par l’utilisateur.
• C’est la combinaison avec l’attention linéaire — orientée qui est la plus surprenante. La plupart des couches sont remplacées par une forme de régression avec porte, chaque couche conservant un état de taille fixe au lieu d’un cache infiniment long, et une couche d’attention complète n’est insérée que toutes les quelques couches afin de préserver la précision de la mémorisation. 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’impact é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. Avec une grande partie de la couche constituée de régressions à é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 convient peut-être de préciser ceci : en supprimant des tokens pour faciliter la lecture, on court toujours le risque d’omettre justement un token important. Les tests de rétrospection précise dans des contextes longs restent le point sur lequel ces architectures sont le plus scrutées, et les méthodes de mesure actuelles ne font pas l’unanimité.

Séparation des tâches : préremplissage d'un bloc, décodage d'un bloc

Si deux phases nécessitent deux types de ressources opposées, 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 le 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 nombre de lectures reste très important. En répartissant les experts sur des dizaines de GPU reliés par des liaisons à très haut débit — du type des baies 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 jeton, pour le dire sans détour, correspond au loyer horaire d'un GPU divisé par le nombre de jetons que ce GPU produit chaque heure. Le numérateur est déterminé par le marché du matériel et est actuellement sous pression ; toute la couche algorithmique située au-dessus n’a pour seule fonction que d’augmenter le dénominateur — tout en maintenant l’engagement de latence, car un débit obtenu en faisant attendre les utilisateurs n’est pas commercialisable. Dans le secteur, on appelle cette mesure 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 mémoire cache KV alors que la mémoire HBM est limitée. Il convient de réduire la précision des clés-valeurs (KV) à FP8, ou de compresser les clés-valeurs via l’architecture ; ces deux approches permettent indirectement d’augmenter la taille des lots — c’est pourquoi la quantification des clés-valeurs (KV) 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 par exécution. On estime que ce nombre pourrait passer de un à deux ou trois.
• Quantité de poids à lire pour chaque token. Le MoE combiné à des experts en parallèle s’attaque directement à ce point — c’est le levier offrant le plus grand potentiel d’amélioration.

Il y a une conséquence à laquelle peu de gens prêtent attention : le modèle de raisonnement génère beaucoup plus de tokens en sortie qu’en entrée, ce qui signifie que le centre de gravité des coûts se déplace 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/éparse et une couche d’attention complète ; l’attention complète deviendra l’exception, réservée uniquement 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 passera du GPU au rack. Le chiffre de référence sera le nombre de tokens par seconde et 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 concernant les mesures. Plus les systèmes réduisent le nombre de jetons pour réaliser des économies, plus il y a de risques de voir surgir une controverse majeure sur le fait que les scores sur des contextes longs 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 présenté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 les calculs parviennent à optimiser efficacement ; ceux qui ne le comprennent pas achètent davantage de GPU et continuent de payer le prix fort.