11 novembre 2026 · Équipe VRAMfarm

Combien de VRAM faut-il ? Le tableau pour les LLM, Flux, la vidéo Wan 2.2 et l’entraînement

Un modèle de chat de 7 à 8B en 4 bits tient sur une carte de 12 Go, un modèle 32B demande 24 Go, et Llama 3.3 70B a besoin d’environ 43 Go rien que pour ses poids : 48 Go sont donc le minimum réaliste. Les modèles d’image se situent entre 10 Go (SDXL) et 24 Go (Qwen-Image en fp8), et la vidéo Wan 2.2 demande 22 à 48 Go. Ces mêmes estimations alimentent le sélecteur de VRAM de la page d’accueil, et la formule dont elles découlent fonctionne pour n’importe quel modèle que vous voulez vérifier vous-même.

La formule : poids, KV cache et marge

Pendant qu’un modèle tourne, la mémoire vidéo contient trois choses :

VRAM ≈ paramètres × octets par paramètre + KV cache (ou activations) + 1 à 2 Go de marge

La première partie, ce sont les poids. Un milliard de paramètres à 2 octets chacun, cela fait 2 Go : un modèle 8B en fp16 demande donc environ 16 Go avant d’avoir traité le moindre mot. Le nombre d’octets par paramètre dépend de la précision :

La deuxième partie dépend de ce que fait le modèle. Pour un modèle de langage, c’est le KV cache : le modèle garde les clés et les valeurs de chaque token de la conversation, et ce cache grossit avec la longueur du contexte. Pour les modèles d’image et de vidéo, ce sont les activations : des tenseurs intermédiaires qui grossissent avec la résolution, le nombre d’images et la taille du lot.

La troisième partie regroupe le contexte CUDA, les tampons du framework et la fragmentation de la mémoire. Prévoyez 1 à 2 Go, davantage avec vLLM, qui réserve par défaut 90 % de la carte dès le départ.

La quantification est le moyen qu’utilisent la plupart des gens pour faire tenir de plus gros modèles sur de plus petites cartes. Le fp8 divise les poids par deux sans différence presque visible, et c’est le format par défaut de Flux, Qwen-Image et Wan dans ComfyUI. Le 4 bits les divise encore par deux. Pour le chat et le résumé, un modèle 32B en 4 bits (environ 20 Go) donne généralement de meilleures réponses qu’un modèle 8B en fp16, qui occupe presque autant de mémoire. Pour le code et les maths sur de petits modèles, la perte se remarque davantage. En dessous de 4 bits, la qualité chute vite.

Un détail matériel : le fp8 est calculé nativement à partir de la génération Ada (RTX séries 40 et 50, L40S, H100, B200). Les cartes Ampere (RTX 3090, RTX A6000, A100) peuvent charger des poids fp8, mais elles calculent en fp16 : vous économisez de la mémoire sans gagner en vitesse.

Modèles de langage : de 8B à 235B

Les chiffres sont approximatifs : poids plus tampons de travail, avec un contexte court. Un long contexte vient s’y ajouter, voir la section sur le KV cache plus bas. La colonne « 4 bits » correspond à ce qu’affiche notre sélecteur, car c’est ainsi que la plupart des gens font tourner ces modèles sur une seule carte.

Quelques clés de lecture :

• 24 Go font tourner un modèle 32B, avec un contexte court. Un modèle 32B en 4 bits laisse 2 à 3 Go au KV cache sur une carte de 24 Go, de quoi tenir environ 8 000 à 10 000 tokens. La RTX 5090 de 32 Go offre au même modèle de la place pour quelque 30 000 à 40 000 tokens, selon la quantification et les tampons propres au moteur d’exécution.
• Un 70B sur une seule carte, c’est 48 Go ou plus. Sur 48 Go, un 70B en 4 bits tourne avec 8 000 à 12 000 tokens de contexte, environ le double avec un cache en 8 bits. Pour de longs documents, plusieurs utilisateurs à la fois ou un service avec vLLM, prenez une A100 ou une H100 de 80 Go.
• La H200 de 141 Go semble idéale pour un modèle de 136 Go, mais c’est trop juste. Une fois le contexte CUDA chargé, il ne reste presque rien pour le cache. Prenez une B200 ou deux cartes de 80 Go.
• Les modèles MoE ont besoin de tous leurs experts en mémoire. Qwen3 235B-A22B active 22B de paramètres par token : il génère du texte à peu près aussi vite qu’un modèle dense de 22 à 30B, mais il lui faut la mémoire d’un 235B.

La vitesse est une autre question. Générer chaque token oblige à relire tout le modèle en mémoire : un plafond approximatif du nombre de tokens par seconde est donc la bande passante mémoire divisée par la taille du modèle. Une RTX 4090 (1 008 Go/s) avec un modèle de 20 Go plafonne vers 50 tokens par seconde, et les chiffres réels sont un peu inférieurs. C’est pourquoi une H100 à 3 350 Go/s paraît tellement plus rapide avec le même modèle.

Modèles d’image et de vidéo

Dans ComfyUI, les modèles d’image et de vidéo tournent généralement en fp8, et ComfyUI fait entrer et sortir l’encodeur de texte et le VAE de la VRAM selon les besoins. La colonne « carte minimale » signifie « tourne en 1024 × 1024 (ou en vidéo 720p) sans erreur » ; la carte recommandée vous laisse de la marge pour les LoRA, ControlNet et des résolutions plus élevées. Prenez ces chiffres comme des estimations pour un workflow typique : la résolution, le nombre d’images et les réglages de déchargement de ComfyUI peuvent les faire varier de plusieurs gigaoctets dans un sens ou dans l’autre.

La vidéo est la catégorie où « ça tient » et « ça tient confortablement » diffèrent le plus. Chaque seconde de vidéo supplémentaire ajoute des images, et chaque image ajoute des activations. Wan 2.2 14B en fp8 demande environ 30 Go en 720p pour un clip de 5 secondes : une RTX 5090 de 32 Go s’en sort, mais des clips plus longs ou une résolution plus élevée vous poussent vers 48 Go. C’est pourquoi notre application Wan 2.2 14B prête à l’emploi demande une carte de 48 Go, et l’application 5B une carte de 24 Go.

Il existe des quantifications GGUF (Q4, Q5) de Flux et de Qwen-Image qui les font tenir sur des cartes de 8 à 12 Go, au prix d’étapes plus lentes et d’une partie des détails. Pour quelques images, c’est très bien ; pour un vrai travail, la mémoire supplémentaire se rentabilise en temps gagné. Le guide des GPU pour Flux, SDXL et ComfyUI passe en revue chaque carte.

Voix et entraînement

Les modèles de voix sont petits. L’entraînement demande bien plus de mémoire que l’exécution du même modèle, car les gradients et les états de l’optimiseur s’ajoutent aux poids.

La ligne du fine-tuning complet mérite une explication. Avec l’optimiseur AdamW standard en précision mixte, chaque paramètre coûte environ 16 octets : poids en bf16 (2), gradients (2), copie maîtresse en fp32 (4) et deux états d’optimiseur (8). Pour 8B de paramètres, cela fait environ 128 Go avant les activations, soit deux cartes de 80 Go ou plus, une H200 ou une B200. Un optimiseur 8 bits et le gradient checkpointing ramènent ce total à environ 70 Go, selon la longueur des séquences et l’outil d’entraînement, ce qui tient sur une seule A100 ou H100. QLoRA évite presque tout cela : le modèle de base reste figé en 4 bits et seules de petites matrices d’adaptation sont entraînées.

Pourquoi un modèle qui tient plante quand même sur un long contexte

C’est la surprise la plus fréquente : le modèle se charge, répond aux premières questions, puis échoue sur « CUDA out of memory » quand vous collez un long document. Les poids tenaient bien. Le KV cache, non.

Le cache par token vaut 2 × couches × têtes KV × taille de tête × octets. En fp16, cela donne :

Un 70B en 4 bits sur une carte de 48 Go se porte donc bien à 8 000 tokens et manque de mémoire quelque part vers 10 000 à 12 000. À son contexte annoncé de 128 000 tokens, le cache seul est aussi gros que les poids. Servir plusieurs utilisateurs multiplie le cache par le nombre de conversations parallèles.

Comment s’en sortir sans carte plus grande :

• Plafonnez le contexte. Dans vLLM, fixez --max-model-len 16384. vLLM refuse de démarrer si le contexte demandé ne peut pas tenir, ce qui vaut mieux qu’un plantage plus tard. Dans Ollama, c’est la longueur de contexte (num_ctx) qui détermine la mémoire : réglez-la délibérément plutôt que de vous fier à la valeur par défaut, qui a changé d’une version à l’autre.
• Quantifiez le cache. --kv-cache-dtype fp8 dans vLLM, ou -ctk q8_0 -ctv q8_0 dans llama.cpp (avec la flash attention activée), divise le cache par deux avec peu d’effet sur les réponses.
• Limitez les requêtes parallèles si vous servez une API : moins de conversations simultanées, moins de cache.

Si vous avez besoin du long contexte tous les jours, la solution la moins chère est généralement la carte du palier supérieur : une carte de 80 Go pour un 70B, ou une RTX 5090 de 32 Go au lieu de 24 Go pour un 32B.

Choisir la carte à partir du chiffre

Prenez le chiffre dans les tableaux, ajoutez 10 à 20 % de marge, et choisissez la plus petite carte au-dessus. Les cartes vont par paliers fixes : 10 à 12 Go, 16 Go, 24 Go, 32 Go, 48 Go, 80 Go, 96 Go, 141 Go et 192 Go. À l’intérieur d’un palier, la différence porte sur la vitesse, pas sur ce que vous pouvez faire tourner : une RTX 3090 et une RTX 4090 ont toutes deux 24 Go. La 4090 génère des images environ 1,6 à 2,5 fois plus vite, mais du texte de LLM à peine plus vite, car leurs bandes passantes mémoire sont proches (936 contre 1 008 Go/s). Comparez leurs prix horaires, à partir de 0,30 € et 0,59 €, sur la page des tarifs.

En cas de doute, partez d’un palier au-dessus de ce que vous pensez. La facturation se fait à la minute : une carte trop grande vous coûte quelques centimes pour le test, alors qu’une carte trop petite vous coûte une soirée d’erreurs de mémoire insuffisante.