OpenAI SemiAnalysis Lens : Vera Rubin NVL72 surpasse GB200, mais l’argumentaire TCO est plus limité

Le Vera Rubin NVL72 de NVIDIA a publié ses premiers résultats mesurés sur silicium, revendiquant un débit par mégawatt dix fois supérieur à celui du GB200 NVL72, à interactivité équivalente. Le lien avec OpenAI SemiAnalysis passe par Triton, dont la prise en charge de Rubin contribue à rendre l’architecture accessible aux logiciels d’IA largement utilisés.

Le chiffre est frappant, mais il compare Rubin à une référence logicielle GB200 de début 2025. SemiAnalysis a constaté un avantage plus limité face aux résultats Blackwell de juillet 2026, même si Rubin restait en tête sur toute la plage d’interactivité testée.

Cette distinction définit la véritable compétition. Rubin n’est pas simplement un GPU plus rapide remplaçant un GPU plus ancien. C’est un système à l’échelle d’un rack conçu pour maintenir une inférence réactive lorsque la taille des modèles, le trafic mémoire et la demande en tokens augmentent simultanément.

Ce résultat met sous pression les exploitants de GB200, les fournisseurs d’accélérateurs concurrents et les développeurs qui maintiennent des kernels personnalisés. Il laisse également subsister une lacune importante en matière de vérification. Le test initial a utilisé un rack d’échantillonnage d’ingénierie, un ancien modèle de raisonnement et une charge de travail à un seul tour.

Le premier résultat de Rubin modifie la comparaison NVL72

L’avance initiale de Rubin semble réelle, mais le chiffre de dix fois correspond à une comparaison dans le meilleur des cas plutôt qu’à un ratio de performance universel.

CoreWeave a publié le premier benchmark mesuré sur silicium du Vera Rubin NVL72 le 21 juillet 2026. Ses ingénieurs ont exécuté DeepSeek R1 sur Rubin et GB200 NVL72 avec les mêmes principales optimisations d’inférence activées.

Le test a mesuré le débit de tokens de sortie par mégawatt en fonction de l’interactivité, exprimée en tokens par seconde pour chaque utilisateur. Ce point est important, car un service d’inférence doit concilier la capacité totale et une vitesse de réponse acceptable.

À interactivité équivalente, les résultats mesurés sur silicium ont montré jusqu’à dix fois plus de débit de tokens de sortie par mégawatt. La comparaison reposait sur une référence GB200 NVL72 de 2025.

CoreWeave indique que les deux systèmes utilisaient la précision NVFP4, le décodage spéculatif, un parallélisme d’experts étendu ainsi qu’un préremplissage et un décodage désagrégés. TensorRT-LLM et NVIDIA Dynamo fournissaient le logiciel de service.

NVFP4 est le format numérique quatre bits de NVIDIA visant à réduire le stockage et les calculs des modèles. Le décodage spéculatif génère des tokens candidats avant leur vérification finale, ce qui accélère la sortie lorsque ses prédictions sont correctes.

Le service désagrégé sépare le préremplissage et le décodage entre différents groupes de GPU. Le préremplissage traite le prompt, tandis que le décodage génère la réponse un token à la fois.

Ces optimisations comptent, car les résultats de benchmark mesurent souvent autant la qualité du logiciel que celle du silicium. Un kernel, un ordonnanceur ou une stratégie de parallélisation plus ancien peut laisser inutilisée une grande partie de la capacité d’un GPU.

SemiAnalysis a ajusté ses propres données InferenceX afin de correspondre à la méthode de comptabilisation de CoreWeave. Le benchmark original comptait la consommation électrique des GPU de préremplissage et de décodage, tout en ne rapportant que les tokens de sortie.

Face aux résultats GB300 NVL72 de juillet 2026, Rubin a fourni presque deux fois le débit jusqu’à 100 tokens par seconde et par utilisateur. Son avantage s’est élargi à environ quatre fois autour de 200 tokens par seconde.

À 300 tokens par seconde, le ratio rapporté a atteint 5,4 fois. Toutefois, SemiAnalysis a souligné que GB300 fonctionnait à la limite de sa courbe de performance viable.

GB200 ne pouvait pas atteindre ce niveau d’interactivité dans la configuration testée. Rubin a continué jusqu’à 350 tokens par seconde, où il a produit 70 703 tokens de sortie par seconde et par mégawatt.

Cela n’invalide pas l’affirmation de CoreWeave. Rubin, dans sa version initiale, maintient clairement une interactivité plus élevée que les systèmes Blackwell mesurés. En revanche, cela modifie ce que les acheteurs devraient déduire du chiffre mis en avant.

Un chiffre de dix fois décrit une charge de travail, un point de fonctionnement, une référence logicielle et une méthode de comptabilisation précis. Il ne signifie pas que chaque déploiement Rubin remplace immédiatement dix racks GB200.

La conclusion la plus solide est plus circonscrite et plus utile. Rubin conserve son efficacité lorsque le service évolue vers des lots plus petits et des réponses individuelles plus rapides, là où le débit de Blackwell chute fortement.

Ce comportement affecte directement les agents de programmation, les systèmes de recherche et les applications de sécurité. Ces services génèrent de nombreux appels séquentiels au modèle, ce qui rend difficile de masquer la latence avec de grands lots.

Pourquoi la performance par mégawatt compte désormais davantage que les FLOPS de pointe

La capacité électrique est devenue une contrainte pratique ; les tokens utiles par mégawatt peuvent donc compter davantage que le débit théorique de calcul.

Le nombre maximal de FLOPS d’un accélérateur mesure ses opérations en virgule flottante maximales dans des conditions précises. Il ne décrit pas l’efficacité avec laquelle un rack complet sert un modèle de raisonnement.

L’inférence déplace les poids, les activations et les données du cache KV entre la mémoire et les unités de calcul. Le cache KV stocke les informations d’attention issues des tokens précédents, évitant au modèle de recalculer toute la séquence.

Les contextes plus longs agrandissent ce cache. Les modèles à mélange d’experts envoient également des tokens entre des sous-réseaux spécialisés, créant un trafic de communication entre GPU.

Rubin répond à ces contraintes en tant que système NVL72 complet. Le rack combine 72 GPU Rubin, 36 CPU Vera, un réseau ConnectX-9, des processeurs BlueField-4 et des commutateurs NVLink 6.

NVIDIA indique 20,7 téraoctets de mémoire HBM4 répartis sur le rack. L’entreprise spécifie également 260 téraoctets par seconde de bande passante agrégée des commutateurs NVLink 6.

Chaque GPU reçoit 3,6 téraoctets par seconde de bande passante scale-up tout-à-tout. Le réseau scale-up relie les accélérateurs au sein d’un grand domaine de calcul, leur permettant de se comporter comme un dispositif unifié.

Rubin attaque donc l’efficacité de l’inférence à plusieurs niveaux. Des opérations tensor plus rapides prennent en charge les calculs matriciels, la HBM4 fournit les poids et NVLink déplace les tokens entre les experts.

Les CPU Vera gèrent les mouvements de données et les tâches d’agents gourmandes en CPU. Celles-ci peuvent inclure les appels d’outils, la compilation de code, l’orchestration et l’exécution en bac à sable.

Les spécifications NVL72 de NVIDIA revendiquent 3 600 pétaFLOPS de performance d’inférence NVFP4 à l’échelle du rack. L’entreprise revendique également un coût par token dix fois inférieur à celui du GB200 NVL72.

Ces chiffres restent des affirmations de l’entreprise dépendantes de la charge de travail. Ils expliquent néanmoins pourquoi l’avantage de Rubin augmente lorsque l’interactivité progresse.

Les grands lots aident un GPU à rester occupé, car de nombreux utilisateurs partagent chaque chargement de poids. Un service interactif rapide réduit les possibilités de mise en lot, ce qui accroît la pression sur la bande passante mémoire et l’ordonnancement.

La bande passante HBM4 de Rubin, de 22 téraoctets par seconde par GPU, lui donne davantage de marge dans ces conditions. SemiAnalysis estime qu’elle atteint 2,8 fois la bande passante mémoire globale de Blackwell Ultra.

Une bande passante plus élevée ne réduit pas automatiquement la latence mémoire. Elle déplace davantage de données par seconde, mais un accès individuel peut toujours prendre un temps similaire.

L’avantage plus marqué de Rubin à forte interactivité reflète donc plusieurs mécanismes qui agissent ensemble. Aucune spécification de pointe isolée ne l’explique entièrement.

La métrique de puissance inclut également les choix d’infrastructure. Les équipements de refroidissement, le réseau, les processeurs hôtes, le stockage et les pertes de conversion consomment tous de l’électricité au-delà du boîtier GPU.

NVIDIA a conçu Rubin pour un liquide de refroidissement entrant à 45 degrés Celsius. Dans des installations compatibles, cette température permet un refroidissement à sec sans groupes frigorifiques traditionnels.

L’entreprise indique que son approche en boucle fermée peut réduire la consommation d’eau et les coûts de refroidissement. Ces gains dépendent de la conception de l’installation et ne doivent pas être présumés pour tous les centres de données existants.

SemiAnalysis a appliqué la même hypothèse d’efficacité de l’utilisation de l’énergie à l’ensemble des systèmes refroidis par liquide. Ce choix prudent évite que la conception des installations de Rubin ne gonfle la comparaison du silicium.

Le résultat reste favorable à Rubin. Plus important encore, il montre pourquoi l’architecture du rack est devenue indissociable de l’économie des accélérateurs.

Un acheteur ne peut pas évaluer Rubin en comparant uniquement les FLOPS des GPU. L’unité pertinente est le système de service qui fournit une vitesse de réponse requise dans une enveloppe électrique fixe.

La prise en charge logicielle OpenAI SemiAnalysis donne à Rubin une avance au démarrage

Rubin peut réutiliser d’importants kernels Blackwell, réduisant le travail de déploiement avant que les développeurs n’entament le réglage propre à l’architecture.

L’angle OpenAI SemiAnalysis ne correspond pas à un partenariat matériel avec OpenAI. Il fait référence à la prise en charge de Rubin apparaissant dans OpenAI Triton aux côtés de PyTorch, vLLM, CUDA et d’autres projets publics.

Triton est un langage et un compilateur open source permettant d’écrire des kernels GPU avec une syntaxe proche de Python. Un kernel est un programme spécialisé qui exécute une opération de calcul sur le GPU.

OpenAI a introduit la programmation Triton afin de rendre le développement de kernels haute performance plus accessible que le code CUDA de bas niveau. Les compilateurs PyTorch et les projets d’inférence s’appuient désormais sur des kernels générés par Triton pour de nombreuses opérations.

NVIDIA a publié une préversion développeur de CUDA 13.4 avec prise en charge de Rubin et instructions PTX mises à jour. PTX est le langage d’instructions intermédiaire de NVIDIA servant à décrire les opérations GPU.

La préversion CUDA permet aux développeurs d’examiner les nouvelles capacités de Rubin et de commencer à porter leurs logiciels. NVIDIA avertit qu’il s’agit d’un logiciel de préversion, inadapté aux benchmarks de production.

SemiAnalysis rapporte que les modifications liées à Rubin ont également atteint les dépôts PyTorch, vLLM et OpenAI Triton. Cette exposition publique donne aux développeurs de frameworks le temps de s’adapter avant une disponibilité élargie dans le cloud.

Le multiprocesseur de flux de Rubin utilise la cible SM107. Plus important encore, il peut exécuter les principaux kernels de la famille SM100 de Blackwell dans des bibliothèques telles que CUTLASS, DeepGEMM et FlashMLA.

Blackwell n’a pas bénéficié de la même commodité en héritage de Hopper. Son modèle de programmation des Tensor Cores a nécessité d’importantes réécritures de kernels avant que les développeurs puissent s’approcher du potentiel du matériel.

Rubin préserve une plus grande part de cet investissement. Les équipes peuvent commencer avec des kernels Blackwell fonctionnels, déployer plus tôt, puis optimiser les opérations les plus importantes.

La compatibilité ne doit pas être confondue avec la performance maximale. SemiAnalysis indique qu’un réglage spécifique à l’architecture reste nécessaire pour atteindre la limite pratique de vitesse.

Rubin augmente la mémoire partagée, qui passe des 228 KiB de Blackwell à un mode optionnel de 328 KiB. La Tensor Memory atteint également 256 KiB, offrant aux kernels davantage d’espace pour les accumulateurs et les informations de mise à l’échelle.

L’architecture ajoute des mises à jour en ligne des descripteurs Tensor Memory Accelerator. TMA est un mécanisme matériel qui déplace des données multidimensionnelles sans obliger les unités d’exécution normales à gérer chaque transfert.

Dans une couche à mélange d’experts, chaque expert possède une matrice de poids distincte. Blackwell peut devoir réécrire et synchroniser un descripteur lorsque l’expert actif change.

Rubin peut transmettre la nouvelle adresse avec l’instruction de transfert. Un descripteur peut alors servir plusieurs experts sans réécriture mémoire intermédiaire.

Cela réduit la surcharge de distribution lors du décodage avec de petits lots. Cela illustre également pourquoi les véritables gains d’inférence viennent de petites améliorations dans les mouvements de données, et pas seulement de moteurs matriciels plus grands.

Rubin double le débit des Tensor Cores FP8 et FP4 par rapport à Blackwell, selon les informations d’architecture publiées par NVIDIA. Il ajoute également une synchronisation plus fine entre les blocs de threads dépendants.

Ces fonctionnalités aident les développeurs à construire des kernels fusionnés plus grands. La fusion combine plusieurs opérations, réduisant les lancements répétés et les mouvements inutiles dans la mémoire.

L’avantage logiciel va au-delà de la préparation au lancement. Des outils compatibles permettent à davantage de développeurs d’examiner le comportement de Rubin, de signaler des défauts et d’optimiser les architectures de modèles courantes.

Toutefois, le support public reste précoce. Les restrictions de préversion de CUDA montrent que du code disponible n’équivaut pas à une pile de production mature.

L’intégration de PyTorch et vLLM peut établir la fonctionnalité tout en laissant une optimisation substantielle inachevée. Les opérateurs doivent distinguer « fonctionne sur Rubin » de « exploite Rubin efficacement ».

Le schéma historique invite à cette prudence. L’inférence GB200 s’est améliorée durant sa première année, à mesure que les kernels, les ordonnanceurs et les recettes de serving distribué gagnaient en maturité.

Rubin part d’une position de compatibilité plus solide. Son avance finale dépendra néanmoins de la capacité des mainteneurs de frameworks à transformer les nouvelles instructions en gains fiables au niveau des modèles.

Le Tensor Core LUT 3 bits cible le goulot d’étranglement de la mémoire

La fonctionnalité d’inférence la plus intéressante de Rubin compresse les poids au sein du Tensor Core, réduisant le trafic mémoire sans nécessiter d’étape distincte de déquantification.

Rubin ajoute un mode opérande B à table de correspondance à son instruction d’accumulation de multiplications matricielles. SemiAnalysis le décrit comme le premier format Tensor Core de NVIDIA utilisant un codebook interne non uniforme.

Dans ce mode, chaque poids stocké devient un indice de trois bits. Cet indice sélectionne l’une des huit valeurs E4M3 de huit bits d’une table de correspondance partagée par un bloc de poids.

Le Tensor Core reconstruit la valeur sélectionnée au sein de l’opération matricielle. Le logiciel n’a pas besoin de générer une matrice de poids décompressée distincte avant la multiplication.

En incluant le codebook partagé, SemiAnalysis calcule une empreinte stockée de 3,125 bits par poids. Le codebook contient 64 bits partagés entre 512 poids.

Cette conception diffère des formats NVFP4 et MXFP. Ces formats utilisent une mise à l’échelle par blocs, appliquant une échelle uniforme à un groupe de valeurs de faible précision.

Une table de correspondance peut répartir ses huit valeurs de manière inégale. Elle peut concentrer les entrées près de regroupements denses de poids ou représenter des distributions positives et négatives asymétriques.

Cette flexibilité peut préserver davantage d’informations qu’un arrondi uniforme avec un nombre de bits comparable. Elle ne garantit pas une meilleure qualité de modèle.

Un codebook couvre 512 poids, tandis que NVFP4 peut adapter son échelle sur des groupes bien plus petits. Les résultats dépendront des données de calibration, de l’ajustement du codebook et de la sensibilité du modèle.

Certaines couches peuvent également nécessiter une précision plus élevée. Une recette de quantification agressive peut économiser de la mémoire tout en dégradant la précision du raisonnement ou en déstabilisant les résultats.

Le mécanisme matériel répond néanmoins à une contrainte centrale de l’inférence. Lors du décodage à faible lot, les GPU attendent fréquemment l’arrivée des poids du modèle depuis la HBM.

Réduire la taille stockée de chaque poids permet à la mémoire de fournir davantage de poids par seconde. Cela réduit aussi l’énergie consacrée au déplacement de ces bits dans le système.

SemiAnalysis a utilisé un modèle hypothétique de 2,8 billions de paramètres pour illustrer l’effet sur la capacité. Son calcul situait la charge brute de poids près de 1,09 téraoctet avec le format de Rubin.

La comparaison excluait le cache KV, les activations, la réplication et les surcoûts de serving. Elle démontre donc le stockage des poids, et non la mémoire totale de déploiement.

Avec 288 gigaoctets de HBM4 par GPU Rubin, les poids compressés nécessiteraient environ quatre modules. Une représentation alternative à faible précision en exigeait environ six dans cet exemple.

Moins de GPU participants peuvent réduire les communications et la réplication. Cela peut également laisser davantage de mémoire pour des contextes plus longs, des lots plus grands ou le cache KV.

Toutefois, le mode LUT comporte des contraintes d’implémentation. SemiAnalysis note qu’il ne peut pas transposer la matrice B, ce qui limite les opérations pouvant l’utiliser directement.

Le benchmark public ne semble pas non plus utiliser cette fonctionnalité. L’avance initiale de Rubin ne peut donc pas être attribuée à l’inférence par table de correspondance à trois bits.

C’est à la fois encourageant et incertain. Rubin dispose de capacités matérielles supplémentaires que les futurs logiciels pourront exploiter, mais leur précision et leur valeur en production restent non vérifiées.

NVIDIA a également ajouté une sparsité d’activation 2:4 à l’exécution. Cette méthode conserve deux valeurs dans chaque groupe de quatre et ignore les deux autres lors des opérations prises en charge.

Contrairement à la sparsité antérieure des poids, la sparsité d’activation à l’exécution n’exige pas d’élaguer et de réentraîner définitivement le modèle. Le matériel peut compresser les valeurs intermédiaires pendant l’exécution du modèle.

NVIDIA n’a toutefois pas publié d’éléments sur la précision obtenue en supprimant la moitié des valeurs d’activation sélectionnées avant les opérations suivantes. Le résultat de CoreWeave ne semble pas non plus utiliser cette fonctionnalité.

Ces capacités inutilisées représentent la marge d’optimisation de Rubin. Elles ne doivent pas entrer dans les calculs actuels de TCO comme des gains futurs garantis.

Les acheteurs devraient exiger des tests de qualité au niveau du modèle en plus du débit. Un format avec moins de bits ne réduit les coûts de serving que si le modèle obtenu atteint le même niveau de précision et de fiabilité.

Rubin remporte le test du TCO, mais la référence modifie l’écart

Rubin semble moins cher par token livré malgré des coûts de possession plus élevés, bien que son avantage se réduise face à des systèmes Blackwell entièrement optimisés.

Le coût total de possession combine le matériel, l’électricité, les installations, le réseau, la maintenance et les dépenses d’exploitation. Il offre une vision plus large que la performance par watt seule.

SemiAnalysis a appliqué son modèle de coût de possession opérateur au débit de sortie normalisé. L’analyse a évité les tarifs de location cloud, qui peuvent inclure la rareté, les conditions contractuelles et les marges des fournisseurs.

L’analyse a conclu que Rubin était moins cher par token de sortie à chaque niveau d’interactivité mesuré face aux résultats GB200 et GB300 de juillet 2026. L’avantage augmentait à mesure que la vitesse de réponse s’élevait.

Face à la référence GB200 actuelle, Rubin était environ 1,5 fois moins cher jusqu’à 100 tokens par seconde et par utilisateur. L’avantage relatif atteignait environ trois fois autour de 200 à 250 tokens.

La comparaison entre Rubin et la référence logicielle GB200 de 2025 a produit un résultat plus important. Rubin a culminé à près de huit fois moins cher autour de 150 tokens par seconde et par utilisateur.

Cette ancienne référence explique une grande partie de l’écart entre le titre marketing de NVIDIA et une comparaison d’achat concrète. Un GB200 optimisé en 2026 est plus performant que lors de son état initial de déploiement.

SemiAnalysis estime également que Rubin supporte un coût de possession par GPU plus élevé que GB200 ou GB300. Son gain de débit doit compenser cette charge système supplémentaire.

C’est le cas dans la charge de travail examinée, surtout pour des objectifs d’interactivité exigeants. L’économie devient moins décisive à des vitesses de réponse plus faibles, où Blackwell peut utiliser efficacement des lots plus grands.

Cela crée une décision d’achat propre à chaque charge de travail.

Pour l’inférence hautement interactive

• Rubin maintient des vitesses de réponse que GB200 ne peut pas atteindre dans la configuration testée.

• Sa bande passante mémoire et son interconnexion de rack prennent davantage de valeur à mesure que la taille des lots diminue.

• Les agents de programmation et les services de recherche en temps réel correspondent à ce profil.

Pour l’inférence axée sur le débit

• Un logiciel Blackwell mature peut réduire le gain relatif de Rubin.

• L’infrastructure existante et la capacité réservée peuvent l’emporter sur un avantage d’efficacité théorique.

• Les coûts de migration méritent d’être inclus dans le modèle de TCO de l’opérateur.

Pour les modèles à contexte long

• Le plus grand pool mémoire de Rubin donne aux opérateurs davantage d’espace pour les poids et le cache KV.

• Le benchmark initial à un seul tour ne mesure pas directement cet avantage.

• Les tests d’agents à plusieurs tours fourniront un signal plus représentatif.

Le benchmark utilisait DeepSeek R1 671B avec une entrée de 8 000 tokens et une sortie de 1 000 tokens. Ce modèle et cette forme de séquence ne représentent pas toutes les charges de travail de production de 2026.

SemiAnalysis soutient que les modèles plus récents à plusieurs billions de paramètres devraient favoriser la capacité et la bande passante de Rubin. Cette affirmation reste une attente technique jusqu’à l’arrivée de résultats comparatifs.

CoreWeave a également exécuté le test sur un rack Dell d’échantillon d’ingénierie sans interconnexion scale-out. Le scale-out relie plusieurs racks, tandis que le backplane NVLink interne assure la connectivité scale-up.

Le test concluant confirme le fonctionnement interne du rack en parallélisme d’experts. Il n’établit pas les performances, la fiabilité ni l’efficacité d’un déploiement de grande ampleur sur plusieurs racks.

La concurrence ajoute une autre contrainte. Le MI455X d’AMD offre 432 gigaoctets de HBM4 par accélérateur, contre 288 gigaoctets pour Rubin.

Sur 72 accélérateurs, la conception Helios d’AMD fournit 31,1 téraoctets de mémoire. Rubin fournit 20,7 téraoctets sur son rack NVL72.

L’avantage de capacité d’AMD peut compter pour les grands modèles et les contextes longs. NVIDIA réplique avec son écosystème logiciel établi, son interconnexion NVLink et une expérience antérieure de l’exploitation à l’échelle du rack.

Les systèmes TPU de Google offrent une autre voie intégrée. Ils combinent accélérateurs personnalisés, interconnexions, compilateurs et services cloud sous un même opérateur.

La compétition sur le TCO ne se limite donc pas à Rubin et GB200. Les acheteurs doivent comparer des recettes de serving complètes en utilisant le même modèle, le même objectif de précision, la même latence, la même longueur de contexte et la même comptabilisation de l’énergie.

Rubin détient actuellement le résultat public précoce le plus solide. Les éléments disponibles n’établissent pas encore un ratio de coût fixe pour l’inférence de production.

Ce que les prochains benchmarks doivent démontrer

Trois signaux détermineront si le premier résultat d’ingénierie de Rubin devient un avantage durable en production.

Le premier signal est la soumission InferenceX promise par NVIDIA au troisième trimestre 2026. SemiAnalysis indique que NVIDIA s’est engagée à fournir des chiffres Rubin vérifiables de manière indépendante via ce benchmark.

Une soumission crédible devrait tester des modèles actuels dans des configurations de serving documentées. Elle devrait présenter conjointement l’interactivité, le débit de sortie, les limites de puissance et les réglages d’optimisation.

Des résultats face à des systèmes GB200 et GB300 de juillet 2026 renforceraient la comparaison actuelle. Une reprise de l’ancienne référence GB200 laisserait la préoccupation méthodologique centrale sans réponse.

Le deuxième signal est une charge de travail d’agent à plusieurs tours. L’inférence à un seul tour ne peut pas reproduire les appels d’outils répétés, les caches KV croissants et les longueurs de prompts changeantes au cours d’une session d’agent.

SemiAnalysis développe un scénario AgentX avec des contributeurs de l’infrastructure et du serving open source. Son analyse de Rubin identifie le travail agentique à contexte long comme une probable force architecturale.

Rubin devrait accroître son avance lorsque la capacité mémoire et la bande passante dominent. Si l’avantage reste inchangé ou se réduit, l’argument du rack pour les contextes longs devient moins convaincant.

Le troisième signal est un logiciel public mature. Les développeurs devraient surveiller les versions de production de CUDA, PyTorch, vLLM, Triton, TensorRT-LLM et Dynamo.

La compatibilité fonctionnelle arrivera avant les performances optimisées. L’élément décisif viendra de kernels stables exploitant les fonctionnalités propres à Rubin en matière de déplacement de mémoire, de synchronisation et de faible précision.

L’inférence LUT à trois bits mérite une attention particulière. Les tests publiés doivent indiquer la précision, les méthodes de calibration, les couches affectées et le débit de bout en bout face à NVFP4.

La sparsité des activations exige le même traitement. Des taux arithmétiques plus élevés importent peu si une perte de qualité oblige les opérateurs à utiliser un modèle plus grand ou à répéter des requêtes échouées.

Feynman soulève également une question logicielle à plus long terme. NVIDIA a identifié son architecture suivante comme SM140, tandis que Rubin utilise SM107.

SemiAnalysis s’attend à ce que Feynman nécessite des réécritures de kernels plus étendues, à l’image de la difficile transition de Hopper à Blackwell. L’avantage de compatibilité de Rubin ne durera donc peut-être qu’une génération.

Pour les acheteurs d’infrastructure, la décision immédiate n’est pas de savoir si Rubin possède de meilleures spécifications. C’est le cas.

La question plus difficile est de savoir si une charge de travail précise en bénéficie suffisamment pour justifier des changements de déploiement. Les opérateurs ont besoin de tests fondés sur leur modèle, leur distribution de contextes, leur objectif de réponse et leur capacité électrique existante.

Pour les développeurs, l’action utile consiste à suivre dès maintenant la prise en charge des kernels et les recettes de benchmark. Un profilage précoce peut révéler si une application est limitée par le calcul, le trafic HBM, le réseau ou l’ordonnancement.

Pour les équipes produit d’IA, surveillez les résultats au niveau des utilisateurs. Des tokens plus rapides n’ont d’importance que s’ils réduisent le temps nécessaire pour accomplir une tâche, améliorent la fiabilité des agents ou permettent de servir davantage de clients simultanément.

Le fil OpenAI SemiAnalysis relie au final trois couches : les outils open source au niveau du kernel, l’analyse indépendante des performances et le matériel à l’échelle d’un rack de NVIDIA. Aucune de ces couches ne peut, à elle seule, valider Rubin.

Rubin conservera-t-il son avantage sur les modèles modernes, les agents multi-tours et les tests reproductibles de manière indépendante ? Ce sont ces éléments de preuve, plutôt qu’un unique multiple de titre, qui devraient déterminer le prochain engagement en matière d’infrastructure d’inférence.