Comment exécuter un LLM sur une carte de 6 à 8 Go

Réponse courte : sur une carte de 6–8 Go, vous pouvez faire tourner un modèle de 7–8B en 4 bits avec un contexte modéré, ou un modèle de 3–4B à plus haute précision. Ce que vous ne pouvez pas faire, c'est un 13–14B en 4 bits : il demande environ 10 Go avant même que le bureau ne prenne sa part. La différence entre 6 et 8 Go n'est pas cosmétique, mais elle est plus petite que ne le suggèrent la plupart des guides.

Ce n'est pas un banc d'essai de cartes précises. Tous les chiffres viennent de la même formule que notre calculateur de VRAM, donc vous pouvez reproduire chaque ligne avec votre propre modèle. Vérifié le 2 novembre 2026.

Ce que « 6–8 Go » veut vraiment dire

Le chiffre sur la boîte n'est pas celui dont vous disposez. Le compositeur du bureau, le navigateur avec accélération matérielle et toute autre application qui utilise le GPU occupent déjà de la mémoire sur la carte avant que votre modèle ne démarre. Sur une machine à 8 Go, `nvidia-smi` affiche souvent entre 0,6 et 1,6 Go utilisés avec le bureau au repos.

La première habitude à prendre est donc de lire le chiffre réel, pas la fiche technique :

nvidia-smi sur NVIDIA
rocm-smi sur AMD
Moniteur d'activité → historique GPU sur Apple Silicon

Appliquez ensuite la règle qu'utilise le calculateur : un modèle qui occupe moins de 85 % de la carte est confortable, jusqu'à 100 % c'est juste, et au-delà il déborde vers la RAM système ou plante.

Les quatre choses qui mangent votre VRAM

Les poids. Le modèle lui-même : paramètres × bits par poids ÷ 8.
Le cache KV. Les clés et valeurs d'attention de la conversation en cours. Il grandit avec la fenêtre de contexte que vous autorisez.
La surcharge du moteur. Le moteur, le contexte GPU et les tampons de travail. Nous comptons 0,8 Go.
Tout le reste. Bureau, navigateur, autres applications. C'est la partie qu'on oublie, et la raison pour laquelle un modèle qui « tient » plante à 95 %.

poids_Go = paramètres_B × bits ÷ 8
kv_Go ≈ (contexte ÷ 8192) × paramètres_B × 0,15
total ≈ poids + kv + 0,8

La ligne du cache KV est une approximation assumée : le chiffre exact dépend de l'architecture, du nombre de couches qui partagent un cache et du type de données de ce cache. C'est suffisant pour décider si un modèle tient.

Ce qui tient avec 8 192 jetons de contexte

Modèle	Q4_K_M	Q5_K_M	Q8	Verdict sur 8 Go	Verdict sur 6 Go
3B	2,8 Go	3,1 Go	4,3 Go	Confortable même en Q8	Confortable
4B	3,6 Go	4,0 Go	5,6 Go	Confortable	Tient en Q5
7B	5,4 Go	5,6 Go	7,4 Go	Confortable	Juste
8B	6,0 Go	7,0 Go	10,0 Go	Juste / confortable, voir ci-dessous	Uniquement en contexte 4k
14B	9,9 Go	11,7 Go	16,9 Go	Ne tient pas	Ne tient pas

C'est sur la ligne 8B que la question 6 contre 8 Go devient concrète. À 6,0 Go sur une carte de 6 Go, vous êtes à 100 % : techniquement dedans, en pratique sur le fil. Sur 8 Go, vous êtes à 75 %, ce qui laisse de la place au bureau et à un prompt un peu plus long.

Le contexte est le levier inattendu

Les poids ne changent pas avec la conversation ; le cache, si. Avec un modèle 8B en Q4_K_M :

Contexte	Cache KV	Total
4 096	0,6 Go	5,4 Go
8 192	1,2 Go	6,0 Go
16 384	2,4 Go	7,2 Go
32 768	4,8 Go	9,6 Go

Voilà toute l'histoire du « ça marchait hier » : le même modèle à 32k demande 3,6 Go de plus qu'à 8k. Si une conversation qui fonctionnait échoue maintenant, baissez le contexte avant de toucher à la quantification. Vous perdez de la mémoire de conversation, pas de la qualité de réponse.

Modèles et quantifications pour commencer

7–8B en Q4_K_M : le choix raisonnable

C'est le point où la qualité cesse d'être une démo et où le fichier tient encore sur une carte de milieu de gamme. Une réserve, tirée de notre guide GGUF : Q4_K_M ne fait pas quatre bits par poids. llama.cpp mesure environ 4,89 pour Llama 3.1 8B, et c'est pourquoi le fichier sur disque est plus gros que ne le suggère l'arithmétique ci-dessus. Le calculateur reste sur la version simple pour que les chiffres soient reproductibles ; prenez la taille du fichier comme un plancher, pas comme la réponse.

13–14B : quand cela vaut le coup (pas sur cette carte)

En Q4_K_M, un modèle 14B demande environ 9,9 Go à 8k de contexte. Sur une carte de 8 Go, la seule façon d'y arriver est de déporter des couches vers la RAM système, ce qui effondre la vitesse et donne généralement une expérience pire qu'un 8B qui tourne entièrement sur le GPU. Passez à 12 Go ou plus avant d'y penser.

Petits modèles et mélange d'experts

Les modèles 3–4B en Q5 ou Q6 sont l'option sous-estimée pour 6 Go : ils tiennent à l'aise, répondent plus vite et suffisent pour résumer, réécrire et classer. Les MoE sont un autre compromis : ils n'activent qu'une fraction de leurs paramètres par jeton, donc ils peuvent être rapides, mais le modèle entier doit rester en mémoire. Un MoE de 30B avec 3B actifs ne tiendra pas sur une carte de 8 Go simplement parce qu'il tourne comme un 3B.

Configurer le moteur

Ollama

Ollama décide seul du nombre de couches envoyées au GPU. `ollama ps` montre la répartition après le chargement : s'il indique 100 % GPU, tout est sur la carte.

ollama run llama3.1:8b
ollama ps
ollama run llama3.1:8b --verbose

Le contexte se règle par modèle dans le Modelfile (`PARAMETER num_ctx 8192`) ou par session avec `/set parameter num_ctx 4096`. Le baisser est la sortie la plus rapide d'une erreur de mémoire. Le reste des commandes est dans notre aide-mémoire Ollama.

LM Studio

Son curseur d'offload GPU est la même décision exprimée en couches : moins de couches sur le GPU, plus en RAM, plus lent mais possible. Fixez la longueur de contexte volontairement au lieu de la laisser au maximum, et regardez le panneau d'offload après chargement pour voir la mémoire réellement utilisée.

llama.cpp

`-ngl` (nombre de couches sur le GPU), `-c` (contexte) et `-b` (lot) sont les trois options qui comptent ici. Réduire le lot baisse le pic de mémoire pendant le traitement du prompt, et c'est là que survient une bonne partie des erreurs de mémoire — pas pendant la génération.

Si le message « out of memory » apparaît

Divisez le contexte par deux. De 32k à 16k, vous économisez environ 2,4 Go avec un 8B.
Fermez le navigateur. L'accélération matérielle retient des centaines de mégaoctets sur la carte. Un lanceur de jeux ou un appel vidéo aussi.
Réduisez la taille du lot si vous envoyez des prompts ou des documents longs.
Baissez ensuite la quantification, de Q5 à Q4. Attendez-vous à une perte réelle mais modérée.
Puis changez de modèle. Si un 8B en Q4 avec 4k de contexte ne tient toujours pas, la limite est la carte, pas les réglages.

Comment savoir que ça tourne vraiment bien

Trois chiffres, tous faciles à obtenir :

Temps jusqu'au premier jeton (TTFT). Combien de temps avant le début de la réponse. Il dépend du traitement du prompt ; il augmente avec la longueur du prompt et avec les couches déportées en RAM.
Jetons par seconde. Vitesse de génération. Pour du chat, environ 10 jetons/s sont déjà utilisables ; en dessous de 5, cela paraît cassé. Mesurez-le avec `--verbose` dans Ollama ou lisez-le dans le pied de page de LM Studio.
VRAM de pointe. Surveillez `nvidia-smi -l 1` dans une autre fenêtre pendant que vous envoyez le prompt le plus long que vous comptez utiliser.

Répétez ensuite le même prompt trois fois et gardez la médiane. La température et l'échantillonnage rendent une mesure unique bruitée ; un test que vous ne pouvez pas répéter ne dit rien de votre machine.

Liste de vérification

Lisez la VRAM disponible, pas la spécification de la carte.
Choisissez 7–8B en Q4_K_M, ou 3–4B en Q5/Q6 si la carte fait 6 Go.
Commencez à 8k de contexte, pas à 32k.
Confirmez avec `ollama ps` ou le panneau d'offload que tout est sur la carte.
Mesurez le TTFT et les jetons/s ; si c'est lent, cherchez si des couches sont en RAM.
C'est seulement ensuite que vous ajustez la quantification.

Notre guide VRAM contient le tableau complet par taille de modèle et par carte, et le calculateur fait l'arithmétique pour votre modèle, votre quantification et votre contexte exacts.

Search this blog