RAM et VRAM : leur relation dans un serveur d’IA

La première question que se posent les acheteurs de serveurs d'IA est : « Combien de GPU ? ». La seconde : « Quel CPU ? ». La question qui détermine réellement le bon fonctionnement du système — et celle que la plupart des fiches techniques occultent — concerne la taille relative des deux systèmes de mémoire. Une machine à 4 GPU avec 192 Go de VRAM et 32 Go de RAM système est inutilisable. La même machine avec 1 To de RAM système représente, pour la plupart des charges de travail, un gaspillage d'argent. La solution optimale se situe entre les deux et dépend des applications que vous utilisez.

Cet article détaille le rôle de la VRAM et de la RAM système, leur relation, les goulots d'étranglement en termes de bande passante et les ratios généralement utilisés. Il s'adresse aux acheteurs et aux intégrateurs qui dimensionnent une configuration, et non aux ingénieurs qui développent des noyaux CUDA.

Ce que la VRAM contient réellement

Lorsqu'un modèle est « chargé sur le GPU », trois éléments résident dans la VRAM :

1. Poids du modèle. Un modèle 70B à FP16 est de 140 Go ; à INT8, 70 Go ; à INT4 (la quantification auto-hôte courante), 35 à 40 Go selon le schéma de quantification.
2. Cache KV. Coût mémoire par requête lié à l'attention. Un modèle 70B avec un contexte de 8K en flux unique nécessite 1 à 2 Go. À 32K, ce coût est de 4 à 8 Go. En mode de traitement par lots (10 à 20 requêtes simultanées), c'est la VRAM restante qui est utilisée, et non les poids.
3. Activations et espace de travail. Intermédiaires de la passe avant, zone de travail pour l'attention, espace de travail du noyau. Quelques Go pour l'inférence ; beaucoup plus pendant l'entraînement car les activations sont stockées pour la passe arrière.

Pour l'entraînement, ajoutez état de l'optimiseur (Adam conserve deux valeurs FP32 par poids — environ 8 fois la taille du poids FP16) et les gradients (1× taille du poids). C'est pourquoi l'entraînement d'un modèle 70B à partir de zéro nécessite 8 nœuds H100 ou A100 de 80 Go et n'est pas réalisable sur un boîtier Kentino. Le réglage fin avec LoRa ou QLoRa est une autre affaire et fonctionne parfaitement sur une configuration Blackwell à 4 GPU 5090 ou Pro 6000.

Conséquence pratique : la taille du modèle en VRAM n’est pas égale au nombre de paramètres multiplié par le nombre d’octets par paramètre. Pour un déploiement de 8 Ko d’un modèle de 70 octets sur INT4, planifiez… 40 Go de poids + 20 à 40 Go de cache KV pour un traitement par lots réaliste + 4 Go de surcharge Cela représente environ 70 Go. Cela tient sur une seule RTX Pro 6000 Blackwell Server Edition (96 Go) ou nécessite 3 à 4 RTX 5090 pour une configuration raisonnable. La quantité totale de VRAM importe moins que la VRAM par carte et leur configuration.

Bande passante VRAM : le chiffre qui détermine la vitesse de génération des jetons

La génération de jetons sur un LLM de type transformateur est limitée par la bande passante, et non par la puissance de calcul. Chaque jeton généré lit l'intégralité du modèle depuis la VRAM via le bus mémoire. La puissance de calcul en TFLOPS indiquée dans la fiche technique est largement sans importance pour l'inférence ; ce qui compte, c'est la bande passante mémoire en Go/s.

Kentino ne vend pas les modules H100 ni H200 ; ils sont mentionnés à titre de comparaison objective. Ils restent les références en matière de bande passante et la raison pour laquelle les hyperscalers les achètent. L’écart de prix est de 6 à 10 fois, tandis que l’écart de bande passante pour l’inférence mono-flux est de 2 fois. Pour les charges de travail non hyperscale, ce calcul ne plaide pas en faveur de la mémoire HBM.

Règle approximative pour la génération de jetons à flux unique INT4 : tok/s ≈ bande passante (Go/s) / taille du modèle (Go), multiplié par un facteur d'efficacité de pile de 0.6 à 0.8. Un modèle 70 octets à INT4 (~40 Go) sur une seule 5090 :

1790 GB/s × 0.7 / 40 GB ≈ 31 tok/s (single stream, no batching)

Cela correspond à nos mesures en laboratoire. Le traitement par lots porte le débit agrégé à 50–100 tok/s, mais la vitesse par flux reste proche de la limite de bande passante. La quantité de RAM système n'a aucune incidence sur ce résultat.

VRAM ECC : importante pour l’entraînement, moins critique pour l’inférence

La gamme RTX Pro 6000 Blackwell intègre de la mémoire VRAM ECC (à correction d'erreurs). Les cartes grand public (5090, 4090) n'en sont pas équipées. Le marketing insiste sur ce point, mais la réalité est plus nuancée.

La mémoire VRAM ECC détecte et corrige les erreurs de mémoire mono-bit en temps réel. Sans elle, une erreur se propage, généralement de manière invisible lors de l'inférence (un jeton légèrement différent de ce qu'il aurait dû être), parfois de manière catastrophique lors de l'entraînement (propagation de NaN, divergence, exécution morte).

Quand la CCE compte :

• Entraînement de longue durée. Le trafic mémoire lors des tâches de plusieurs jours augmente considérablement le risque d'inversion silencieuse de bits. Perdre 48 heures de calcul à cause d'une erreur non détectée est bien pire que de perdre une erreur corrigée.
• Charges de travail numériques sans intervention humaine. Simulation, modélisation, tout ce qui est consommé en aval sans vérification de cohérence.
• Charges de travail réglementées. Si votre système de conformité exige une reproductibilité au bit près, la correction d'erreurs (ECC) est obligatoire.

Lorsque l'ECC est essentiellement cosmétique :

• Service d'inférence LLM. Le taux d'inversion de bits sur la GDDR7 moderne est suffisamment faible pour que son impact sur la qualité de l'image soit négligeable. Nous avons utilisé des cartes 5090 grand public avec une charge d'inférence importante pendant des mois sans observer d'anomalies imputables à des erreurs de VRAM.
• Génération d'images et de vidéos. Le bruit de fond perceptuel absorbe une erreur d'un seul bit.
• Développement et expérimentation. Redémarrer et relancer l'exécution ne coûte pas cher.

En toute franchise : si votre activité principale est l’inférence, le surcoût du Pro 6000 se justifie par ses 96 Go de VRAM et ses pilotes validés, et non par la correction d’erreurs ECC. Si votre activité principale est l’entraînement, la correction d’erreurs ECC est indispensable. Nous vendons les deux modèles et nous vous le confirmerons par téléphone.

Mémoire vive système : quantité et vérité sur le déchargement du processeur

La mémoire RAM système remplit quatre fonctions dans un serveur d'IA :

1. Étapes de chargement du modèle du disque vers la VRAM. Un fichier modèle de 70 octets déplace le système de stockage NVMe vers le cache de pages, puis vers la RAM système et enfin vers la VRAM. Si la RAM système est plus petite que le fichier, le chargement échoue ou provoque un ralentissement important.
2. Prend en charge le système d'exploitation, le serveur d'inférence (vLLM, llama.cpp, Triton) et les services auxiliaires. (base de données vectorielle, surveillance, file d'attente des requêtes).
3. Contient l'état du tokenizer, les files d'attente de requêtes et les tampons de pré/post-traitement.
4. Peut héberger des couches déportées du processeur (en option). C'est celui que les gens surestiment.

Le déchargement du processeur, dans llama.cpp et des environnements d'exécution similaires, permet d'exécuter un modèle plus volumineux que la VRAM en conservant certaines couches sur le processeur et en les transférant via le GPU par jeton. Cela fonctionne. Dans la quasi-totalité des cas réalistes, c'est aussi une véritable galère.

Chiffres : une 5090 possède une bande passante VRAM de 1.79 To/s. Une plateforme EPYC Genoa à 12 canaux avec DDR5-4800 offre une bande passante agrégée d’environ 460 Go/s. Le déchargement du processeur est 4 à 6 fois plus lent par jeton que la résidence complète en VRAM, dans le meilleur des cas. — cela suppose une localité NUMA parfaite et un processeur qui n'est pas également occupé par des tâches de traitement supplémentaires.

Résultats des tests de performance d'une configuration 4×5090 avec --n-gpu-layers accordé :

• Entièrement sur GPU (70B INT4 sur 4×24 Go) : 28–32 tok/s en flux unique.
• 80 % sur GPU, 20 % sur CPU : 6–9 tok/s.
• 50/50 : 2–4 tok/s.

Ceci n'est pas l'avis de Kentino. Il s'agit de la comparaison entre la bande passante de la DDR5 et celle de la GDDR7. La solution au problème « le modèle ne tient pas dans la VRAM » réside dans l'utilisation de GPU plus performants, et non dans la RAM système avec déchargement. L'exception est la plateforme à mémoire unifiée AMD Ryzen AI Max 300, un système différent qui ne sera pas abordé ici.

Achetez suffisamment de RAM système pour charger et servir des serveurs, pas pour effectuer des calculs.

Combien de RAM système, concrètement ?

Une règle de travail pour les configurations K-AI :

System RAM ≈ 1.5 × total VRAM, rounded to the next standard config.

Pour une configuration à 4 GPU :

Pour les configurations à 8 GPU, la capacité de RAM n'est pas strictement linéaire ; il est préférable de rester dans la limite des canaux d'un même socket. Par défaut, nous recommandons 256 Go pour 8 GPU 5090 et 512 Go pour 8 GPU Pro 6000 Blackwell.

La règle présente deux modes de défaillance aux limites :

• Spécifications insuffisantes : 64 Go sur un serveur à 8 GPU. Le modèle se charge lentement, le cache de pages ne peut pas contenir les poids pour un rechargement rapide, et le service simultané ainsi que les services auxiliaires (pgvector, surveillance) commencent à saturer la mémoire.
• Surdimensionné : 2 To sur un serveur d'inférence à 4 GPU. Ça fonctionne, certes, mais vous avez dépensé entre 4 000 et 8 000 € pour de la RAM qui ne sert à rien. L'exception ? L'hébergement de nombreux modèles avec une rotation VRAM↔RAM : dans ce cas, une grande quantité de RAM système fait office de cache actif. Rare en dehors des laboratoires de recherche.

Le cas où « 64 Go suffisent » existe : une machine à deux GPU, un seul modèle à la fois, sans concurrence ni services auxiliaires. Il ne s’agit pas d’un serveur professionnel, mais d’une station de travail pour développeurs exigeants.

Canaux EPYC : d’où provient réellement la bande passante

La bande passante de la mémoire vive système sur les processeurs AMD EPYC (qui équipent la quasi-totalité de nos serveurs 8 GPU) est proportionnelle au nombre de canaux mémoire occupés, et non à la vitesse nominale des barrettes DIMM. Chaque canal correspond à un socket, et une barrette DIMM y est occupée.

Deux éléments de ce tableau :

1. Remplissez les douze canaux Sur une plateforme EPYC Genoa/Turin, pour obtenir la bande passante annoncée, il faut installer huit barrettes DIMM. Dans un système à douze canaux, cela donne huit canaux de bande passante, et non douze. Nous constatons fréquemment cette erreur de configuration sur le terrain.
2. Le nombre de barrettes de mémoire (DIMM) détermine la taille minimale raisonnable de la RAM. 12 × 16 Go = 192 Go. 12 × 32 Go = 384 Go. Les configurations « économiques » sous-dimensionnées (six barrettes DIMM de 32 Go pour 192 Go) gaspillent la moitié de la bande passante. À éviter absolument.

Le double socket offre un total de 24 canaux ; la bande passante double globalement, mais seulement si la charge de travail respecte la norme NUMA.

NUMA : le coût du franchissement de la ligne

Un serveur EPYC biprocesseur possède deux puces CPU, chacune avec ses propres contrôleurs mémoire, emplacements DIMM et interface PCIe. Le passage de la mémoire d'un processeur au GPU de l'autre emprunte le protocole Infinity Fabric ; c'est rapide, mais moins rapide qu'en restant au niveau local.

Des chiffres approximatifs mais utiles :

Pour l'inférence, la pénalité NUMA est généralement invisible : une fois le modèle en VRAM, le trafic RAM système est négligeable. NUMA a une importance lorsque :

• Chargement d'un modèle. Un chargement de 100 Go depuis le mauvais nœud prend sensiblement plus de temps. Liez-vous avec numactl ou définissez une affinité dans votre environnement d'exécution de conteneur.
• Prétraitement côté processeur (Tokenisation à grande échelle, décodage d'images, rééchantillonnage audio). Un tokenizer très sollicité sur le socket 0, avec des GPU connectés au socket 1, perd 20 à 40 % de débit.
• Entraînement avec état d'optimiseur déchargé du processeur (DeepSpeed ​​Zero-Offload). L'état NUMA externe double le temps d'exécution. Épinglez tout.

Réponse pratique : par défaut, un seul socket est utilisé pour les serveurs d'inférence Sauf raison particulière, nous proposons une configuration biprocesseur (K-AI 256 Turin Dual) car certaines charges de travail l'exigent : entraînement et inférence simultanés, stockage de vecteurs en mémoire importante, huit GPU nécessitant deux complexes racine. La plupart des cas n'en ont pas besoin. Un Turin monoprocesseur à 12 canaux et 384 à 512 Go de mémoire suffit pour la plupart des applications d'inférence.

DDR5 RDIMM vs LRDIMM et ECC

En 2026, la mémoire vive des serveurs sera exclusivement de type DDR5 ECC. Le choix se portera sur les modules RDIMM ou LRDIMM.

• RDIMM (enregistrée) : Mémoire serveur standard, chemin de commandes tamponné, ECC inclus. Modules propres jusqu'à 64 Go, 128 Go sur certaines plateformes.
• LRDIMM (charge réduite) : Ajoute une mémoire tampon réduisant la charge du bus et permettant une capacité par canal plus élevée. Requise pour les modules de 128 Go et plus. Latence légèrement supérieure, négligeable en conditions réelles d'utilisation.

Configuration par défaut du Kentino : 32 Go ou 64 Go de RDIMM à DDR5-4800 (Genoa) ou DDR5-6000 (Turin). LRDIMM est utilisé uniquement lorsque la configuration requiert plus de 1 To, ce qui est rare en dehors des formations ou de l’hébergement multi-modèles. La mémoire ECC est obligatoire : les plateformes livrées ne comportent pas de barrettes DIMM serveur non ECC.

Que se passe-t-il lorsque la mémoire est défaillante ?

Modes de défaillance prévisibles, par ordre de fréquence approximatif :

• Chargement lent du modèle sur une RAM sous-dimensionnée. Un modèle 70B occupe environ 40 Go sur disque. Avec 32 Go de RAM système, le chargement sature le cache de pages et un démarrage à froid de 40 secondes passe à 4 minutes. Solution : VRAM totale minimale de 1.5 fois.
• Pénalité de bande passante réduite de moitié en raison de canaux DIMM sous-utilisés. Six barrettes DIMM dans une carte mère EPYC à douze canaux. Le prétraitement, gourmand en ressources CPU, est divisé par deux sans avertissement. Solution : installer des barrettes DIMM dans tous les canaux.
• Accès NUMA externe sur un système à deux sockets avec une affinité incompatible. Correction: numactl --cpunodebind=0 --membind=0, ou le mode compatible NUMA du framework.
• Erreur de mémoire insuffisante (OOM) lors d'un lot important sur un cache KV sous-estimé. vLLM --gpu-memory-utilization 0.9 Il reste 10 % de marge, mais 64 requêtes simultanées avec un contexte de 32 Ko saturent toujours une carte de 24 Go. Solution : contexte plus court, lot plus petit ou plus de VRAM.
• Le déchargement du processeur « sauve » la compilation mais détruit le débit. « Le serveur est lent » — il s'avère que 30 % des couches sont utilisées par le processeur en raison d'une mémoire vidéo insuffisante. Erreur de dimensionnement, pas d'optimisation. Il faut prévoir le nombre de GPU adéquat dès le départ.

Aucun de ces problèmes n'est rare. Ils apparaissent tous au cours du premier mois suivant une nouvelle installation.

---

Ceci fait partie du Kentino Wiki, une série de référence sur l'intelligence artificielle, la robotique et les systèmes qui les connectent. Commentaires et corrections bienvenus. info@kentino.com.