Guide VRAM pour les modèles 32B et 70B : options mono-GPU et multi-GPU
La réponse pratique aux exigences VRAM du modèle 70B est la suivante : un modèle 70B peut être chargé avec environ 35 Go à 45 Go avec une quantification 4 bits courante, autour de 70 Go à 90 Go avec une quantification 8 bits et la surcharge d’exécution, et plus de 140 Go avant surcharge en FP16 ou BF16. Un modèle 32B est plus facile, mais nécessite tout de même une planification : environ 18 Go à 24 Go pour l’inférence 4 bits, 32 Go à 45 Go pour l’inférence 8 bits, et plus de 64 Go avant surcharge en FP16 ou BF16.
Ces chiffres ne représentent que le minimum. Les vraies exigences VRAM du modèle 70B dépendent de la longueur du contexte, de la taille de lot, du cache KV, du moteur de service, du parallélisme tensoriel, des adaptateurs LoRA, de l’état de l’optimiseur et de la marge de sécurité dont vous avez besoin avant que le trafic de production ne commence à échouer avec des erreurs de mémoire insuffisante.
Ce guide s’adresse aux ingénieurs IA, aux équipes plateforme et aux acheteurs techniques qui décident si une charge de travail 32B ou 70B peut tenir sur un seul GPU, nécessite plusieurs GPU, ou devrait être servie via une API de modèle plutôt que via de la capacité GPU louée.
Vérifié le 13 octobre 2026.
exigences VRAM du modèle 70B : la réponse rapide
Utilisez ceci comme premier dimensionnement, puis benchmarkez votre modèle exact, votre fenêtre de contexte et votre pile de service.
| Charge de travail | Point de départ pour 32B | Point de départ pour 70B | Remarque pratique |
|---|---|---|---|
| Inférence locale 4 bits | 24 Go peuvent fonctionner, 48 Go sont plus confortables | 48 Go peuvent charger certains modèles quantifiés, 80 Go sont plus sûrs | Convient pour le développement, les démos, les outils internes et un service à faible concurrence. |
| Inférence 8 bits | 48 Go ou 80 Go | 80 Go minimum, 96 Go ou 141 Go plus sûrs | La surcharge d’exécution et le cache KV déterminent souvent si le point de terminaison est stable. |
| Inférence FP16/BF16 | 80 Go | 2x80 Go, 141 Go, 180 Go, ou des systèmes multi-GPU plus grands | La mémoire des poids seule correspond à environ 2 octets par paramètre. |
| Service local mono-utilisateur de type Ollama | 24 Go à 48 Go | 48 Go à 80 Go | La question des exigences VRAM du modèle 70B pour Ollama concerne surtout la taille du modèle quantifié plus le contexte. |
| Service de production vLLM ou SGLang | 48 Go à 80 Go | 80 Go, 96 Go, 141 Go, ou multi-GPU | Prévoyez une marge pour le cache KV, le batching et la récupération après requête échouée. |
| Fine-tuning QLoRA | 48 Go pour des exécutions contraintes, 80 Go plus sûr | 48 Go est un minimum pour la recherche ; 80 Go ou multi-GPU est plus sûr | Les exigences VRAM du modèle 70B pour QLoRA dépendent fortement de la longueur de séquence et de la stratégie de batch. |
Le raccourci pour les acheteurs :
- Choisissez 24 Go uniquement pour des expériences quantifiées 32B ou des workflows 70B très contraints avec répartition CPU/GPU.
- Choisissez 48 Go pour le confort en 32B, l’inférence locale 70B en 4 bits, ou des expériences QLoRA finement réglées.
- Choisissez 80 Go pour une inférence 70B sérieuse, des fenêtres de contexte plus longues, ou un QLoRA plus fiable.
- Choisissez 96 Go, 141 Go, 180 Go, ou multi-GPU lorsque vous avez besoin de marge de production, de contextes plus longs, d’une concurrence plus élevée, ou de FP16/BF16.
Si le produit n’a besoin que des sorties du modèle et non d’un contrôle matériel direct, comparez une approche modèle/API avant de signer un contrat GPU. Flatkey offre aux équipes une seule clé, un seul solde, une seule facture et un registre d’utilisation sur des centaines de modèles et outils officiels, ce qui peut constituer une base plus propre lorsque l’utilisation est incertaine.
Pourquoi les poids du modèle ne représentent pas l’ensemble des besoins en VRAM
L’estimation mémoire la plus simple est :
model_weight_memory = parameter_count x bytes_per_parameter
Cela donne un minimum utile :
| Taille du modèle | Minimum FP16/BF16 | Minimum 8 bits | Minimum 4 bits |
|---|---|---|---|
| 32B | environ 64 Go | environ 32 Go | environ 16 Go |
| 70B | environ 140 Go | environ 70 Go | environ 35 Go |
Mais un LLM en cours d’exécution a besoin de plus que des poids :
| Composant mémoire | Pourquoi c’est important |
|---|---|
| Métadonnées de quantification | Les formats 4 bits et 8 bits nécessitent des échelles, des métadonnées de groupe et des tampons du framework. |
| Cache KV | Des fenêtres de contexte plus longues et davantage de requêtes concurrentes consomment plus de mémoire. |
| Tampons d’exécution | vLLM, SGLang, TensorRT-LLM, llama.cpp et Ollama réservent chacun la mémoire différemment. |
| Graphes et noyaux CUDA | Les moteurs de service peuvent réserver de l’espace de travail pour la vitesse et la stabilité. |
| Adaptateurs LoRA | Les adaptateurs fine-tunés ajoutent moins de mémoire que les poids complets, mais nécessitent tout de même un budget. |
| Marge de sécurité | Les points de terminaison de production ont besoin d’espace pour les variations de prompt, les nouvelles tentatives et la dérive du déploiement. |
C’est pourquoi exigences VRAM du modèle 70B quantifié n’est pas la même chose que « le fichier 4 bits fait 35 Go ». Un modèle 70B quantifié de 35 Go à 45 Go peut se charger sur un GPU de 48 Go, mais un contexte plus long, un batch plus important ou une exécution plus lourde peut tout de même échouer.
Options mono-GPU pour les modèles 32B et 70B
GPU 24 Go
Les cartes 24 Go sont utiles pour les modèles 32B au format 4 bits, pour des tests 70B plus petits avec déchargement partiel vers le CPU, et pour des expériences développeur où la latence n’est pas l’objectif principal.
Ne considérez pas 24 Go comme une réponse confortable pour les exigences VRAM du modèle 70B. Cela peut être utile avec une quantification agressive, un contexte réduit, un déchargement CPU ou des tests locaux de type llama.cpp, mais ce n’est généralement pas un niveau de service de production pour un 70B.
Meilleur choix :
- Inférence 32B en 4 bits.
- Petites fenêtres de contexte.
- Tests locaux pour un seul utilisateur.
- Évaluation de prototype avant de louer des GPU plus puissants.
Points d’attention :
- Le 70B nécessite souvent un déchargement vers le CPU ou des paramètres très serrés.
- Les prompts longs peuvent épuiser rapidement le cache KV.
- Le débit sera limité.
GPU 48 Go
48 Go est le premier palier sérieux pour un seul GPU en matière de travail quantifié sur 70B. Il peut exécuter de nombreuses charges d’inférence 70B en 4 bits si le contexte et la concurrence sont contrôlés. C’est aussi un seuil pratique pour de nombreuses expériences QLoRA, conforme au résultat QLoRA original montrant un fine-tuning de grande taille, de la classe 65B, sur un seul GPU de 48 Go.
Meilleur choix :
- Inférence locale 70B en 4 bits.
- Inférence 32B en 8 bits.
- Fine-tuning 32B avec de la marge pour les adaptateurs et un contexte plus long.
- Expériences serrées de qlora fine-tuning 70b model vram requirements.
Points d’attention :
- Le 70B en 8 bits n’a généralement pas assez de marge.
- Le service à long contexte peut faire basculer un modèle 70B en 4 bits hors limites.
- La taille de lot est limitée.
GPU 80 Go
80 Go est la réponse pratique la plus courante pour un travail sérieux sur 70B. Les GPU A100 80 Go et H100 80 Go peuvent gérer de nombreuses charges d’inférence 70B quantifiées avec une meilleure marge de contexte que 48 Go, et ils constituent un point de départ beaucoup plus confortable pour QLoRA.
Meilleur choix :
- Inférence 70B en 4 bits avec des tests de contexte proches de la production.
- Inférence 70B en 8 bits si le runtime et le contexte s’y prêtent.
- Inférence 32B en FP16/BF16 avec surcharge.
- QLoRA 70B avec des paramètres contraints mais réalistes.
Points d’attention :
- Le 70B en FP16/BF16 nécessite généralement plus d’un GPU de 80 Go.
- Une forte concurrence exige toujours une planification soigneuse du cache KV.
- La forme du nœud et le prix spécifiques au fournisseur peuvent compter autant que la VRAM.
GPU 96 Go, 141 Go et 180 Go
Les accélérateurs plus récents à grande capacité changent la question du GPU unique. Une carte de 96 Go offre davantage de marge pour du 70B en 8 bits ou des contextes quantifiés plus larges. La mémoire de 141 Go de classe H200 peut permettre à de nombreuses charges de travail 70B de passer avec beaucoup plus de marge. Les configurations de 180 Go de classe B200 poussent encore plus loin le plafond du GPU unique ou du nœud unique, surtout lorsque la pile de service peut utiliser des chemins de précision plus faible plus récents.
Meilleur choix :
- Inférence 70B avec long contexte.
- Tailles de lot et concurrence plus élevées.
- Service en 8 bits ou en précision mixte.
- Réduction de la complexité du sharding pour les grands modèles.
Points d’attention :
- La disponibilité et le prix de location peuvent primer sur l’adéquation théorique.
- La maturité logicielle diffère selon les générations de GPU.
- Vous avez toujours besoin d’un benchmark du coût par sortie acceptée.
Pour des comparaisons matérielles voisines, voir B200 vs H200, H200 vs H100, et meilleur GPU pour l’inférence LLM.
Options multi-GPU pour les modèles 70B
Le service multi-GPU n’est pas seulement « plus de VRAM ». Il ajoute aussi des frais de communication, des contraintes de topologie, des risques de placement et de la complexité logicielle.
Utilisez le multi-GPU lorsque :
- Le modèle ne tient pas sur un seul GPU à la précision dont vous avez besoin.
- Le long contexte ou une forte concurrence nécessitent plus d’espace pour le cache KV.
- Vous avez besoin d’un service 70B en FP16/BF16.
- Vous avez besoin d’un débit qu’un seul GPU ne peut pas fournir.
- Vous pouvez valider le parallélisme tensoriel et les performances de l’interconnexion.
| Option | Quand cela a du sens | Ce qu’il faut vérifier |
|---|---|---|
| 2x48 Go | Service 70B quantifié avec plus de marge qu’une seule carte de 48 Go | Interconnexion, prise en charge du parallélisme tensoriel, comportement en cas de panne. |
| 2x80 Go | Expériences 70B FP16/BF16 ou service quantifié à forte marge | Si le sharding bat un seul GPU plus grand en latence et en coût. |
| 4x80 Go | Service 70B plus lourd, contextes plus grands, plusieurs réplicas ou fine-tuning | NVLink/NVSwitch, politique de batch, utilisation, stratégie de checkpoints. |
| 8x80 Go ou plus | Cluster de production partagé, plusieurs endpoints ou modèles plus grands que 70B | Ordonnanceur, stockage, observabilité et allocation des coûts. |
Pour les déploiements multi-nœuds, la conception du cluster est importante. Utilisez le guide architecture de cluster GPU pour passer en revue les exigences de calcul, réseau, stockage et plan de contrôle avant d’acheter de la capacité.
Exigences VRAM du modèle Ollama 70B
La réponse à ollama 70b model vram requirements dépend du tag du modèle et de la quantification. Les pages de modèles Ollama listent couramment des artefacts 70B quantifiés de l’ordre de dizaines de gigaoctets, et non 140 Go, car le chemin local par défaut est généralement quantifié plutôt qu’en FP16.
Règle pratique :
- 48 Go peuvent suffire pour charger et tester certains modèles 70B quantifiés.
- 64 Go à 80 Go donnent plus de marge pour le contexte et moins de mauvaises surprises OOM.
- 24 Go signifient généralement des modèles plus petits, des contextes plus courts, un offload important ou des expériences lentes.
- Si vous avez besoin d’une latence de production ou de plusieurs utilisateurs, dimensionnez pour la marge de service, pas seulement pour la taille du modèle téléchargé.
Pour les tests locaux, consignez le tag exact du modèle, la quantification, la longueur de contexte, les couches GPU et l’utilisation mémoire observée. N’écrivez pas « le 70B fonctionne sur mon GPU » sans ces détails. Une même famille 70B peut avoir plusieurs variantes quantifiées avec des comportements mémoire différents.
Exigences VRAM du fine-tuning QLoRA du modèle 70B
La question des qlora fine-tuning 70b model vram requirements a deux réponses :
- Le plancher de recherche peut être étonnamment bas, car QLoRA fige le modèle de base, le quantifie et entraîne de petits adaptateurs à faible rang.
- La zone de confort en production est plus élevée, car la longueur de séquence, la taille du batch, le gradient checkpointing, le pipeline de données, la cadence d’évaluation et la gestion des adaptateurs ajoutent tous une pression mémoire pratique.
Utilisez ce tableau de planification :
| Configuration de fine-tuning | Point de départ 32B | Point de départ 70B | Remarques |
|---|---|---|---|
| Expérience QLoRA minimale | 24GB à 48GB | 48GB | Gardez une longueur de séquence et une taille de batch modestes. |
| Exécution QLoRA pratique | 48GB à 80GB | 80GB | Plus d’espace pour les données, l’évaluation et moins de redémarrages. |
| Séquence plus longue ou batch effectif plus grand | 80GB ou multi-GPU | 2x80GB ou plus | La mémoire augmente avec la longueur de séquence et la stratégie d’entraînement. |
| Fine-tuning complet | Multi-GPU | Cluster multi-GPU | L’état de l’optimiseur fait du fine-tuning complet un problème différent. |
Si votre requête est qlora fine-tune 70b model vram requirements, commencez par prouver une exécution contrainte sur 48GB ou 80GB, puis augmentez la longueur de séquence et le batch effectif uniquement après avoir enregistré la mémoire de pointe réelle. Pour un workflow de fine-tuning en production, une capacité de 80GB ou multi-GPU est généralement plus facile à exploiter qu’une configuration ponctuelle au minimum mémoire.
Le cache KV et la longueur de contexte peuvent changer la réponse
Un modèle 70B qui tient avec un contexte de 4K peut ne pas tenir avec un contexte de 32K. Le cache KV augmente avec :
- Le nombre de couches.
- Les têtes KV et la dimension des têtes.
- La longueur de contexte.
- La taille du batch ou le nombre de séquences actives.
- Les octets par élément du cache KV.
Les moteurs de serving gèrent cela différemment. vLLM expose l’utilisation mémoire et le comportement du cache KV comme des préoccupations de serving de premier ordre. llama.cpp et les variantes de serving local de type Ollama exposent les choix de contexte et de déchargement, qui peuvent permettre à un modèle de tenir, mais avec des compromis de performance.
Le workflow pratique :
- Chargez le modèle avec la quantification prévue.
- Définissez la vraie longueur de contexte, pas la valeur par défaut.
- Exécutez une distribution de prompts qui correspond à la production.
- Augmentez la concurrence jusqu’à ce que la latence ou la mémoire échoue.
- Enregistrez la VRAM de pointe, les requêtes échouées, les tokens par seconde et la qualité des sorties acceptées.
Ne dimensionnez pas les 70b model vram requirements à partir d’un test de chargement à vide. Dimensionnez-les en fonction du contexte et de la concurrence que vous exécuterez réellement.
Une feuille de calcul VRAM simple
Utilisez cette feuille de calcul avant de louer ou de réserver de la capacité.
model_family:
parameter_count: 32B | 70B | other
precision: fp16 | bf16 | int8 | 4-bit | mixed
serving_engine: Ollama | llama.cpp | vLLM | SGLang | TensorRT-LLM | other
target_context_window:
input_tokens_p50:
input_tokens_p95:
output_tokens_p50:
output_tokens_p95:
target_concurrency:
batching_policy:
fine_tuning_method: none | LoRA | QLoRA | full fine-tune
gpu_candidate:
gpu_memory:
observed_idle_load_vram:
observed_peak_vram:
oom_failures:
tokens_per_second:
accepted_outputs_per_hour:
cost_per_accepted_output:
Pour la planification des coûts, associez la feuille de calcul à les prix de location de GPU, les coûts cachés du cloud GPU et le TCO d’un cluster GPU.
Quand une API de modèle est meilleure que la location de GPU
La capacité GPU a du sens lorsque vous avez besoin d’un contrôle direct sur les poids, la quantification, le déploiement, les adaptateurs personnalisés, le serving privé ou une utilisation soutenue.
Une API de modèle peut être meilleure lorsque :
- Le trafic est irrégulier.
- Le produit change fréquemment de modèle.
- L’équipe ne veut pas gérer l’infrastructure de serving.
- L’économie unitaire est plus simple à gérer par requête que par heure de GPU.
- Vous avez besoin d’un accès rapide à plusieurs familles de modèles plutôt qu’à un déploiement fixe.
Flatkey appartient au côté API de cette décision. Il offre aux développeurs un endpoint compatible OpenAI, une seule clé, un seul solde, une seule facture et un registre d’utilisation sur les modèles et outils officiels. Si votre feuille de calcul 70b model vram requirements montre une faible utilisation, des marges OOM fragiles ou une forte surcharge opérationnelle, testez une base de référence modèle/API avant de vous engager dans la location de GPU. Le guide cloud GPU vs API de modèle fournit le cadre de décision.
Sources officielles et documentation à garder ouvertes
| Source | Pourquoi c’est important |
|---|---|
| Article QLoRA et dépôt QLoRA | Référence pour le fine-tuning d’adaptateurs à faible consommation mémoire des grands modèles. |
| Documentation de quantification bitsandbytes de Hugging Face | Comportement pratique du chargement en 8 bits et 4 bits dans Transformers. |
| Documentation vLLM | Mémoire de service, batching et comportement du cache KV. |
| Dépôt llama.cpp | GGUF, déchargement CPU/GPU et comportement de l’inférence locale. |
| Bibliothèque de modèles Ollama | Tags de modèles, tailles des artefacts quantifiés et options de service local. |
| NVIDIA A100, H100, H200, et DGX B200 | Paliers officiels de mémoire GPU utilisés dans les décisions de dimensionnement. |
Recommandation finale
Pour les modèles 32B, commencez avec 24 Go pour des expériences en 4 bits, 48 Go pour une inférence confortable, et 80 Go si vous voulez du FP16/BF16, une longueur de contexte plus élevée ou une marge pour le fine-tuning.
Pour les modèles 70B, considérez 48 Go comme le point de départ contraint en 4 bits, 80 Go comme le palier pratique pour une inférence sérieuse, et 96 Go à 180 Go ou le multi-GPU comme la marge de production. Pour du 70B en FP16/BF16, prévoyez du multi-GPU ou des GPU à très grande capacité mémoire.
La meilleure réponse aux besoins en VRAM pour un modèle 70b n’est pas un chiffre de GPU unique. C’est une configuration mesurée : modèle, quantification, longueur de contexte, concurrence, moteur de service, méthode de fine-tuning et coût par sortie acceptée.
Questions fréquemment posées
De combien de VRAM un modèle 70B a-t-il besoin ?
Un modèle 70B nécessite environ 140 Go uniquement pour les poids FP16 ou BF16, environ 70 Go avant surcharge en 8 bits, et à peu près 35 Go à 45 Go pour de nombreuses variantes quantifiées en 4 bits. En pratique, les besoins en VRAM pour un modèle 70b sont plus élevés une fois pris en compte le cache KV, les tampons d’exécution, la longueur de contexte et la concurrence.
Un modèle 70B peut-il fonctionner sur un GPU de 48 Go ?
Oui, un modèle 70B peut fonctionner sur un GPU de 48 Go lorsqu’il est fortement quantifié et que le contexte/la concurrence sont contrôlés. C’est un niveau viable pour l’inférence locale et des tests limités, mais 80 Go ou plus est plus sûr pour un service de type production.
Quels sont les besoins en VRAM d’un modèle Ollama 70B ?
Pour les besoins en VRAM d’un modèle ollama 70b, vérifiez le tag exact du modèle et la taille de l’artefact quantifié. 48 Go peuvent suffire pour certains modèles 70B quantifiés, mais 64 Go à 80 Go offrent plus de marge pour le contexte et réduisent les échecs de type OOM.
Quels sont les besoins en VRAM d’un modèle QLoRA 70B ?
Pour les besoins en VRAM d’un modèle qlora 70b, 48 Go constituent un plancher pratique de recherche pour des expériences contraintes, tandis que 80 Go ou une capacité multi-GPU sont plus sûrs pour des longueurs de séquence plus longues, des tailles de lots effectives plus grandes et des flux de travail de fine-tuning en production.
24 Go suffisent-ils pour un modèle 70B ?
24 Go ne suffisent généralement pas pour une inférence GPU confortable d’un modèle 70B. Cela peut fonctionner avec une forte quantification, un déchargement CPU, de petites fenêtres de contexte ou des expériences lentes, mais il vaut mieux considérer cela comme un palier 32B quantifié.
80 Go suffisent-ils pour un modèle 70B ?
80 Go suffisent pour de nombreux workloads d’inférence 70B quantifiés et pour des exécutions QLoRA contraintes. Ce n’est généralement pas suffisant pour une inférence complète 70B en FP16/BF16 sur un seul GPU après surcharge, et cela peut encore échouer si la fenêtre de contexte ou la concurrence est trop importante.
