Aller au contenu principal

Vitesse des tokens : pourquoi l'inférence IA est soudain 10 à 15× plus rapide

Intermédiaire

Cette semaine, OpenAI a présenté en avant-première GPT-5.6 Sol, un modèle de pointe servi sur du matériel wafer-scale Cerebras à jusqu'à 750 tokens de sortie par seconde — soit environ 5 à 10× les 70–150 tokens/seconde par utilisateur que les modèles de pointe servis sur GPU délivrent typiquement. Les titres ont parlé de magie. Il n'y en a aucune. C'est le fruit d'un déplacement de goulot d'étranglement qui se construit depuis deux ans, et presque personne en dehors de l'ingénierie de l'inférence n'en comprend le mécanisme. Cette leçon en est la version claire : ce qui limite réellement la vitesse des tokens, la course au matériel spécialisé qui vient de briser cette limite, les astuces logicielles qui la multiplient encore, et pourquoi des tokens rapides changent discrètement ce que les produits IA peuvent être.

What you'll learn
  • Expliquer pourquoi l’inférence LLM est limitée par la bande passante mémoire, et non par la puissance de calcul brute — et ce que cela signifie physiquement
  • Décrire comment les puces wafer-scale de Cerebras, les LPU de Groq et les RDU de SambaNova s’attaquent chacun au mur mémoire
  • Nommer les trois multiplicateurs logiciels — décodage spéculatif, quantification, batching — et le compromis que chacun implique
  • Prédire quels produits les tokens rapides transforment en premier : les agents, les modèles de raisonnement et la voix
  • Mesurer correctement la vitesse d’inférence pour votre propre charge de travail : tokens/s ET temps jusqu’au premier token, jamais un seul des deux

Le goulot d'étranglement auquel personne ne s'attend : la bande passante mémoire, pas le calcul​

Voici le fait qui réorganise tout le reste : pour générer un seul token, le modèle doit lire en mémoire la quasi-totalité de ses poids (actifs). Pas une partie d'entre eux — tous, une fois par token.

Un modèle de 70 milliards de paramètres en précision 16 bits représente environ 140 Go de poids. Générer un token : transférer 140 Go depuis la mémoire vers les unités de calcul. Générer le token suivant : transférer à nouveau les mêmes 140 Go. Le calcul matriciel lui-même est presque trivial en comparaison — les puces modernes ont de la puissance de calcul en réserve. C'est le tuyau entre la mémoire et le calcul qui sature.

Faites le calcul et l'expérience de l'« IA lente » s'explique d'elle-même. La bande passante mémoire HBM d'un NVIDIA H100 est d'environ 3,35 To/s. Divisez 3,35 To/s par 140 Go par token et vous obtenez un plafond dur d'environ 24 tokens par seconde pour un seul utilisateur sur un GPU, avant tout autre surcoût. Voilà pourquoi les chatbots écrivent à la vitesse de lecture : non pas parce que la puce ne sait pas multiplier assez vite, mais parce qu'elle ne peut pas lire son propre cerveau assez vite. Les ingénieurs de l'inférence appellent cela le mur mémoire, et Cerebras comme Groq le décrivent comme la contrainte fondamentale de l'IA générative.

Et cela s'aggrave : en plus des poids, chaque nouveau token lit aussi le cache KV — les clés et valeurs d'attention stockées pour chaque token déjà présent dans le contexte. Les contextes longs rendent chaque token suivant plus coûteux à produire.

Guided walkthrough1 of 4
  1. Le prompt entier est traité en une seule passe parallèle. Cette phase est limitée par le calcul (beaucoup de maths, les poids lus une fois pour de nombreux tokens à la fois) et détermine votre temps jusqu’au premier token.

Ainsi, la course à l'inférence rapide est en réalité une course pour déplacer plus vite les octets de poids. Il n'existe que deux façons de gagner : construire une mémoire radicalement plus rapide, ou réduire le nombre d'octets à déplacer. Les entreprises de matériel ont choisi la première voie. Les astuces logicielles (ci-dessous) ont choisi la seconde. L'explosion de vitesse actuelle, c'est les deux à la fois.

La course au matériel : mettre les poids SUR la puce​

La mémoire la plus rapide d'un ordinateur est la SRAM — la mémoire située sur le même die que le calcul. Elle est plusieurs ordres de grandeur plus rapide que la HBM empilée à côté d'un GPU, mais minuscule : des mégaoctets, pas des gigaoctets. Les trois entreprises d'inférence spécialisée ont toutes fait le même pari audacieux — rendre la mémoire embarquée assez grande (ou le nombre de puces assez élevé) pour contenir tout le modèle en SRAM — et chacune l'a conçu différemment.

Cerebras : une puce de la taille d'une assiette​

Cerebras construit le Wafer-Scale Engine (WSE-3) : au lieu de découper un wafer de silicium en centaines de petites puces, le wafer de 300 mm entier est une seule puce — 46 225 mm², 4 000 milliards de transistors, 900 000 cœurs, 44 Go de SRAM embarquée, et environ 21 pétaoctets/seconde de bande passante mémoire. Cerebras présente cela comme environ 7 000× la bande passante mémoire d'un H100, et c'est toute l'astuce : des poids qui vivent en SRAM ne traversent jamais un bus externe lent. Parmi les résultats publics : Llama 3.1-405B à 969 tokens/seconde avec un temps jusqu'au premier token de 240 ms et Llama 3.1 70B à plus de 2 100 tokens/seconde.

L'annonce GPT-5.6 Sol, décodée​

Voilà la machinerie derrière l'annonce de cette semaine. L'avant-première GPT-5.6 Sol d'OpenAI associe un modèle de pointe à un service Cerebras allant jusqu'à 750 tokens/seconde — contre les ~70 tokens/seconde que la même classe de modèle atteint par utilisateur sur un service GPU de classe H100, soit un bond de 10× (~15× face aux déploiements grand public les plus lents). Sol est lancé à 5 $ en entrée / 30 $ en sortie par million de tokens comme fleuron d'une famille de trois modèles (Sol, Terra, Luna), avec un accès anticipé limité à un petit ensemble d'organisations avant la disponibilité générale à la mi-juillet 2026. Des analystes de la communauté estiment que Sol est servi sur environ 70 à 100 wafers — approximativement une couche de transformer par wafer — même si OpenAI n'a pas confirmé la topologie, il faut donc traiter cette disposition comme une spéculation éclairée. Ce que cela signale dans tous les cas : pour la première fois, un modèle de classe frontière, et pas seulement un modèle à poids ouverts, est servi à la vitesse du matériel spécialisé.

Groq : des centaines de petites puces déterministes​

La LPU (Language Processing Unit) de Groq prend la forme inverse. Chaque LPU n'a aucune DRAM externe — seulement quelques centaines de mégaoctets de SRAM embarquée à ~80 To/s (contre 3,35 To/s pour le H100). Un grand modèle est réparti sur des centaines de puces : Llama 3 70B en FP8 s'étend sur un rack de plus de 300 LPU, chacune détenant une tranche d'environ 230 Mo. L'ingrédient magique, c'est le déterminisme : pas de caches, pas d'ordonnancement dynamique — le compilateur planifie l'exécution entière, y compris la communication entre puces, jusqu'au cycle d'horloge près, de sorte que rien n'attend jamais quoi que ce soit d'imprévisible. La formule de Groq est « le déterminisme, c'est la vitesse », et avec le décodage spéculatif ils ont montré Llama 3 70B à plus de 1 660 tokens/seconde.

SambaNova : trois niveaux de mémoire, des modèles géants​

La RDU (Reconfigurable Dataflow Unit) de SambaNova mélange les approches avec un système mémoire à trois niveaux (SRAM + HBM + DRAM), ce qui lui permet de servir efficacement les plus grands modèles : le DeepSeek-R1 complet à 671 milliards de paramètres à ~198–250 tokens/seconde sur seulement 16 puces SN40L — un modèle qui plafonne à 30–80 tokens/seconde sur un service GPU typique — et Llama 3 8B à 1 000 tokens/seconde, validé indépendamment par Artificial Analysis.

ApprocheIdée cléMémoire pour les poidsExemple de vitesse vérifiée
GPU (classe H100)Généraliste, priorité au débitHBM externe, ~3,35 To/s~70–150 tok/s par utilisateur, modèles de pointe
Cerebras WSE-3Le wafer entier = une puce44 Go de SRAM embarquée, ~21 Po/sLlama 3.1-405B à 969 tok/s ; GPT-5.6 Sol jusqu'à 750 tok/s
Groq LPUDataflow déterministe, ordonnancé par le compilateurSRAM uniquement (~230 Mo/puce), modèle réparti sur plus de 300 pucesLlama 3 70B à plus de 1 660 tok/s (avec décodage spéculatif)
SambaNova RDUDataflow reconfigurable, mémoire à 3 niveauxSRAM + HBM + DRAMDeepSeek-R1 671B à ~250 tok/s sur 16 puces
What you'll learn
  • Aucun de ces chiffres n’est de la puissance de calcul magique : chaque ligne de ce tableau est une réponse différente à la même question — comment transférer plus vite les octets de poids vers les unités de calcul ?
  • Les records de vitesse sont des vitesses par utilisateur (par session). Le débit total d’un datacenter est une métrique différente, sur laquelle les GPU restent excellents — c’est la distinction du compromis de batching ci-dessous.

Multiplicateurs logiciels : des tokens plus rapides sur N'IMPORTE QUEL matériel​

Le matériel n'est pas le seul levier. Trois techniques logicielles multiplient la vitesse aussi bien sur les GPU que sur les puces spécialisées — et elles expliquent en grande partie pourquoi même le service GPU ordinaire s'est accéléré cette année.

Le décodage spéculatif — le contre-intuitif. Un petit modèle brouillon, rapide, devine les quelques tokens suivants ; le grand modèle les vérifie ensuite tous en une seule passe avant. Vérifier N tokens de brouillon coûte à peu près le même transfert de poids que générer un seul token — donc quand les devinettes sont justes (et pour du texte prévisible elles le sont généralement), vous obtenez plusieurs tokens au prix mémoire d'un seul. Ce que peu de gens savent : la sortie est prouvablement identique à celle que le grand modèle aurait produite seul. Ce n'est pas une approximation — les mauvaises devinettes sont simplement rejetées et régénérées. C'est la technique derrière le chiffre de 1 660 tok/s de Groq, et tous les grands fournisseurs en utilisent désormais une variante.

La quantification — la directe. Si le goulot d'étranglement est le nombre d'octets déplacés par token, divisez les octets par deux : stockez les poids en 8 bits ou 4 bits au lieu de 16 bits, et la vitesse de décodage augmente presque proportionnellement parce que vous transférez littéralement la moitié (ou le quart) des données. Le compromis est un coût en précision généralement faible, mais parfois bien réel — mesurez sur votre tâche, pas au feeling.

Le batching — celui du compromis. Les GPU récupèrent de l'efficacité en servant de nombreux utilisateurs en une seule passe : les poids sont transférés une fois et réutilisés pour tout le lot, si bien que le débit total s'envole. Mais les tokens de chaque utilisateur individuel sortent toujours au rythme séquentiel partagé — de gros lots signifient un débit datacenter élevé et une vitesse par utilisateur médiocre. C'est le chiffre le plus mal interprété du marketing de l'inférence : un fournisseur qui annonce « des milliers de tokens par seconde » peut parler de débit agrégé, pas de ce que vous vivrez dans une session.

Pourquoi des tokens rapides changent tout​

La vitesse ressemble à un simple confort. C'est en réalité un seuil de capacité, car plusieurs catégories de produits ne fonctionnent qu'en dessous d'une certaine latence en temps réel.

Les agents obtiennent le plus gros multiplicateur. Une boucle d'agent est sérielle : appeler le modèle, exécuter un outil, réinjecter les résultats, recommencer — 20 appels de modèle à la suite est monnaie courante. À 70 tok/s, 20 appels de 800 tokens de sortie en moyenne représentent ~230 secondes de génération pure : une pause café, donc les agents se retrouvent relégués aux tâches d'arrière-plan. À 750 tok/s, la même boucle prend ~21 secondes : interactif. L'accélération se multiplie à chaque étape de la boucle, donc des tokens 10× plus rapides ne rendent pas un agent 10 % plus agréable — ils le font passer de l'outil batch au partenaire de conversation. (Vous construisez des agents ? Commencez par Choisir un modèle.)

Les modèles de raisonnement pensent davantage par seconde. La qualité d'un modèle de raisonnement croît avec le nombre de tokens de réflexion qu'il peut dépenser. Aux vitesses GPU, « effort élevé » signifie des minutes d'attente, alors les utilisateurs réduisent la réflexion. Aux vitesses wafer-scale, le même budget de réflexion se termine en quelques secondes — vous obtenez plus d'intelligence pour la même latence en temps réel, ce qui est sans doute le vrai enjeu stratégique de l'association OpenAI–Cerebras.

La voix devient véritablement temps réel. La conversation humaine tolère ~500 ms d'écart de réponse. Un service rapide avec un temps jusqu'au premier token inférieur à 300 ms (Cerebras a démontré 240 ms sur un modèle 405B), plus une génération bien au-dessus de la vitesse de parole, rend enfin possible un échange oral naturel — avec un modèle de pointe, pas un petit modèle distillé.

La dynamique des coûts devient intéressante. Rapide ne veut pas automatiquement dire bon marché : le service spécialisé se paie au prix fort (les 30 $/M de tokens de sortie de Sol sont dans le haut de gamme), et la vitesse qui ravit les utilisateurs permet aussi aux agents de brûler des tokens plus vite. Mais les fournisseurs wafer-scale soutiennent également que leur coût par token est inférieur à celui des GPU à grande échelle, alors attendez-vous à ce que les paliers de vitesse deviennent un axe de tarification standard, comme la livraison express. Le contexte budgétaire se trouve dans Ce que coûte l'IA chez les différents fournisseurs.

Comment évaluer la vitesse — pour VOTRE charge de travail​

L'erreur de benchmarking la plus courante : traiter les « tokens par seconde » comme toute l'histoire. Il y a deux chiffres, produits par deux goulots d'étranglement différents :

  • Temps jusqu'au premier token (TTFT) — combien de temps avant que la sortie commence. Dominé par la phase de prefill, limitée par le calcul, il croît donc avec la longueur de votre prompt. C'est ce que ressentent les utilisateurs de chat et de voix.
  • Tokens de sortie/seconde — à quelle vitesse le texte s'écoule une fois lancé. Dominé par la phase de décodage, limitée par la mémoire. C'est ce que ressentent les longues générations et les boucles d'agent.

Un fournisseur peut gagner sur l'un et perdre sur l'autre, car ils sollicitent des limites matérielles différentes. Une application RAG qui bourre des contextes de 50 000 tokens vit et meurt par le TTFT ; un agent qui écrit de longs fichiers de code vit et meurt par la vitesse de décodage. Des classements indépendants comme Artificial Analysis rapportent les deux — mais vos formes de prompts, vos longueurs de contexte et vos profils de trafic sont les vôtres, alors mesurez avec votre propre charge de travail. (Le streaming fait que la latence perçue ≈ TTFT plutôt que le temps total — voir Streaming.)

Guided walkthrough1 of 5
  1. Choisissez 10 à 20 prompts réels issus de votre produit — vrai prompt système, vraie longueur de contexte. La vitesse varie énormément selon la taille de l’entrée ; des prompts jouets produisent des chiffres jouets.

Une tâche de benchmark pour mesurer la vitesse de génération réelle

Write a complete Python module implementing a rate limiter with three strategies
(fixed window, sliding window, token bucket), a shared abstract base class,
type hints throughout, docstrings, and a pytest test suite covering edge cases
(burst traffic, clock skew, zero-capacity buckets). Target roughly 2,000 tokens
of output. Do not truncate or summarize - produce the full code.

--- How to use this prompt as a benchmark ---
1. Send it with streaming enabled and your production system prompt attached.
2. Record TTFT = time from request to first streamed chunk.
3. Record decode speed = output_tokens / (total_time - TTFT).
4. Repeat 5 times at 3 different times of day; report medians, not best runs.
5. Re-run the same prompt with 30K tokens of context pasted above it -
 watch what happens to TTFT. That difference is your prefill cost.

Vérifiez vos connaissances

0/5
  1. Quelle est aujourd’hui la principale limite physique à la vitesse de génération de tokens d’un LLM ?
  2. Comment l’approche wafer-scale de Cerebras contourne-t-elle le mur mémoire ?
  3. Quel est le piège du décodage spéculatif ?
  4. Un fournisseur annonce 3 000 tokens/seconde. Que devez-vous vérifier avant de supposer que vos utilisateurs verront cela ?
  5. Pourquoi des tokens plus rapides profitent-ils davantage aux agents qu’au simple chat ?
Vocabulaire de l'inférence rapide
Appuyez sur Entrée ou Espace pour retourner la carte. Utilisez les flèches gauche et droite pour naviguer entre les cartes.Terme affiché.
1 / 10
Key takeaways
  • La vitesse d’inférence est un problème de bande passante mémoire : chaque token exige de transférer tous les poids actifs, donc un modèle 70B en FP16 signifie ~140 Go de lectures par token — c’est tout le goulot d’étranglement.
  • La course au matériel spécialisé (SRAM wafer-scale de Cerebras, LPU déterministes sans DRAM de Groq, RDU à trois niveaux de SambaNova) franchit le mur en gardant les poids en mémoire embarquée — et GPT-5.6 Sol à 750 tok/s vient d’apporter cette vitesse à un modèle de pointe.
  • Le logiciel la multiplie encore : décodage spéculatif (sortie identique, vérification multi-tokens), quantification (moins d’octets par token), batching (débit en hausse, vitesse par utilisateur en baisse — lisez attentivement les annonces des fournisseurs).
  • Les tokens rapides sont un seuil de capacité, pas un confort : les boucles d’agent sérielles deviennent interactives, les modèles de raisonnement pensent davantage par seconde réelle, et la voix avec modèle de pointe passe en temps réel.
  • Évaluez avec deux chiffres — le TTFT (prefill, sensible à la longueur du prompt) et les tokens de sortie/s (décodage) — mesurés sur vos propres prompts, à votre propre concurrence, revérifiés chaque mois.

Vous découvrez le fonctionnement interne des modèles ? La section Fondamentaux couvre les tokens, les fenêtres de contexte et les bases des modèles sur lesquelles cette leçon s'appuie.

Sources et lectures complémentaires​