Comprendre les LLM en local : modèles, quantization, RAM et coûts

Faire tourner un modèle de langage (LLM) sur sa propre machine n'est plus réservé aux laboratoires. Avec des outils comme Ollama, llama.cpp ou LM Studio, on télécharge un fichier, on tape une commande, et un assistant répond en quelques secondes — sans connexion, sans abonnement, sans envoyer la moindre donnée à un tiers. Mais derrière cette simplicité se cachent quelques notions clés : taille du modèle, quantization, RAM, vitesse. Les comprendre évite les déceptions (« pourquoi ça rame ? », « pourquoi ça dit n'importe quoi ? ») et permet de choisir le bon modèle pour sa machine. Ce guide fait le tour de la question, chiffres réalistes à l'appui.

LLM local vs API cloud : la différence concrète

Quand vous utilisez une API cloud (OpenAI, Anthropic, Google…), le modèle tourne sur des serveurs distants équipés de GPU haut de gamme. Vous envoyez votre texte (le prompt), il revient transformé. Vous payez à l'usage, généralement au token (un token ≈ 0,75 mot en anglais, un peu moins en français). Les modèles sont énormes (souvent des centaines de milliards de paramètres) et la qualité est au rendez-vous, mais vos données transitent par un tiers et vous dépendez d'une connexion et d'une facture.

En local, le modèle s'exécute sur votre propre matériel : processeur (CPU), carte graphique (GPU) et surtout mémoire. Avantages : confidentialité totale, pas de coût marginal par requête, fonctionnement hors-ligne, contrôle complet. Inconvénients : les modèles que l'on peut faire tourner chez soi sont bien plus petits que les modèles cloud de pointe, donc moins « intelligents », et la vitesse dépend entièrement de votre matériel.

L'enjeu du local tient en une phrase : faire entrer un modèle utile dans la mémoire dont on dispose, à une vitesse acceptable. Les deux leviers pour y parvenir sont la taille du modèle et la quantization.

Les tailles de modèles : que veut dire « 7B » ?

Le « B » signifie billions (milliards en anglais) de paramètres : ce sont les poids ajustés pendant l'entraînement, en quelque sorte le « savoir » et la « capacité de raisonnement » du modèle figés dans des nombres. Plus il y en a, plus le modèle est généralement capable — mais plus il est lourd.

Voici les ordres de grandeur courants et ce qu'ils impliquent :

1,5B à 3B : très légers, rapides même sur CPU. Bons pour de la complétion simple, du résumé court, de la classification, de l'autocomplétion de code. Raisonnement limité, hallucinations fréquentes sur les sujets pointus.
7B à 8B : le sweet spot du grand public. Polyvalents, corrects en conversation et en code basique, tournent confortablement sur un PC récent ou un Mac Apple Silicon. C'est la taille par défaut pour découvrir le local.
14B : sensiblement plus fins en raisonnement et en suivi d'instructions. Demandent une machine bien dotée en mémoire.
32B : qualité nettement supérieure, proche d'un usage « sérieux ». Réclament un GPU costaud ou beaucoup de RAM, et la vitesse chute sur CPU seul.
70B : le haut du panier accessible en local. Très bons, mais exigeants : sans GPU dédié de 24 à 48 Go (ou plusieurs), c'est lent. C'est la frontière au-delà de laquelle le cloud reprend l'avantage pour la plupart des particuliers.

Règle empirique : doubler la taille n'apporte pas un saut de qualité spectaculaire, mais double (au moins) les besoins en mémoire et en temps de calcul. Un bon 8B bien quantifié rend souvent plus de services qu'un 32B qui rame.

La quantization, expliquée simplement

À l'origine, chaque paramètre est stocké en fp16 (nombre à virgule flottante sur 16 bits, soit 2 octets). Un modèle 7B en fp16 occupe donc grosso modo 7 milliards × 2 octets ≈ 14 Go. C'est lourd.

La quantization consiste à représenter ces paramètres avec moins de bits : au lieu de 16 bits par poids, on en utilise 8, 5, 4, voire moins. On perd un peu de précision, mais on divise la taille (et les besoins en RAM) d'autant. L'astuce, c'est que les LLM tolèrent étonnamment bien cette compression : un modèle en Q4 reste très utilisable, alors qu'il pèse environ quatre fois moins que l'original fp16.

Les notations comme Q4_K_M ou Q5_K_M (format GGUF, celui d'Ollama et llama.cpp) indiquent le nombre de bits (4, 5, 8…) et la méthode (_K_M = quantization « K-quants » de taille moyenne, un bon compromis répandu).

Quant	Taille relative (vs fp16)	Qualité	Quand l'utiliser
fp16 / fp32	100 % (×1)	Référence, aucune perte	Recherche, fine-tuning, GPU avec mémoire à revendre
Q8_0	~50 %	Quasi indiscernable de fp16	Si la RAM suit : qualité maximale en pratique
Q5_K_M	~35 %	Très bonne, perte minime	Bon compromis quand Q8 ne rentre pas
Q4_K_M	~28-30 %	Bonne, légère dégradation	Le choix par défaut : meilleur rapport qualité/poids
Q3 / Q2	~20 % et moins	Dégradation nette, erreurs plus fréquentes	Dernier recours quand la mémoire est très limitée

En résumé : Q4_K_M est le réglage par défaut recommandé pour la plupart des usages locaux. On monte en Q5 ou Q8 si la mémoire le permet et qu'on veut le meilleur ; on descend en Q3/Q2 uniquement contraint et forcé.

Combien de RAM faut-il vraiment ?

La règle de calcul de base : taille du fichier modèle ≈ nombre de paramètres × bits par paramètre ÷ 8. Pour un 7B en Q4 (~4,5 bits effectifs par poids en moyenne avec les K-quants) :

7 milliards × 4,5 bits ÷ 8 ≈ ~4 Go de poids, auxquels s'ajoutent le contexte (la mémoire du KV-cache, qui grandit avec la longueur de conversation) et un peu d'overhead. D'où le fameux ~5 Go en pratique pour un 7B Q4.

Ces poids doivent tenir entièrement en mémoire — RAM système si vous tournez sur CPU, VRAM (mémoire de la carte graphique) si vous tournez sur GPU. Sur les Mac Apple Silicon, la mémoire est unifiée : RAM et VRAM ne font qu'un, ce qui les rend particulièrement à l'aise pour le local.

Ordres de grandeur réalistes, en Q4, à prévoir avec une marge pour le contexte et le système :

Modèle	Poids en Q4 (approx.)	RAM/VRAM confortable
3B	~2 Go	8 Go
7-8B	~4,5-5 Go	8-16 Go
14B	~8-9 Go	16 Go
32B	~18-20 Go	24-32 Go
70B	~40 Go	48 Go (ou multi-GPU)

Si le modèle ne tient pas en VRAM, llama.cpp peut « déborder » sur la RAM système (offloading partiel CPU/GPU), mais chaque couche traitée par le CPU ralentit fortement l'ensemble. La règle d'or : tout doit tenir dans la mémoire la plus rapide disponible.

Vitesse : CPU vs GPU, et pourquoi c'est lent sans GPU

La vitesse de génération se mesure en tokens par seconde (t/s). Pour donner un repère, une lecture confortable correspond à environ 5 à 10 t/s ; en dessous, on attend visiblement le texte.

Pourquoi le GPU change tout ? La génération de texte est massivement parallèle : à chaque token, le modèle effectue des milliards de multiplications matricielles. Un GPU possède des milliers de cœurs conçus exactement pour ça et une bande passante mémoire bien supérieure. Un CPU, avec ses quelques cœurs, traite ces opérations en file : il s'en sort, mais bien plus lentement. Concrètement, sur un même 7B Q4, un bon GPU peut être 10 à 30 fois plus rapide qu'un CPU récent.

Deux phases à distinguer :

Prompt processing (prefill) : la lecture initiale de votre prompt. Le modèle « ingère » tout le texte d'entrée d'un coup. Cette phase est gourmande en calcul mais parallélisable, donc rapide sur GPU. Sur CPU, un très long prompt peut imposer plusieurs secondes d'attente avant même que le premier mot de réponse n'apparaisse.
Génération (decoding) : la production token par token. Chaque nouveau token dépend du précédent, donc cette phase est intrinsèquement séquentielle et limitée surtout par la bande passante mémoire — d'où l'importance d'une RAM/VRAM rapide.

À retenir : sans GPU, le local reste possible et utile pour les petits modèles (3B, voire 7B en patientant), mais l'expérience « temps réel » suppose une carte graphique ou un Mac Apple Silicon à mémoire généreuse.

Coûts réels : local vs API

Le local n'est pas « gratuit », mais sa structure de coût est radicalement différente. Côté API cloud, on paie au token, séparément pour l'entrée et la sortie. Les tarifs varient énormément selon les fournisseurs et la taille du modèle — de l'ordre de quelques dizaines de centimes à plusieurs euros par million de tokens. Pour un usage léger et ponctuel, la facture reste dérisoire et il n'y a aucun investissement matériel.

Côté local, le coût est surtout fixe et amorti : l'achat du matériel (un GPU correct se chiffre en centaines à milliers d'euros) plus l'électricité. Un PC qui génère consomme pendant l'inférence, mais ramené au token, le coût électrique est généralement négligeable face au prix d'une API pour un usage intensif.

Quand le local est-il rentable ?

Volume élevé et régulier : si vous traitez des milliers de requêtes par jour, l'amortissement du matériel finit par battre la facture cloud.
Confidentialité non négociable : données médicales, juridiques, internes — ici le local gagne quel que soit le coût.
Usage hors-ligne ou edge : pas de réseau fiable, latence critique, déploiement embarqué.

Quand le cloud reste préférable :

Usage occasionnel : amortir un GPU pour quelques requêtes par semaine n'a aucun sens.
Besoin de la meilleure qualité : les modèles cloud de pointe surclassent ce qu'on fait tourner chez soi.
Pics de charge : le cloud absorbe l'élasticité que votre machine unique ne peut pas offrir.

Idées reçues

« Plus c'est gros, mieux c'est. » Faux en pratique : un 8B rapide et bien quantifié bat un 70B qui rame ou ne tient pas en mémoire. La taille utile dépend de votre matériel et de votre cas d'usage.
« La quantization casse le modèle. » Non : entre fp16 et Q8, la différence est quasi imperceptible ; Q4 reste excellent. C'est en dessous de Q4 que la dégradation devient visible.
« Il faut une grosse config pour commencer. » Faux : un 3B ou un 7B Q4 tourne sur la plupart des PC récents et des Mac. On démarre avec ce qu'on a.
« Le local, c'est gratuit. » Trompeur : pas de coût par requête, mais matériel et électricité bien réels.

Notre lecture

Pour débuter, le combo gagnant est un modèle 7-8B en Q4_K_M, sur une machine avec 16 Go de mémoire. C'est le meilleur rapport qualité/accessibilité, et cela suffit pour l'assistance au code, la rédaction, le résumé et la conversation courante. On ne monte en taille (14B, 32B) que si l'on a constaté une limite et que le matériel suit. Inutile de viser le 70B sans GPU dédié : la frustration est garantie.

La quantization n'est pas un compromis honteux mais un outil normal : Q4 par défaut, Q8 si la RAM le permet et que la qualité prime. Enfin, le choix local vs cloud n'est pas binaire — beaucoup d'usages mixtes ont du sens : local pour le quotidien confidentiel et volumineux, cloud pour les tâches exigeantes ponctuelles.

Pour aller plus loin

Ollama : le moyen le plus simple de tester (ollama run), gère le téléchargement et la quantization automatiquement.
llama.cpp : le moteur sous-jacent, pour qui veut régler finement l'offloading CPU/GPU et le format GGUF.
LM Studio : interface graphique pour explorer, télécharger et comparer les modèles sans ligne de commande.
Expérimentez la mesure : surveillez vos tokens/seconde et votre usage mémoire pour trouver le couple taille/quant idéal sur votre machine — c'est le seul vrai juge de paix.