Combien de tokens par seconde ?

Trois seuils suffisent. En dessous de dix tokens par seconde, la lecture devient pénible et l'usage conversationnel s'effondre. Autour de trente, le texte arrive plus vite que vous ne le lisez. Au-delà, payer davantage n'améliore plus rien que vous puissiez percevoir — et c'est la raison pour laquelle notre calculateur cesse d'y accorder de la valeur.

D'où vient le chiffre

La génération est limitée par la bande passante mémoire, pas par la puissance de calcul. Pour produire chaque token, la machine relit l'intégralité des poids actifs du modèle. Le plafond théorique est donc une simple division : la bande passante divisée par le poids des paramètres actifs.

En pratique, les moteurs — llama.cpp, MLX, vLLM — n'atteignent pas ce plafond. Nous en retenons environ 72 %, ce que détaille notre méthode. Ce sont des ordres de grandeur dérivés d'une caractéristique constructeur, pas des relevés de banc d'essai, et nous le rappelons partout où ces chiffres apparaissent.

Ce que les seuils donnent en pratique

Les deux dernières lignes portent tout le raisonnement. Entre 70 et 282 tokens par seconde, il y a un facteur quatre et plusieurs milliers d'euros — et rigoureusement aucune différence pour quelqu'un qui lit les réponses.

Les cas où la vitesse compte quand même

Le seuil de trente vaut pour un usage conversationnel, où un humain lit la sortie. Trois situations le font sauter.

• Le traitement par lots. Résumer trois cents documents n'a pas de lecteur : le débit se convertit directement en temps d'attente total.
• Les modèles à raisonnement. Un modèle qui réfléchit avant de répondre produit des centaines de tokens que vous ne lirez jamais. À débit égal, la réponse utile arrive bien plus tard.
• Le traitement du contexte. Avant de générer, la machine doit lire ce que vous lui donnez. Sur un document de 30 000 tokens, cette phase se compte en secondes, et elle dépend de la puissance de calcul, pas seulement de la bande passante.

Ce que ça change à l'achat

La conséquence est simple et va à l'encontre du réflexe habituel : une fois passé trente tokens par seconde sur le modèle que vous visez, cessez de payer pour la vitesse et payez pour la mémoire. Les giga-octets supplémentaires ouvrent des modèles entiers ; les tokens par seconde supplémentaires n'ouvrent rien.

C'est exactement le raisonnement qui fait gagner la carte la moins chère dans notre comparatif 5060 Ti contre 5070.

Pourquoi la puissance de calcul ne sert presque à rien ici

C'est le contresens le plus répandu sur l'IA locale. On compare des cartes sur leur puissance brute alors que la génération de texte n'en consomme presque pas : produire un token demande peu d'opérations, mais impose de relire tous les poids actifs depuis la mémoire. Le processeur graphique passe l'essentiel de son temps à attendre la mémoire.

C'est aussi pourquoi une machine à mémoire unifiée large mais lente, comme un Mac, se comporte de façon si différente d'une carte dédiée : elle stocke davantage et lit moins vite. Les deux caractéristiques sont indépendantes, et il faut les regarder séparément.

Le temps avant le premier mot compte autant

Le débit ne décrit que la production. Avant elle, la machine doit lire ce que vous lui donnez — c'est la phase de traitement du contexte, et elle dépend cette fois de la puissance de calcul. Sur une question courte, elle est invisible. Sur un document de trente mille tokens, elle se compte en secondes, parfois en dizaines de secondes.

Cette phase explique un décalage fréquent entre les chiffres annoncés et le ressenti : deux machines au même débit peuvent donner une impression de réactivité très différente si l'une met dix secondes à lire votre document. C'est un poste que nous n'estimons pas sur le site, faute de pouvoir le faire honnêtement à partir d'une seule caractéristique constructeur.

Mesurer chez soi plutôt que nous croire

Nos chiffres sont des ordres de grandeur dérivés de la bande passante. Le seul relevé qui vaille est le vôtre, et il ne demande aucun outil : llama.cpp affiche en fin de génération le nombre de tokens produits et le temps écoulé, et Ollama fournit le même détail avec l'option `--verbose`.

Comparez ce relevé à notre estimation. Un écart important vers le bas signale presque toujours la même chose : une partie du modèle a débordé sur la mémoire système, parce que le contexte demandé dépasse ce que vous croyiez. Le cache KV est le premier endroit où regarder.

Le seuil se déplace selon ce que vous faites

Trente tokens par seconde correspond à quelqu'un qui lit les réponses au fil de l'eau. Si vous générez du code que vous relirez ensuite en bloc, le confort de lecture ne joue plus, et seul compte le temps total. Si vous dictez des tâches à un modèle qui raisonne longuement avant de répondre, la moitié du débit part dans un raisonnement que vous ne verrez pas.

Il n'y a donc pas un seuil mais une famille de seuils, et le bon réflexe consiste à estimer le nombre de tokens réellement produits par requête dans votre usage, plutôt qu'à comparer des débits dans l'absolu.

La quantification est aussi un réglage de vitesse

On présente la quantification comme un moyen de faire tenir un modèle en mémoire. Elle a un second effet, rarement mentionné : puisque la génération consiste à relire les poids, des poids plus légers se relisent plus vite. La vitesse est inversement proportionnelle au poids.

L'ordre de grandeur est net : passer de Q8_0 à Q4_K_M divise le poids par environ 1,7, et multiplie donc le débit d'à peu près autant. Sur un modèle qui plafonnait à quinze tokens par seconde, cette bascule seule le fait passer au-dessus du seuil de confort — sans changer de carte.

C'est le premier levier à essayer quand une configuration est trop lente, avant d'envisager un achat. Ce qu'il coûte en qualité est détaillé dans ce que vous perdez à quantifier.

En résumé

• Dix tokens par seconde est le plancher en dessous duquel l'usage devient pénible.
• Trente est le seuil au-delà duquel vous ne percevez plus rien en conversation.
• Le traitement par lots et les modèles à raisonnement font sauter ce plafond.
• Passé le seuil, payez la mémoire, pas la vitesse.