gpu memory, large language model, llm, fine-tuning, inference, calculator - Platform For AI

La mémoire GPU nécessaire au déploiement et à l'affinage d'un grand modèle de langage (LLM) dépend de facteurs tels que le nombre de paramètres, la précision et la longueur de séquence. Utilisez le calculateur présenté dans cette rubrique pour estimer rapidement vos besoins en mémoire GPU et choisir la spécification GPU adaptée.

Instructions

Sélectionnez les paramètres du modèle dans le calculateur ci-dessous.
Consultez les résultats estimés pour déterminer la configuration requise.

Comparez les spécifications GPU disponibles avec les besoins calculés.

1. Calculateur simple de mémoire GPU

Remarque

Cette rubrique estime la mémoire GPU requise pour le déploiement et l'affinage des LLM selon des méthodes de calcul courantes. L'utilisation réelle de la mémoire GPU peut varier en fonction des structures de réseau du modèle et des algorithmes employés.
Pour les modèles Mixture-of-Experts (MoE), tels que DeepSeek-R1-671B, l'ensemble des 671 milliards de paramètres du modèle doit être chargé. Toutefois, seuls 37 milliards de paramètres sont activés lors de l'inférence. Par conséquent, vous devez calculer la mémoire GPU pour les valeurs d'activation sur la base du nombre de 37 milliards de paramètres.
Lors de l'affinage du modèle, les paramètres du modèle, les valeurs d'activation et les gradients sont généralement stockés avec une précision de 16 bits. L'optimiseur Adam/AdamW est utilisé et son état est conservé avec une précision de 32 bits.

Inférence

Title

Model type:

Total model parameters: B

Inference concurrency:

Sequence length:

Scenario	Required GPU memory (GB)
Inference (16-bit)	-
Inference (8-bit)	-
Inference (4-bit)	-

Affinage

Model type:

Total model parameters: B

Parameter precision: bit

Optimizer:

Training batch size:

Sequence length:

Scenario	Required GPU memory (GB)
Full fine-tuning	-
LoRA fine-tuning	-
QLoRA (8-bit) fine-tuning	-
QLoRA (4-bit) fine-tuning	-

2. Facteurs influençant la mémoire GPU pour l'inférence de modèles

La mémoire GPU requise pour l'inférence de modèles se compose des éléments principaux suivants :

2.1 Paramètres du modèle

Lors de l'inférence, les paramètres du modèle doivent être stockés en mémoire. La formule de calcul de l'espace mémoire qu'ils occupent est la suivante : Nombre de paramètres × Précision des paramètres. Les précisions courantes sont FP32 (4 octets), FP16 (2 octets) et BF16 (2 octets). Pour les grands modèles de langage (LLM), les paramètres sont généralement stockés au format FP16 ou BF16. Par exemple, pour un modèle 7B avec une précision FP16, la mémoire GPU nécessaire s'élève à :

$\frac{7 \times 1 0 ^{9} \times 2}{1 0 ^{9}} = 14 GB$

2.2 Valeurs d'activation

Pendant l'inférence d'un LLM, il faut calculer la valeur d'activation de chaque couche de neurones. L'espace mémoire GPU correspondant dépend positivement de la taille du lot (batch size), de la longueur de la séquence et de l'architecture du modèle (nombre de couches, dimension de la couche cachée, etc.). Cette relation s'exprime comme suit : $Activation value memory \propto b \times s \times h \times L \times p a r am_b y t es$

Où :

b (taille du lot) : taille du lot pour une seule requête. Elle est généralement de 1 pour les services en ligne, mais peut dépasser 1 lors du traitement par lots.
s (longueur de la séquence) : longueur totale de la séquence, incluant l'entrée et la sortie (nombre de jetons).
h (dimension de la couche cachée) : dimension de la couche cachée du modèle.
L (couches) : nombre de couches Transformer dans le modèle.
param_bytes : précision utilisée pour stocker les valeurs d'activation, généralement 2 octets.

À partir de ces facteurs et de l'expérience pratique, vous pouvez simplifier l'estimation. Pour un modèle 7B avec une taille de lot (b) de 1, une longueur de séquence (s) de 2048 et une valeur param_bytes de 2, la mémoire allouée aux valeurs d'activation représente environ 10 % de l'empreinte mémoire du modèle. Cela offre une marge de sécurité. Le calcul donne : $14 GB \times 0.1 = 1.4 GB$ .

2.3 Cache KV

Pour accélérer l'inférence des LLM, les matrices de clé (K) et de valeur (V) calculées pour chaque couche Transformer sont généralement mises en cache. Cette approche évite de recalculer les paramètres du mécanisme d'attention pour tous les jetons précédents à chaque pas de temps. L'utilisation d'un cache KV réduit la complexité computationnelle de $O (n^{2})$ à $O (n)$ , ce qui améliore considérablement la vitesse d'inférence. Comme pour les valeurs d'activation, l'espace mémoire GPU occupé par le cache KV dépend positivement de la taille du lot, de la longueur de la séquence, de la concurrence et de l'architecture du modèle (nombre de couches, dimension de la couche cachée, etc.). Cette relation s'exprime comme suit : $K V cache memory \propto 2 \times b \times s \times h \times L \times C \times p a r am_b y t es$

Où :

2 : représente les deux matrices à stocker, K (Key) et V (Value).
b (taille du lot) : taille du lot pour une seule requête. Elle est généralement de 1 pour les services en ligne, mais peut dépasser 1 lors du traitement par lots.
s (longueur de la séquence) : longueur totale de la séquence, incluant l'entrée et la sortie (nombre de jetons).
h (dimension de la couche cachée) : dimension de la couche cachée du modèle.
L (couches) : nombre de couches Transformer dans le modèle.
C (concurrence) : niveau de concurrence des requêtes adressées à l'interface de service.
param_bytes : précision utilisée pour stocker les valeurs d'activation, généralement 2 octets.

À partir de ces facteurs et de l'expérience pratique, vous pouvez simplifier l'estimation. Pour un modèle 7B avec une concurrence (C) de 1, une taille de lot (b) de 1, une longueur de séquence (s) de 2048 et une valeur param_bytes de 2, la mémoire allouée au cache KV représente environ 10 % de l'empreinte mémoire du modèle. Cela offre une marge de sécurité. La valeur obtenue est : $1.4 GB$ .

2.4 Autres facteurs

Outre les facteurs mentionnés ci-dessus, les données d'entrée du lot actuel, les cœurs CUDA ainsi que le framework d'apprentissage profond lui-même (PyTorch ou TensorFlow, par exemple) consomment également une partie de la mémoire GPU, généralement entre 1 Go et 2 Go.

Sur la base de cette analyse, la mémoire GPU minimale requise pour déployer un LLM 7B en vue de l'inférence est d'environ :

$14 GB + 1.4 GB + 1.4 GB + 2 GB = 18.8 GB$

3. Facteurs influençant l'utilisation de la mémoire GPU pour le fine-tuning des modèles

La mémoire GPU nécessaire au fine-tuning d'un modèle se compose des éléments principaux suivants :

3.1 Paramètres du modèle

Lors du fine-tuning, il est impératif de stocker les paramètres du modèle. La formule de calcul de la mémoire GPU qu'ils occupent est la suivante : Number of parameters × Parameter precision. Les précisions courantes sont FP32 (4 octets), FP16 (2 octets) et BF16 (2 octets). Pour le fine-tuning des LLM, les paramètres sont généralement stockés en FP16 ou BF16. Par exemple, pour un modèle 7B avec une précision FP16, la mémoire GPU requise est :

$\frac{7 \times 1 0 ^{9} \times 2}{1 0 ^{9}} = 14 GB$

3.2 Paramètres de gradient

Pendant la phase de rétropropagation de l'entraînement du modèle, les gradients doivent être calculés pour les paramètres du modèle. Le nombre de gradients correspond exactement au nombre de paramètres entraînés. Dans les LLM, les gradients sont généralement stockés avec une précision de 2 octets. Ainsi, pour un modèle 7B, la mémoire GPU requise pour les gradients varie selon la méthode de fine-tuning :

|
Méthode de fine-tuning
|
Mécanisme d'entraînement
|
Scénarios
|
Mémoire GPU pour les gradients (modèle 7B, 1 % des paramètres, stockage sur 2 octets)
| | --- | --- | --- | --- | |
Fine-tuning complet des paramètres
|
Le nombre de paramètres entraînables est identique au nombre de paramètres du modèle.
|
Besoin de haute précision avec puissance de calcul suffisante
|
14 Go
| |
LoRA (adaptation à faible rang)
|
Le fine-tuning LoRA fige les paramètres originaux du modèle et n'entraîne que les matrices de faible rang. Le nombre de paramètres entraînables dépend de la structure du modèle et de la taille des matrices de faible rang, représentant généralement 0,1 % à 1 % du total des paramètres du modèle.
|
Adaptation à des tâches spécifiques avec ressources limitées
|
0,14 Go
| |
QLoRA (Quantification + LoRA)
|
Le modèle pré-entraîné est compressé en 4 bits ou 8 bits. Le modèle est ensuite affiné à l'aide de LoRA. La double quantification et les optimiseurs paginés sont introduits pour réduire davantage l'utilisation de la mémoire GPU. Le nombre de paramètres entraînables représente généralement 0,1 % à 1 % du total des paramètres du modèle.
|
Fine-tuning de modèles à très grande échelle
|
0,14 Go
|

3.3 État de l'optimiseur

Durant l'entraînement, l'état de l'optimiseur doit également être sauvegardé. Le nombre de valeurs d'état est lié au nombre de paramètres entraînables. De plus, les modèles utilisent souvent un entraînement en précision mixte. Cela signifie que les paramètres du modèle et les gradients sont stockés avec une précision de 2 octets, tandis que l'état de l'optimiseur est stocké avec une précision de 4 octets. Cette pratique garantit une haute précision lors des mises à jour des paramètres et prévient l'instabilité numérique ou les débordements causés par la plage dynamique limitée du FP16/BF16. Le stockage de l'état en précision 4 octets double la mémoire GPU requise. Le tableau suivant décrit les optimiseurs courants :

Type d'optimiseur	Mécanisme de mise à jour des paramètres	Exigence de stockage supplémentaire (par paramètre entraînable)	Scénarios	Mémoire GPU pour l'état de l'optimiseur (modèle 7B, stockage sur 4 octets)
Type d'optimiseur	Mécanisme de mise à jour des paramètres		Scénarios	Fine-tuning complet des paramètres	Fine-tuning LoRA (1 % des paramètres)	Fine-tuning QLoRA (1 % des paramètres)
SGD	Utilise uniquement le gradient actuel	0 (aucun état supplémentaire)	Petits modèles ou expérimentations	0	0	0
SGD + Momentum	Inclut un terme de momentum	1 nombre à virgule flottante (momentum)	Meilleure stabilité	28 Go	0,28 Go	0,28 Go
RMSProp	Taux d'apprentissage adaptatif	1 nombre à virgule flottante (second moment)	Optimisation non convexe	28 Go	0,28 Go	0,28 Go
Adam/AdamW	Momentum + Taux d'apprentissage adaptatif	2 nombres à virgule flottante (premier et second moments)	Courant pour les LLM	56 Go	0,56 Go	0,56 Go

3.4 Valeurs d'activation

Lors de l'entraînement, les valeurs d'activation intermédiaires issues de la passe avant doivent être stockées afin de calculer les gradients durant la rétropropagation. Cette consommation de mémoire est positivement corrélée à la taille du lot (batch size), à la longueur de la séquence et à l'architecture du modèle, telle que le nombre de couches et la taille des couches cachées. La relation peut s'exprimer ainsi : $Activation value memory \propto b \times s \times h \times L \times p a r am_b y t es$

Où :

b (taille du lot) : la taille du lot.
s (longueur de séquence) : la longueur totale de la séquence, incluant l'entrée et la sortie (nombre de tokens).
h (taille cachée) : la dimension de la couche cachée du modèle.
L (couches) : le nombre de couches Transformer dans le modèle.
param_bytes : la précision pour le stockage des valeurs d'activation, généralement 2 octets.

Sur la base de ces facteurs et de l'expérience pratique, vous pouvez simplifier l'estimation. Pour un modèle 7B avec une taille de lot (b) de 1, une longueur de séquence (s) de 2048 et des param_bytes de 2, la mémoire pour les valeurs d'activation peut être estimée grossièrement à 10 % de l'empreinte mémoire du modèle. Cela offre une marge de sécurité. Le calcul est le suivant : $14 GB \times 0.1 = 1.4 GB$ .

3.5 Autres facteurs

Outre les facteurs mentionnés ci-dessus, les données d'entrée du lot actuel, les cœurs CUDA et le framework d'apprentissage profond lui-même, tel que PyTorch ou TensorFlow, consomment également une partie de la mémoire GPU, généralement entre 1 Go et 2 Go.

Selon cette analyse, la mémoire GPU approximative requise pour le fine-tuning d'un LLM 7B est :

|
Méthode de fine-tuning
|
Exigences de mémoire GPU du modèle
|
Mémoire des gradients
|
État de l'optimiseur Adam
|
Valeurs d'activation
|
Autres
|
Total
| | --- | --- | --- | --- | --- | --- | --- | |
Fine-tuning complet des paramètres
|
14 Go
|
14 Go
|
56 Go
|
1,4 Go
|
2 Go
|
87,4 Go
| |
LoRA (adaptation à faible rang)
|
14 Go
|
0,14 Go
|
0,56 Go
|
1,4 Go
|
2 Go
|
18,1 Go
| |
QLoRA (quantification 8 bits + LoRA)
|
7 Go
|
0,14 Go
|
0,56 Go
|
1,4 Go
|
2 Go
|
11,1 Go
| |
QLoRA (quantification 4 bits + LoRA)
|
3,5 Go
|
0,14 Go
|
0,56 Go
|
1,4 Go
|
2 Go
|
7,6 Go
|

Remarque

Les LLM utilisent généralement l'optimiseur Adam/AdamW.
Dans le tableau, les paramètres du modèle QLoRA sont stockés avec une précision de 4 bits ou 8 bits, et l'état de l'optimiseur est stocké avec une précision de 32 bits (4 octets). Tous les autres paramètres sont stockés avec une précision de 16 bits (2 octets).

4. FAQ

Q : Comment vérifier le nombre de paramètres d’un LLM ?

R : Pour les LLM open source, le nombre de paramètres est généralement indiqué dans le nom du modèle. Par exemple, Qwen-7B comporte $7 \times 1 0^{9}$ paramètres. Qwen3-235B-A22B totalise $235 \times 1 0^{9}$ paramètres, dont $22 \times 1 0^{9}$ sont activés lors de l’inférence. Si le nom du modèle ne précise pas ce nombre, consultez la documentation associée pour obtenir cette information.

Q : Comment vérifier la précision des paramètres d’un LLM ?

R : Sauf indication contraire, les LLM utilisent généralement un stockage sur 16 bits (2 octets). Les modèles quantifiés peuvent recourir à un stockage sur 8 ou 4 bits. Pour plus de détails, reportez-vous à la documentation du modèle. Par exemple, si vous utilisez un modèle issu de PAI Model Gallery, la page produit indique généralement la précision des paramètres :

Instructions d’entraînement pour Qwen2.5-7B-Instruct :

Q : Comment vérifier l’optimiseur et la précision de son état pour le fine-tuning d’un LLM ?

R : L’entraînement des LLM fait généralement appel à l’optimiseur Adam/AdamW avec une précision des paramètres sur 32 bits (4 octets). Pour obtenir des configurations plus détaillées, examinez la commande de démarrage ou le code.

Q : Comment vérifier l’utilisation de la mémoire GPU ?

R : Consultez l’utilisation de la mémoire GPU sur les pages de surveillance graphique de PAI-DSW, PAI-EAS ou PAI-DLC :

Sur la page des détails du service PAI-EAS, cliquez sur l’onglet Monitoring. Dans le panneau de surveillance GPU, vous pouvez consulter des métriques telles que GPU Utilization, GPU Memory (mémoire GPU utilisée et totale) et GPU Memory Utilization (pourcentage d’utilisation de la mémoire GPU). Ajustez la plage de temps de surveillance à l’aide du sélecteur situé en haut de la page.

Vous pouvez également exécuter la commande nvidia-smi dans le terminal du conteneur pour vérifier l’utilisation du GPU :

    root@dsw-xxx:/mnt/workspace# nvidia-smi
    Tue Jun  3 13:58:56 2025
    +-----------------------------------------------------------------------------------------+
    | NVIDIA-SMI 550.127.08          Driver Version: 550.127.08    CUDA Version: 12.4        |
    |-----------------------------------------+------------------------+----------------------+
    | GPU  Name              Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
    | Fan  Temp   Perf       Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M.  |
    |                                         |                        |               MIG M. |
    |=========================================+========================+======================|
    |   0  NVIDIA A10                 Off |   0000000:00:08.0 Off |                    0 |
    |  0%   28C    P8          11W / 150W |       1MiB / 23028MiB |      0%      Default |
    |                                         |                        |                  N/A |
    +-----------------------------------------+------------------------+----------------------+

    +-----------------------------------------------------------------------------------------+
    | Processes:                                                                              |
    |  GPU   GI   CI        PID   Type   Process name                        GPU Memory       |
    |        ID   ID                                                           Usage          |
    |=========================================================================================|
    |  No running processes found                                                             |
    +-----------------------------------------------------------------------------------------+

Q : Quelles sont les erreurs « out of memory » courantes ?

R : Lorsque la mémoire GPU d’une carte NVIDIA est saturée, une erreur CUDA out of memory. Tried to allocate X GB se produit. Dans ce cas, augmentez la mémoire GPU disponible ou réduisez certains paramètres, tels que la taille du lot (batch size) ou la longueur de séquence.