Quel LLM pour 32 Go de VRAM ?

#32 Go de VRAM : ce que la capacité change par rapport à 24 Go

Un modèle en Q4 occupe environ 0,6 Go par milliard de paramètres, plus le cache de contexte qui grandit avec la longueur de la conversation. À 24 Go, un dense de 27 à 32B en Q4 (16 à 20 Go) tient, mais le contexte doit rester court. À 32 Go, il reste 12 à 16 Go pour le contexte, les activations et le système : c'est ce budget qui rend possibles les fenêtres de 32 000 à 128 000 tokens sur un 27B, ou un MoE de 30-35B avec une marge confortable.

Ces valeurs sont des poids de fichiers, pas des besoins totaux : le calculateur du site ajoute le cache pour un modèle et un contexte donnés. Le cache peut aussi être quantifié en q8_0, ce qui, selon la FAQ d'Ollama, en divise la taille par deux environ par rapport à f16, à condition d'activer Flash Attention.

• Calculateur de mémoire pour un modèle et son contexte
• Quantifier le cache KV pour gagner de la mémoire

#Quelles cartes offrent 32 Go, et pourquoi la bande passante compte

Deux cartes de bureau se distinguent. La GeForce RTX 5090 embarque 32 Go de GDDR7 sur un bus de 512 bits, avec 1 792 Go/s de bande passante d'après NVIDIA. La Radeon AI PRO R9700 d'AMD offre aussi 32 Go, mais en GDDR6 sur un bus de 256 bits, à 640 Go/s selon AMD, pour un ordinateur de bureau et un usage professionnel. La capacité est identique ; la vitesse de génération ne l'est pas.

Le plafond se calcule en divisant la bande passante par les poids lus à chaque token ; il ne se réalise jamais entièrement, mais le rapport reste valable : à modèle égal, la RTX 5090 génère plus de deux fois plus vite que la R9700. Pour une carte AMD, le pilote et la pile logicielle (ROCm, Vulkan) comptent aussi ; le guide dédié aux cartes AMD détaille les limites. Les cartes précises ont leurs pages : celle de la RTX 5090 donne les détails de la carte.

Deux autres voies atteignent 32 Go. Deux cartes de 16 Go se répartissent un modèle avec llama.cpp, mais la liaison PCIe ralentit les échanges et le modèle doit se découper proprement ; le guide multi-GPU donne la méthode. Un Mac à mémoire unifiée de 32 Go ou plus est une troisième option, avec une bande passante plus faible mais sans limite de VRAM dédiée.

Les prix évoluent vite : le suivi du site relève chaque lundi et chaque jeudi le prix le plus bas des cartes graphiques pour l'IA locale, avec le prix du Go de VRAM.

• Suivi des prix des cartes graphiques pour l'IA locale
• LLM sur RTX 5090
• Setup multi-GPU avec llama.cpp

#Les modèles à privilégier sur 32 Go

Dense 27 à 32B

Le choix qualité : Qwen 3.5 27B ou 3.8 27B (16 Go en Q4), Gemma 4 31B (18 Go), Qwen 3 32B (19 à 20 Go). Ils laissent la place d'un long contexte et se prêtent bien à des quantifications plus fines (Q5, Q6) si vous voulez plus de qualité.

MoE 30-35B

Qwen3-Coder 30B-A3B (19 Go) et Qwen 3.6 35B-A3B (21 Go) n'activent qu'environ 3 milliards de paramètres par token : c'est la meilleure vitesse pour la taille, et le bon choix pour le code et les agents.

gpt-oss-20b

14 Go dans la bibliothèque Ollama ; la page Ollama indique qu'il peut tourner sur des systèmes disposant d'au moins 16 Go de mémoire. Sur 32 Go, il laisse un contexte immense et permet d'en garder un second modèle chargé en même temps.

Modèle de code de 24B

Devstral Small 2 24B (14 Go) : un spécialiste des agents de code qui laisse de la place à deux modèles résidents.

Pour choisir, posez trois questions. Le modèle doit-il s'adapter à un contexte long (documents, dépôt de code) ? Choisissez un dense de 27 B en Q4, qui laisse 16 Go de cache. Faut-il de la vitesse (agents, boucles d'outils) ? Le MoE. Voulez-vous simplement plus de qualité qu'à 24 Go ? Passez d'un Q4 à un Q6 sur un 27 à 32B : la place existe.

• Les modèles MoE expliqués
• Choisir sa quantification

#Vérifier que le modèle tient vraiment sur la carte

Un modèle qui « se charge » n'est pas forcément entièrement sur le GPU. Ollama répartit silencieusement les couches entre la carte et la mémoire vive quand la VRAM manque, et la vitesse chute sans message d'erreur. La FAQ officielle indique que la commande ollama ps affiche dans la colonne Processor où le modèle a été chargé : 100 % GPU signifie qu'il l'est entièrement, une répartition comme 30 %/70 % CPU/GPU signale un débordement.

1. 01
   Charger le modèle avec le contexte visé

   Lancez le modèle avec la taille de contexte réelle de votre usage, pas la valeur par défaut : c'est le cache de contexte qui fait déborder.
2. 02
   Lire la colonne Processor

   Exécutez ollama ps dans un autre terminal. Visez 100 % GPU ; toute part de CPU divise la vitesse.
3. 03
   Réduire si nécessaire

   Si le modèle déborde, réduisez le contexte, activez la quantification du cache en q8_0 avec Flash Attention, ou passez à une quantification plus légère.
4. 04
   Contrôler la VRAM restante

   Sous Windows ou Linux, nvidia-smi affiche la mémoire utilisée ; gardez une marge d'un à deux Go pour l'affichage et les pics.
5. 05
   Mesurer sur votre usage

   Comparez le débit avec un court prompt et avec votre prompt réel : c'est le second chiffre qui compte.

• Ollama sur cartes AMD avec ROCm
• Dépanner les erreurs GPU d'Ollama

#70B et 123B : pourquoi l'offload ne rend pas ces modèles utilisables

Llama 3.3 70B pèse 43 Go dans la bibliothèque Ollama, Mistral Large 123B 73 Go. Sur 32 Go, il faut donc laisser au moins 11 Go pour le 70B et 41 Go pour le 123B en mémoire vive. À chaque token, ces couches sont lues par le processeur à la vitesse de la mémoire système : environ 102 Go/s au maximum pour une DDR5-6400 double canal (6 400 MT/s × 8 octets × 2). Divisé par 41 Go, le plafond du 123B est d'environ 2,5 tokens par seconde ; pour le 70B, avec 11 Go en RAM, d'environ 9 tokens par seconde. Ce sont des plafonds, pas des mesures : ils montrent surtout que le débit ne se dégrade pas de façon progressive, mais par paliers, dès que les couches quittent la carte.

Ce calcul suppose que la carte garde 32 Go de poids ; en pratique, le cache de contexte prend aussi de la place, donc davantage part en RAM et le plafond baisse. Les MoE se comportent mieux : llama.cpp propose une option pour garder les experts de certaines couches sur le processeur (--n-cpu-moe), pour les configurations qui ne peuvent pas charger le modèle en entier sur le GPU. Elle sauve un modèle qui ne tient pas, mais un utilisateur du dépôt llama.cpp signale une perte de vitesse d'environ 80 % en mettant tous les experts sur le CPU : c'est une solution de dernier recours.

llama-server -m modele-moe.gguf -ngl 99 -fa --n-cpu-moe 12 -c 16384

La valeur de --n-cpu-moe dépend de votre mémoire ; il faut la trouver par essais. Pour un 70B dense, la bonne réponse à 32 Go est presque toujours un modèle plus petit ou plus de mémoire, pas de l'offload.

#Affiner un modèle sur 32 Go : ce qui passe, ce qui ne passe pas

L'affinage avec QLoRA garde les poids du modèle en 4 bits et n'entraîne que de petits adaptateurs. Les poids seuls d'un 70B occupent déjà 40 Go, donc un QLoRA sur 70B ne tient pas sur 32 Go. Un 32B en 4 bits occupe environ 19 à 20 Go : il reste 12 Go pour les activations, l'optimiseur et les adaptateurs, ce qui est faisable avec un contexte court et un lot de 1, sans marge de sécurité. Un 7 à 14B est confortable. Ce sont des ordres de grandeur à confirmer dans l'outil que vous utilisez.

#32 Go de VRAM ou une autre solution : le tableau de décision

• Quel LLM pour 24 Go de VRAM
• Mac Studio pour 64 à 512 Go
• Source : NVIDIA, annonce des RTX 50
• Source : AMD, Radeon AI PRO R9700
• Source : bibliothèque Ollama, Mistral Large

#Questions fréquentes