« Ce modèle tourne à 250 tokens par seconde ! » — on trouve ce chiffre dans presque chaque post de benchmark de la scène locale AI. Et il n'est presque jamais toute la vérité. Nous avons analysé les 300 recettes communautaires de notre base de données local AI pour montrer quels chiffres on peut croire, lesquels exigent du contexte — et comment mesurer proprement soi-même en cinq minutes.
Piège 1 : Decode, prefill et le « mean wall TPS »
La plus grosse erreur se produit à la lecture : les tok/s de decode (la vitesse à laquelle le texte apparaît pendant qu'il est écrit) et les tok/s de prefill (la vitesse de traitement du prompt) sont deux mondes différents. Une recette sur une RTX PRO 6000 a mesuré 14 842 tok/s de prefill — contre 207 tok/s de decode. Celui qui poste « 2 000 tok/s » a probablement attrapé le chiffre de traitement de prompt, qui se comporte de façon dramatiquement différente avec de longs contextes ou des prompts répétés (cache de préfixe !).
S'ajoute l'astuce du « mean wall TPS » : une recette rapporte 251,8 tok/s de mean wall TPS sur plusieurs streams. C'est du débit agrégé — aucun utilisateur seul ne voit jamais cette vitesse. En flux simple sur le même matériel, on obtient en réalité 40–60 tok/s. Les deux chiffres sont exacts. Un seul répond à votre question.
Piège 2 : Le montage du benchmark détermine le résultat
Deux recettes pour la même classe 35B-A3B sur deux RTX 5090 : 249,4 tok/s en quantification NVFP4, 251,8 tok/s en AutoRound INT4. Ça sonne identique ? Le second chiffre provient d'un prompt-essai de 800 mots, le premier de courtes requêtes structurées. Le prompt du benchmark décide du résultat :
- Prompts structurés courts (tableaux, comptage) : forte acceptation du drafter, chiffres artificiellement rapides
- Essai de 800 mots : vitesse réelle sans le bonus du drafter
- Les sempiternels tests « count to 300 » : des chiffres de démonstration qui n'existent jamais dans l'usage réel
Une recette sérieuse sépare donc code, prose et sortie structurée — chacun avec speculative decoding activé et désactivé. Celui qui ne cite qu'un chiffre sans dire ce qui a été mesuré a généralement choisi le plus flatteur.
Piège 3 : Quantification sans preuve de fidélité
2,05 bits par poids sonne comme « inutilisable », 8,49 bits comme « forcément mieux ». La réalité est plus subtile. Une recette EXL3 2 bits (GLM-5.3-Flash sur une seule DGX Spark) atteint 18,9 tok/s de decode avec un écart documenté par rapport à l'original (métrique KLD, accord top-1 de 78,8 %). Une recette EXL3 4 bits sur deux Sparks décode à 36,1 tok/s — deux fois plus rapide et mesurablement plus proche de l'original.
La règle : ce n'est pas le nombre de bits seul qui décide, c'est le nombre de bits plus la fidélité documentée. Une recette sans chiffre KLD/PPL est une affirmation, pas une mesure. Et : 2 bits peut suffire pour le chat mais casser mesurablement pour les agents de code — c'est pourquoi les recettes sérieuses séparent par cas d'usage.
Piège 4 : Chiffres vendeur vs. harnais standards
Les benchmarks des fournisseurs tournent souvent sur leurs propres scaffolds. Les mesures communautaires montrent régulièrement un écart de 15 à 20 points entre scaffold vendeur et harnais standard (Terminal-Bench, SWE-bench). Cela ne veut pas dire que les fournisseurs mentent — mais que leur dispositif de test est différent (plus clément). Pour un achat, les chiffres certifiés comptent ; pour un déploiement réel, les recettes communautaires.
L'auto-vérification en 5 minutes
Comment contrôler une recette avant de l'adopter :
- Quel chiffre, quel mode ? Decode ou prefill ? Flux simple ou agrégé ? Est-ce indiqué ?
- Quel prompt ? Essai en prose (réaliste) ou « count to 300 » (démonstration du drafter) ?
- Quelle quantification, quelle fidélité ? bpw plus KLD/PPL contre l'original documentés ?
- Quel logiciel ? Version du moteur indiquée ? Une simple mise à jour de vLLM peut déplacer 10 %.
- Mesurez vous-même : même prompt, mêmes réglages, trois exécutions, prenez la médiane. Votre machine, votre version, votre chiffre.
Quels chiffres peut-on croire ?
Les chiffres les plus honnêtes de notre base viennent des recettes qui séparent les trois dimensions : cas d'usage (prose/code/structuré), modes de fonctionnement (speculative decoding on/off) et exactitude (KLD contre l'original). Ces recettes ont les notes les plus longues et les chiffres les moins spectaculaires. C'est exactement cela, le marqueur de qualité.
Toutes les mesures citées dans cet article proviennent de la base de recettes publique de notre page Local AI — chaque recette renvoie au dépôt d'origine avec méthodologie et instructions de reproduction.
Questions fréquentes
Pourquoi deux recettes du même modèle sur le même matériel diffèrent-elles autant ? Parce que « le même matériel » est rarement le même matériel : limite de puissance (300 W contre 600 W sur une RTX 3090), lignes PCIe, version du moteur, type de cache KV et le prompt de benchmark lui-même déplacent le résultat par facteurs. Une recette sérieuse documente précisément ces paramètres — c'est pourquoi ils font partie de nos champs de données de recette.
Le speculative decoding est-il un chiffre truqué ? Non, mais c'est un autre mode de fonctionnement. Le speculative decoding (par exemple avec un modèle draft) délivre une sortie plus rapide à qualité égale — mais le taux d'acceptation dépend du prompt. Les sorties structurées en profitent massivement, la prose libre à peine. Les mesures sérieuses séparent les deux ; « un seul chiffre » est un signal d'alerte.
Que signifient KLD et l'accord top-1 pour les quantifications ? La KLD (divergence de Kullback-Leibler) mesure l'écart de distribution entre le modèle quantifié et l'original — plus elle est basse, plus le modèle est fidèle. L'accord top-1 indique à quelle fréquence les deux modèles choisissent le même token (78,8 % à 2 bits, plus de 94 % pour les bons packs 4 bits). Sans ce chiffre, une quantification est un pari à risques.
Les valeurs élevées de prefill me concernent-elles ? Beaucoup — si vous traitez de longs documents ou des prompts système répétés. Le prefill décide de l'attente jusqu'au premier token. Avec des prompts récurrents s'ajoute le cache de préfixe : la même préfixe de prompt n'est pas recalculée. Pour de courtes sessions de chat, le decode compte davantage ; pour le RAG et les agents, c'est souvent le prefill.
Pourquoi faire confiance aux recettes communautaires plutôt qu'aux benchmarks des fournisseurs ? Parce que les recettes communautaires sont reproductibles : dépôt, version du moteur, prompt, configuration matérielle — tout est ouvert. Les chiffres des fournisseurs sont des affirmations marketing avec un scaffold inconnu. Notre base de recettes relie chaque recette à son original pour que vous puissiez la vérifier sur votre propre machine.
Sources
- Local AI — Context Studios (base de recettes publique, 300 recettes)
- club3090 — Qwen3.6 35B-A3B NVFP4 sur 1× RTX 5090 (251,8 tok/s mean wall TPS)
- vcruz305 — GLM-5.3-Flash EXL3 K2 sur 1× DGX Spark (documentation de fidélité KLD)
- MiaAI-Lab — GLM-5.3-Flash EXL3 4bpw sur 2× DGX Sparks
- jpezzulli — Qwen3.8-Flash-Next NVFP4 SGLang sur 1× RTX PRO 6000 (prefill 14 842 tok/s)
- Regolo — DeepSeek V4 Flash vs Qwen3.8-Flash-Next vs GLM-5.3-Flash (discussion sur les scaffolds vendeurs)