L'architecture NVIDIA Rubin maximise le débit de l'inférence IA grâce à la co-conception
NVIDIA détaille cinq stratégies matérielles et logicielles dans son architecture Rubin qui améliorent l'efficacité des usines d'IA en optimisant l'utilisation de la mémoire pour les caches KV et les poids des modèles.
Traduit automatiquement depuis l'original anglais.
NVIDIA a présenté une stratégie globale visant à maximiser l'efficacité des charges de travail d'inférence IA grâce à une co-conception étroite entre le matériel et le logiciel. Publiée le 5 novembre 2026, cette analyse technique approfondie explique comment le futur système Vera Rubin NVL72 atteint un débit par mégawatt jusqu'à 30 fois supérieur à celui de la génération précédente GB300. Ce bond en performance ne provient pas d'une augmentation de la capacité mémoire, qui reste fixée à 288 Go par GPU, mais d'une amélioration significative de l'utilisation de chaque octet de la mémoire à large bande passante (HBM).
Ce qui s'est passé
Le défi central abordé dans cette mise à jour est le goulot d'étranglement de la HBM dans les usines d'IA modernes. À mesure que les modèles grossissent et que les fenêtres de contexte s'élargissent, la HBM devient la ressource la plus coûteuse et la plus disputée. NVIDIA soutient que simplement ajouter davantage de mémoire est insuffisant ; il faut plutôt se concentrer sur la garantie que chaque octet contribue directement à la génération de tokens, plutôt que de rester inactif ou de stocker des données redondantes. L'entreprise démontre que le débit agentique par mégawatt a augmenté bien plus rapidement que la capacité brute, indiquant un changement fondamental dans les priorités architecturales.
Pour résoudre ce problème, NVIDIA a introduit cinq leviers spécifiques issus de la co-conception, couvrant l'architecture GPU, les interconnexions, le logiciel de service, les CPU et le stockage. Ces innovations travaillent ensemble pour réduire l'empreinte des modèles, optimiser la distribution des poids, gérer les caches clé-valeur (KV) comme une ressource à l'échelle de la flotte, exploiter la mémoire CPU pour les contextes inactifs et étendre les niveaux de stockage à travers l'ensemble des pods. Le résultat est un système capable de gérer des flux de travail agentiques complexes et à long contexte avec une concurrence beaucoup plus élevée et une latence réduite.
Comment cela fonctionne
Le premier levier est NVFP4, un nouveau format de précision qui réduit l'empreinte des poids du modèle d'environ 3,5x par rapport au FP16 et de 1,8x par rapport au FP8. En utilisant un élément de 4 bits avec deux niveaux de mise à l'échelle, NVFP4 préserve la précision tout en libérant une quantité significative de HBM pour les caches KV et les lots plus grands. Ce format s'applique également au cache KV lui-même, réduisant son empreinte jusqu'à 50 % par rapport au FP8, ce qui permet de conserver deux fois plus de contexte résident sur l'appareil. Cette réduction minimise les évictions et la consommation de bande passante lors du décodage.
Deuxièmement, le parallélisme expert large dans TensorRT-LLM répartit les poids des modèles mixture-of-experts (MoE) sur huit GPU ou plus. Cette approche laisse plus de HBM disponible par GPU pour la mise en cache et augmente l'intensité arithmétique en réutilisant les poids sur un plus grand nombre de tokens. Troisièmement, NVIDIA Dynamo traite le cache KV comme une ressource partagée à l'échelle de toute la flotte. Il utilise le routage sensible aux KV pour placer les requêtes là où le contexte pertinent existe déjà, le service désagrégé pour séparer les charges de travail de préremplissage et de décodage, et un KV Cache Runner pour hiérarchiser les blocs entre GPU, CPU et stockage via la bibliothèque NIXL.
Les quatrième et cinquième leviers impliquent l'extension de la hiérarchie mémoire au-delà du GPU. Le CPU NVIDIA Vera dispose de 88 cœurs Olympus et jusqu'à 1,5 To de mémoire LPDDR5X connectée de manière cohérente au GPU via NVLink-C2C à 1,8 To/s. Cela permet de mettre en attente les caches KV inactifs dans la mémoire CPU pendant les appels d'outils, empêchant leur éviction de la HBM. Enfin, NVIDIA CMX ajoute un niveau de stockage G3.5 au niveau du pod, basé sur BlueField-4 STX et le réseau Spectrum-X. Ce niveau permet le partage et la réutilisation du cache KV entre les nœuds, garantissant que le contexte survit au-delà des sessions uniques ou des pannes de GPU.
Détails clés
- NVFP4 réduit l'empreinte des poids du modèle d'environ ~3,5x par rapport au FP16 et ~1,8x par rapport au FP8 tout en maintenant la précision.
- Le Vera Rubin NVL72 offre jusqu'à 30x le débit par mégawatt du GB300 NVL72 malgré la même capacité de 288 Go de HBM par GPU.
- Le parallélisme expert large répartit les experts MoE sur 8+ GPU, augmentant la disponibilité de la HBM pour le cache KV et améliorant la réutilisation des poids.
- NVIDIA Dynamo permet le routage sensible aux KV et le service désagrégé, traitant le cache KV comme une ressource à l'échelle de la flotte plutôt que comme un artefact local du GPU.
- Le CPU Vera fournit 1,5 To de mémoire LPDDR5X connectée à 1,8 To/s, permettant un déchargement efficace des caches KV inactifs pendant les appels d'outils.
- NVIDIA CMX introduit un niveau de stockage G3.5 utilisant BlueField-4 STX et Spectrum-X pour partager le cache KV entre les nœuds via du flash attaché à Ethernet.
Pourquoi c'est important
Pour les responsables d'infrastructure et les ingénieurs ML, ces développements signalent un passage de la mise à l'échelle brutale vers une gestion intelligente des ressources. La capacité à gérer des contextes plus vastes et une concurrence plus élevée sans augmentation proportionnelle du coût de la HBM est cruciale pour déployer des applications d'IA agentique économiquement viables. En réduisant l'empreinte des poids et des caches, les organisations peuvent exécuter des modèles plus complexes sur les contraintes matérielles existantes ou atteindre des débits significativement plus élevés lors de nouveaux déploiements.
L'intégration des niveaux CPU et stockage dans le pipeline d'inférence change également la façon dont les systèmes sont architecturés. Les développeurs ne peuvent plus considérer le GPU comme une unité de calcul isolée ; ils doivent concevoir des systèmes qui exploitent l'accès mémoire cohérent entre les CPU et les réseaux de stockage rapides et partagés. Cette approche de co-conception réduit la pénalité liée au temps d'inactivité pendant les appels d'outils et garantit que le contexte précieux n'est pas perdu en raison de la pression mémoire, conduisant à des agents IA plus réactifs et efficaces.
Ce que vous pouvez faire
- Évaluez la précision NVFP4 pour vos modèles actuels afin de réduire l'empreinte mémoire et d'augmenter la taille des lots sans sacrifier la précision.
- Implémentez le parallélisme expert large dans TensorRT-LLM si vous exécutez de grands modèles MoE pour optimiser l'utilisation de la HBM et l'intensité arithmétique.
- Explorez NVIDIA Dynamo pour le routage sensible aux KV et le service désagrégé afin d'améliorer les taux de réussite du cache et de réduire les coûts de recomputation.
- Envisagez des architectures exploitant la mémoire CPU pour mettre en attente les caches KV inactifs, surtout pour les charges de travail comportant des appels d'outils fréquents ou des pauses.
- Étudiez les solutions de stockage au niveau du pod comme NVIDIA CMX pour permettre le partage du cache KV entre les nœuds pour les sessions longues ou multi-agents.
- Surveillez attentivement les métriques d'utilisation de la HBM pour identifier les opportunités d'optimisation du cache et de compression des poids dans vos pipelines d'inférence.



