« Combien de VRAM me faut-il pour faire tourner de l’IA en local ? » est la première question que se pose tout pleb avant d’acheter un GPU — et c’est la question à laquelle chaque fiche technique refuse de répondre clairement. La réponse honnête, c’est que vous pouvez le calculer vous-même avec une seule ligne d’arithmétique, sans marketing. Une fois que vous comprenez les trois choses qui consomment de la VRAM — les weights du model, la fenêtre de context, et un peu de surcoût d’exécution — vous pouvez dimensionner n’importe quel rig en moins d’une minute et arrêter de surpayer du matériel que vous ne saturerez jamais. C’est le compagnon de dimensionnement matériel de notre guide sur GGUF, Q4, Q8 et la quantization fp16 : cet article explique ce que les libellés de quant signifient ; celui-ci vous dit exactement combien de VRAM chaque choix coûte et quel débit de tokens/sec vous devez attendre à l’exécution.
Si vous préférez posséder votre inference en propre plutôt que de la louer à un cloud qui journalise chaque prompt, c’est le même instinct qui anime la self-custody du Bitcoin. Posséder son compute, c’est une couche de plus de décentralisation — et tout commence par savoir quoi acheter.
La seule formule VRAM dont vous avez vraiment besoin
Un LLM est un tas de nombres appelés paramètres. Pour exécuter l’inference, chacun de ces nombres doit résider dans une mémoire accessible au GPU — c’est la VRAM. La taille du model en mémoire n’est que le nombre de paramètres multiplié par le nombre d’octets utilisés pour stocker chaque paramètre. Ce second nombre est entièrement fixé par votre niveau de quantization.
Voici les octets par paramètre avec lesquels vous travaillez :
- fp16 / bf16 — 2 octets par paramètre (la base « pleine qualité » pour l’inference)
- Q8 (8-bit) — environ 1 octet par paramètre
- Q4 (4-bit) — environ 0.5 octet par paramètre
Donc le calcul pour les weights seuls est d’une simplicité totale :
VRAM pour les weights ≈ paramètres × octets-par-paramètre
Un model à 7 milliards de paramètres en Q4, c’est 7,000,000,000 × 0.5 octet ≈ 3.5 GB. Le même 7B en fp16 fait 7B × 2 ≈ 14 GB. Un model 70B en fp16, c’est un brutal 140 GB — territoire de centre de données — mais quantifié en Q4, il tombe à environ 35 GB, ce qui tient sur une paire de 3090 d’occasion. Même model, presque le même comportement, les trois quarts de l’empreinte jetés. C’est toute la raison d’être de la quantization, et c’est pourquoi votre décision d’achat de GPU est en réalité une décision de quantization déguisée.
Une petite règle empirique utile : le « B » dans le nom d’un model est à peu près sa taille Q8 en GB, parce que Q8 c’est environ un octet par paramètre. Un model 8B fait ~8 GB en Q8, ~4 GB en Q4, ~16 GB en fp16. Une fois que vous avez intégré ça, vous pouvez estimer n’importe quel model d’un coup d’œil.
Les weights ne sont pas toute la facture : context et surcoût
Si vous dimensionnez votre GPU pour les weights seuls, vous obtiendrez une erreur out-of-memory dès que vous collerez un long document. Deux autres éléments réclament de la VRAM à l’exécution.
Le cache KV (votre fenêtre de context)
Chaque token que le model lit ou écrit est stocké dans une structure appelée le cache KV. Plus votre fenêtre de context est longue — le prompt plus la conversation jusqu’ici — plus le cache consomme de VRAM, et elle croît à peu près linéairement avec le nombre de tokens. Une courte conversation ne coûte presque rien. Un context de 32k tokens (un long document, une grosse base de code, une conversation interminable) peut ajouter plusieurs gigaoctets en plus des weights, en fonction de la taille du model comme du nombre de tokens. C’est la partie du budget que les gens oublient, et c’est la cause n°1 du redouté plantage OOM — que nous traitons en profondeur dans notre guide de dépannage de l’IA self-hosted.
Surcoût d’exécution
Le moteur d’inference, le context CUDA et les tampons d’activation prennent aussi leur part. En marge de travail, prévoyez environ 15–20 % en plus des weights plus le context, puis arrondissez au palier de GPU qui couvre le total. La marge, c’est de la performance gratuite : un model qui rentre tout juste débordera en RAM système et rampera ; un model avec de l’air tourne à pleine vitesse.
Aide-mémoire de dimensionnement VRAM
En rassemblant l’arithmétique, voici le tableau de référence pratique. Le « total » suppose une fenêtre de context modeste plus le surcoût — augmentez-le si vous utilisez des contexts très longs.
| Taille du model | weights Q4 | weights Q8 | weights fp16 | GPU confortable (Q4) |
|---|---|---|---|---|
| 3B | ~1.5 GB | ~3 GB | ~6 GB | carte 6–8 GB / iGPU |
| 7–8B | ~4 GB | ~8 GB | ~16 GB | carte 8–12 GB |
| 13–14B | ~7 GB | ~14 GB | ~28 GB | carte 12–16 GB |
| 32–34B | ~18 GB | ~34 GB | ~68 GB | carte 24 GB (une 3090/4090) |
| 70B | ~35 GB | ~70 GB | ~140 GB | 2× 24 GB (deux 3090) |
Le schéma est clair : 24 GB de VRAM, c’est le point idéal du pleb. Ça fait tourner confortablement tout model jusqu’à ~34B en Q4 avec de la place pour un vrai context, et deux d’entre elles ouvrent la porte au 70B. C’est exactement pourquoi le marché de l’occasion est ce qu’il est — plus de détails sur la carte précise ci-dessous.
Et les tokens par seconde ?
Faire rentrer le model en VRAM vous dit s’il tourne. Les tokens par seconde vous disent s’il est agréable à utiliser. Pour le chat, tout ce qui dépasse votre propre vitesse de lecture (~10 tokens/sec) donne une sensation de temps réel ; en dessous de ~5 tokens/sec, on a l’impression du modem d’antan.
La vitesse de génération est limitée presque entièrement par la bande passante mémoire, pas par le calcul brut, parce que chaque token exige de relire le model entier depuis la VRAM une fois. C’est pourquoi la spécification GB/s d’une carte compte autant que sa capacité en GB, et pourquoi un quant plus petit qui tient en VRAM rapide bat systématiquement un plus gros qui déborde en RAM système.
Attentes approximatives pour un model 7–8B en Q4, la charge de travail pleb la plus populaire :
- GPU 24 GB moderne (3090, 4090 d’occasion) : très confortable — bien dans les dizaines de tokens/sec, plus vite que vous ne lisez.
- GPU milieu de gamme 8–12 GB : encore nerveux pour du 7–8B ; resserrez le quant et le context pour les models plus gros.
- Apple Silicon (mémoire unifiée) : utilisable grâce à la RAM partagée à haute bande passante ; excellent pour les portables, pas un champion de vitesse.
- CPU seul / model débordé en RAM système : fonctionnel mais lent — tokens/sec à un chiffre. Acceptable pour les traitements par lots, pénible pour le chat interactif.
Les models plus gros sont plus lents au même palier matériel parce qu’il y a simplement plus de données à streamer par token. Un 70B en Q4 sur deux 3090 est réellement utile, mais nettement plus posé qu’un 8B sur une seule carte. Adaptez le model à la tâche : un 8B gère la plupart des tâches d’assistant et de lecture de logs ; n’allez vers le 34B–70B que lorsque le saut de qualité justifie la latence. Si vos tokens/sec sont mystérieusement mauvais, la cause est presque toujours un débordement de VRAM — vérifiez avec les diagnostics de notre guide de dépannage avant de blâmer le GPU.
Alors, quel GPU un pleb devrait-il réellement acheter ?
Partez du model que vous voulez faire tourner au quotidien, dimensionnez la VRAM d’après l’aide-mémoire, ajoutez votre budget de context, et achetez la carte la moins chère qui le couvre avec de la marge. Pour la plupart des bâtisseurs de stack souverain, ça tombe au même endroit : une carte 24 GB d’occasion. Elle fait tourner tout jusqu’à 34B en Q4 avec un context confortable et s’associe par paire pour le 70B quand vous y arrivez. Nous avons détaillé toute la proposition de valeur dans notre analyse approfondie de la RTX 3090 d’occasion pour les LLM en 2026 — la version courte : les cartes 24 GB de seconde main restent le meilleur achat en dollar par VRAM utilisable sur la planète.
Quelques principes d’achat qui font économiser de l’argent aux plebs :
- Achetez de la VRAM, pas des benchmarks. Pour les LLM locaux, une carte 24 GB de génération précédente bat net une carte 12 GB de génération actuelle — la capacité décide de ce que vous pouvez faire tourner tout court.
- La bande passante, c’est votre cadran de vitesse. Entre deux cartes de VRAM égale, le plus haut GB/s gagne en tokens/sec.
- La marge plutôt que l’héroïsme. Ne dimensionnez pas à l’octet près ; laissez 15–20 % pour que la croissance du context ne bascule pas en débordement.
- Les prix ici sont en CAD. Quand vous comparez avec des annonces en USD ailleurs, faites la conversion avant de crier à la « bonne affaire ».
Et rappelez-vous : la chaleur n’est pas du gaspillage. Un GPU qui tire 350W est un radiateur de 350W qui se trouve à réfléchir — le même premier principe derrière chauffer sa maison avec l’inference, pas seulement le hashing. Dans un hiver québécois froid, votre rig d’IA souveraine gagne sa place deux fois.
Dimensionnement en pratique : trois builds de pleb
- Le bricoleur portable. Objectif : un assistant privé et un aide au code. Faites tourner un 8B en Q4 (~4 GB) sur un GPU 8–12 GB ou Apple Silicon. Commencez ici avec notre installation Ollama en 10 minutes.
- Le bâtisseur de labo maison. Objectif : un model 32B capable pour le travail sérieux, long context pour les documents. Une carte 24 GB le couvre en Q4 avec de la marge. Choisissez votre runner avec LM Studio vs Ollama vs llama.cpp.
- Le souverain de sous-sol. Objectif : raisonnement classe 70B, entièrement hors ligne. Deux cartes 24 GB en Q4 (~35 GB de weights répartis sur les deux). C’est le palier sous-sol, pas une stratégie nationale de GPU — de l’inference lourde que vous possédez de bout en bout.
Questions fréquemment posées
Combien de VRAM me faut-il pour faire tourner un model 7B ?
Environ 4 GB pour les weights en Q4, ou ~8 GB en Q8. Ajoutez quelques GB pour le context et le surcoût, et une carte 8 GB fait tourner un model 7–8B confortablement. Le fp16 demande ~16 GB pour le même model, c’est pourquoi presque personne ne fait d’inference en fp16.
Une fenêtre de context plus longue demande-t-elle plus de VRAM ?
Oui. Le cache KV qui contient votre conversation croît à peu près linéairement avec le nombre de tokens, donc une session à context 32k peut ajouter plusieurs gigaoctets en plus des weights. Si vous prévoyez d’alimenter de longs documents ou des bases de code entières, dimensionnez votre carte pour les weights plus un budget de context généreux, pas les weights seuls.
La quantization Q4 est-elle « pire » que le fp16 ?
Techniquement oui, en pratique à peine. Q4 jette ~75 % de l’empreinte mémoire par rapport au fp16 pour une perte de qualité de l’ordre de quelques pourcents sur la plupart des tâches — généralement imperceptible en chat et en raisonnement général. Pour les rigs locaux, Q4_K_M ou Q5 est le défaut standard du pleb ; réservez le fp16 aux cas où vous avez mesuré une vraie différence. Le détail complet est dans notre guide de quantization.
Pourquoi mes tokens/sec sont-ils si lents alors que le model « rentre » ?
Presque toujours parce qu’une partie du model a débordé de la VRAM vers la RAM système, où la bande passante n’est qu’une fraction de celle du GPU. Soit descendez vers un quant plus petit, réduisez votre context, ou passez à une carte avec plus de VRAM pour que le model entier reste sur l’appareil.
Possédez le compute, pas seulement le prompt
Le dimensionnement VRAM n’a rien de mystique — c’est params × octets par param, plus le context, plus une marge. Faites l’arithmétique, achetez la bonne carte une fois, et vous ne louerez plus jamais votre pensée à un cloud qui lit vos prompts. C’est tout le sens d’un stack souverain : vos données, votre compute, votre code, une couche de plus de décentralisation. Nouveau dans l’idée ? Commencez par Le guide du pleb pour l’IA self-hosted, puis explorez le hub IA de D-Central pour les runners, models et builds de rig qui le rendent concret.
Et si vous voulez pousser la souveraineté jusqu’au silicium — posséder le micrologiciel de votre matériel de la même façon que vous possédez votre inference — DCENT_OS est notre micrologiciel open-source pour le matériel Antminer industriel, construit en Rust sur les épaules de Braiins OS+, VNish et LuxOS, actuellement en beta publique. Rejoignez la liste d’attente beta DCENT_OS et possédez votre stack de la puce jusqu’au sommet.
