LLM quels chiffres ? Quel usage ?

0,3 token par seconde pour un LLM en local sur un Ryzen 6800H dans le UM680. 30 sur un MacBook M3 Pro. J’ai mesuré ces deux chiffres il y a quelques mois sans m’arrêter sur ce qu’ils disent. Ils ne disent pas « le Mac est cent fois plus puissant » : en calcul brut, AMD n’a rien à envier à la puce Apple. Ils disent que, pour écrire du texte, la puissance de calcul n’est pas ce qui compte.

En résumé : un LLM en local se joue d’abord sur la mémoire (est-ce que ça tient ?), puis sur sa bande passante (est-ce que ça écrit vite ?). Le calcul n’intervient que pour la lecture du prompt. Tout ce qui suit explique ce facteur cent, parce qu’il décide de ce qu’il faut acheter.

Faire tourner un LLM en local se résume à trois questions, et chacune a son chiffre. Est-ce que ça tient ? C’est la taille du modèle, plus celle du contexte. Est-ce que ça écrit à une vitesse supportable ? C’est la bande passante mémoire. Est-ce que ça démarre dans un délai acceptable quand on lui donne un long document ? C’est la puissance de calcul. Les fiches techniques mettent en avant le troisième chiffre. Les deux premiers décident presque tout.

L’arithmétique est simple et personne ne la fait. Un modèle, c’est un nombre de paramètres multiplié par la place accordée à chacun. En précision d’origine, deux octets par paramètre : 8 milliards de paramètres font 16 Go, et ça ne rentre pas dans une carte de 12 Go.

Quantifier, c’est rogner cette place. En 8 bits (le Q8, environ 8,5 bits en pratique) on tombe autour de 8,5 Go. En 4 bits, le Q4_K_M, on est entre 4,5 et 5 Go pour le même modèle. Le rapport de trois entre le début et la fin de ce paragraphe sépare « impossible » de « confortable ». Et globalement, la plupart des évaluations montrent qu’un Q4 est une poignée de % moins précis.

Pour estimer vite : fichier en Go ≈ milliards de paramètres × bits par poids ÷ 8. Un 14B en Q4 pèse 8 à 9 Go, un 32B autour de 19 Go, un 70B autour de 40 Go.

On aimerait croire que cette division par trois se paie cher en qualité. Beaucoup moins qu’on le craint en réalité. Entre la précision d’origine et le 8 bits, l’écart tient dans le bruit de mesure. Entre le 8 et un 4 bits bien fait, il existe mais reste discret, et c’est pour ça que tout l’écosystème s’est installé sur le Q4.

En dessous, en 3 puis 2 bits, la dégradation est insidieuse : le modèle reste fluide, poli, bien tourné, mais il se trompe avec aplomb sur le code et les enchaînements logiques. La quantification trop agressive ne produit pas un flou progressif, elle produit une assurance qui survit à la compétence. Et c’est pire.

À chaque token produit, le modèle relit ce qu’il a déjà en tête, et ce contexte doit vivre quelque part : c’est le cache d’attention (KV cache). Il grossit avec la longueur du contexte. Pour une architecture classique de la taille d’un Llama 3 8B (32 couches, 8 têtes de clés/valeurs, dimension 128, cache en FP16), il coûte 128 Ko par token. Ça donne environ 0,3 Go à 2 000 tokens, 1,1 Go à 8k, 4,3 Go à 32k et 17 Go à 128k. À 128k, le cache pèse alors plus de trois fois le modèle en Q4 qui l’accompagne.

Nuance importante : les modèles récents trichent intelligemment. Les architectures hybrides (seule une partie des couches garde un cache), à attention compressée ou à fenêtre glissante coûtent bien moins. LLM Sizer calcule par exemple environ 8,7 Go à 128k pour un Qwen 27B hybride dont 16 couches sur 64 gardent un cache, là où la formule classique donnerait plusieurs fois plus.

Deux conséquences. D’abord, la fenêtre de contexte « géante » se paie en mémoire, la même que celle des poids, mais le prix dépend de l’architecture, pas seulement de la taille du modèle. Ensuite, un modèle qui rentre pile à 2k tokens de contexte peut ne plus rentrer du tout à 32k. Il faut toujours lire la taille du cache au contexte que l’on compte vraiment utiliser.

Voilà ce que la fiche technique cache le mieux. Générer du texte n’est pas du calcul intensif, c’est de la relecture intensive. Pour produire un seul token, il faut faire passer tous les poids actifs de la mémoire vers le processeur. Un token, une lecture complète. D’où le plafond, qui se calcule de tête :

Prenons un modèle de 8B en Q4, soit environ 4,9 Go lus par token. Sur un M1 Pro à 200 Go/s, le plafond théorique est de 41 tokens par seconde. En DDR5-4800 double canal, environ 77 Go/s sur le papier, partagés avec tout le reste du système, le plafond tombe vers 15. C’est le bon ordre de grandeur de l’écart entre mes deux machines pour un modèle qui tient : un facteur deux à trois, pas cent.

Le plafond n’est jamais atteint. LLM Sizer, qui ajuste ses estimations sur des mesures réelles, ajoute à la lecture un coût fixe par token (lancement des noyaux, routage) de plusieurs millisecondes sur un M1 Pro, et un rendement de l’ordre de 90 à 95 % de la bande passante annoncée sur cette puce. Les fichiers K-quant (Q4_K_M) lisent en plus environ 25 % plus lentement que les formats simples sur Metal, selon l’hypothèse du site. Résultat pour le même modèle : environ 25 tokens par seconde sur M1 Pro, et non 41. C’est une estimation, pas une mesure, et le site le dit lui-même.

Alors d’où viennent mes 0,3 token par seconde ? D’un modèle qui ne tient pas. Quand les poids débordent de la mémoire, le système va les chercher sur le disque, à quelques Go/s au mieux. Ça ne ralentit pas, ça s’effondre : l’interface répond, le modèle est chargé, et on regarde les mots tomber un par un. C’est le vrai sens de « 8 Go de mémoire suffisent » dans la vidéo du youtubeur qui montre son Qwen local : ça charge, oui. Mais on a le temps de se faire un café entre chaque phrase.

L’iGPU 680M du 6800H fait quatre à cinq fois mieux que le CPU sur la même machine, mais il ne rattrape pas le M1 : il lit la même DDR5. Ce n’est pas de la puissance en plus qu’il faut, c’est un accès mémoire plus large.

Un chiffre sans seuil ne sert à rien. Voici ceux que j’applique, comme on parle de 30 images par seconde pour un jeu :

Pour la lecture, l’arithmétique est parlante : à 300 tokens par seconde, un document de 8 000 tokens se lit en 27 secondes, et un de 32 000 en environ 1 minute 45. En dessous de 100, le même document de 32 000 tokens fait attendre plus de 5 minutes avant le premier mot.

Mes seuils sont plus exigeants que ceux de LLM Sizer, qui classe 12 tokens par seconde comme « usable pour des réponses courtes » et 12 à 30 comme « chat confortable ». Pour un chat, ce n’est pas faux. Pour du code ou des agents qui enchaînent les appels, 30 est le bon repère.

Avant d’écrire, le modèle lit tout le prompt : consignes, document collé, conversation passée. Cette lecture (le prefill) n’a pas la même cause que l’écriture. Écrire est limité par la bande passante. Lire est limité par le calcul, donc par le nombre de cœurs GPU et la génération de la puce. Un modèle agréable en conversation courte peut devenir insupportable sur un long document, et l’inverse existe.

Exemple chiffré de LLM Sizer pour un 27B dense en Q4_K_M avec llama.cpp : environ 77 tok/s en lecture sur un Mac mini M4 Pro 16 cœurs GPU (8,6 minutes pour 32 000 tokens), environ 270 sur un M5 Pro 16 cœurs (2,4 minutes), environ 670 sur un M5 Max (1 minute). La génération M5 lit environ 3,5 fois plus vite par cœur que la M4, alors que son écriture progresse à peine, parce que la bande passante ne change presque pas. Choisir un M5 plutôt qu’un M4 est donc une décision de lecture, pas d’écriture.

À titre d’ordre de grandeur, la même formule donne de l’ordre de 200 tok/s en lecture pour un 8B sur un M1 Pro : sous mon seuil de 300. Dans une conversation, le runtime garde en mémoire ce qu’il a déjà lu, donc chaque tour n’attend que son texte nouveau. Le prix de lecture se paie d’un coup quand on colle une base de code ou un livre entier.

Cette logique explique des choix d’achat qui paraissent absurdes. Une RTX 3060 12 Go, lente et vieille sur le papier, rend de meilleurs services en local qu’une 5060 8 Go plus récente. Pas pour la bande passante : la 5060 est plus rapide à ce chapitre (environ 448 Go/s contre 360). C’est la capacité qui tranche : 12 Go permettent de loger un modèle ou un contexte que 8 Go refusent, et le calcul en plus de la 5060 ne sert à rien si le modèle ne rentre pas.

Une 3090 d’occasion reste la référence de ceux qui font tourner des modèles chez eux : 24 Go et près de 940 Go/s. Sur cet usage précis, la fiche technique de 2020 bat celle de 2026.

La colonne de droite est un plafond, pas une promesse, et la ligne de la 5060 est un piège : un plafond élevé sur un modèle qui ne rentre pas vaut zéro.

Les modèles « à experts » (MoE) n’activent qu’une fraction de leurs paramètres à chaque token. Pour eux, la mémoire dépend du nombre total de paramètres, et la vitesse du nombre de paramètres actifs. GPT-OSS 20B est l’exemple parlant : environ 21 milliards de paramètres occupent la mémoire, mais seuls 3 à 4 milliards sont relus à chaque token. Sans ce découpage, un M1 Pro 16 Go resterait spectateur.

Attention au côté mémoire : sur un Mac 16 Go, LLM Sizer ne laisse environ 11 Go à l’IA par défaut (macOS réserve 6 Go et plafonne la part du GPU). Un fichier de 12 à 13 Go passe donc au ras, souvent en relevant la limite GPU de macOS, et à condition de ne rien lancer d’autre. Autre précision : les MoE paient un coût fixe de routage par token, donc leur vitesse réelle reste sous le plafond théorique, parfois nettement.

Prenons un Mac avec 36 Go. En unités de fichiers (36 Go binaires font environ 38,7 Go décimaux), macOS autorise le GPU à en utiliser environ 78 %, soit autour de 30 Go si la machine ne fait rien d’autre. Dès qu’on garde un IDE et un navigateur ouverts, LLM Sizer réserve par défaut 16 Go pour les applications : il ne reste alors qu’environ 17 Go pour tout ce que le modèle consomme, poids, cache et tampons.

Ma règle pratique : un modèle de 15 à 18 Go, en limitant toute autre charge sur le système. Aller beaucoup plus loin oblige à sacrifier l’IDE, le navigateur ou le reste. Et ces 15 à 18 Go sont le fichier, pas le total : il faut ajouter le cache du contexte et environ 1,5 Go de tampons.

Dernier point sur Mac : les variantes MLX, le moteur d’Apple, peuvent être un peu plus rapides, mais pas partout. D’après les mesures de LLM Sizer, le gain porte sur le coût fixe par token et non sur la lecture des poids. Il est net sur les petits modèles à experts des puces M4 et suivantes (71 à 130 tok/s sur un M4 Max pour un MoE à 3 milliards actifs). Il est quasi nul sur un gros modèle dense, parce que c’est la bande passante qui limite. En lecture de prompt, MLX est environ 30 % plus rapide que llama.cpp sur M3 et plus récent, mais environ 20 % plus lent sur M1 et M2. Cela vaut pour un Mac M1 Pro : ne pas s’attendre à un miracle.

Le seuil raisonnable aujourd’hui, c’est 16 Go de mémoire réellement utilisable par le modèle. À 8 Go on tient un petit modèle en 4 bits avec un contexte de démonstration, et on quitte la zone de confort dès qu’on travaille pour de vrai. À 12 Go on respire, jusqu’à ce que le contexte reprenne ce qu’on venait de gagner. À 16 Go on loge un modèle de classe intermédiaire en Q4 avec un contexte qui sert à quelque chose : c’est le premier palier où l’on choisit un modèle pour ce qu’il fait et non pour ce qu’il pèse. « Réellement utilisable » compte : sur un Mac, retirez la réserve de macOS et celle de vos applications.

Au-delà, méfiance sur la promesse implicite. 24 Go ne donnent pas accès aux modèles de 70 milliards de paramètres : même en Q4 ils réclament 40 Go et plus. Les écraser en 2 bits pour les faire entrer, c’est payer une carte haut de gamme pour obtenir un modèle éclopé. Pour repère, LLM Sizer chiffre un 27B dense en Q4 à 16,8 Go de fichier, soit environ 20,7 Go avec 32k de contexte. La bonne question n’a jamais été « quel est le plus gros modèle que ma machine accepte ? », mais « quel est le plus gros modèle que ma machine fait tourner assez vite, avec le contexte dont j’ai besoin ? ».

Tout le monde demande quel modèle est le meilleur, et personne n’a la réponse. La question qui en a une : sur quelles tâches un modèle qui tient dans 16 Go est-il au niveau d’un service en ligne, et sur lesquelles décroche-t-il ? Mon hypothèse tient en une phrase : les modèles locaux sont bons pour transformer un texte qu’on leur fournit, et faibles dès qu’il faut savoir quelque chose qu’ils n’ont pas sous les yeux. Pour la tester, une tâche par famille, les mêmes données pour tous les modèles, et un critère de réussite fixé avant de lancer.

1. Transformation bornée : reformuler, corriger, changer de registre, traduire. L’entrée contient tout ce qu’il faut, et l’hypothèse est que les petits modèles se distinguent peu des gros. Évaluation rapide : relecture manuelle d’une vingtaine de sorties et comptage des passages à reprendre, comme on le faisait pour le résumé automatique il y a vingt ans.

2. Extraction structurée : un texte libre vers un JSON à schéma imposé. Le critère est binaire et automatisable : le JSON est-il valide, les champs sont-ils exacts, rien d’inventé, les vides respectés ? C’est la mesure la plus honnête, parce qu’elle ne dépend d’aucun jugement.

3. Connaissance factuelle : une question dont la réponse n’est pas dans le prompt. C’est là que le modèle local décroche, et où il se trompe avec le plus d’aplomb. La parade n’est pas un plus gros modèle mais de lui donner la source : recherche web ou documents fournis.

4. Code réel : pas un exercice de licence ni une landing page, mais une fonction à corriger dans un fichier existant au milieu d’une base de code, avec un test qui passe ou non, ou des tests à écrire. Le critère est automatique et ne se discute pas : le bug est-il corrigé, les tests passent-ils ? J’ai déjà exploré ce cas d’usage dans Claude Code gratuit avec son LLM local ?.

5. Appels d’outils : appeler une fonction avec les bons arguments et savoir quand s’arrêter. C’est là que les petits modèles s’effondrent le plus vite, et c’est mesurable : taux d’appels bien formés, taux de boucles infinies. Mon montage Open WebUI + SearXNG est le banc d’essai idéal : quel modèle sait réellement lancer la recherche, parser le retour et en faire une synthèse ?

6. Contexte long : une information plantée au milieu d’un long document, une question sur le premier tiers de la conversation. Il faut faire varier la position de l’information, pas seulement la longueur : beaucoup de modèles retrouvent le début et la fin et perdent le milieu. Test piège : « mais alors, ce que tu m’as dit tout à l’heure était complètement faux », en citant un point du milieu de la conversation, et regarder si le modèle plie ou tient.

Rien de tout ça ne dit si le modèle est utilisable. Il faut ajouter les deux vitesses, qui n’ont pas la même cause : le délai avant le premier token (prompt et puissance de calcul) et les tokens par seconde ensuite (bande passante). Il faut noter les deux, à plusieurs longueurs de contexte, et les comparer à des seuils d’acceptabilité : 30 tok/s en écriture, 300 en lecture.

Ne pas se fier au ressenti : on pose trois questions, le modèle répond vite et bien, on conclut qu’il est bon. Les sorties sont fluides, bien tournées, et la fluidité n’est pas la justesse. Un protocole honnête consiste à fixer d’abord le jeu de données et le critère, puis à tout lancer avec une température basse, sur une vingtaine d’échantillons par tâche.

Dans l’ordre :

1. Mémoire réellement disponible (moins la réserve système et les applications ouvertes) ≥ fichier du modèle + cache au contexte voulu + environ 10 % de marge.

2. Bande passante ÷ Go lus par token (poids actifs + cache), en retirant environ un tiers au plafond pour obtenir un chiffre réaliste. Objectif : 30 tok/s minimum, 60 pour la sensation cloud.

3. Calcul (cœurs GPU, génération de la puce) : 300 tok/s minimum en lecture pour digérer un long prompt.

4. Quantification : Q4 par défaut, Q8 si on a de la marge, jamais en dessous de 3 bits pour du code ou du raisonnement.

5. Dense ou MoE : le MoE gagne en vitesse mais pas en mémoire.

6. Sur Mac : essayer la variante MLX du modèle, surtout sur M3 et plus récent.

On nous vendra encore longtemps des NPU, des TOPS et des téraflops, parce que ces chiffres montent comme on aime les montrer. Ce qui compte ici figure rarement ailleurs qu’à la ligne « bande passante mémoire », tout en bas du tableau, en petits caractères. La mémoire dit si le modèle tient. La bande passante dit si l’on pourra s’en servir. Le calcul dit combien de temps on attendra avant le premier mot.