La physique des jetons par seconde

La vitesse de génération de jetons n'a rien de mystérieux : pendant le décodage, chaque jeton exige de lire pour ainsi dire tous les poids actifs depuis la mémoire une fois. Cela rend le décodage limité par la bande passante mémoire, et cela signifie que vous pouvez prédire vos tok/s par division. Tout ce dont les gens débattent — quantification, MoE, délestage, traitement par lots — est cette formule avec différents chapeaux.

L'unique formule

jetons/sec ≈ bande passante mémoire effective ÷ octets de poids lus par jeton

RTX 4090, 8B Q4_K_M :
  1008 GB/s ÷ 4.9 GB ≈ 205 tok/s de plafond théorique
  observé : ~120–150 tok/s (frais généraux, attention, lectures KV)

Tableau de vérification pour un cas courant (8B en Q4_K_M, flux unique — chiffres d'ordre de grandeur, pas des specs ; mesurez les vôtres) :

Pourquoi l'écart entre plafond et réalité ? Frais de lancement de noyaux, travail d'attention croissant avec le contexte, et lectures du cache KV par-dessus les poids. La formule vous donne le plafond ; vous en réalisez typiquement 60–75% en flux unique.

Une carte, quatre modèles

La formule prédit aussi comment la taille du modèle s'échange contre la vitesse sur un matériel fixe. Plafond sur une carte ~1,000 GB/s, puis 60–75% réalisés (illustratif) :

Deux leçons s'en dégagent. Doubler les paramètres divise à peu près la vitesse par deux sur la même carte. Et un 32B sur une carte 24 GB reste assez rapide pour le chat — limité par la mémoire n'est pas désespéré. Ce duo explique pourquoi les cartes 24 GB et les quants 32B Q4 apparaissent sans cesse ensemble (voir paliers de GPU).

La quantification est une fonctionnalité de vitesse, pas juste une compression

Même formule, moins d'octets : un modèle 8B en fp16 lit ~16 GB par jeton ; en Q4_K_M il lit ~4.9 GB. Sur la même carte, Q4 tourne à peu près 3× la vitesse fp16 et tient là où fp16 ne tient pas. Voilà pourquoi les quants de classe Q4 sont la recommandation par défaut en local (voir quantification) — la perte de qualité est faible, et le gain de vitesse est structurel, pas accessoire.

Le contexte vous ralentit

À mesure que la conversation grandit, chaque nouveau jeton doit aussi lire le cache KV de chaque jeton antérieur — ces lectures passent à l'échelle de la longueur du contexte. Près d'un contexte vide, un 8B Q4 peut faire 140 tok/s sur une carte de classe 4090 ; au fond d'une session de 64k jetons, la même installation peut fléchir à la moitié ou au tiers. Les noyaux d'attention cessent aussi de rentrer dans des formes cache-friendly. Les charges long contexte sont là où flash attention et quantification KV se remboursent (voir cache KV et paramètres moteur).

Une confusion fréquente : « le modèle a ralenti au fil du chat » est habituellement la croissance du KV, pas la dégradation du serveur (voir cache KV).

MoE : rapide pour la capacité

Les modèles mixture-of-experts n'activent que quelques blocs experts par jeton, donc les octets lus par jeton suivent les paramètres actifs, pas les totaux. Un modèle 30B totaux/3B actifs en Q4 ne lit que quelques gigaoctets par jeton — il décode comme un petit modèle tout en portant les connaissances d'un grand. C'est tout l'attrait des familles MoE en local (voir familles de modèles) : vous payez la mémoire pour stocker les experts, mais la bande passante seulement pour ceux que vous utilisez.

Silhouette concrète à ce jour : la classe Qwen3-30B-A3B ne lit que ses ~3B paramètres actifs par jeton — connaissances de grand modèle à vitesse de petit, pour ~18 GB de VRAM en Q4.

Décodage spéculatif

Appairez un petit modèle draft à la grande cible : le draft propose k jetons à bas coût, la cible vérifie les k en une passe avant, les jetons acceptés sortent à la qualité de la cible. Sur des charges quasi gloutonnes — complétion de code, JSON, extraction à basse température — attendez 2–3× d'accélération du décodage. À haute température, le draft se trompe plus souvent et le gain rétrécit. llama.cpp expose cela via --model-draft et des options de longueur de draft ; les noms exacts dérivent entre versions, consultez --help.

Coûts : le draft doit partager le tokenizer de la cible, et les deux modèles siègent en mémoire.

Parallélisme : la réalité

Deux GPU ne vous donnent pas 2× un flux unique. Le parallélisme de tenseurs (vLLM -tp 2) découpe chaque couche entre cartes pour le débit, au prix de trafic d'interconnexion ; le découpage par défaut de llama.cpp est le pipeline (par couches), qui aide la capacité plus que la latence en flux unique. Attente réaliste pour un bon découpage bi-carte : 1.2–1.6× le flux unique, pas 2×. Si quelqu'un promet une montée linéaire par GPU, il vend quelque chose.

Ajouter des cartes fait quand même bien monter la capacité à l'échelle — c'est l'histoire serveur dans concurrence.

La falaise du délestage CPU

Quand des couches restent sur CPU, chaque passe avant de jeton saute à travers PCIe (~10–25 GB/s) vers la RAM système et retour. La boucle tourne à la vitesse de sa partie résidente la plus lente : un modèle avec 80% de couches sur GPU tourne bien plus près de la vitesse CPU que des « 80% de la vitesse GPU ». Si un modèle tient presque, descendez d'un pas de quant plutôt que de délester à moitié — voir paramètres moteur. Le signe révélateur du délestage partiel accidentel est 3–10 tok/s sur du matériel de classe GPU.

Le préremplissage est limité par le calcul : le TTFT est une autre mesure

Le traitement de votre prompt est parallèle entre jetons et limité par le calcul, pas la bande passante — une carte de classe 4090 peut préremplir un 8B Q4 à quelques milliers de tok/s. Donc un collage de 12k jetons coûte ~3–5 s avant le premier jeton de sortie, alors même que le décodage ensuite tourne à 140 tok/s. Temps jusqu'au premier jeton et tok/s en régime établi sont des chiffres différents mesurant des goulots différents ; quand vous lisez un benchmark, vérifiez lequel il montre.

Mesurez vous-même

Les chiffres sur les pages (celle-ci comprise) sont des plafonds et des fourchettes. Votre installation se mesure en deux minutes :

1. Générez ~200 jetons depuis un prompt court ; ignorez le tout premier run (chargement à froid).
2. Prenez le décodage en régime établi : jetons générés ÷ secondes après le premier jeton.
3. Notez séparément le temps jusqu'au premier jeton sur un long collage — c'est un goulot différent.

llama-server affiche les tok/s d'éval de prompt et d'éval par requête ; LM Studio montre les tok/s de décodage en direct ; nvidia-smi confirme que le GPU travaille vraiment pendant votre test.

Ressenti des vitesses

Les seuils sont étonnamment bas parce que la vitesse de lecture n'est que ~5–10 tok/s pour les humains — mais attendre une complétion à 5 tok/s est une misère. Ressentez-le vous-même : le simulateur rend la même réponse à différents débits de jetons, et une minute là-bas enseigne plus que n'importe quel tableau.

Sous ~2–3 tok/s, une interface en streaming paraît cassée plutôt que lente — les gens ferment l'onglet, traitez donc cela comme un plancher dur pour l'usage interactif.

Voir aussi : panorama du matériel · calcul de VRAM · paliers de GPU · paramètres moteur