Les GPU bénéficient du budget, des communiqués de presse et de l'attention des dirigeants. Mais c'est toujours la mémoire système qui décide si un serveur GPU alimente proprement les accélérateurs ou s'il transforme discrètement un matériel coûteux en un désordre inactif, ralenti et saturé de swaps.
Commencez par la mémoire vive.
Je sais que cela semble rétrograde sur un marché où les acheteurs se vantent des H100, H200, B200, NVLink, du débit FP8 et de la structure 400GbE, mais l'horrible vérité opérationnelle est que la planification de la mémoire des serveurs GPU commence toujours par le sous-système de mémoire côté CPU, car les données doivent être mises en scène, décodées, mises en cache, épinglées, transférées, planifiées et récupérées avant que ces accélérateurs onéreux ne fassent un travail utile. Pourquoi dépenser des sommes à six chiffres pour des GPU et traiter la mémoire du système comme une réflexion après coup ?
NVIDIA Documentation DGX H100/H200 Le système H100 indique 640 Go de mémoire GPU, la configuration H200 indique 1 128 Go de mémoire GPU, et le même système contient encore 2 To de mémoire système utilisant 32 DIMM. Ce n'est pas de la décoration. C'est de l'architecture.
Voici ce que j'en pense : La RAM du CPU contre la VRAM du GPU n'est pas une rivalité. C'est un pipeline. La VRAM contient les tenseurs chauds, les shards de modèle, le cache KV, les embeddings, les activations et les données de travail à grande vitesse. La RAM du système gère le monde désordonné autour de ce travail : les chargeurs de données, les files d'attente de prétraitement, les tampons de l'hôte, les services du système d'exploitation, les conteneurs, les agents de journalisation, les métadonnées de stockage, la récupération des tâches échouées et les parties de l'apprentissage distribué qui refusent de s'intégrer dans une diapositive de référence propre.
Ainsi, lorsque quelqu'un demande “de quelle quantité de RAM un serveur GPU a-t-il besoin ?” je ne commence pas par un chiffre générique. Je demande ce que fait la machine à 2h17 du matin lorsque le modèle est en train de faire un checkpoint, que la couche de stockage tousse, que Kubernetes a surchargé le nœud et que huit GPU attendent sur un goulot d'étranglement du côté de l'hôte.
Le mensonge vend du matériel.
La mémoire système pour les serveurs GPU est importante car la mémoire HBM est rapide mais locale, limitée et coûteuse, tandis que la mémoire vive DDR4 ou DDR5 attachée au processeur est la zone de transit la plus large qui empêche le mouvement des données, l'isolation des processus et l'orchestration de la charge de travail de s'effondrer lors d'une utilisation en production réelle.
Le marché rend les choses plus difficiles, et non plus faciles. L'IHA de Stanford Rapport sur l'indice IA 2025 indique que les calculs de formation pour les modèles d'IA notables doublent tous les cinq mois environ, tandis que la taille des ensembles de données double tous les huit mois environ. Voilà qui devrait effrayer tous ceux qui évaluent les besoins en mémoire vive des serveurs d'IA à partir d'une feuille de calcul recyclée.
Et il ne s'agit pas seulement d'un problème de laboratoire d'intelligence artificielle. Le ministère américain de l'énergie a indiqué que la croissance de la charge des centres de données a triplé au cours de la dernière décennie et qu'elle devrait doubler ou tripler d'ici 2028, d'après les travaux du Lawrence Berkeley National Laboratory. Le laboratoire Berkeley a également indiqué que les centres de données américains consommaient environ 4,4% de l'électricité totale des États-Unis en 2023 et pourraient atteindre 6,7% à 12% d'ici 2028, en fonction d'une croissance plus large de la demande. Communiqué de presse sur l'énergie des centres de données du ministère de l'énergie et Résumé du Berkeley Lab Les deux indiquent la même direction : l'infrastructure accélérée devient une infrastructure industrielle.
L'infrastructure industrielle sanctionne le manque de rigueur dans le calcul de la mémoire.
Si vous construisez autour de plates-formes plus récentes, c'est ici qu'intervient le Mémoire serveur DDR5 commence à prendre tout son sens : plates-formes de plus haute génération, densité DIMM plus élevée, canaux de mémoire CPU modernes et meilleur alignement avec les cycles de construction actuels des serveurs d'IA. Pour les flottes patrimoniales stables, Mémoire serveur DDR4 joue encore un rôle très réel, en particulier lorsque la plateforme est déjà validée et que la charge de travail ne justifie pas un rafraîchissement complet des nœuds.
La plupart des mauvais serveurs GPU n'échouent pas de manière spectaculaire. Ils boitent.
Ils se manifestent par une utilisation du GPU de 52% sur un matériel qui devrait fonctionner à 85%. Ils se manifestent par des décrochages des chargeurs de données, une activité de swap, un déséquilibre NUMA, un comportement bruyant des conteneurs voisins, des retards dans les points de contrôle et des travaux de formation “aléatoires” qui fonctionnent bien le mardi et s'effondrent le vendredi.
Le tableau ci-dessous est la version que je présenterais à un acheteur d'infrastructure sceptique.
| Modèle de charge de travail | Ce qui casse en premier | L'importance de la mémoire vive | Note sur les marchés publics |
|---|---|---|---|
| Réglage fin du LLM sur 4 à 8 GPU | Dataloader et pression sur les points de contrôle | La RAM de l'hôte met en mémoire tampon les données tokenisées, la mémoire épinglée, les journaux et les états de récupération. | Ne pas dimensionner uniquement en fonction de la VRAM du GPU ; laisser une marge de manœuvre pour l'orchestration |
| RAG / intégration du pipeline | Prétraitement par l'unité centrale et mise en lots de vecteurs | L'analyse de texte, le découpage en morceaux, les métadonnées et les files d'attente de lots sont stockés dans la mémoire vive avant l'exécution par le GPU. | La capacité de la mémoire peut être plus importante que la vitesse maximale des modules DIMM |
| Inférence multi-locataires | Extension des conteneurs et surcharge de l'hôte | Chaque pile de services consomme de la RAM en dehors de la VRAM, en particulier avec les agents de surveillance. | Le surengagement semble rentable jusqu'à ce que le temps de latence augmente. |
| Formation à la vision par ordinateur | Pipeline de décodage et d'augmentation d'images | La mémoire vive de l'unité centrale absorbe les images décodées et les transformations avant le transfert. | Les GPU rapides exposent les faiblesses de la planification de la mémoire hôte. |
| Simulation HPC avec accélération GPU | NUMA et déséquilibre des sockets | La localité de la mémoire de l'unité centrale affecte l'alimentation en données et le comportement de MPI. | Achetez l'agencement de la population, et pas seulement l'étiquette du module DIMM. |
| Nœuds d'IA hérités | Plafond de capacité DDR4 | Les plateformes plus anciennes peuvent encore être utiles si la mémoire est adaptée et validée. | La mémoire vive mixte bon marché peut coûter plus cher que les modules de remplacement approuvés |
J'observe trop souvent une mauvaise habitude en matière d'approvisionnement : les acheteurs sont obsédés par le nombre de GPU et demandent ensuite “toutes les clés de 64 Go disponibles”. Mais la mémoire des serveurs n'est pas de la RAM vendue au détail avec un autocollant différent. L'ECC, les RDIMM, les LRDIMM, la structure des rangs, la vitesse, la tension, la prise en charge par le BIOS et l'ordre de peuplement ont leur importance.
C'est pourquoi j'enverrais tout acheteur sérieux à une test de qualité de la mémoire du serveur et processus de garantie avant de les laisser se disputer sur de minuscules différences de prix à l'unité. La page qualité de ServerDIMM met l'accent sur l'examen de la compatibilité, les vérifications de la génération DDR4/DDR5, la validation ECC RDIMM ou LRDIMM, l'examen des numéros de pièces et le contrôle avant expédition. Il s'agit là d'un travail fastidieux qui permet d'éviter des défaillances coûteuses.
Une plus grande quantité de mémoire vive est utile.
Mais si les modules DIMM se trouvent dans les mauvais emplacements, s'ils sont répartis de manière inégale sur les sockets des processeurs ou s'ils sont mélangés dans des structures de rangs non prises en charge, la capacité devient alors une couverture de confort. Elle fait bonne figure dans un bon de commande, mais ne donne pas de bons résultats sous charge.
J'aime la formulation de ServerDIMM sur les mémoire population ordreLes clients de l'agencement : ils achètent l'agencement, pas le module. C'est exactement comme cela que le travail de guide de construction de serveur GPU devrait être fait. Un objectif de mémoire de 2 To n'est pas un élément unique. Il s'agit de la symétrie des sockets, du remplissage des canaux, du type de DIMM, du comportement des rangs, de la vitesse supportée et de la validation de la plate-forme.
L'Agence internationale de l'énergie Analyse de l'énergie et de l'IA prévoit que la consommation électrique mondiale des centres de données atteindra environ 945 TWh d'ici 2030 dans son scénario de base, avec une consommation électrique accélérée des serveurs augmentant d'environ 30% par an. Ce chiffre devrait modifier la façon dont nous parlons de la construction des serveurs : l'utilisation insuffisante des GPU n'est pas seulement un problème de performance ; c'est un problème d'énergie, de refroidissement, de densité des racks et d'efficacité des investissements.
Voici la partie que les fournisseurs n'aiment pas dire haut et fort : un serveur GPU avec des accélérateurs sous-alimentés n'est pas “presque optimisé”. C'est une fuite financière avec des ventilateurs.
Je ne fais pas confiance aux formules universelles.
Néanmoins, lorsque je dois vérifier rapidement les besoins en RAM d'un serveur GPU, j'utilise les ratios comme argument de départ, et non comme conception finale. Pour de nombreux nœuds d'apprentissage et d'inférence en IA, je veux suffisamment de mémoire système pour couvrir les frais généraux du système d'exploitation, les frais généraux du conteneur, le chargement des données, le prétraitement, la mémoire épinglée, la mise en scène des lots, la télémétrie, le point de contrôle et le chevauchement des tâches dans le pire des cas. Dans de nombreuses constructions réelles, cela signifie que la RAM du CPU peut facilement dépasser la VRAM totale du GPU, parfois avec une grande marge.
Pour un serveur de classe H100 à 8 GPU avec 640 Go de mémoire GPU totale, un plan de RAM système de 1 To peut être justifié pour une inférence contrôlée ou des charges de travail étroites. Mais pour une infrastructure d'IA à forte charge de formation, multi-locataire, à forte charge de préparation des données ou à usage mixte, 2 To n'est pas extravagant. C'est souvent le chiffre adulte.
Et oui, c'est là que les marchés publics deviennent politiques.
Le département des finances demande pourquoi le budget de la RAM augmente. L'équipe chargée de l'infrastructure répond “stabilité”. L'équipe d'intelligence artificielle répond “débit”. Le revendeur dit “nous pouvons économiser de l'argent avec des lots mixtes”. Puis quelqu'un ouvre le guide du fournisseur et se rend compte que les RDIMM et les LRDIMM ne sont pas des bracelets de l'amitié.
Avant de mélanger quoi que ce soit, lisez un guide de compatibilité sobre tel que Peut-on mélanger la mémoire vive d'un serveur ?. La version courte : parfois, mais uniquement dans le cadre des règles de la plate-forme. Même génération DDR. Même type de module DIMM pris en charge. Comportement ECC correct. Ordre de population correct. Symétrie correcte du socle du processeur. Comportement correct en termes de rang et de vitesse. Sinon, vous n'économisez pas d'argent, vous achetez de l'incertitude.
Le choix de la meilleure RAM pour un serveur GPU se résume généralement à quatre questions :
La plateforme est-elle DDR4 ou DDR5 ?
A-t-il besoin de modules ECC RDIMM, LRDIMM ou d'un autre type de module approuvé ?
Quelle est la capacité totale nécessaire par nœud, par socket et par GPU ?
Le fournisseur peut-il fournir des numéros de pièces cohérents, des stocks testés et une documentation avant le déploiement ?
Cette dernière question est plus importante que ne l'admettent de nombreux acheteurs. A fournisseur de RAM pour serveur en vrac L'approvisionnement en DDR3, DDR4, DDR5, ECC, RDIMM et LRDIMM ne se limite pas à la vente de capacité. La valeur réside dans un approvisionnement reproductible : marques connues, stocks testés, examen de la compatibilité et processus de devis qui demande le modèle de serveur, la capacité cible, le type de module, la quantité et la destination avant de prétendre que tout est simple.
Pour les nœuds d'IA actuels, j'examinerais d'abord les options RDIMM DDR5 telles que les modules de 64 Go, 96 Go et 128 Go, puis je validerais la prise en charge de la plate-forme. DIMM pour serveur Micron 96GB DDR5 5600 2Rx4 server RAM est un exemple utile du niveau de détail auquel les acheteurs sérieux devraient s'intéresser : capacité, génération, configuration du rang, niveau de vitesse, MPN et application.
L'étiquette est importante.
Un module RDIMM DDR5-5600 2Rx4 de 96 Go n'est pas interchangeable avec un module aléatoire de 96 Go provenant d'une autre plateforme, simplement parce que la capacité correspond. Dans les serveurs GPU, les petites erreurs de compatibilité créent un bruit opérationnel important.
Les dirigeants veulent des graphiques d'utilisation des GPU parce qu'ils sont faciles à comprendre. La ligne verte en haut, c'est bien. Une ligne verte vers le bas, c'est mauvais.
Mais la ligne verte est souvent en aval de la discipline de la mémoire hôte. Si la couche de mémoire côté CPU ne peut pas alimenter les lots, maintenir le prétraitement en amont de l'apprentissage, maintenir la pression du cache et absorber les frais généraux d'orchestration, alors les GPU attendent. Ils ne se plaignent pas. Ils se contentent de rester là à brûler de l'énergie coûteuse pendant que les tableaux de bord s'allongent poliment.
C'est pourquoi je n'aime pas le dimensionnement paresseux de la mémoire du serveur GPU. Il traite la RAM du système comme un acteur de soutien alors qu'elle fait en réalité partie du plan de données. Dans un serveur d'IA sérieux, les goulets d'étranglement de la mémoire dans les serveurs GPU méritent la même attention que le SKU du GPU, la génération PCIe, la topologie NVLink, la vitesse du NIC, l'agencement du stockage et l'enveloppe de refroidissement.
Voici donc la version de l'opinion : si le budget GPU est sacré mais que le budget RAM est négociable, le processus de construction est déjà cassé.
Un serveur GPU a besoin de suffisamment de RAM pour prendre en charge le système d'exploitation, les conteneurs, les chargeurs de données, le prétraitement, la mémoire épinglée, le point de contrôle, les agents de surveillance et les tâches simultanées sans échanger les accélérateurs ou les affamer. Pour l'inférence légère, 512 Go à 1 To peuvent faire l'affaire. Pour les nœuds de formation à 8 GPU, 1 à 2 To sont souvent plus réalistes.
La RAM du CPU est la mémoire système générale du serveur pour les processus hôtes, la mise en scène des données, l'orchestration, le prétraitement et l'activité du système d'exploitation, tandis que la VRAM ou HBM du GPU est la mémoire locale de l'accélérateur utilisée pour l'exécution de modèles à grande vitesse, les tenseurs, les activations, le cache KV et les charges de travail résidant dans le GPU. Dans la pratique, ils travaillent ensemble. La VRAM gère le chemin chaud ; la RAM du système empêche le reste de la machine d'affamer ce chemin.
La DDR5 est meilleure pour les serveurs GPU lorsque la plateforme la prend en charge, que la charge de travail bénéficie d'une bande passante plus élevée ou d'options de densité plus récentes, et que le plan d'approvisionnement peut valider le type de module, la capacité, la vitesse, la structure de rang et la disposition de la population sans créer de risque de prise en charge. La DDR4 peut encore être la bonne réponse pour les parcs validés plus anciens. Un mauvais module DDR5 est pire qu'un bon module DDR4.
La RAM du serveur ne peut être mélangée que si la plate-forme du serveur prend explicitement en charge la combinaison exacte de la génération DDR, du comportement ECC, du type RDIMM ou LRDIMM, de la structure de rang, de la disposition de la capacité, du comportement de la vitesse, de la symétrie de la prise CPU et de l'ordre de la population DIMM utilisée dans la configuration finale. Traiter le mélange comme une exception. Dans les serveurs GPU, le mélange de mémoire non pris en charge peut entraîner des échecs au démarrage, un downclocking, une instabilité ou un comportement imprévisible de la charge de travail.
Les goulots d'étranglement de la mémoire dans les serveurs GPU se produisent lorsque la capacité de la RAM côté CPU, la bande passante de la mémoire, le placement NUMA, la population DIMM, la mise en cache du stockage, le comportement du dataloader ou la planification du transfert de l'hôte vers le GPU ne peuvent pas alimenter en permanence les accélérateurs avec du travail utile. Le symptôme est souvent une faible utilisation du GPU. La cause est souvent en amont : un prétraitement insuffisant, une mauvaise mise en lot, une RAM insuffisante ou une disposition de la mémoire déséquilibrée.
Ne pas dimensionner la mémoire du serveur GPU à partir d'une copie marketing.
Auditer la charge de travail. Comptez les GPU, mais aussi les ensembles de données, les conteneurs, les utilisateurs, les points de contrôle, les étapes de prétraitement, les limites NUMA, les canaux de mémoire, les emplacements DIMM et les domaines de défaillance. Ensuite, approvisionnez la mémoire en fonction des règles de la plateforme, et non en fonction de vos souhaits.
Pour une construction réelle, envoyez votre modèle de serveur, la génération de votre CPU, la configuration de votre GPU, votre RAM totale cible, votre capacité DIMM préférée, votre exigence DDR4 ou DDR5, la règle ECC RDIMM/LRDIMM, et la quantité cible à un fournisseur qui peut la valider avant l'expédition. Commencez par La voie d'approvisionnement en RAM pour serveurs de ServerDIMM et faire de la mémoire du système une décision de conception, et non un élément de dernière minute.
ServerDimm fournit des mémoires de serveur de marque, neuves et d'occasion, aux distributeurs, aux acheteurs OEM, aux revendeurs et aux équipes des centres de données. Nous prenons en charge l'approvisionnement en DDR4 et DDR5 avec des stocks testés, des vérifications de compatibilité et un service de devis réactif.
Copyright © 2026 Shenzhen Lux Telecommunication Technology Co.,Ltd. Tous droits réservés
