Exigences de mémoire GPU pour les LLM : poids, cache KV, activations et surcharge

Les exigences de mémoire GPU pour les LLM ne se résument pas à « la taille du modèle plus un peu d’espace ». Un job de service ou d’entraînement comporte plusieurs compartiments mémoire distincts : poids du modèle, cache KV, activations, espaces de travail du framework, graphes CUDA, tampons temporaires et marge opérationnelle.

La règle rapide de planification est la suivante :

required VRAM =
  model weights
+ KV cache for live tokens
+ activation and workspace memory
+ training state, if training or full fine-tuning
+ allocator and safety headroom

C’est pourquoi deux équipes peuvent exécuter le même modèle 70B sur la même classe de GPU et obtenir des résultats différents. L’une utilise de courtes invites, un flux unique, un cache KV en FP8 et un batching prudent. L’autre utilise un contexte long, de nombreuses requêtes simultanées, la capture de graphes CUDA et un réglage élevé de gpu_memory_utilization. Le premier job tient. Le second échoue avec des erreurs de manque de mémoire ou dégrade la latence en déportant le travail ailleurs.

Ce guide fournit une feuille de calcul pratique pour les llm gpu memory requirements en inférence, en service vLLM, en fine-tuning et en entraînement. Utilisez-le avant de louer un GPU, de choisir une capacité H100 plutôt que H200 ou B200, ou de décider si une API de modèle est plus simple que l’exploitation de votre propre point de terminaison GPU.

Réponse rapide sur les exigences de mémoire GPU des LLM

Pour l’inférence, commencez par les poids, puis dimensionnez le cache KV en fonction de la longueur du contexte et de la concurrence. Pour l’entraînement, les poids ne sont que le début ; les états de l’optimiseur, les gradients et les activations enregistrées dominent le plan mémoire.

Si vous n’avez besoin que des sorties du modèle, comparez d’abord un service direct sur GPU à une base de référence d’API de modèle. Les GPU directs sont pertinents lorsque vous avez besoin de poids personnalisés, d’un contrôle du placement, d’une politique d’exécution privée ou d’une charge de travail moins coûteuse une fois l’utilisation mesurée. Si vous avez surtout besoin de réponses API fiables, une offre de modèle gérée peut éviter des semaines de dimensionnement GPU, de mise en file d’attente et de travail d’exploitation.

Feuille de calcul des exigences de mémoire GPU des LLM

Utilisez cette feuille de calcul avant de choisir une instance.

L’erreur la plus courante consiste à faire tenir les poids et à oublier les jetons actifs. Pour une estimation des exigences de mémoire GPU pour l’inférence LLM, le cache KV peut faire la différence entre un endpoint stable et une boucle d’OOM.

Étape 1 : calculer la mémoire des poids du modèle

Les poids sont la partie la plus simple des exigences de mémoire GPU pour les charges de travail LLM.

weight_memory_gib = parameters x bytes_per_parameter / 1024^3

Ce tableau constitue une borne inférieure. Les déploiements réels ajoutent des échelles de quantification, des tampons non liés aux paramètres, l’état du tokenizer/runtime, des espaces de travail temporaires et une surcharge de service.

Pour une estimation de la mémoire GPU vLLM pour un modèle 70B, les poids BF16/FP16 à eux seuls dépassent déjà un seul H100 de 80 Go. Un seul H200 dispose de 141 Go de HBM3e selon la page H200 de NVIDIA, donc les poids peuvent théoriquement tenir, mais le cache KV restant et la marge d’exécution peuvent encore imposer un contexte plus court, une concurrence plus faible, une quantification du cache KV ou un parallélisme tensoriel. NVIDIA indique H100 SXM à 80 Go, H200 à 141 Go et DGX B200 comme huit GPU Blackwell avec 1 440 Go de HBM3e au total, ce qui équivaut en pratique à 180 Go par GPU B200 dans ce système.

Étape 2 : calculer la mémoire du cache KV pour les exigences de mémoire GPU des LLM

Le cache KV est la mémoire utilisée pour stocker les clés et les valeurs d’attention des jetons déjà traités. Il permet au modèle de générer sans recalculer le préfixe complet à chaque fois.

Pour l’inférence d’un transformeur decoder-only :

kv_cache_bytes =
  active_tokens
x num_layers
x num_kv_heads
x head_dim
x 2
x bytes_per_kv_element

Où :

À titre d’exemple, une configuration de type Llama 70B avec 80 couches, 8 têtes KV et une dimension de tête de 128 utilise :

80 x 8 x 128 x 2 x 2 bytes = 327,680 bytes per token

Soit environ 0,3125 Mio par jeton actif dans un cache KV BF16/FP16.

Le nombre exact varie selon l’architecture du modèle. Un modèle avec davantage de têtes KV utilise plus de mémoire KV. Un modèle avec attention multi-requête ou à requêtes groupées peut utiliser beaucoup moins de mémoire KV qu’un design d’attention multi-têtes complet.

vLLM documente plusieurs paramètres importants ici : --gpu-memory-utilization contrôle la fraction de la mémoire GPU utilisée par l’exécuteur du modèle, --kv-cache-memory-bytes peut dimensionner explicitement le cache KV, --kv-cache-dtype peut sélectionner la précision du cache, et le guide d’économie de mémoire recommande de réduire max_model_len et max_num_seqs lorsque la mémoire est limitée. vLLM documente également le cache KV FP8 comme un moyen de réduire l’empreinte du cache KV et de prendre en charge un contexte plus long ou un débit plus élevé, avec toutefois une validation de précision toujours nécessaire.

Étape 3 : ajouter les activations et la surcharge d’exécution

Pour l’inférence, la mémoire des activations est généralement plus faible que celle des poids et du cache KV, mais elle n’est pas nulle. Le préremplissage, les CUDA graphs, les kernels d’attention, les tampons temporaires, les processeurs multimodaux, le décodage spéculatif et la planification par lots peuvent réserver de la mémoire supplémentaire.

Pour l’entraînement, la mémoire des activations devient un terme de premier ordre. L’anatomie de la mémoire des modèles de Hugging Face liste les composants mémoire d’entraînement comme les poids du modèle, les états de l’optimiseur, les gradients, les activations de passage avant conservées pour le calcul du gradient, les tampons temporaires et la mémoire spécifique aux fonctionnalités. Elle note également que la mémoire des activations dépend de la longueur de séquence, de la taille cachée et de la taille de lot.

Une répartition utile pour la planification est :

Ne faites pas tourner la production à 99 % de mémoire simplement parce qu’une requête de test tient. Cela ne laisse aucune place pour des invites plus longues, des rechargements à chaud, la capture de CUDA graph, le comportement de l’allocateur ou un mix de trafic différent de celui du benchmark.

Étape 4 : estimer la mémoire d’entraînement et de fine-tuning

La mémoire d’entraînement est plus importante parce que le GPU doit contenir davantage que les poids du passage avant.

Pour un fine-tuning complet avec précision mixte et AdamW, l’anatomie de la mémoire de Hugging Face fournit une répartition pratique : l’entraînement en précision mixte peut conserver des copies des poids en FP32 et FP16/BF16, les états de l’optimiseur AdamW, les gradients, les activations sauvegardées, les tampons temporaires et la mémoire spécifique aux fonctionnalités. La même page résume une configuration AdamW en précision mixte typique à 18 octets par paramètre de modèle, plus la mémoire des activations.

Cela signifie :

C’est pourquoi les requêtes gpu memory requirements LLM training nécessitent une réponse différente de celle des requêtes d’inférence. Un modèle 70B qui peut être servi avec du parallélisme tensoriel et un cache KV quantifié n’est pas automatiquement praticable pour un fine-tuning complet sur un petit nombre de GPU.

Les moyens de réduire la mémoire d’entraînement incluent :

Pour l’entraînement complet, les formules vous amènent à une première configuration de cluster. Elles ne remplacent pas une exécution mesurée du framework.

Étape 5 : relier les exigences de mémoire GPU des LLM aux tailles courantes de mémoire GPU

Utilisez la capacité mémoire GPU comme une contrainte, et non comme seul critère d’achat. La bande passante mémoire, la topologie NVLink, le réseau, le stockage, la planification et l’utilisation peuvent compter autant que la VRAM brute.

Si votre feuille de calcul indique qu’un seul H200 « tient tout juste » un modèle 70B, ce n’est pas un plan de déploiement. C’est un signal pour tester ces paramètres :

Pour les détails de sélection matérielle, utilisez cette feuille de calcul en parallèle avec les guides Flatkey sur le meilleur GPU pour l’inférence LLM, H200 vs H100 et B200 vs H200.

Exemple : dimensionnement de l’inférence 70B dans vLLM

Voici une manière prudente de raisonner sur les vllm gpu memory requirements 70b model vram avant de louer de la capacité.

Supposons :

Comparez ensuite quelques configurations de service :

En pratique, un plan vLLM pour un modèle 70B se répartit généralement dans l’un de ces cas :

C’est la réponse pratique à la question des exigences de mémoire GPU pour le service des LLM : le nombre de paramètres vous dit si le modèle peut se charger ; le cache KV et la réserve d’exécution vous disent s’il peut servir un trafic utile.

Pourquoi la longueur du contexte change la réponse

Un contexte long est coûteux parce que le cache croît avec les tokens actifs. Si vous doublez le contexte de 8K à 16K, le cache KV double approximativement pour le même modèle, la même précision et la même concurrence. Si vous doublez la concurrence au même contexte, le cache KV double à nouveau à peu près.

Pour les équipes qui comparent des plans llm hardware requirements gpu memory, cela crée un schéma de dimensionnement simple :

plus d’utilisateurs x des prompts plus longs x plus de tokens de sortie = plus de cache KV

Avant de louer un GPU plus grand, demandez-vous si le produit a réellement besoin du contexte maximal pour chaque requête. De nombreux systèmes peuvent router :

C’est souvent moins coûteux et plus stable que d’exécuter un seul énorme point de terminaison avec un seul paramètre mémoire global.

Ce qu’il faut mesurer dans le premier benchmark

Exécutez un benchmark qui ressemble au trafic de production, pas à un seul prompt du chemin heureux.

Pour les déploiements multi-nœuds, associez cela aux listes de contrôle GPU cluster architecture et GPU cluster TCO. Un modèle compatible avec la mémoire peut malgré tout être coûteux si le réseau, le stockage, la mise en file d’attente ou l’utilisation sont faibles.

Erreurs courantes

Guide de décision : louer des GPU ou utiliser une API de modèle ?

La capacité GPU directe est la bonne direction lorsque vous avez besoin d’un ou plusieurs des éléments suivants :

Flatkey est utile comme voie de référence lorsque le contrôle matériel n’est pas l’exigence du produit. Il offre aux équipes un point d’équilibre entre les modèles officiels et les outils, afin que vous puissiez comparer le coût de location du GPU au coût de sortie de l’API du modèle avant de vous engager dans un cluster de longue durée. Si le benchmark prouve que les GPU directs gagnent, utilisez la feuille de calcul mémoire ci-dessus pour louer la configuration la plus petite et fiable plutôt que la plus grande et impressionnante.

Questions fréquemment posées

De combien de mémoire GPU un LLM de 70B a-t-il besoin ?

Les poids BF16 ou FP16 pour un modèle de 70B nécessitent environ 130 GiB avant le cache KV et la surcharge d’exécution. Les poids INT8 représentent environ 65 GiB avant les métadonnées. Les poids 4 bits représentent environ 33 GiB avant les métadonnées de quantification. Pour l’inférence en production, ajoutez le cache KV pour le contexte et la concurrence, la réserve du framework de service et une marge de sécurité.

Pourquoi un modèle se charge-t-il mais échoue-t-il sous trafic ?

Le test de chargement peut ne couvrir que les poids. Le trafic réel ajoute le cache KV pour les invites actives et les jetons générés, la surcharge de batch, les tampons temporaires et les réserves du framework. Des invites plus longues et davantage de séquences concurrentes peuvent faire basculer le même modèle en OOM.

Qu’est-ce qui affecte le plus les besoins en mémoire GPU pour l’inférence LLM ?

Les variables les plus importantes sont la taille du modèle, la précision des poids, la longueur du contexte, les séquences concurrentes, la précision du cache KV et les paramètres du framework de service. Pour un service à long contexte, le cache KV devient souvent le goulot d’étranglement.

Qu’est-ce qui affecte les besoins matériels d’un LLM en mémoire GPU pour l’entraînement ?

L’entraînement ajoute les états de l’optimiseur, les gradients, les activations sauvegardées, les tampons temporaires et la surcharge du framework distribué. La taille du batch, la longueur de séquence, le checkpointing des activations, le choix de l’optimiseur et la stratégie de sharding peuvent modifier considérablement le nombre de GPU.

vLLM réduit-il les besoins en mémoire GPU ?

vLLM offre des contrôles mémoire utiles et une gestion efficace du cache KV, mais il ne supprime pas le budget mémoire sous-jacent. Vous avez toujours besoin de suffisamment de VRAM pour les poids, le cache KV, les activations, la réserve d’exécution et une marge. Ses contrôles mémoire vous aident à choisir le compromis entre longueur de contexte, concurrence, précision et débit.

Le cache KV FP8 peut-il résoudre la pression mémoire des longs contextes ?

Il peut réduire l’empreinte du cache KV, et vLLM documente la prise en charge du cache KV FP8. Considérez-le comme un réglage de benchmark, pas comme un interrupteur gratuit : validez la qualité des sorties, la latence, les chemins matériels/logiciels pris en charge et le comportement en cas d’échec avant de l’utiliser en production.

Liste de contrôle finale

Avant de louer de la capacité, répondez à ces questions :

1. Quelle taille de modèle et quelle précision des poids servez-vous ?
2. Quelle est la longueur de contexte maximale que les utilisateurs peuvent réellement envoyer ?
3. Combien de séquences concurrentes doivent tenir au chargement p95 ?
4. Quelle longueur de sortie réservez-vous pour la génération ?
5. Le cache KV est-il en BF16/FP16, en FP8 ou dans un autre format pris en charge ?
6. Quelle marge reste-t-il après les poids et le cache KV ?
7. Utilisez-vous le parallélisme tensoriel, la quantification, LoRA, FSDP ou ZeRO ?
8. Quel SKU GPU exact, quelle capacité mémoire et quelle topologie le fournisseur allouera-t-il ?
9. Quels seuils d’OOM, de latence et de coût par sortie acceptée définissent le succès ?
10. Si vous n’avez pas besoin de contrôle matériel, quel est le coût de référence de l’API du modèle ?

La meilleure estimation des llm gpu memory requirements est celle qui survit à un benchmark représentatif de la production. Utilisez la feuille de calcul pour écarter rapidement les configurations GPU impossibles, puis validez la liste courte avec des longueurs de contexte réelles, une concurrence réelle et suffisamment de marge pour rester en ligne.

Sources

• Arguments du moteur vLLM : gpu_memory_utilization, kv_cache_memory_bytes, kv_cache_dtype et contrôles de cache associés : https://docs.vllm.ai/en/latest/configuration/engine_args.html
• Guide vLLM de conservation de la mémoire : parallélisme tensoriel, quantification, longueur de contexte, taille de batch, mémoire CUDA graph et contrôles de mémoire multimodaux : https://docs.vllm.ai/en/latest/configuration/conserving_memory/
• Guide vLLM du cache KV quantifié : options de cache KV FP8 et compromis : https://docs.vllm.ai/en/latest/features/quantization/quantized_kvcache.html
• Anatomie de la mémoire des modèles Hugging Face Transformers : segments de mémoire d’entraînement, états de l’optimiseur, gradients, activations et notes sur la mémoire en précision mixte : https://huggingface.co/docs/transformers/v4.57.1/en/model_memory_anatomy
• Page produit NVIDIA H100 : mémoire H100, bande passante, H100 NVL et positionnement LLM : https://www.nvidia.com/en-us/data-center/h100/
• Page produit NVIDIA H200 : 141 GB de HBM3e et bande passante mémoire : https://www.nvidia.com/en-us/data-center/h200/
• Page produit NVIDIA DGX B200 : huit GPU B200 et 1 440 GB de HBM3e au total : https://www.nvidia.com/en-us/data-center/dgx-b200/