Fin août 2026, j'ai fait passer trois modèles ouverts sur la même carte, dans les mêmes conditions, avec le même moteur d'inférence : Gemma 4 26B, Qwen 3.8 27B et Qwen 3.6 35B. L'objectif n'était pas d'élire un vainqueur, c'était de savoir ce qu'une carte unique tient réellement quand plusieurs personnes s'en servent en même temps.
Cet article ne contient que des mesures de service : conversations simultanées, vitesse, attente, tenue sur gros dossiers. La théorie du prefill et du decode est déjà dans Pourquoi l'inférence LLM est memory-bound, je n'y reviens pas. La qualité des réponses n'est pas traitée ici : rien dans cet article ne prétend classer ces trois modèles sur ce qu'ils savent faire.
En bref, trois résultats qui vont chacun contre un réflexe courant :
- Le débit en tokens par seconde ne prédit pas le temps de traitement d'une tâche. Sur ce banc, il inverse même l'ordre entre les deux modèles rapides.
- La capacité mémoire ne prédit pas le nombre d'utilisateurs servis. La formule usuelle se trompe dans les deux sens sur le même modèle.
- Pour un usage documentaire, le facteur limitant observé est le coût du prefill, donc la taille du contexte injecté, et non le débit de génération.
Ce qui les résume : on ne benchmarke pas un modèle, on benchmarke un service.
Les conditions exactes
| Paramètre | Valeur |
|---|---|
| Carte | RTX PRO 6000 Blackwell, partition MIG de 48 Go |
| Conteneur | 13,6 vCPU, 94 Go de RAM |
| Moteur | vLLM 0.28.0 |
| Contexte servi | 131 072 tokens sur 262 144 natifs |
| Mémoire allouée | 97 %, cache KV en fp8 |
| Gemma 4 26B | RedHatAI/gemma-4-26B-A4B-it-NVFP4 |
| Qwen 3.8 27B | Qwen/Qwen3.8-27B-FP8 |
| Qwen 3.6 35B | Qwen/Qwen3.6-35B-A3B-FP8 |
Chaque modèle est servi avec les paramètres d'échantillonnage publiés par son propre éditeur, jamais avec une configuration uniforme, qui avantagerait mécaniquement ceux dont les valeurs par défaut se trouvent être les nôtres. Les tests de charge tournent sur la machine mesurée elle-même, pour que la latence du réseau ne s'ajoute pas aux temps relevés. La version du moteur et l'empreinte exacte de chaque modèle sont enregistrées avec les résultats, pour qu'une campagne conduite dans six mois soit comparable à celle-ci.
La vitesse par token ne dit pas le temps de réponse
| Gemma 4 26B | Qwen 3.8 27B | Qwen 3.6 35B | |
|---|---|---|---|
| Génération | 104,0 tok/s | 25,5 tok/s | 123,5 tok/s |
| Attente au premier mot | 0,09 s | 0,14 s | 0,11 s |
| Part de raisonnement | 80 % | 64 % | 84 % |
| Les 113 questions en | 38 min | 173 min | 46 min |
Les deux premières lignes sont des médianes sur ces 113 questions, en session isolée, un seul appel à la fois. La dernière donne le temps total mis par chaque modèle pour traiter la même série de 113 questions, de bout en bout.
La ligne « part de raisonnement » est la fraction des tokens produits que l'utilisateur ne voit jamais : le modèle réfléchit avant de répondre, et cette réflexion occupe la carte exactement comme le reste. De 64 à 84 % de ce que ces trois modèles produisent n'est jamais lu par personne.
D'où le résultat qui casse l'intuition. Qwen 3.6 génère 19 % de tokens en plus par seconde que Gemma, et met pourtant 21 % de temps en plus pour abattre le même travail. Il est plus rapide au token et plus lent à la tâche, parce qu'il raisonne davantage. Ce qu'attend un utilisateur, c'est une réponse, pas un débit.
Conséquence pratique : le chiffre en tokens par seconde, celui que tout le monde compare, ne suffit pas à choisir. Il faut le multiplier par le volume que le modèle produit pour une question donnée. Sur ce banc, cela inverse l'ordre entre les deux modèles rapides.
Le cas de Qwen 3.8 est différent et structurel : il active la totalité de ses 27 milliards de paramètres à chaque token produit, là où les deux autres n'en activent que 3 à 4 milliards sur un total plus grand. Le nombre de paramètres actifs explique l'essentiel de l'écart de coût par token, sans que le débit lui soit proportionnel pour autant : la quantification, les noyaux de calcul et le régime de charge y contribuent aussi. Ce qu'on peut affirmer est déjà suffisant pour décider : le facteur quatre observé n'est pas un réglage de vLLM à corriger.
Ce qui limite la concurrence n'est ni la mémoire ni le débit
Le banc ouvre 1, puis 2, 4, 8, 12, 16, 24 et 32 conversations en même temps. Un palier est retenu si chacun reçoit au moins 15 tokens par seconde, si l'attente avant le premier mot reste sous 2 s en chat et 5 s en documentaire pour 95 % des demandes, et si personne n'est mis en file d'attente.
Un chiffre de capacité ne veut rien dire sans le profil de charge qui l'a produit, alors le voici en entier.
| Élément du profil | Chat court | Documentaire |
|---|---|---|
| Prompt, premier tour | 120 à 320 tokens | 6 000 à 8 000 tokens |
| Plafond de génération | 500 tokens, saturé | 800 tokens, saturé |
| Requêtes par session | 3, enchaînées, sessions relâchées ensemble par une barrière à chaque ronde | |
| Départ des sessions | simultané, après une requête d'échauffement et 8 s de repos entre paliers | |
| Réflexion | active, réglages de l'éditeur ; elle compte dans les tokens générés | |
| Seuil de débit | 15 tok/s par session, jamais en agrégé | |
| TTFT | p95 par rang plafond, critère écarté sous 20 mesures, donc aux paliers 1, 2 et 4 | |
| « Mis en file d'attente » | préemption vLLM lue sur /metrics, tolérance zéro sur le palier | |
| Répétitions | une exécution par palier, aucun appel rejoué, aucun appel écarté | |
Deux garde-fous invalident un palier plutôt que d'en publier le chiffre : si la concurrence moyenne effective tombe sous 80 % du nominal, parce que les sessions les plus rapides ont fini et laissé les autres seules ; et si le banc lui-même sature ses vCPU, auquel cas il mesure sa boucle de lecture et l'attribue à la carte. Le pas entre 16 et 24 est large, assumé : une carte louée à l'heure ne se balaie pas au palier près.
| Gemma 4 26B | Qwen 3.8 27B | Qwen 3.6 35B | |
|---|---|---|---|
| Chat court | 32 et plus | 32 et plus | 32 et plus |
| Sur documents | 16 | 4 | 12 |
| Ce qui a lâché | attente 6,2 s à 24 | attente 8,6 s à 8 | attente 5,3 s à 16 |
| Réservoir de contexte (tokens) | 1 712 680 | 457 295 | 1 004 885 |
Le plafond testé était de 32 conversations, et les trois l'atteignent en chat court : leur limite réelle est au-delà, sans qu'on sache où. C'est l'usage documentaire qui les départage, et l'écart y va de 4 à 16.
Trois enseignements de dimensionnement sortent de ce tableau, et les trois vont contre les réflexes habituels.
Sur ce banc, ce n'est pas la mémoire qui limite. Au palier refusé, elle est occupée à 20 %. La formule usuelle, celle qui divise le réservoir de contexte disponible par la taille de contexte servie à chacun, annonçait 13 conversations pour Gemma. Elle se trompe dans les deux sens : trop basse en chat, où l'on dépasse 32, et trop haute en documentaire, où l'on s'arrête à 16. Ce n'est pas qu'elle soit fausse, c'est qu'elle répond à une autre question : elle donne une capacité de coexistence mémoire, pas une capacité de service. Les deux ne coïncident que par accident.
Ce n'est pas la vitesse d'écriture non plus, aux paliers mesurés. Au palier refusé, chaque personne reçoit encore 33 tokens par seconde, soit cinq fois la vitesse de lecture humaine. Personne n'aurait l'impression d'un système lent, et pourtant le palier est refusé : le critère de TTFT tombe bien avant celui de débit.
Le facteur limitant observé est le prefill. Ce qui casse, à chaque fois et sur les trois modèles, c'est l'attente avant le premier mot, donc le moment où la machine prend connaissance du dossier avant de répondre. Une réserve d'honnêteté sur ce point : ce TTFT sous charge additionne le prefill lui-même et l'attente d'admission dans le batch, et je n'ai pas séparé les deux. Ce que la mesure établit, c'est que le seuil franchi est celui du TTFT, pas celui du débit.
Le mur est à la taille du dossier injecté
Même constat en isolant complètement le prefill : attente avant le premier mot, avec un seul utilisateur sur la machine.
| Taille du dossier | Gemma 4 26B | Qwen 3.8 27B | Qwen 3.6 35B |
|---|---|---|---|
| 8 000 tokens | 0,53 s | 1,81 s | 0,67 s |
| 32 000 tokens | 2,71 s | 10,15 s | 3,77 s |
| 64 000 tokens | 7,45 s | 28,57 s | 10,34 s |
64 000 tokens représentent environ 200 pages. Avec 5 secondes comme seuil de confort, la limite pratique d'injection documentaire se situe entre 32 000 et 64 000 tokens, et c'est l'attente qui la fixe, pas la capacité du modèle à retrouver l'information dans le dossier. Même le plus rapide des trois dépasse le seuil à 64 000 tokens, avec un seul utilisateur, sur une machine vide.
C'est un point à trancher au moment de concevoir la recherche documentaire, pas après : le nombre de passages qu'on injecte dans le prompt est un paramètre de latence avant d'être un paramètre de pertinence.
Le cache de préfixe tient les conversations longues
Cinq échanges d'affilée sur le même sujet, comme le fait un salarié qui affine sa demande.
| Contexte tour 1 | Contexte tour 5 | Attente tour 1 | Attente tour 5 | |
|---|---|---|---|---|
| Gemma 4 26B | 967 | 4 385 | 0,10 s | 0,09 s |
| Qwen 3.8 27B | 948 | 9 463 | 0,21 s | 0,38 s |
| Qwen 3.6 35B | 948 | 5 211 | 0,11 s | 0,16 s |
Le contexte grossit à chaque tour, et l'attente ne suit pas cette progression : elle reste stable chez Gemma, et augmente bien plus lentement que le contexte chez les deux autres. Un contexte multiplié par près de cinq à TTFT constant n'est pas compatible avec un recalcul intégral à chaque tour. C'est le comportement attendu du cache de préfixe, et je le donne comme tel : je n'ai pas relevé le taux de succès du cache sur ces pods, seulement l'effet.
Avec une nuance qui coûte cher. Les conversations de Qwen 3.8 gonflent deux fois plus vite, parce qu'il conserve son raisonnement des tours précédents dans l'historique là où les deux autres ne renvoient que les réponses visibles. Le défaut se cumule au précédent : il consomme déjà quatre fois plus de mémoire par token, et ses conversations en consomment deux fois plus de tokens.
Ces chiffres servent aussi de référence pour une architecture à deux cartes, que je n'ai pas encore mesurée. Un répartiteur qui enverrait le deuxième tour d'une conversation sur la machine qui n'a pas calculé le premier lui ferait tout recommencer : l'écart se chiffrerait par rapport à ces 0,09 seconde, et il serait brutal.
La carte mesurée n'est pas celle qu'on croit
Le loueur ne proposait pas en cloud garanti la carte que je déploie. La mesure a donc été faite sur une RTX PRO 6000 Blackwell découpée en deux instances MIG de 48 Go. Chaque partition dispose de la moitié des ressources de la carte entière, et le relevé sur la machine le confirme : 94 SM sur les 188 de la carte complète. La bande passante, elle, est déduite et non mesurée, aucun outil ne la rapportant par partition : le profil 2g.48gb attribue la moitié des contrôleurs mémoire, soit environ 896 Go/s contre les 1 792 annoncés pour la carte entière. Le fonctionnement de ce découpage matériel est détaillé dans l'article de méthode.
Or la carte réellement déployée, une RTX PRO 5000 Blackwell, affiche 1 344 Go/s et 110 SM. La partition mesurée est donc plus lente d'un tiers en bande passante que la carte de production, mais seulement de 15 % en unités de calcul, alors qu'elle porte le nom d'une carte plus prestigieuse. « RTX PRO 6000 » sur la facture, la moitié d'une RTX PRO 6000 dans la machine, et moins vite qu'une RTX PRO 5000 dans les faits.
Trois conséquences, et il faut résister à la tentation de les résumer par un coefficient unique.
Les vitesses de génération relevées ci-dessus sont un plancher. Le décodage étant limité par la bande passante mémoire, une carte de production ferait environ une fois et demie mieux sur ce point. Un lecteur qui reproduirait ce banc sur une PRO 5000 obtiendrait de meilleurs chiffres, et c'est normal.
Ce facteur ne se transporte pas sur le prefill, donc pas sur les capacités en RAG. Le prefill est borné par le calcul, pas par la bande passante : l'écart pertinent y est de 110 SM contre 94, soit 17 %, et non 50 %. Comme c'est le TTFT qui décroche à chaque palier refusé du volet concurrence, appliquer le rapport des bandes passantes aux capacités simultanées reviendrait à créditer la carte de production d'un gain qu'elle n'obtiendra pas. Je ne publierai pas de capacité extrapolée : le banc sera rejoué sur la carte du catalogue.
Le rapport entre les modèles, lui, survit au changement de carte. En régime de décodage, le coût par token est dominé par le nombre de paramètres activés : le facteur quatre entre l'architecture dense et les architectures à experts se retrouvera sur une autre carte. C'est son ordre de grandeur qui se transporte, pas sa valeur exacte, qui dépend aussi de la quantification, des noyaux et du régime de charge.
Point vérifié au passage, parce qu'il conditionnait la validité de tous les chiffres ci-dessus : deux partitions MIG de la même carte physique ne se gênent pas. Un pod tournant à 32 conversations simultanées n'a fait varier la vitesse du pod voisin que de 0,5 %, ce qui est du bruit de mesure. Aucun de ces relevés n'est pollué par le locataire de l'autre moitié.
Ce que ces chiffres ne disent pas
Les capacités relevées sont des bornes hautes, jamais des capacités de déploiement. Elles sont mesurées sur une carte qui ne fait que servir le modèle. En production, la même carte porte aussi la recherche documentaire et son moteur de reclassement, et l'interface envoie plusieurs requêtes au modèle pour une seule question posée par un humain. Aucun de ces nombres ne doit partir en argument commercial sans cette réserve.
Le duel n'est pas parfaitement symétrique. Gemma est servi en 4 bits, les deux Qwen en 8 bits, faute de version officielle équivalente pour chacun. Le quantificateur de Gemma publie que son procédé coûte environ 7 % en code et 19 % en appel d'outil face à la version pleine précision : une part de l'écart mesuré ne vient donc pas des modèles eux-mêmes. Et Qwen 3.8 a tourné sans son accélérateur de génération, indisponible sur ces machines : sa vitesse est un plancher, pas sa valeur réelle.
Enfin, la comparaison qui manque le plus est absente. Ces trois modèles ont été comparés entre eux, pas à l'outil que les salariés utilisent aujourd'hui dans leur navigateur. C'est pourtant la seule comparaison que fera un utilisateur le premier jour.
Ce que je retiens pour dimensionner
Trois choses, dans l'ordre où elles servent.
D'abord, mesurer le temps de tâche et pas le débit. Un modèle qui raisonne beaucoup peut être le plus rapide au token et le plus lent à l'usage, et l'écart de 21 % relevé ici se paie en attente réelle.
Ensuite, dimensionner sur le prefill. Le nombre d'utilisateurs simultanés qu'une carte accepte ne se déduit ni de sa mémoire ni de son débit : il se déduit du volume de document injecté à chaque question. Un même modèle tient plus de 32 conversations en chat court et 4 seulement dès qu'on lui injecte des documents.
Enfin, se méfier du nom écrit sur la facture. La moitié du travail de cette campagne a consisté à vérifier ce que la machine louée contenait vraiment, et c'est le sujet de l'article compagnon sur les défauts de banc. Le montage de ces mesures pour des PME, c'est ce que je fais chez Sover.tech.
