Débit d'un LLM en tokens par seconde : les quatre conditions qui changent tout, mesurées sur seize machines

Un serveur d'IA se vend avec un chiffre, tant de tokens par seconde, et ce chiffre dépend autant du logiciel, du format du modèle et du nombre d'utilisateurs que de la machine elle-même. Voici, tableaux à l'appui et sources en main, comment lire ce chiffre et ce qu'il faut demander avant d'acheter.

Par QDNA · Publié le 30 août 2026 · Mis à jour le 7 septembre 2026 · 14 min de lecture

Mis à jour le 7 septembre 2026 : réécriture en langage courant avec un lexique en tête, huit tableaux sourcés (llama.cpp, LMSYS, livre blanc NVIDIA, Hugging Face, quinze sources de mesures du DGX Spark) en plus des quatre vidéos de la version d'origine ; le prix de la carte professionnelle reste le relevé idealo.fr du 2 septembre 2026.

Pour lire cet article : cinq mots à connaître

Un modèle de langage travaille par petits morceaux de mots appelés tokens, et tout ce qui suit se mesure en tokens par seconde ; voici les cinq notions dont les tableaux se servent, sans lesquelles un chiffre de débit ne dit rien.

• Token. Un morceau de mot, environ trois quarts d'un mot en français. Le modèle lit et écrit token par token.
• Lecture du texte fourni (les techniciens disent préremplissage ; « pp512 » dans les tableaux veut dire 512 tokens lus d'un coup). C'est rapide, parce que la machine traite tout le texte en parallèle.
• Écriture de la réponse (génération ; « tg128 » veut dire 128 tokens écrits un par un). C'est ce que l'utilisateur voit défiler, et c'est le chiffre qui compte. Pour chaque token écrit, la machine relit l'intégralité du modèle en mémoire : la vitesse dépend donc de la vitesse de la mémoire, pas du nombre de cœurs.
• Compression du modèle (quantification). Un modèle se stocke avec 16, 8 ou 4 bits par valeur ; les tableaux notent ces formats F16, Q8_0 et Q4_0, et d'autres noms existent (FP8, NVFP4, MXFP4). Moins de bits, fichier plus petit, relecture plus rapide, réponses parfois moins bonnes.
• Un seul utilisateur ou plusieurs. Un flux, c'est une personne qui attend sa réponse ; le débit agrégé additionne toutes les réponses écrites en même temps pour plusieurs personnes. Les deux chiffres n'ont rien à voir et sont souvent confondus.

Dernière notion : la vitesse maximale calculée, obtenue en divisant la bande passante de la mémoire (en gigaoctets par seconde) par la taille du fichier du modèle (en gigaoctets). C'est un plafond théorique, jamais atteint, et nos pages le nomment toujours calcul et jamais mesure.

Que vaut le même modèle sur seize machines ?

De 14 à 290 tokens par seconde en écriture de réponse, pour le même fichier de modèle et la même commande de test, soit un facteur vingt entre la puce M1 d'un Mac de 2020 et la carte graphique RTX 5090 de 2025.

Ces chiffres viennent des deux tableaux publics de llama.cpp, un logiciel libre très utilisé pour faire tourner des modèles en local, où des centaines de personnes mesurent le même fichier avec la même commande sur leur propre machine ; le tableau 1 les réunit, avec la bande passante mémoire annoncée par le constructeur quand une source officielle la donne.

Tableau 1. Le même modèle (Llama 2 7B, fichier compressé à 4 bits de 3,79 Go) testé avec la même commande sur seize machines. Sources : tableaux publics de llama.cpp, discussions 4167 et 15013, relus le 6 septembre 2026. Ce sont des mesures.

Trois choses se lisent dans ce tableau. Le DGX Spark de NVIDIA et le M4 Pro d'Apple ont la même bande passante mémoire et écrivent 57 et 51 tokens par seconde : l'écart de 12 % vient du logiciel et du pilote, pas de la mémoire. La carte de jeu RTX 5090 dépasse de 6 % la carte professionnelle RTX PRO 6000 à bande passante égale, ce qui dit ce que la carte professionnelle vend vraiment : 96 Go de mémoire, pas de la vitesse. Enfin, le H100, une puce de centre de données, n'écrit que 268 tokens par seconde sur ce petit modèle, moins qu'une carte de jeu : un fichier de 3,79 Go ne fait pas travailler une puce de cette taille, et un classement établi sur un petit modèle ne vaut pas pour un grand.

Peut-on prévoir la vitesse d'une machine à partir de sa fiche technique ?

On peut calculer un maximum, jamais la vitesse réelle : les machines mesurées atteignent entre 44 % et 83 % de leur maximum calculé, selon la puce.

Le calcul est simple. La machine relit tout le modèle à chaque token écrit ; si sa mémoire livre 273 gigaoctets par seconde et que le fichier pèse 3,79 gigaoctets, elle ne peut pas écrire plus de 72 tokens par seconde. C'est le cas du DGX Spark, qui en écrit 57 en réalité, soit 79 % du maximum. Notre article sur la lecture, l'écriture et la mémoire de travail d'un modèle détaille cette mécanique.

Tableau 2. Vitesse maximale calculée = bande passante de la mémoire divisée par 3,79 Go. La vitesse mesurée vient du tableau 1. Le maximum est un calcul, la part atteinte une comparaison.

La part qui manque s'explique : à chaque token, la machine passe aussi du temps à lancer ses calculs, à relire sa mémoire de travail et à coordonner ses unités. Cette part grandit avec la taille de la puce : les deux puces Ultra d'Apple, avec 76 et 80 cœurs graphiques, n'atteignent que 44 % à 45 % parce qu'un modèle de 7 milliards de paramètres ne suffit pas à les occuper, quand la petite puce M1 atteint 79 %. Un maximum calculé sert donc à repérer un chiffre impossible ou une installation mal réglée, pas à classer deux machines.

Que gagne-t-on à compresser le modèle ?

Une vitesse multipliée par 2,3 à 3,2 quand on passe de 16 à 4 bits, pour un fichier 3,6 fois plus petit, sur les six puces mesurées.

Le tableau 3 prend six puces Apple du même tableau llama.cpp et ne change que le format du fichier : non compressé (13,48 Go), compressé à 8 bits (7,16 Go) ou à 4 bits (3,79 Go), tailles lues sur le dépôt Hugging Face qui héberge ces fichiers.

Tableau 3. Même puce, même modèle, trois niveaux de compression ; vitesse d'écriture de la réponse en tokens par seconde (llama.cpp, discussion 4167). Mesures.

Le gain suit la taille du fichier sans l'égaler : le fichier est 3,6 fois plus petit, l'écriture va 2,3 à 3,2 fois plus vite, parce que la part fixe du temps par token ne rétrécit pas avec le modèle. Sur un modèle dix fois plus gros, Alex Ziskind observe la même chose : Llama 70B sur une même carte RTX PRO 6000 écrit 20 tokens par seconde en 8 bits et 60 en 4 bits. Ce gain se paie en qualité des réponses, qui ne se lit dans aucun tableau de vitesse et se vérifie sur vos propres tâches.

Le logiciel compte-t-il autant que la machine ?

Oui : une simple mise à jour du même logiciel gagne jusqu'à 33 % sur une même puce et un même fichier, et changer de logiciel en gagne 14 % à utilisateur unique.

Le tableau 4 suit une même puce M2 Ultra et un même fichier à travers quatre versions successives de llama.cpp, la première sans une optimisation appelée Flash Attention, les trois suivantes avec.

Tableau 4. Même puce (M2 Ultra à 76 cœurs), même fichier, quatre versions successives du même logiciel ; vitesse d'écriture en tokens par seconde (llama.cpp, discussion 4167). Mesures.

Entre la première et la dernière version, l'écriture en 4 bits passe de 94 à 125 tokens par seconde. La chaîne Tech-Practice mesure l'autre face du même phénomène en changeant de logiciel plutôt que de version : sur un même Mac à puce M5 Max et un même modèle Qwen3.6-35B-A3B en 4 bits, MLX écrit 98 tokens par seconde quand llama.cpp en écrit 86. Un chiffre de vitesse sans le nom du logiciel et sa version ne dit donc pas ce qu'il compare.

Que se passe-t-il quand le modèle ne tient plus en mémoire ?

La vitesse s'effondre, et même un modèle qui tient tout juste dans la mémoire peut rester inutilisable pour une seule personne, parce que la machine passe alors tout son temps à relire un modèle trop gros pour elle.

Alex Ziskind oppose deux cartes sur Llama 70B : la RTX 5090, avec ses 32 Go, ne loge pas le modèle et tombe à 1,8 token par seconde parce qu'une partie du modèle vit hors de la carte, quand la RTX PRO 6000, qui le loge entièrement, en écrit 7 ; quatre fois plus, pour un modèle que ni l'une ni l'autre ne sert confortablement.

Tenir en mémoire ne suffit pas non plus. LMSYS fait tenir Llama 3.1 70B en 8 bits dans les 128 Go du DGX Spark et mesure 2,7 tokens par seconde pour un seul utilisateur : 273 Go/s divisés par quelque 70 Go de modèle donnent un maximum calculé proche de 4, et la mesure en atteint 69 %. La machine ne déborde pas, elle est simplement trop lente pour ce modèle avec une personne, ce que LMSYS résume en réservant ces usages au prototypage.

La carte la plus chère est-elle la plus rapide ?

Non, pas sur un modèle qui tient dans les deux cartes, et deux sources indépendantes le montrent sur deux modèles différents.

Le tableau 5 reprend la revue LMSYS du DGX Spark, qui fait tourner GPT-OSS 20B avec le logiciel Ollama sur trois machines NVIDIA.

Tableau 5. Trois machines NVIDIA, tokens par seconde pour un seul utilisateur (LMSYS, revue du DGX Spark, 13 octobre 2025). Mesures.

La RTX PRO 6000 Blackwell, vendue plus de 12 000 € (idealo.fr, 2 septembre 2026), écrit 215 tokens par seconde contre 205 à la RTX 5090, et le tableau 1 renverse même l'ordre sur Llama 2 7B avec 274 contre 290. Alex Ziskind relève la même chose sur Gemma 3 4B : une RTX 5080 écrit 119 tokens par seconde, une RTX 5090 en écrit 239 et le serveur RTX PRO 6000 en écrit 233. Sur un modèle qui tient partout, c'est la bande passante mémoire qui décide, et les deux cartes Blackwell ont la même. La carte professionnelle reprend l'avantage dès que le modèle grossit, ce que la même série montre sur Gemma 3 12B, où l'on passe de 50 à 88 tokens par seconde. Acheter 96 Go pour servir un modèle de 4 milliards de paramètres, c'est payer une capacité qu'on n'utilise pas ; le DGX Spark, à 49,7 tokens par seconde sur le même modèle, paie de son côté sa mémoire lente.

Combien d'utilisateurs en même temps ?

Servir plusieurs personnes à la fois multiplie le total de tokens écrits par 3 à 20 sur une machine qui ne change pas : c'est le facteur le plus fort, et le plus souvent passé sous silence.

Le tableau 6 réunit cinq sources indépendantes sur le DGX Spark, seul ou en paire, d'abord avec un utilisateur, puis avec plusieurs.

Tableau 6. Un utilisateur, puis plusieurs : cinq sources indépendantes, tokens par seconde (relues les 2 et 6 septembre 2026). Mesures ; les gains sont calculés par QDNA.

Le gain dépend du modèle et du logiciel. Un modèle classique de 8 milliards de paramètres gagne un facteur 18 entre 1 et 32 requêtes, parce qu'écrire un token de plus pour une autre personne ne coûte presque rien en relecture du modèle. Un modèle « à experts » de 284 milliards de paramètres, qui n'active qu'une partie de lui-même à chaque token, gagne seulement un facteur 3 avec 12 requêtes, parce que chaque requête réveille des parties différentes. Le total à plusieurs sert à dimensionner un service partagé ; la vitesse pour une personne sert à juger le confort d'un utilisateur seul ; un chiffre qui ne dit pas lequel il est ne sert à rien.

Plus troublant encore, le classement entre machines s'inverse selon la longueur de la réponse demandée. Dans la vidéo d'Alex Ziskind, pour des réponses de 128 tokens le Spark domine, quand pour 1 024 tokens le Mac Studio repasse devant avec 396 tokens par seconde contre 386, si bien que deux articles honnêtes peuvent désigner deux vainqueurs opposés sans que ni l'un ni l'autre ne mente. L'auteur ne nommant pas précisément le modèle, nous en reprenons les rapports, pas les valeurs absolues.

Où trouver des mesures fiables du DGX Spark ?

Dans une quinzaine de sources publiques, dont cinq donnent la commande et les versions qui permettent de refaire la mesure ; sur un même modèle, leurs résultats vont du simple au quadruple.

Le DGX Spark est la machine la plus mesurée de sa catégorie, parce que ses 128 Go de mémoire partagée et sa bande passante modeste en font un cas d'école du maximum calculé ; le tableau 7 réunit les sources que nous avons relues, avec un exemple chacune, du billet officiel de NVIDIA aux dépôts d'utilisateurs.

Tableau 7. Quinze sources publiques de mesures sur le DGX Spark, avec un exemple chacune (lecture / écriture en tokens par seconde ; « → » sépare un utilisateur seul du total à plusieurs). Toutes relues sur leur page d'origine le 6 septembre 2026.

Trois familles se distinguent. Les sources reproductibles (discussion 16578 de llama.cpp, dépôt dgx-spark-field-notes, Kubesimplify, DandinPower, nabe2030, howtospark.com) donnent la commande, la version et la longueur des textes. Les revues du jour de lancement (ServeTheHome, StorageReview, Level1Techs, LMSYS) photographient un logiciel d'octobre 2025 qui a beaucoup progressé depuis. Le billet de NVIDIA donne les longueurs de texte mais aucune version de logiciel. Deux dépôts communautaires font d'ailleurs le même calcul de maximum que notre tableau 2 et trouvent la même part atteinte : DandinPower mesure 10,7 tokens par seconde sur Qwen3 32B pour un maximum de 15, nabe2030 mesure 64 % et 78 % du maximum sur deux modèles à experts.

Le tableau 8 montre ce que cette diversité fait à un seul modèle, gpt-oss 120B, le fichier le plus mesuré sur cette machine, pour un seul utilisateur.

Tableau 8. Le même modèle gpt-oss 120B sur un seul DGX Spark, pour un seul utilisateur : huit mesures de sept sources. Mesures des sources ; le classement est de QDNA.

Du simple au quadruple sur une machine et un modèle qui n'ont pas changé, et chaque écart a une cause lisible dans les conditions. ServeTheHome mesure avec Ollama sans aucun réglage le jour du lancement ; Level1Techs compte le temps d'attente avant le premier mot dans sa vitesse ; les deux mesures llama.cpp d'octobre 2025, à dix jours d'écart, passent de 42,0 à 55,4 tokens par seconde par la seule mise à jour du logiciel ; Dendro Logic pose une question de 1 500 tokens et StorageReview utilise un autre format de compression ; en août 2026, le même utilisateur mesure 42,1 avec Ollama et 60,7 avec vLLM sur la même question. Un chiffre de « vitesse du DGX Spark » sans ces conditions ne renseigne donc que sur la personne qui l'a produit.

Que demander avant de croire un chiffre ?

Six informations, sans lesquelles on ne peut pas savoir si l'écart annoncé vient de la machine ou d'un simple réglage ; les tableaux ci-dessus montrent que chacune déplace le chiffre d'au moins 10 %.

• Le modèle exact, avec sa taille en paramètres et le poids du fichier en gigaoctets.
• Le niveau de compression, en nommant le format (Q4_0, Q4_K_M, FP8, NVFP4, MXFP4), pas seulement le nombre de bits.
• Le logiciel et sa version, avec les options qui comptent.
• La longueur de la réponse, et celle du texte fourni si la lecture compte.
• Le nombre de personnes servies en même temps, et si le chiffre est un total ou la vitesse d'une seule.
• La nature du chiffre : une mesure avec sa procédure, ou un maximum calculé depuis la fiche technique.

C'est la discipline que nous appliquons à nos propres pages, où un maximum calculé est nommé calcul et une mesure publiée avec sa procédure. Nos pages de mesures ne portent que des couples réellement mesurés, les autres restant sans valeur affichée, et notre calculateur de mémoire distingue de la même façon ce qui est calculé de ce qui est mesuré.

Références

Les tableaux llama.cpp, la revue LMSYS, le livre blanc NVIDIA, le dépôt Hugging Face et les quinze sources du tableau 7 (liées dans le tableau lui-même) ont été relus le 6 septembre 2026 ; les trois vidéos et les trois mesures à plusieurs utilisateurs l'avaient été le 2 septembre 2026. Aucune valeur n'a été reproduite par QDNA ; les maximums, les parts et les gains sont des calculs de QDNA à partir de ces sources. Le prix de la RTX PRO 6000 Blackwell 96 Go est celui d'idealo.fr le 2 septembre 2026 (à partir de 12 483 € pour la Max-Q, 14 314 € pour la Server Edition).

• llama.cpp, discussion 4167 : mesures sur puces Apple, Llama 2 7B en 16, 8 et 4 bits
• llama.cpp, discussion 15013 : mesures sur cartes graphiques (CUDA), Llama 2 7B en 4 bits
• LMSYS, revue approfondie du DGX Spark, 13 octobre 2025 (SGLang et Ollama, 1 à 32 requêtes)
• NVIDIA, livre blanc de l'architecture RTX Blackwell : bandes passantes des RTX 5090, 5080, 5070 et 3090
• NVIDIA, fiche RTX PRO 6000 Blackwell Workstation Edition : 96 Go GDDR7, 1 792 Go/s
• Hugging Face, ggml-org/Llama-2-7B-GGUF : tailles des fichiers en 16, 8 et 4 bits
• Entrpi sur le forum développeurs NVIDIA, DeepSeek V4 Flash sur un DGX Spark, 1 à 12 requêtes
• Classmethod, DeepSeek V4 Flash 0731 sur deux DGX Spark, vLLM, 1 à 6 utilisateurs
• MiaAI-Lab, DeepSeek V4 Flash sur deux DGX Spark, DSpark, résultats du 14 août 2026
• Tech-Practice, MLX contre llama.cpp sur Qwen3.6-35B-A3B, Mac M5 Max
• Alex Ziskind, mesures sur serveur RTX PRO 6000 96 Go, plusieurs modèles et compressions
• Alex Ziskind, quatre machines comparées, llama.cpp puis vLLM avec de plus en plus d'utilisateurs