Données · version originale (anglais) du 23 octobre 2026, traduite le 24 octobre 2026

Vitesse des LLM en local : nos estimations face à 52 vrais bancs d’essai

Chaque fiche machine du site affiche un nombre de jetons par seconde pour chaque modèle. Ce sont des estimations, pas nos propres essais : nous avons donc cherché 52 résultats publiés pour mesurer notre erreur. En bref : nous nous trompions beaucoup sur les modèles MoE.

Voici ce que nous avons trouvé, ce que nous avons changé et où nous restons imprécis.

Par l’équipe Best Local AI Rig · Mis à jour le 2026-10-24 · Prix et stocks vérifiés le 2026-10-24 (prix US en USD, ils changent chaque jour : confirmez sur la page du détaillant) · Notre méthode

26 % → 5 %écart médian, 43 essais ajustés

12 → 37des 43 essais à ±15 %

34 % → 10 %écart médian, 9 essais de contrôle

122 % → 24 %pire écart, essais ajustés

Pourquoi le simple calcul par la bande passante se trompe-t-il?

La règle habituelle pour les LLM en local est la suivante. Pour générer un jeton, la machine doit lire une fois chaque poids actif en mémoire : les jetons par seconde valent donc à peu près la bande passante mémoire divisée par la taille du modèle. C’est ce que nous utilisions : 0,6 × bande passante ÷ poids actifs, le 0,6 représentant le fait qu’on n’obtient jamais toute la bande passante de la fiche technique.

Pour les gros modèles denses, c’est le bon ordre de grandeur, et même un peu pessimiste. Llama 3.3 70B sur Strix Halo mesure 4,8 tok/s, et nous annoncions 3,6. Les versions récentes de llama.cpp atteignent plutôt 80 à 90 % de la bande passante maximale sur les grosses lectures, pas 60 %.

Le vrai problème vient des modèles à mélange d’experts (MoE). Un modèle comme gpt-oss-120b ne touche qu’environ 5B paramètres par jeton : la formule voit une lecture minuscule et prédit des vitesses énormes. Sur une RTX PRO 6000, elle prédisait 397 tok/s pour gpt-oss-120b. La mesure est de 196. Sur un M3 Ultra, gpt-oss-20b était prédit à 257 contre 116 mesurés : plus de 2 fois trop haut.

La formule oublie que chaque jeton a aussi un coût fixe qui ne dépend pas de la taille du modèle : lancement des noyaux GPU, attention et, pour les MoE, routage de chaque jeton vers ses experts. Quand la lecture des poids ne prend qu’une ou deux millisecondes, ce coût fixe pèse lourd. Un GPU plus rapide aide alors peu, car il n’accélère que la partie déjà petite.

Quelle est la nouvelle formule, en termes simples?

temps par jeton = poids actifs ÷ (efficacité × bande passante) + surcoût fixe
jetons/s = 1 ÷ temps par jeton

Il y a donc deux réglages par plateforme. L’efficacité est la part de la bande passante annoncée réellement obtenue sur les grosses lectures. Le surcoût est le coût fixe par jeton, avec une valeur pour les modèles denses et une plus grande pour les MoE. Nous avons ajusté les deux sur les essais ci-dessous. Pour chaque plateforme, nous avons choisi les valeurs qui minimisent l’erreur en logarithme : un écart de 20 % sur un essai lent compte autant qu’un écart de 20 % sur un essai rapide.

Plateforme	Efficacité de bande passante	Surcoût, dense	Surcoût, MoE	Essais ajustés
NVIDIA GeForce / RTX PRO (CUDA)	83 %	1,0 ms	2,5 ms	12
DGX Spark / GB10 (CUDA)	77 %	0,0 ms	3,4 ms	7
AMD Strix Halo (Vulkan / ROCm)	80 %	0,1 ms	5,1 ms	10
Apple M Pro / Max (Metal / MLX)	90 %	1,2 ms	5,3 ms	8
Apple M Ultra (Metal / MLX)	84 %	1,8 ms	6,5 ms	6

Quelques constats ressortent. Les cartes NVIDIA ont le plus petit surcoût MoE (2,5 ms) : c’est pourquoi elles gardent l’avantage sur les MoE à peu de paramètres actifs. Apple et Strix Halo paient environ le double, autour de 5 à 6 ms par jeton. Les puces M Ultra perdent aussi un peu d’efficacité face à un M Max à une seule puce, ce qui concorde avec l’observation courante : deux puces fusionnées ne doublent pas tout à fait la vitesse.

Quelle était la précision des estimations, avant et après?

Sur les 43 essais ajustés, l’écart médian est passé de 26 % à 5 %. 37 des 43 sont maintenant à ±15 %, contre 12 avant. Le pire écart est passé de 122 % à 24 %.

Ajuster sur des données puis se noter sur ces mêmes données flatte le résultat. Nous avons donc gardé 9 essais hors de l’ajustement et ne les avons vérifiés qu’après. Sur ceux-là, l’écart médian est passé de 34 % à 10 %, et 7 des 9 sont à ±15 % (l’ancienne formule : 0). Ce jeu de contrôle inclut les essais Ollama de Jeff Geerling avec un modèle 70B sur un Framework Desktop, un Dell GB10 et un M3 Ultra, ainsi que le résultat Strix Halo à l’origine de tout ceci : Qwen3.6 35B-A3B mesuré à 63 tok/s, là où nous annoncions 84,5 et annonçons maintenant 71,5.

Chaque ligne verticale relie l’ancienne estimation (anneau) à la nouvelle (point) pour le même essai. Survolez un point pour les détails.

Qu’est-ce qui a changé sur le site?

Voici comment les chiffres de quelques fiches machine ont bougé, en 4 bits. Les gros modèles denses ont augmenté d’environ un tiers. Les MoE à peu de paramètres actifs sur du matériel rapide ont nettement baissé.

Machine	Modèle	Ancienne est.	Nouvelle est.	Variation
NVIDIA GeForce RTX 5090 Founders Edition	Qwen3.6 35B-A3B	591	269	−55 %
PNY NVIDIA RTX PRO 6000 Blackwell	GPT-OSS 120B	397	231	−42 %
Mac Studio M5 Ultra	GPT-OSS 120B	266	109	−59 %
Mac Studio M5 Max	Qwen3.6 35B-A3B	203	116	−43 %
GMKtec EVO-X2	Qwen3.6 35B-A3B	84	72	−15 %
NVIDIA DGX Spark	GPT-OSS 120B	60	61	+2 %
GMKtec EVO-X2	Llama 3.3 70B	3,6	4,8	+33 %
PNY NVIDIA RTX PRO 6000 Blackwell	Llama 3.3 70B	25	34	+34 %

Où restons-nous imprécis?

Qwen3-Next / Coder-Next. Ces modèles à attention hybride tournent plus lentement que leurs 3B paramètres actifs ne le laissent penser. Sur Strix Halo, nous sommes encore environ 24 % trop hauts. Leurs couches d’attention font un travail supplémentaire que notre formule ne modélise pas.
RTX 5090 avec versions spéciales. llama.cpp propose une option CUDA graph (GGML_CUDA_GRAPH_OPT=1) qui réduit beaucoup le surcoût par jeton. Avec elle, la 5090 fait tourner les petits MoE 26 à 37 % plus vite que notre estimation. Nous modélisons les versions par défaut, celles que la plupart des gens utilisent.
Quelques gros MoE. Qwen3.5-122B sur DGX Spark (+20 %) et gpt-oss-120b sur M2 Ultra et RTX PRO 6000 (+18 à 19 %) restent un peu optimistes. Qwen3-Coder-30B en Q8 sur Spark est pessimiste de 18 %.
Les bancs d’essai se contredisent. Le même Qwen3 30B-A3B sur Strix Halo affiche 75 tok/s dans une source et 85 dans une autre. Cela représente environ ±10 % de bruit lié aux pilotes, aux versions et aux réglages : être plus précis que cela ne veut pas dire grand-chose.
Contexte court, un utilisateur. Tout ceci concerne la génération pour un utilisateur avec un contexte court et des moteurs de type llama.cpp. À 32K de contexte, comptez 20 à 40 % plus lent. Le décodage spéculatif, le MTP et le traitement par lots peuvent être plus rapides. Le traitement du prompt (prefill) est une autre histoire : il dépend du calcul, et NVIDIA y prend nettement l’avantage.
Pas de M1 Ultra. Il est arrivé bien en dessous de tout modèle fondé sur la bande passante, et nous ne le listons pas : nous l’avons donc écarté.

Les 52 essais

Chaque ligne renvoie à la source du chiffre. Les écarts à ±15 % sont en vert. Les lignes marquées contrôle n’ont pas servi à ajuster la formule. Cliquez sur un en-tête de colonne pour trier.

									Source
1	DGX Spark 273 Go/s	Qwen2.5-Coder 7B Q8_0 llama.cpp tg32	Dense	29,4	20,2	−31 %	26,0	−12 %	source
2	DGX Spark 273 Go/s	Gemma 3 4B Q4_0 llama.cpp tg32	Dense	81,0	64,9	−20 %	83,4	+3 %	source
3	DGX Spark 273 Go/s	gpt-oss-120b MXFP4 llama.cpp tg32	MoE	58,7	60,5	+3 %	61,4	+5 %	source
4	DGX Spark 273 Go/s	gpt-oss-20b MXFP4 llama.cpp tg32	MoE	83,4	85,6	+3 %	80,0	−4 %	source
5	DGX Spark 273 Go/s	Qwen3-Coder 30B-A3B Q8_0 llama.cpp tg32	MoE	61,1	46,7	−23 %	49,8	−18 %	source
6	DGX Spark 273 Go/s	GLM-4.7-Flash Q8_0 llama.cpp tg32	MoE	48,7	51,4	+6 %	53,9	+11 %	source
7	DGX Spark 273 Go/s	Qwen3.5-122B-A10B Q5_K_S llama.cpp tg128	MoE	23,0	23,8	+4 %	27,7	+20 %	source
8	Strix Halo 256 Go/s	Llama-2 7B Q4_0 llama.cpp Vulkan tg128	Dense	52,7	40,2	−24 %	53,4	+1 %	source
9	Strix Halo 256 Go/s	Qwen3 8B Q4_K_M llama.cpp Vulkan tg128	Dense	41,4	30,6	−26 %	40,7	−2 %	source
10	Strix Halo 256 Go/s	Mistral Small 24B Q4_K_M llama.cpp Vulkan tg128	Dense	14,3	10,7	−25 %	14,3	0 %	source
11	Strix Halo 256 Go/s	Llama 3.3 70B Q4_K_M llama.cpp Vulkan tg128	Dense	4,8	3,6	−25 %	4,8	0 %	source
12	Strix Halo 256 Go/s	Qwen3 30B-A3B Q4_K_M llama.cpp Vulkan tg128	MoE	85,5	76,8	−10 %	67,3	−21 %	source
13	Strix Halo 256 Go/s	Qwen3 30B-A3B UD-Q4_K_XL llama.cpp Vulkan tg128	MoE	75,3	76,8	+2 %	67,3	−11 %	source
14	Strix Halo 256 Go/s	Qwen3-Coder-Next 80B-A3B Q4_K_M llama.cpp Vulkan tg128	MoE	57,5	84,5	+47 %	71,5	+24 %	source
15	Strix Halo 256 Go/s	Llama 4 Scout UD-Q4_K_XL llama.cpp Vulkan tg128	MoE	20,2	14,9	−26 %	18,0	−11 %	source
16	Strix Halo 256 Go/s	gpt-oss-120b MXFP4 llama.cpp ROCm tg128	MoE	47,5	56,7	+19 %	54,6	+15 %	source
17	Strix Halo 256 Go/s	Qwen3 235B-A22B IQ3_XS llama.cpp Vulkan tg128	MoE	18,1	16,9	−6 %	20,2	+12 %	source
18	M5 Max 40c 614 Go/s	Llama-2 7B Q4_0 llama.cpp tg128	Dense	119,9	96,5	−19 %	123,4	+3 %	source
19	M5 Max 40c 614 Go/s	Llama-2 7B Q8_0 llama.cpp tg128	Dense	72,4	51,4	−29 %	70,6	−2 %	source
20	M5 Pro 307 Go/s	Llama-2 7B Q4_0 llama.cpp tg128	Dense	67,6	48,3	−29 %	66,6	−1 %	source
21	M5 Pro 307 Go/s	Llama-2 7B Q8_0 llama.cpp tg128	Dense	38,9	25,7	−34 %	36,9	−5 %	source
22	M5 Max 40c 614 Go/s	Qwen3.6-27B Q8_0 llama.cpp decode@128	Dense	18,0	12,9	−28 %	18,9	+5 %	source
23	M5 Max 40c 614 Go/s	Qwen3.6-35B-A3B Q8_0 llama.cpp decode@128	MoE	93,0	115,6	+24 %	90,3	−3 %	source
24	M5 Max 40c 614 Go/s	gpt-oss-120b MXFP4 llama.cpp 4K ctx	MoE	87,9	136,0	+55 %	98,0	+12 %	source
25	M4 Max 40c 546 Go/s	gpt-oss-20b MXFP4 llama.cpp tg128	MoE	117,8	171,3	+45 %	108,8	−8 %	source
26	M5 Ultra 1 228 Go/s	Llama-2 7B Q4_0 llama.cpp tg128	Dense	179,1	193,1	+8 %	181,8	+2 %	source
27	M5 Ultra 1 228 Go/s	Llama-2 7B Q8_0 llama.cpp tg128	Dense	119,0	102,9	−14 %	114,4	−4 %	source
28	M3 Ultra 80c 819 Go/s	Llama 3.3 70B 4-bit MLX (oMLX) 1K ctx	Dense	17,0	12,4	−27 %	16,8	−1 %	source
29	M3 Ultra 80c 819 Go/s	gpt-oss-20b MXFP4 llama.cpp tg128	MoE	115,5	256,9	+122 %	107,8	−7 %	source
30	M2 Ultra 76c 800 Go/s	gpt-oss-120b MXFP4 llama.cpp tg128	MoE	79,7	177,2	+122 %	95,0	+19 %	source
31	M2 Ultra 76c 800 Go/s	gpt-oss-20b MXFP4 llama.cpp tg128	MoE	116,1	251,0	+116 %	107,0	−8 %	source
32	RTX PRO 6000 1 792 Go/s	Llama-2 7B Q4_0 llama.cpp tg128	Dense	274,2	281,7	+3 %	280,4	+2 %	source
33	RTX PRO 6000 1 792 Go/s	Llama 3.3 70B Q4_K_M llama.cpp tg128	Dense	34,0	25,3	−26 %	33,8	−1 %	source
34	RTX PRO 6000 1 792 Go/s	gpt-oss-120b MXFP4 llama.cpp tg128	MoE	196,3	396,8	+102 %	231,4	+18 %	source
35	RTX PRO 6000 1 792 Go/s	gpt-oss-20b MXFP4 llama.cpp tg128	MoE	286,9	562,2	+96 %	264,1	−8 %	source
36	RTX 5090 1 792 Go/s	Llama-2 7B Q4_0 llama.cpp tg128	Dense	290,0	281,7	−3 %	280,4	−3 %	source
37	RTX 5090 1 792 Go/s	Qwen3.6-27B Q4_K_M llama.cpp tg128	Dense	77,1	64,0	−17 %	81,3	+5 %	source
38	RTX 5090 1 792 Go/s	Qwen3.6-35B-A3B UD-Q4_K_M llama.cpp tg128	MoE	271,0	591,2	+118 %	268,6	−1 %	source
39	RTX 5090 1 792 Go/s	gpt-oss-20b MXFP4 llama.cpp tg128	MoE	282,5	562,2	+99 %	264,1	−6 %	source
40	RTX 4090 1 008 Go/s	Llama-2 7B Q4_0 llama.cpp tg128	Dense	186,2	158,5	−15 %	179,8	−3 %	source
41	RTX 4090 1 008 Go/s	Qwen3 32B Q4_K_M llama.cpp tg128	Dense	42,0	30,4	−28 %	40,4	−4 %	source
42	RTX 4090 1 008 Go/s	gpt-oss-20b MXFP4 llama.cpp tg128	MoE	222,0	316,2	+42 %	208,9	−6 %	source
43	RTX 4090 1 008 Go/s	Qwen3 30B-A3B Q4_K_M llama.cpp tg128 (fusion off)	MoE	198,4	302,3	+52 %	204,4	+3 %	source
44	Strix Halo 256 Go/s	Qwen3.6 35B-A3B Q4_K_Mcontrôle Ollama/llama.cpp	MoE	63,0	84,5	+34 %	71,5	+14 %	source
45	M5 Ultra 1 200 Go/s	gpt-oss-120b MXFP4contrôle MLX short prompt (concurrency caveat)	MoE	99,0	265,7	+168 %	108,8	+10 %	source
46	M5 Max 40c 614 Go/s	gpt-oss-120b MXFP4contrôle MLX (oMLX) 1K ctx	MoE	92,8	136,0	+47 %	98,0	+6 %	source
47	RTX PRO 6000 1 792 Go/s	gpt-oss-120b MXFP4contrôle llama.cpp 4K ctx (newer build)	MoE	221,3	396,8	+79 %	231,4	+5 %	source
48	RTX 5090 1 792 Go/s	Qwen3 30B-A3B Q4_K_Mcontrôle llama.cpp + GGML_CUDA_GRAPH_OPT=1	MoE	352,1	537,4	+53 %	260,1	−26 %	source
49	RTX 5090 1 792 Go/s	gpt-oss-20b MXFP4contrôle llama.cpp + GGML_CUDA_GRAPH_OPT=1	MoE	419,1	562,2	+34 %	264,1	−37 %	source
50	Framework Desktop (Strix Halo) 256 Go/s	Llama 3.1 70B Q4_K_Mcontrôle Ollama (Geerling)	Dense	5,0	3,6	−27 %	4,8	−3 %	source
51	Dell Pro Max GB10 273 Go/s	Llama 3.1 70B Q4_K_Mcontrôle Ollama (Geerling)	Dense	4,7	3,9	−18 %	4,9	+5 %	source
52	M3 Ultra 512GB 819 Go/s	Llama 3.1 70B Q4_K_Mcontrôle Ollama (Geerling)	Dense	14,1	11,6	−18 %	15,7	+12 %	source

« Go actifs par jeton » = paramètres actifs × bits par poids ÷ 8. Pour les fichiers GGUF denses, nous avons déduit les bits par poids de la taille du fichier. Les lignes MoE utilisent les mêmes valeurs que le reste du site (Q4_K_M 4,85, Q8_0 8,5, MXFP4 4,25). Les essais M2 et M3 Ultra ont servi pour la classe Ultra, à leur propre bande passante. Un banc d’essai à ajouter, ou une erreur? Écrivez à hello@bestlocalairig.com. Méthode complète : notre méthode.

Voir les chiffres pour votre machine

Toutes les fiches machine utilisent maintenant la nouvelle formule. Choisissez une machine pour voir quels modèles ouverts rentrent et à quelle vitesse ils devraient tourner, ou consultez la page des modèles pour la mémoire nécessaire.

Comparer toutes les machines Modèles et mémoire nécessaire Recevoir le courriel hebdomadaire

Nous envoyons un court courriel par semaine avec les baisses de prix, les retours en stock et les nouveaux modèles ouverts (en anglais pour l’instant). Si nous refaisons cette vérification avec de nouveaux essais, c’est là qu’elle paraîtra en premier.