Mémoire Unifiée Grace Hopper Offre une Bande Passante Cohérente CPU-GPU de 900 Go/s

Pourquoi les plateformes NVLink/NVSwitch changent les règles de la mémoire, de la localité et du scaling par rapport aux systèmes GPU classiques connectés en PCIe

La frontière entre CPU et GPU était autrefois un gouffre. Les données résidaient dans la DRAM de l’hôte, les modèles et activations dans l’HBM du GPU, et tout ce qui traversait cet écart payait le prix d’un lien PCIe — des dizaines de gigaoctets par seconde et des latences à l’échelle de la microseconde qui pénalisaient l’accès irrégulier et le partage à grain fin. Avec Grace Hopper et l’écosystème plus large NVLink/NVSwitch, cette frontière se réduit en un pont cohérent et à haute bande passante. Jusqu’à environ 900 Go/s de bande passante cohérente CPU-GPU traversent NVLink-C2C à l’intérieur d’un superpuce Grace Hopper — plus d’un ordre de grandeur par rapport à un lien PCIe 5.0 x16 par direction — reformulant la façon dont les développeurs pensent au placement de la mémoire, au NUMA et au scaling.

Ce n’est pas « une mémoire pour les gouverner toutes ». C’est une évolution pratique: espaces d’adressage unifiés, charge/store cohérent CPU-GPU dans un package, et accès au niveau de tissu à travers les GPUs assez rapide pour faire des lectures distantes une option de premier ordre. La physique récompense toujours la localité, mais les pénalités pour devenir non local sont plus petites et plus prévisibles — surtout lorsque vous comprenez la mécanique de CUDA Unified Memory.

Deux architectures, un objectif: garder les données proches du calcul

Le modèle discret classique est simple à décrire et notoirement fastidieux à optimiser: les CPUs se connectent à la DDR ou LPDDR, les GPUs intègrent l’HBM sur le package, et un interconnect PCIe connecte les deux côtés. Les GPUs de classe Hopper offrent environ 3 To/s de bande passante HBM3 par appareil, avec une capacité de 80–96 Go. La mémoire hôte offre une capacité bien plus grande mais une bande passante inférieure; par exemple, la Grace-class LPDDR5X maintient au-dessus de 500 Go/s en agrégat. Il n’y a pas de cohérence de cache matériel entre CPU et GPU dans ce modèle — chaque côté garde ses propres caches, et les données bougent grâce à un DMA explicite (cudaMemcpy) ou à des migrations granulaires de page lors de l’utilisation de la mémoire unifiée.

Les plateformes de mémoire unifiée reconfigurent l’image. Dans un superpuce Grace Hopper, NVLink-C2C lie le complexe CPU et GPU ensemble avec un protocole cohérent et très haute bande passante — jusqu’à environ 900 Go/s pour le trafic CPU-GPU — avec une latence bien inférieure au PCIe. Cela permet le partage de charge/store à grain fin entre CPU et GPU sans copies explicites. À l’échelle du nœud, NVLink et NVSwitch interconnectent les GPUs de sorte que chaque appareil peut accéder aux HBM pair à haute bande passante et à latence relativement uniforme, avec support pour les charges/stores distants et les atomiques. La mémoire reste physiquement attachée à chaque GPU, mais le logiciel peut la traiter comme un espace d’adresse global avec des caractéristiques NUMA plutôt qu’une frontière nette.

Dans les deux mondes, l’objectif global reste inchangé: garder les données chaudes près des moteurs de calcul qui les utilisent le plus. La différence réside dans la sévérité des pénalités lorsqu’il est impossible de le faire.

Mémoire et cohérence: des frontières dures aux paliers NUMA

Les systèmes classiques attachés en PCIe tracent une ligne nette entre la RAM du CPU et l’HBM de chaque GPU. Il n’existe pas de cohérence de cache matériel CPU-GPU; les pilotes et environnements d’exécution doivent vider, copier ou migrer les données explicitement, et les lignes de cache obsolètes sont le problème du développeur s’ils se trompent dans l’ordre. Les effets NUMA s’accumulent rapidement: les hôtes multi-socket imposent leurs propres paliers, et les topologies PCIe ajoutent des asymétries à travers les commutateurs et complexes racines.

Grace Hopper adoucit la ligne à l’intérieur du package. Le CPU Grace et le GPU Hopper partagent un accès cohérent à travers NVLink-C2C. Les tables de pages sont coordonnées de sorte que, lorsque le CPU accède aux données résidant sur le GPU — ou que le GPU accède aux données résidant sur le CPU — l’accès possède des sémantiques cohérentes de charge/store. Cela ouvre la porte à des structures riches en pointeurs partagées à travers les phases CPU/GPU sans chorégraphie de copie.

À travers les GPUs, la cohérence s’arrête à la frontière L2. NVLink et NVSwitch ne rendent pas chaque cache GPU cohérent avec chaque autre. Au lieu de cela, le tissu offre un accès distant à haute bande passante et des atomiques, tandis que CUDA Unified Memory (et des bibliothèques comme NVSHMEM) orchestrent la migration et le mappage. Le résultat est une hiérarchie NUMA plutôt qu’un pool uniforme:

• L’HBM du GPU local reste le palier de la plus haute bande passante et à la plus faible latence pour les noyaux.
• La DDR/LPDDR du CPU local est le palier naturel pour le code hôte.
• L’accès croisé CPU-GPU via NVLink-C2C est plus lent que le local, mais nettement plus rapide et à latence plus faible que le PCIe.
• L’HBM des pairs GPU via NVSwitch est accessible à haute bande passante avec une latence presque uniforme, et pourtant toujours plus lente que l’HBM local.

Traiter explicitement ces paliers — plutôt que de supposer que « unifié » signifie « uniforme » — est la clé pour des performances cohérentes.

Interconnexions et topologie: plafonds PCIe vs tissus NVLink

PCIe établit la ligne de base. Un lien PCIe Gen5 x16 soutient environ 63 Go/s par direction (Gen4 ~31.5 Go/s; Gen6 ~128 Go/s). Les latences sont en microsecondes pour initier le DMA, et les sauts de commutateur ajoutent à la fois latence et concurrence. Les serveurs multi-GPU suspendent souvent deux à huit GPUs sur un ou plusieurs commutateurs PCIe par socket; sous charge, il est facile de saturer les liaisons montantes vers le complexe racine, et le trafic qui traverse les sockets CPU paie des pénalités inter-socket supplémentaires.

NVLink et NVSwitch vont bien au-delà de ces plafonds. La génération NVLink de Hopper expose jusqu’à ~900 Go/s de bande passante GPU–GPU agrégée par H100, avec une latence plus faible que le PCIe. À l’intérieur d’un nœud, NVSwitch construit un tissu entièrement connecté, à haute section critique, de sorte que tout GPU peut atteindre tout autre à presque latence uniforme et pleine bande passante par GPU vers le commutateur. Le couplage CPU–GPU à l’intérieur de Grace Hopper utilise NVLink-C2C pour offrir jusqu’à environ 900 Go/s de bande passante cohérente — suffisamment rapide pour rendre le partage à grain fin pratique.

Échelle ces idées, et le NVLink Switch System coud de nombreux nœuds Grace Hopper en un domaine logique. Les systèmes de classe DGX GH200 combinent jusqu’à 256 superpuces, exposant un espace d’adresse massif — de l’ordre de 144 To de mémoire agrégée — que le logiciel peut parcourir avec placement compatible NUMA.

CXL ajoute de la cohérence à la couche physique PCIe et mûrit rapidement pour l’expansion de la mémoire centrée sur le CPU et l’attachement des accélérateurs. Dans les plateformes de mémoire GPU unifiée d’aujourd’hui, cependant, NVLink/NVSwitch et NVLink-C2C portent le poids pour la cohérence GPU haute performance et l’accès à la mémoire au niveau du tissu.

Mémoire Unifiée en pratique: migration de pages, mapping et contrôle

CUDA Unified Memory (UVM) lie le modèle de programmation ensemble. Une seule allocation cudaMallocManaged donne un pointeur que le CPU et le GPU peuvent déréférencer. Sous le capot, UVM gère des pages, non des octets ou des structures. Lorsqu’un processeur accède à une page qui n’est pas localement résidente, l’accès déclenche un défaut de page:

• Le pilote peut migrer la page vers le processeur accédant.
• Ou il peut établir un mappage distant pour que l’accès soit servi à travers l’interconnect.

La granularité est importante. Sous Linux, UVM fonctionne avec des pages de base de 4 Ko. Les défauts fréquents sur de petites pages peuvent bloquer les noyaux, en particulier sur les systèmes PCIe où le traitement d’un défaut coûte des microsecondes et le lien plafonne le débit pratique. C’est là que la politique entre en jeu:

• cudaMemAdviseSetPreferredLocation épingle les régions fréquemment accédées près d’un GPU donné.
• cudaMemAdviseSetAccessedBy prépare les tables de pages pour un appareil sans migrer les données.
• cudaMemAdviseSetReadMostly permet la duplication pour un accès de lecture partagé à travers les processeurs.
• cudaMemPrefetchAsync transforme le paging à la demande en mouvement proactif avant le lancement des noyaux.

Sur les plateformes activées NVLink, le pilote préfère de plus en plus les mappages distants pour le partage en lecture uniquement pour éviter les migrations ping-pong, et lorsque les migrations sont nécessaires, NVLink offre une bande passante bien supérieure et une latence inférieure à celle du PCIe. À l’intérieur de Grace Hopper, les sémantiques cohérentes de charge/store serrent encore plus les interactions CPU–GPU: les structures de données lourdes en pointeurs et les phases mixtes CPU-GPU se comportent davantage comme un processus unifié qu’un accélérateur boulonné à un hôte.

La surinscription est l’autre moitié de l’histoire. Les allocations gérées peuvent dépasser la capacité HBM. Les pages froides se déversent dans la mémoire du CPU et migrent à la demande. Sur PCIe, le débit pratique est alors limité par le lien PCIe; le préchargement en lot et le streaming aident, mais l’accès aléatoire à grain fin reste douloureux. Sur NVLink et surtout Grace Hopper, la surinscription devient plus indulgente — l’accès distant est nettement plus rapide — mais elle traîne toujours derrière l’HBM local et bénéficie d’un préchargement minutieux, d’un agencement des données, et d’un traitement en lot.

La mémoire hôte épinglée et d’accès direct est assise à côté de UVM. Les tampons épinglés permettent au GPU de DMA directement, évitant les surcharges de paging. L’accès direct permet au GPU d’accéder à la mémoire de l’hôte sans mise en scène. Sur PCIe, l’accès direct est une niche; sur NVLink/Grace Hopper, il peut être sensiblement plus rapide et viable pour les opérateurs de type streaming, bien que toujours pas un substitut à l’HBM local.

Compromis de performance: la localité reste gagnante, mais les pénalités diminuent

La localité reste le levier dominant. L’HBM local offre une bande passante de plusieurs To/s et une faible latence; garder les données chaudes là dépasse la plupart des autres optimisations. La DDR/LPDDR côté CPU offre une bande passante inférieure mais une capacité ample et une réactivité pour les phases résidant sur l’hôte.

Les interconnexions fixent le coût du devenir non local. Par rapport aux ~63 Go/s par direction de PCIe Gen5, NVLink et NVLink-C2C offrent jusqu’à un ordre de grandeur de plus en bande passante avec une latence plus faible. Cela réduit — mais n’élimine pas — la pénalité de l’accès à la mémoire distante. Les résultats pratiques:

• Le partage à grain fin CPU–GPU devient raisonnable sur Grace Hopper, où l’accès cohérent évite une lourde orchestration des copies.
• Le partage en lecture multi-GPU prospère sur NVSwitch, où le mappage distant peut garder les pages chaudes résidentes sur plusieurs GPUs.
• Le partage en écriture à travers les processeurs reste coûteux; évitez les écritures fréquentes sur la même page depuis le CPU et le GPU.

Le comportement de la mémoire unifiée est souvent décisif. Sur les systèmes PCIe, de minuscules défauts de 4 Ko en milieu de noyau peuvent devenir des tempêtes de défauts qui effondrent le débit. Définir les emplacements préférés, marquer les régions principalement en lecture, et précharger de grandes portions contiguës avant le lancement des noyaux transforme le paging à la demande imprévisible en transferts prévisibles. Sur les systèmes NVLink, la même discipline réduit davantage les défauts en noyau, et le partage en lecture sur les mappages distants empêche le ressac.

Les copies de mémoire explicites ont toujours leur place. Lorsque les ensembles de travail s’insèrent confortablement dans l’HBM et que les flux de données đều réguliers, cudaMemcpy avec le pipeline de flux offre un chevauchement déterministe des transferts et du calcul. Avec UVM, des défauts de page surprenants peuvent perturber les chevauchements planifiés sauf si vous préchargez de manière agressive. Des outils comme Nsight Systems/Compute complètent la boucle en montrant les défauts de page, les migrations, et la résidence afin que vous puissiez vérifier que les noyaux chauds s’exécutent sans défaut.

Capacité et mise en pool: des limites par GPU aux espaces d’adressage à l’échelle du système

Le modèle de mémoire partagée limite la capacité utilisable à l’HBM de chaque GPU. Si les modèles ou ensembles de données dépassent cette limite, vous fractionnez à travers les GPUs, tilez explicitement, ou concevez des algorithmes out-of-core pour déplacer les données dans et hors de l’HBM. La mémoire unifiée assouplit la contrainte. Un superpuce Grace Hopper expose un espace d’adresse unique couvrant l’HBM et une large LPDDR; allouer bien au-delà de l’HBM est direct, et l’accès cohérent sur NVLink-C2C permet au GPU d’atteindre les pages résidentes sur le CPU avec plus de grâce que les systèmes connectés en PCIe.

À travers les GPUs, NVSwitch et le logiciel fournissent une vue mise en pool. L’accès en peer CUDA et UVM permettent le mapping et la migration des pages à travers les appareils, tandis que NVSHMEM ajoute des opérations PGAS en unilatéral qui s’alignent sur les codes d’analytique et de simulation. À l’échelle de la plateforme, les systèmes NVLink Switch transforment de nombreux superpuces Grace Hopper en un domaine de mémoire logique; dans les configurations de classe GH200, le logiciel peut cibler des centaines de téraoctets de mémoire adressable avec un placement conscient NUMA.

Le déversement de stockage complète la hiérarchie dans les piles analytiques: les frameworks utilisent des pools de mémoire dans l’HBM, déversent dans la mémoire hôte épinglée, puis dans le NVMe via GPUDirect Storage pour éviter les surcharges de rebond hôte. La compression se fait au niveau de l’application, non pas comme une fonctionnalité transparente de la mémoire GPU.

Facteurs systémiques, sécurité et réalités du déploiement

Les plateformes de mémoire unifiée haut de gamme disposent de fiabilité et d’isolation de qualité centre de données. L’HBM et la LPDDR emploient l’ECC, et les appareils de génération Hopper ajoutent des fonctionnalités RAS robustes comme la retraite de page et la contention des erreurs, avec une télémétrie accessible aux outils. NVLink et NVSwitch incorporent une protection de bout en bout pour maintenir les données intactes à travers le tissu.

L’isolation et la multi-location reposent sur des mécanismes établis:

• Les IOMMUs contraignent le DMA des appareils.
• Multi-Instance GPU (MIG) partitionne un GPU physique en instances isolées avec des portions dédiées de mémoire et de calcul.
• SR-IOV et le passage médié permettent le partage de GPU virtuel.
• Hopper introduit des fonctionnalités de calcul confidentiel — TEEs renforcées par le matériel, cryptage de mémoire et attestation — pour que les modèles et données sensibles puissent fonctionner dans une infrastructure partagée avec des garanties plus fortes.

Le déploiement conteneurisé est simple avec des chaînes d’outils standard; les configurations sensibles aux performances utilisent généralement le passage PCIe avec MIG ou des appareils exclusifs et s’appuient sur la découverte de topologie pour exploiter NVLink/NVSwitch efficacement.

Conseils pratiques: quand choisir les copies explicites vs mémoire unifiée

Choisissez les copies explicites (cudaMemcpy/streams) lorsque:

• L’ensemble de travail tient dans l’HBM et le flux de données est suffisamment régulier pour paralyser de grands transferts.
• Vous avez besoin d’un chevauchement déterministe des transferts H2D/D2H avec le calcul.
• Les noyaux sont serrés et sensibles à la latence, et vous pouvez imposer des tuiles/placement.

Appuyez-vous sur la mémoire unifiée lorsque:

• Vous parcourez des structures de données complexes et riches en pointeurs partagées à travers les phases CPU et GPU.
• Vous prototypez rapidement et voulez la correction avec une orchestration minimale de copie.
• Vous opérez sur des systèmes NVLink/NVSwitch où les mappages distants pour les données principalement en lecture peuvent éviter la duplication et le ressac.
• Vous avez besoin d’une correction fonctionnelle avec oversubscription, et êtes prêt à précharger/batcher l’accès pour atténuer les blocages.

Appliquez les contrôles UVM pour le rendre prévisible:

• Définissez les emplacements préférés pour les régions chaudes sur le GPU cible.
• Marquez les régions principalement en lecture pour qu’elles puissent être dupliquées en toute sécurité.
• Utilisez SetAccessedBy pour préparer les tables de pages pour les GPUs pairs sans migration.
• Préchargez avant le lancement des noyaux pour éliminer les défauts en noyau.
• Évitez le partage fréquent en écriture sur les mêmes pages à travers CPU et GPU.

Un rapide côte à côte

Dimension	Discrète classique (PCIe, RAM CPU + HBM GPU séparées)	Mémoire unifiée (Grace Hopper, NVLink/NVSwitch, CUDA UVM)
Mémoire et bande passante	CPU DDR/LPDDR; HBM3 GPU jusqu’à ~3 To/s localement; pas de cohérence CPU–GPU	HBM3 + large LPDDR5X; cohérence CPU–GPU via NVLink-C2C jusqu’à ~900 Go/s; vue mise en pool à travers GPUs via NVLink/NVSwitch
Cohérence et NUMA	Pas de cohérence matérielle CPU–GPU; fortes frontières NUMA	Cohérence CPU–GPU au sein de GH; paliers NUMA à travers HBM, LPDDR, et pairs; NVSwitch donne un accès uniforme à haute bande passante aux pairs
Interconnect	PCIe Gen4/5/6 x16 ≈ 31.5/63/128 Go/s par direction; latences en microsecondes; contention de commutateur	NVLink GPU–GPU jusqu’à ~900 Go/s agrégé par GPU avec une latence plus faible; NVLink-C2C ~900 Go/s cohérence CPU–GPU; tissus à pleine section critique NVSwitch
Mécanique UVM	Paging à la demande sur PCIe; défauts de 4 Ko coûteux; préchargement/conseils critiques; surinscription limitée par PCIe	Paging à la demande et mappage distante sur NVLink; bande passante de service de défaut plus élevée et latence plus faible; partage cohérent à grain fin sur GH; surinscription plus viable mais toujours plus lente que l’HBM local
Modèle de programmation	cudaMemcpy explicite et pipelining de flux; prévisibilité maximale	cudaMallocManaged avec préchargement/conseils; code simplifié; performance dépend de la résidence et de la localité

Conclusion: simplifier la frontière, pas la physique 🚀

Grace Hopper et NVLink/NVSwitch n’abolissent pas la localité; ils rendent le franchissement des frontières moins coûteux et plus contrôlable. Une bande passante cohérente CPU-GPU allant jusqu’à environ 900 Go/s à l’intérieur du superpuce change ce qui est pratique pour les algorithmes mixtes CPU-GPU. NVSwitch et NVLink élargissent l’idée à travers les GPUs, transformant les lectures et atomiques distantes en primitives viables et à fort débit plutôt qu’en dernier recours. CUDA Unified Memory lie tout cela ensemble avec un modèle à pointeur unique qui, avec les bons conseils et préchargement, transforme le paging à la demande sujet aux défauts en mouvement de données prévisible.

La stratégie gagnante est claire:

• Placez les ensembles de travail les plus chauds dans l’HBM local.
• Utilisez NVLink/NVSwitch pour partager et échelonner sans être submergé par les copies.
• Appliquez des politiques UVM pour garder les noyaux sans défaut de page.
• Traitez la mémoire comme un paysage NUMA en paliers, pas un océan plat.

En résumé, simplifiez la frontière logicielle — unifiez l’espace d’adressage et la cohérence là où cela compte — tout en respectant la physique de la bande passante et de la latence. Faites cela, et le passage des silos connectés PCIe aux tissus NVLink/NVSwitch devient moins une réécriture de code et plus une libération de performances auparavant inaccessibles.

Sources & Références