Guide des charges de travail GPU
De quelle quantité de VRAM GPU avez-vous réellement besoin ?
Un budget mémoire pratique pour l'inférence, le réglage fin, la génération d'images et les charges de travail vidéo—de 24 GB à 192 GB.
Par AnchorGPU · Mis à jour · 6 min de lectureVRAM est un budget, pas une étiquette de modèle
La mémoire GPU est consommée par plusieurs catégories indépendantes : poids du modèle, cache KV d'inférence, activations temporaires, espaces de travail du framework, cache de l'allocateur et, pendant l'entraînement, gradients et état de l'optimiseur. Un modèle qui tient dans une configuration ne prouve pas qu'il tiendra avec un contexte plus long, un lot plus grand, une précision différente ou davantage de requêtes simultanées.
Planifiez à partir de la révision exacte du modèle et de la configuration d'exécution. Des étiquettes telles que 7B, 13B ou 70B décrivent l'échelle des paramètres, pas la mémoire d'exploitation totale, et ne doivent donc jamais être mappées universellement à un GPU.
Estimez d'abord les poids bruts
À titre d'exemple explicitement hypothétique, supposons qu'un modèle possède exactement 13 milliards de paramètres et stocke chaque paramètre dans un format 16 bits. Le stockage brut des poids est de 13,000,000,000 × 2 octets = 26,000,000,000 octets, soit environ 24.2 GiB. Ce nombre exclut toute autre allocation ; il s'agit donc d'une borne inférieure plutôt que d'une recommandation de GPU.
La quantification peut réduire le stockage des poids, mais les empreintes réelles incluent aussi les échelles, les métadonnées, les tampons de déquantification, les tenseurs dupliqués et les espaces de travail d'exécution. Utilisez le format produit par le chargeur réel plutôt que de diviser le nombre de paramètres par une largeur de bits nominale et de traiter le résultat comme définitif.
L'inférence ajoute du cache KV et de la mémoire de travail
Le service autorégressif conserve les tenseurs de clé et de valeur pour les séquences actives. La demande de cache KV dépend de l'architecture du modèle, de la précision du cache, des séquences simultanées et du nombre de jetons actifs dans ces séquences. Augmenter le contexte maximal ou la concurrence peut épuiser la mémoire même lorsque les poids se chargent correctement.
Les activations temporaires, les espaces de travail d'attention, les noyaux compilés, les tampons de communication et l'allocateur du framework consomment de la mémoire supplémentaire. vLLM indique sa capacité de cache KV GPU disponible et une concurrence estimée pour la longueur de séquence configurée ; traitez ces chiffres de démarrage comme des éléments de planification, puis rejouez des invites représentatives avant d'engager une charge de travail en production.
L'entraînement a une forme de mémoire différente
Le réglage fin ajoute des gradients, l'état de l'optimiseur, les activations sauvegardées et parfois des copies supplémentaires en pleine précision. Leur taille exacte dépend de l'optimiseur, de la politique de précision, de l'ensemble de paramètres entraînables et de la stratégie de partitionnement ; un multiplicateur d'inférence unique serait donc trompeur.
DistributedDataParallel réplique l'état d'entraînement nécessaire à chaque worker ; il ne transforme pas plusieurs GPU en un pool mémoire contigu. Fully Sharded Data Parallel peut fragmenter les paramètres, les gradients et les états de l'optimiseur entre les workers, tandis que la segmentation d'activations réduit la mémoire des activations sauvegardées en recalculant certains travaux pendant la rétropropagation. Ces deux techniques échangent simplicité ou calcul contre de la mémoire.
Mesurez la configuration que vous allez exécuter
Testez le chargement du modèle et une requête d'inférence représentative complète ou une étape d'entraînement, y compris la mise à jour de l'optimiseur, avec le framework, la précision, le contexte, le lot et les paramètres de parallélisme exacts. Enregistrez la mémoire allouée et réservée maximale, puis répétez avec une concurrence réaliste ou une accumulation de gradients. Laissez une marge de fonctionnement au lieu de viser le dernier octet disponible.
Choisissez un GPU à mémoire plus grande lorsque le pic mesuré ne peut pas être réduit en toute sécurité. Ajoutez des GPU uniquement lorsque le logiciel fragmente explicitement le modèle ou la charge de travail et que l'interconnexion fournie est connue. Refaites la mesure après tout changement de modèle, d'exécution, de quantification, de contexte ou de lot.
Sources et méthode éditoriale
La documentation officielle étaye les explications techniques. Les recommandations matérielles sont notre interprétation dépendante de la charge de travail, et non une garantie de performance mesurée.
vLLM — parallélisme et mise à l'échelle ↗PyTorch — FullyShardedDataParallel ↗PyTorch — point de contrôle d'activation ↗