Calculateur de VRAM GPU pour LLM

Comment lire ce résultat

Poids du modèle : c'est le poste principal. Un modèle de N milliards de paramètres pèse N × 2 Go en FP16, N Go en INT8, N ÷ 2 Go en INT4. La quantification INT4 divise donc par 4 la mémoire des poids, avec une perte de qualité généralement faible.

Cache KV : la mémoire qui stocke le contexte de chaque requête, calculée à partir de l'architecture réelle du modèle : 2 (K et V) × couches × têtes KV × dim. tête × octets par élément, le tout multiplié par le contexte et la concurrence. Le nombre de têtes KV encode le GQA (Mistral 24B : 8 têtes KV pour 32 têtes de requête, soit un cache divisé par 4 vs une attention classique). L'option FP8 de vLLM stocke chaque élément sur 1 octet au lieu de 2 : cache divisé par 2 sans impact notable en production. Ce poste croît avec la longueur de contexte et le nombre de requêtes simultanées : c'est souvent ce qui explose quand on sert beaucoup d'utilisateurs à la fois.

« Ma carte affiche 95 % d'occupation » : c'est normal avec vLLM. Le moteur pré-réserve ~90 % de la VRAM au démarrage (gpu_memory_utilization=0.9) et remplit tout l'espace libre au-delà des poids avec le pool de cache KV. Une A100 80 Go qui sert Mistral 24B en FP16 apparaît donc « saturée » dans nvidia-smi alors que le besoin réel est d'environ 55 Go : le reste est du cache pré-alloué pour absorber la concurrence.

Swap CPU & préemption : le cache KV vit dans le pool que vLLM pré-alloue sur le GPU. Quand la concurrence demande plus de cache que ce pool ne peut contenir, vLLM ne plante pas : il préempte des requêtes (il recalcule leur contexte plus tard) ou bascule une partie du cache en RAM CPU (swap_space). C'est fonctionnel, mais la latence au premier token (TTFT) grimpe. L'outil signale cette zone critique dès que la marge tombe sous ~10 % du GPU recommandé — c'est le moment de monter en gamme, de réduire le contexte, ou de passer le cache KV en FP8.

Modèles MoE (Mixture of Experts) : un modèle comme Mixtral charge tous ses experts en VRAM (les poids comptés ci-dessus reflètent le total des paramètres, pas seulement les experts actifs), et sa mémoire de travail est plus élevée. On retient donc des activations à ~18 % au lieu de ~10 % pour un modèle dense — c'est le rôle du sélecteur « Type d'architecture ». À cela s'ajoute, dans tous les cas, un socle fixe d'environ 3 Go pour le runtime CUDA et le framework vLLM : cette valeur plancher, indépendante de la taille du modèle, évite de sous-estimer l'empreinte d'un petit modèle (et donc un risque d'OOM au démarrage).

Cycle de vie de la VRAM & effacement quotidien : vLLM pré-alloue son pool de cache KV au démarrage du serveur et le gère par pages (PagedAttention) — il n'y a donc pas de « fuite mémoire » qui grignoterait la VRAM requête après requête. En revanche, un serveur d'inférence qui tourne des semaines peut voir sa mémoire se fragmenter. Notre exploitation éteint et réinitialise les serveurs de traitement chaque nuit : au redémarrage, l'allocation VRAM repart de zéro (pool KV reconstruit à neuf, logs et états purgés). Le dimensionnement calculé ici correspond donc à un serveur « propre » chaque matin — un avantage à la fois de stabilité mémoire et de confidentialité (aucune donnée ne persiste sur le GPU d'un jour à l'autre).

Débit de décodage (tokens/s) : la génération d'un LLM est limitée par la bande passante mémoire — pour produire chaque token, le GPU relit l'ensemble des poids. On estime donc le débit mono-requête par débit ≈ bande passante ÷ poids, avec un rendement réel de 50 à 75 % du pic (d'où une fourchette). C'est un ordre de grandeur pour une seule requête : le débit agrégé de vLLM sous concurrence (batching continu) est bien supérieur, et les valeurs réelles dépendent du modèle, du noyau d'inférence et de la longueur de contexte. À ne pas prendre pour une garantie.

C'est exactement ce dimensionnement que nous réalisons pour chaque déploiement souverain : choisir le bon modèle, la bonne quantification et le bon GPU pour votre charge réelle. Voir notre page Modèles LLM et le glossaire.