Infrastructure IA locale
Mémoire du modèle et adéquation au GPU
De combien de mémoire ce modèle a-t-il besoin, et tient-il sur ces GPU ?
Dimensionnez un modèle, un contexte et une configuration de GPU avant de télécharger ou d'acheter quoi que ce soit.
1 · Modèle
Qwen3-8B
Qwen
Model card sur Hugging Face(s'ouvre dans un nouvel onglet)config.json(s'ouvre dans un nouvel onglet)
- Paramètres
- 8,19 Md
- Couches
- 36
- Têtes
- 32 query, 8 KV
- Dimension de tête
- 128
- Contexte maximal
- 40 960 tokens
- KV cache par token, 16 bits
- 144 KiB/token
- Dimension cachée
- 4 096
- Vocabulaire
- 151 936
Valeurs lues dans le config.json sur Hugging Face le 30 octobre 2026.
Ces valeurs viennent de Hugging Face et ne peuvent pas être modifiées. Personnalisez pour les changer.
2 · Précision
Nombre de bits utilisés pour stocker chaque paramètre.
›Quantifications publiées
Ne s'applique qu'aux formats quantifiés.
Se règle à part des poids. FP8 divise le cache par deux.
3 · Charge de travail
Tokens par séquence, prompt et texte généré compris.
Requêtes traitées en même temps, le batch.
4 · Matériel
RTX PRO 6000 Blackwell Server Edition
NVIDIA · Blackwell
Mémoire
96 GB
GDDR7 · compté comme 96 GiB
Bande passante
1 597 GB/s
Puissance max
300 to 600 W
Configurable.
Les barres comparent chaque chiffre au plus grand GPU du catalogue.
- NVLink
- Aucun
- Instances MIG
- 4
- Groupe NVLink
- Aucun, PCIe seulement
- GPU par serveur
- jusqu'à 8
Comment il est intégré aux serveurs
- The Server Edition lists no NVLink. NVIDIA-Certified RTX PRO servers hold up to 8 GPUs. NVIDIA RTX PRO 6000 Blackwell Server Edition(s'ouvre dans un nouvel onglet)
Diviser ce GPU
MIG
Se divise en 4 tranches mémoire et 4 tranches de calcul, jusqu'à 4 instances sur un GPU. Les profils :
- 1g.24gb
- 2g.48gb
- 4g.96gb
Où une instance peut démarrer :Déduit
vGPU for Compute
10 types avec 8 à 96 GB de framebuffer, jusqu'à 12 vGPU sur un GPU. Cela nécessite une licence NVIDIA AI Enterprise et un hyperviseur.
Partager sans diviser
Le time-slicing fonctionne sur n'importe quel GPU, sans isolation de la mémoire ni des défaillances entre les replicas. MPS partage un GPU entier, pas une instance MIG.
Formats numériques
Documents NVIDIA
›Spécifications et sources
- Mémoire
- 96 GB[1]
- Type
- GDDR7[1]
- Bande passante
- 1 597 GB/s[1]
- Puissance max
- 300 to 600 W[2]Configurable.
- NVLink
- 0[3]Non pris en charge.
- Instances MIG
- 4[4]
- FP4
- 4 000 TFLOPS[1]NVIDIA ne précise pas s'il s'agit de dense ou de sparse.
- FP8
- 2 000 TFLOPS[1]NVIDIA ne précise pas s'il s'agit de dense ou de sparse.
- FP16 / BF16
- 1 000 TFLOPS[1]NVIDIA ne précise pas s'il s'agit de dense ou de sparse.
- TF32
- 234 TFLOPS[1]NVIDIA ne précise pas s'il s'agit de dense ou de sparse.
Formats numériques: FP4, FP8, FP16, BF16, TF32, FP32
Les chiffres tensor sont des valeurs de crête tirées des fiches techniques. Ce ne sont pas des performances applicatives.
Sources
Chargement des sources
Total des GPU. Ils se partagent le modèle par tensor parallelism, étages de pipeline et replicas, comme défini par la disposition ci-dessous.
1 serveur de 8 GPU, le dernier avec 1
Comment le GPU est utilisé
Divisez chaque GPU en tranches ou partagez-le entre des replicas au lieu d'utiliser plus de GPU. Les tranches et les parts exécutent des replicas du modèle : elles ne peuvent pas être réunies en un groupe tensor parallel.
›Disposition du déploiement
Comment les GPU se partagent le modèle. La mémoire par GPU, la place pour le KV cache et le nombre de GPU en découlent, comme vLLM les répartit.
Étages de pipeline
Découpe les couches en tronçons sur différents GPU. Peu de données passent d'un étage à l'autre : adapté aux GPU sans liaison rapide et aux serveurs reliés par un réseau.
Replicas
Copies indépendantes du modèle, chacune avec son propre KV cache. Elles se partagent les séquences. Un modèle mixture of experts répartit ses experts sur toutes.
Taille de tensor parallel : 1, soit les GPU divisés par les étages et les replicas.
GPU par serveur
Le tensor parallelism reste dans un serveur. Au-delà, les GPU deviennent des étages de pipeline.
Taille du decode context parallel
Découpe le KV cache de chaque séquence par token entre les GPU en tensor parallel. N'ajoute aucun GPU et ralentit le decode.
Uniquement pour les modèles mixture of experts.
Hypothèses du runtime›3 GiB de surcoût par GPU, 90 % utilisables, 10 % de marge
Mémoire pour le contexte CUDA, les activations et les graphes, dans l'unité de la page. Une heuristique.
Part de la mémoire du GPU que le moteur d'inférence peut utiliser. La valeur par défaut de vLLM est 92 %.
Part de la mémoire utilisable qui doit rester libre pour que le modèle tienne confortablement.
Ce modèle n'a pas de couches à fenêtre glissante.
Tient avec marge
Il faut 22,76 GiB par GPU. 63,64 GiB des 86,4 GiB utilisables restent libres, plus que la marge de 10 % demandée.
Mémoire requise par GPU
22,76 GiB
sur 86,4 GiB utilisables
Mémoire restante par GPU
63,64 GiB
73,66 % de la mémoire utilisable est libre
Taille brute des poids
15,26 GiB
Paramètres × bits nominaux
Mémoire totale estimée
22,76 GiB
Mémoire GPU totale
96 GiB
Mémoire d'un GPU
Mémoire de chaque GPU
Mémoire GPU 96 GiB
- Poids en mémoire15,26 GiB67,04 %
- KV cache4,5 GiB19,77 %
- Surcoût du runtime3 GiB13,18 %
Budget mémoire
| Poste | Mémoire |
|---|---|
| Taille brute des poidsParamètres × bits nominaux | 15,26 GiB |
| Poids en mémoire | 15,26 GiB |
| Surcoût du runtime | 3 GiB |
| Modèle avec surcoût du runtime | 18,26 GiB |
| KV cache | 4,5 GiB |
| Total | 22,76 GiB |
Place pour le KV cache
Le moteur pourrait contenir 496 206 tokens de KV cache dans ce qui reste après les poids et le surcoût, de quoi loger 60,57 séquences de 8 192 tokens.
vLLM l'affiche comme sa capacité de KV cache au démarrage. La capacité réelle est un peu plus basse : le cache est stocké par blocs.
Nombre de GPU
Minimum mémoire
1
TP 1
26,34 % de la mémoire utilisable, 63,64 GiB libres par GPU
Le plus petit nombre de GPU dont la mémoire contient le modèle, quelle que soit la répartition. La disposition peut ne pas être acceptée par vLLM.
Minimum valide
1
TP 1
26,34 % de la mémoire utilisable, 63,64 GiB libres par GPU
Le plus petit nombre de GPU dans une disposition acceptée par vLLM : tensor parallelism dans un serveur, étages de pipeline au-delà.
Recommandé
1
TP 1
26,34 % de la mémoire utilisable, 63,64 GiB libres par GPU
Une répartition valide qui garde aussi votre marge.
Chaque GPU doit contenir sa propre part, donc la mémoire de plusieurs GPU ne forme pas un seul pool. Plus de huit GPU signifie en général plusieurs serveurs.
Mémoire par GPU selon le nombre de GPU
Chaque barre correspond à un nombre de GPU, avec la disposition que privilégient les recommandations de vLLM. La ligne est la mémoire utilisable. Choisissez une barre pour utiliser ce nombre.
- Utilisable 86,4 GiB
- Limite de marge
- Poids en mémoire
- KV cache
- Surcoût du runtime
- Étoile : recommandé
- Losange : minimum valide
- Cercle : minimum mémoire
- Contour : utilisé
- Atténué, en pointillés : vLLM ne démarrerait pas avec cette disposition
›Afficher en tableau
| GPU | Disposition | Par GPU | Verdict |
|---|---|---|---|
| 1 | TP 1 | 22,76 GiB | Tient avec margeminimum mémoire, minimum valide, recommandé, utilisé |
| 2 | TP 2 | 12,88 GiB | Tient avec marge |
| 3 | TP 3vLLM ne démarrerait pas avec cette disposition | 9,77 GiB | Tient avec marge |
| 4 | TP 4 | 7,94 GiB | Tient avec marge |
| 5 | TP 5vLLM ne démarrerait pas avec cette disposition | 7,18 GiB | Tient avec marge |
| 6 | TP 3 × PP 2vLLM ne démarrerait pas avec cette disposition | 6,39 GiB | Tient avec marge |
| 7 | TP 7vLLM ne démarrerait pas avec cette disposition | 6,3 GiB | Tient avec marge |
| 8 | TP 8 | 5,47 GiB | Tient avec marge |
| 9 | TP 1 × PP 9 | 6,1 GiB | Tient avec marge |
| 10 | TP 2 × PP 5 | 5,27 GiB | Tient avec marge |
| 11 | TP 1 × PP 11 | 5,61 GiB | Tient avec marge |
| 12 | TP 4 × PP 3 | 4,74 GiB | Tient avec marge |
| 13 | TP 1 × PP 13 | 5,13 GiB | Tient avec marge |
| 14 | TP 2 × PP 7 | 4,79 GiB | Tient avec marge |
| 15 | TP 1 × PP 15 | 5,13 GiB | Tient avec marge |
| 16 | TP 8 × PP 2 | 4,23 GiB | Tient avec marge |
Ce qui tient avec d'autres contextes et niveaux de concurrence
Chaque cellule indique la mémoire dont un GPU a besoin pour ce contexte et ce nombre de séquences, avec les GPU et la disposition que vous avez réglés. Choisissez une cellule pour l'utiliser.
Séquences ↓Contexte, en tokens →
| 2K | 4K | 8K | 16K | 32K | 40Kmax du modèle | |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 4 | ||||||
| 16 | ||||||
| 64 | ||||||
| 128 | ||||||
| 256 | ||||||
| 512 | ||||||
| 1024 |
- Coche : tient avec marge
- Triangle : tient, sans la marge demandée
- Croix : ne tient pas
- Contour : utilisé
Façons de modifier la configuration
De la place pour grandir
Cette configuration tient avec marge. Voici jusqu'où elle peut être poussée.
Le contexte pourrait grandir jusqu'à 40 960 tokens avec 4 séquences
Ensuite : tient avec marge, 47,17 % de la mémoire utilisable
Jusqu'à 52 séquences simultanées tiennent à 8 192 tokens
Ensuite : tient avec marge, 88,84 % de la mémoire utilisable
Déployer cette configuration
Ces commandes sont écrites pour la configuration dimensionnée ci-dessus et pour les choix faits ici, et changent dès que l'un ou l'autre change. Rien n'est modifié à votre place : un choix qui ne fonctionne plus est conservé et signalé, avec des moyens de le corriger.
Le serveur
Exécuter avec
Runtime
Le serveur qui charge le modèle.
GPU
Les index des GPU de la machine, tels que nvidia-smi les liste, séparés par des virgules. La configuration utilise 1 GPU.
Identifier les GPU par
Un index dépend de l'ordre dans lequel le pilote trouve les GPU. Un UUID est lié à la carte.
Endpoint
Le port sur lequel l'endpoint répond. 8000 (par défaut)
Écouter sur
La valeur par défaut garde l'endpoint sur cette machine.
L'endpoint ne répond qu'aux requêtes qui portent une clé. La clé est créée sur votre machine et n'est jamais écrite dans une commande ni dans un lien.
Autres options
Où sont gardés les poids téléchargés. Un répertoire qui existe déjà évite le téléchargement.
La valeur par défaut est la version pour laquelle ces commandes ont été écrites. latest suit la plus récente.
Ce qui va tourner
vLLM · Docker · 1 GPU, RTX PRO 6000 Blackwell
- Dépôt
- Qwen/Qwen3-8BDu calculateur
- Runtime
- vLLMPar défaut
- Exécuté avec
- DockerPar défaut
- GPU
- 1 GPU, RTX PRO 6000 BlackwellDu calculateur
- index 0Par défaut
- Contexte
- 8 192 tokensDu calculateur
- Séquences par replica
- 4Déduit
- Mémoire par GPU
- 22,76 GiB requis sur 86,40 GiB utilisables
- Part de chaque GPU pour le moteur
- 90 %Déduit
- Accès
- OuvertDu calculateur
- Endpoint
- 127.0.0.1:8000Par défaut
À regarder
Vous avez dimensionné un KV cache fp16 pour des poids bf16. Un cache en 16 bits occupe la même place dans l'un ou l'autre type, et vLLM le stocke dans le type propre au modèle sauf indication contraire, donc les commandes n'imposent pas fp16.
16 étapes en 5 phases. Ouvrez-en une à la fois, ou toutes.
1Vérifier le matériel
Regarder ce que la machine ou le cluster offre avant de rien modifier.3 étapes
- Étape 1
Vérifier le pilote
Confirmer que le pilote NVIDIA est installé et assez récent pour les logiciels ci-dessous.
nvidia-smiCe que vous devriez voir
- Un tableau avec la version du pilote et une version de CUDA d'au moins 13.0, dont l'image a besoin.
Aide et sources
Si cela ne fonctionne pas
- Si la version de CUDA est inférieure à ce que nécessite le logiciel, mettez à jour le pilote et vérifiez à nouveau.
- nvidia-smi(s'ouvre dans un nouvel onglet)
- CUDA minor version compatibility(s'ouvre dans un nouvel onglet)
D'où viennent les valeurs
- Le GPU choisi : RTX PRO 6000 Blackwell.
- Étape 2
Vérifier les GPU
Confirmer que la machine liste le GPU à l'index 0.
nvidia-smi -LCe que vous devriez voir
- Une ligne par GPU, chacune nommant RTX PRO 6000 Blackwell comme la machine l'écrit.
Aide et sources
Si cela ne fonctionne pas
- Si un GPU que vous avez choisi manque, il n'est pas dans cette machine ou le pilote ne le voit pas.
- Si les noms ne correspondent pas à ce que vous attendez, les index ne sont pas ceux que vous croyez. Identifiez les GPU par UUID, qui ne dépend pas de l'ordre.
D'où viennent les valeurs
- Le calculateur utilise 1 GPU.
- Le GPU choisi : RTX PRO 6000 Blackwell.
- Étape 3
Vérifier que la mémoire est libre
Le calculateur attend 22,76 GiB sur chaque GPU, sur les 86,40 GiB que le moteur peut utiliser. Vérifiez que, pour le GPU à l'index 0, la mémoire est libre.
nvidia-smi --query-gpu=index,name,memory.total,memory.used,memory.free --format=csv -i 0Ce que vous devriez voir
- Presque toute la mémoire du GPU est libre, au moins 22,76 GiB sur chacun.
À garder en tête
- D'autres travaux utilisent peut-être déjà ces GPU. Si leur mémoire n'est pas libre, arrêtez ces travaux ou choisissez d'autres GPU avant de démarrer.
Aide et sources
D'où viennent les valeurs
- Le calculateur : 22,76 GiB nécessaires, 86,40 GiB utilisables sur chaque GPU.
2Préparer
Obtenir l'accès au modèle, installer ce dont le serveur a besoin et le récupérer. Un GPU divisé est aussi créé ici.2 nécessitent des droits d'administrateur5 étapes
Installer les outils
- Étape 4
Vérifier Docker
Confirmer que Docker Engine est installé.
docker --versionCe que vous devriez voir
- Une version de Docker.
Aide et sources
- Étape 5
Installer le NVIDIA Container Toolkit
Droits administrateur requisIl permet aux conteneurs d'utiliser les GPU. Ces commandes sont prévues pour Ubuntu et Debian, et la page liée ci-dessous couvre les autres distributions.
Vient après l'étape 1
sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2 curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \ && curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \ sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update export NVIDIA_CONTAINER_TOOLKIT_VERSION=1.20.1-1 sudo apt-get install -y \ nvidia-container-toolkit=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \ nvidia-container-toolkit-base=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \ libnvidia-container-tools=${NVIDIA_CONTAINER_TOOLKIT_VERSION} \ libnvidia-container1=${NVIDIA_CONTAINER_TOOLKIT_VERSION}Ce que vous devriez voir
- Les paquets s'installent sans erreur.
- Étape 6
Connecter Docker aux GPU
Droits administrateur requisEnregistrer le runtime NVIDIA auprès de Docker et redémarrer Docker.
sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart dockerCe que vous devriez voir
- Aucune erreur, et Docker redémarre.
À garder en tête
- Redémarrer Docker arrête les conteneurs en cours d'exécution.
- Étape 7
Vérifier qu'un conteneur voit les GPU
Exécuter nvidia-smi dans un conteneur qui reçoit le GPU à l'index 0. Seul ce GPU doit apparaître.
docker run --rm --runtime=nvidia --gpus '"device=0"' \ ubuntu nvidia-smiCe que vous devriez voir
- Un tableau avec un GPU, celui que vous avez choisi.
Aide et sources
Si cela ne fonctionne pas
- Si Docker ne peut pas démarrer avec les GPU, le toolkit n'est pas configuré ou les index n'existent pas sur cette machine.
- Si les noms ne correspondent pas à ce que vous attendez, les index ne sont pas ceux que vous croyez. Identifiez les GPU par UUID, qui ne dépend pas de l'ordre.
- NVIDIA Container Toolkit: sample workload(s'ouvre dans un nouvel onglet)
- NVIDIA Container Toolkit: Specialized configurations with Docker(s'ouvre dans un nouvel onglet)
D'où viennent les valeurs
--gpus '"device=0"'Par défaut Les premiers GPU, comptés à partir de 0.
Récupérer le serveur
- Étape 8
Télécharger l'image
Télécharger vllm/vllm-openai:v0.32.0 avant le premier démarrage, pour que le démarrage n'ait plus qu'à charger le modèle.
docker pull vllm/vllm-openai:v0.32.0Ce que vous devriez voir
- Le téléchargement se termine et la dernière ligne nomme l'image.
À garder en tête
- L'image fait plusieurs gigaoctets.
3Démarrer le serveur
Le démarrer avec la configuration dimensionnée.1 étape
- Étape 9
Démarrer le serveur
Démarrer vllm-qwen3-8b avec la configuration dimensionnée : le modèle Qwen/Qwen3-8B, le parallélisme, le contexte et la mémoire qui lui est donnée. Le premier démarrage télécharge le modèle et prend quelques minutes.
Vient après l'étape 3
# config YSTVGT docker run -d --name vllm-qwen3-8b \ --runtime nvidia --gpus '"device=0"' \ --ipc=host \ -v "$HOME/.cache/huggingface":/root/.cache/huggingface \ -p 127.0.0.1:8000:8000 \ vllm/vllm-openai:v0.32.0 \ --model Qwen/Qwen3-8B \ --max-model-len 8192 --max-num-seqs 4 \ --gpu-memory-utilization 0.90Ce que vous devriez voir
- Un id de conteneur.
À garder en tête
- Le premier démarrage télécharge le modèle et prépare les kernels, ce qui prend quelques minutes. Le serveur n'est pas prêt avant.
Aide et sources
Si cela ne fonctionne pas
- S'il s'arrête avec un message out of memory, la configuration nécessite plus que ce que contient le GPU. Réduisez le contexte ou les séquences, donnez plus de mémoire du GPU au moteur, ou utilisez plus de GPU. Le calculateur indique de combien.
- Si vLLM dit que le contexte est plus long que ce que le KV cache peut contenir, réduisez le contexte ou le nombre de séquences.
- Si vLLM dit que les têtes d'attention ne sont pas divisibles par la taille de tensor parallel, utilisez une taille qui les divise.
- Si le port est pris, choisissez-en un autre dans vos choix.
- Si Docker ne peut pas démarrer avec les GPU, le toolkit n'est pas configuré ou les index n'existent pas sur cette machine.
- vLLM: vllm serve arguments(s'ouvre dans un nouvel onglet)
- vLLM: engine arguments(s'ouvre dans un nouvel onglet)
D'où viennent les valeurs
-dPar défaut La façon d'exécuter que vous avez choisie.
--name vllm-qwen3-8bDu calculateur Le dépôt du modèle choisi.
--runtime nvidiaPar défaut La façon d'exécuter que vous avez choisie.
--gpus '"device=0"'Par défaut Les premiers GPU, comptés à partir de 0.
--ipc=hostPar défaut La façon d'exécuter que vous avez choisie.
-v "$HOME/.cache/huggingface":/root/.cache/huggingfacePar défaut Où sont gardés les poids téléchargés.
-p 127.0.0.1:8000:8000Par défaut Le port sur lequel l'endpoint répond.
--model Qwen/Qwen3-8BDu calculateur Le dépôt du modèle choisi.
--max-model-len 8192Du calculateur La longueur de contexte que vous avez définie : 8 192 tokens.
--max-num-seqs 4Déduit 4 séquences à répartir entre 1 replica.
--gpu-memory-utilization 0.90Déduit La part utilisable que vous avez définie, 90 %, divisée entre 1 replica sur le périphérique, arrondie vers le bas pour que les parts ne dépassent jamais le total du périphérique.
- Le dépôt du modèle choisi.
- La longueur de contexte que vous avez définie : 8 192 tokens.
- La part utilisable que vous avez définie, 90 %, divisée entre 1 replica sur le périphérique, arrondie vers le bas pour que les parts ne dépassent jamais le total du périphérique.
4Vérifier que cela fonctionne
Attendre qu'il réponde, lui poser une question et comparer la mémoire avec le calculateur.6 étapes
Vérifier l'endpoint
- Étape 10
Attendre qu'il soit prêt
Le serveur répond sur /health une fois le modèle chargé.
timeout 900 bash -c 'until curl -fs http://127.0.0.1:8000/health >/dev/null; do sleep 5; done' && echo readyCe que vous devriez voir
- Le mot ready, après une minute ou plus, le temps que le modèle se charge.
Aide et sources
Si cela ne fonctionne pas
- S'il ne devient pas prêt, lisez les dernières lignes du log : le modèle est encore en cours de chargement, ou le serveur s'est arrêté avec une erreur.
- S'il s'arrête avec un message out of memory, la configuration nécessite plus que ce que contient le GPU. Réduisez le contexte ou les séquences, donnez plus de mémoire du GPU au moteur, ou utilisez plus de GPU. Le calculateur indique de combien.
- Étape 11
Vérifier que le modèle est servi
Demander au serveur quels modèles il sert.
curl -sS http://127.0.0.1:8000/v1/modelsCe que vous devriez voir
- Une liste contenant Qwen/Qwen3-8B.
Aide et sources
Si cela ne fonctionne pas
- Si la réponse est 401, la clé de ce shell n'est pas celle avec laquelle le serveur a été démarré.
- Étape 12
Lui poser une question
Une requête passant par l'endpoint que vos applications utiliseront.
curl -sS http://127.0.0.1:8000/v1/chat/completions \ -H 'Content-Type: application/json' \ -d '{"model": "Qwen/Qwen3-8B", "messages": [{"role": "user", "content": "Say hello in five words."}], "max_tokens": 32}'Ce que vous devriez voir
- Une réponse JSON avec un message du modèle.
Aide et sources
Si cela ne fonctionne pas
- Si la réponse est 401, la clé de ce shell n'est pas celle avec laquelle le serveur a été démarré.
- S'il ne devient pas prêt, lisez les dernières lignes du log : le modèle est encore en cours de chargement, ou le serveur s'est arrêté avec une erreur.
Observer la machine
- Étape 13
Observer les GPU
Voir la mémoire utilisée et le travail en cours sur le GPU à l'index 0 pendant que le serveur tourne.
nvidia-smi --query-gpu=index,name,memory.used,memory.total,utilization.gpu --format=csv -i 0Ce que vous devriez voir
- Une mémoire utilisée proche de celle qui a été donnée au moteur.
Aide et sources
- Étape 14
Observer le serveur
Voir que vllm-qwen3-8b tourne, et son dernier message.
Vient après l'étape 12
docker ps --filter name=vllm-qwen3-8b --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}' docker logs --tail 20 vllm-qwen3-8bCe que vous devriez voir
- Le serveur tourne, et ses dernières lignes de log ne montrent aucune erreur.
Aide et sources
Comparer avec le calculateur
- Étape 15
Comparer avec le calculateur
Le calculateur attendait 22,76 GiB sur chaque GPU, avec 90 % du GPU confiés au moteur. Le log du serveur indique ce qu'il a pris pour les poids et ce qui reste pour le KV cache.
Vient après l'étape 12
docker logs vllm-qwen3-8b 2>&1 | grep -E 'Model loading took|Available KV cache memory|GPU KV cache size'Ce que vous devriez voir
- Des lignes indiquant la mémoire prise par les poids, la mémoire restante pour le KV cache et le nombre de tokens qu'il contient.
Aide et sources
- vLLM: parallelism and scaling(s'ouvre dans un nouvel onglet)
- vLLM: conserving memory(s'ouvre dans un nouvel onglet)
D'où viennent les valeurs
- Le calculateur : 22,76 GiB nécessaires, 86,40 GiB utilisables sur chaque GPU.
5Nettoyer
Arrêter le serveur et supprimer ce que ces étapes ont créé.1 étape
- Étape 16
Arrêter le serveur
Peut arrêter ou supprimerArrêter vllm-qwen3-8b et libérer les GPU.
Vient après l'étape 9
docker stop vllm-qwen3-8b && docker rm vllm-qwen3-8bCe que vous devriez voir
- Aucune sortie, et les GPU sont libres.
À garder en tête
- L'endpoint cesse de répondre.
Aide et sources
Calcul
- Votre saisie
- Spécification officielle
- Résultat calculé
- Estimation
- Heuristique
- Hypothèse
›Poids
Taille brute des poids
Résultat calculéTaille brute des poids = paramètres × bits nominaux par paramètre ÷ 8
= Votre saisie: 8,19 Md paramètres × Spécification officielle: 16 bit/param ÷ 8
= 15,26 GiB
Poids en mémoire
Résultat calculéPoids en mémoire = paramètres × bits effectifs par paramètre ÷ 8
= Votre saisie: 8,19 Md paramètres × Spécification officielle: 16 bit/param ÷ 8
= 15,26 GiB
›KV cache
KV cache par token
Résultat calculéKV cache par token = 2 × couches avec KV cache × têtes KV × dimension de tête × bits du KV cache par valeur ÷ 8
= 2 × Votre saisie: 36 × Votre saisie: 8 × Votre saisie: 128 × Votre saisie: 16 bit ÷ 8
= 144 KiB/token
KV cache par séquence
Résultat calculéKV cache par séquence = KV cache par token × longueur du contexte
= Résultat calculé: 144 KiB/token × Votre saisie: 8 192 tokens
= 1,13 GiB
KV cache
Résultat calculéKV cache = KV cache par séquence × séquences simultanées
= Résultat calculé: 1,13 GiB × Votre saisie: 4
= 4,5 GiB
›Mémoire par GPU et au total
Mémoire requise par GPU
EstimationMémoire requise par GPU = Poids en mémoire + KV cache + Surcoût du runtime
= Résultat calculé: 15,26 GiB + Résultat calculé: 4,5 GiB + Heuristique: 3 GiB
= 22,76 GiB
Modèle avec surcoût du runtime
EstimationModèle avec surcoût du runtime = Poids en mémoire + Surcoût du runtime
= Résultat calculé: 15,26 GiB + Heuristique: 3 GiB
= 18,26 GiB
›Verdict sur le GPU
Mémoire utilisable par GPU
EstimationMémoire utilisable par GPU = Mémoire GPU × part utilisable ÷ 100
= Spécification officielle: 96 GiB × Hypothèse: 90 % ÷ 100
= 86,4 GiB
Limite confortable par GPU
EstimationLimite confortable par GPU = Mémoire utilisable par GPU × (100 − marge requise) ÷ 100
= Estimation: 86,4 GiB × (100 − Hypothèse: 10 %) ÷ 100
= 77,76 GiB
Mémoire restante par GPU
EstimationMémoire restante par GPU = Mémoire utilisable par GPU − Mémoire requise par GPU
= Estimation: 86,4 GiB − Estimation: 22,76 GiB
= 63,64 GiB
Utilisation de la mémoire utilisable
EstimationUtilisation de la mémoire utilisable = Mémoire requise par GPU ÷ Mémoire utilisable par GPU × 100
= Estimation: 22,76 GiB ÷ Estimation: 86,4 GiB × 100
= 26,34 %
›Place pour le KV cache
Mémoire restante pour le KV cache par GPU
EstimationMémoire restante pour le KV cache par GPU = max(0, Mémoire utilisable par GPU − Poids en mémoire − Surcoût du runtime)
= max(0, Estimation: 86,4 GiB − Résultat calculé: 15,26 GiB − Heuristique: 3 GiB)
= 68,14 GiB
Capacité du KV cache
EstimationCapacité du KV cache = floor(Mémoire restante pour le KV cache par GPU ÷ KV cache par token)
= floor(Estimation: 68,14 GiB ÷ Résultat calculé: 144 KiB/token)
= 496 206 tokens
Séquences de ce contexte qui tiennent
EstimationSéquences de ce contexte qui tiennent = Capacité du KV cache ÷ longueur du contexte
= Estimation: 496 206 tokens ÷ Votre saisie: 8 192 tokens
= 60,57 ×
›Avec 1 GPU minimum mémoire, minimum valide, recommandé
Mémoire requise par GPU
EstimationMémoire requise par GPU = Poids en mémoire + KV cache + Surcoût du runtime
= Résultat calculé: 15,26 GiB + Résultat calculé: 4,5 GiB + Heuristique: 3 GiB
= 22,76 GiB
Mémoire utilisable par GPU
EstimationMémoire utilisable par GPU = Mémoire GPU × part utilisable ÷ 100
= Spécification officielle: 96 GiB × Hypothèse: 90 % ÷ 100
= 86,4 GiB
Limite confortable par GPU
EstimationLimite confortable par GPU = Mémoire utilisable par GPU × (100 − marge requise) ÷ 100
= Estimation: 86,4 GiB × (100 − Hypothèse: 10 %) ÷ 100
= 77,76 GiB
Mémoire restante par GPU
EstimationMémoire restante par GPU = Mémoire utilisable par GPU − Mémoire requise par GPU
= Estimation: 86,4 GiB − Estimation: 22,76 GiB
= 63,64 GiB
Utilisation de la mémoire utilisable
EstimationUtilisation de la mémoire utilisable = Mémoire requise par GPU ÷ Mémoire utilisable par GPU × 100
= Estimation: 22,76 GiB ÷ Estimation: 86,4 GiB × 100
= 26,34 %
Hypothèses
- Hypothèse: Le KV cache est stocké par blocs (16 tokens dans vLLM), donc la capacité réelle est légèrement inférieure au nombre affiché.
- Heuristique: Le surcoût du runtime est de 3 GiB par GPU pour le contexte CUDA, les activations et les graphes. C'est une heuristique : vLLM a mesuré 2,57 GiB pour un modèle 8B, et cela varie selon le moteur et les réglages. Modifier
- Hypothèse: Seuls 90 % de la mémoire du GPU sont donnés au modèle. Les moteurs d'inférence réservent le reste : la valeur par défaut de vLLM est 92 % (documentation de la version 0.32). Modifier
- Hypothèse: On considère que le modèle tient confortablement quand au moins 10 % de la mémoire utilisable reste libre. Modifier
- Hypothèse: NVIDIA indique la mémoire GPU en GB, et le matériel en contient autant de GiB : un H100 80 GB a 80 GiB, et nvidia-smi affiche 79,6. Les quelques pour cent que l'ECC et le pilote retiennent sont couverts par la part utilisable.
- Hypothèse: La précision du KV cache se règle à part de celle des poids. Quantifier les poids ne réduit ni le KV cache ni le surcoût. Modifier
- Hypothèse: On suppose que chaque séquence utilise tout le contexte en même temps, le pire cas. Le trafic réel est en général plus court. Modifier
- Hypothèse: On suppose que plusieurs GPU se partagent le modèle par tensor parallelism, comme le fait vLLM : les poids et les têtes KV sont répartis, et chaque GPU paie le surcoût du runtime.
Tient avec marge22,76 GiB / 86,4 GiBrequis / utilisable
Pourquoi c'est important
Le chiffre d'une model card correspond aux poids. Un modèle en cours d'exécution contient aussi un KV cache qui grandit avec le contexte et la concurrence, plus le surcoût du runtime, et chaque GPU doit contenir sa propre part : la mémoire de plusieurs GPU ne forme pas un seul pool. Planifier avec les poids seuls est l'erreur de dimensionnement la plus courante.
Comment lire le résultat
Tient avec marge laisse libre, sur chaque GPU, la marge de sécurité demandée. Tient en théorie reste sous la mémoire utilisable, mais avec moins de marge que demandé. Ne tient pas signifie qu'un GPU manquerait de mémoire. Le budget mémoire montre chaque part pour tous les GPU et pour un seul. Le nombre de GPU suit les recommandations de vLLM : tensor parallelism dans un serveur, étages de pipeline au-delà. La disposition du déploiement permet de répartir les GPU autrement et de voir ce que contient chaque répartition.
IA locale et souveraineté
Exécuter un modèle sur du matériel que vous contrôlez est un élément d'une décision de souveraineté. Cela ne suffit pas à rendre un déploiement souverain, conforme au RGPD ou à l'AI Act européen.
Ces outils sont issus de l'atelier L'IA sans le cloud.