Vera Rubin : la fin de l'inférence GPU homogène

Pourquoi Rubin n’est pas qu’un GPU plus rapide

On comparait jusqu’ici les générations NVIDIA par addition : Hopper a apporté la HBM3, Blackwell la HBM3e, Blackwell Ultra a encore poussé la capacité. Le réflexe est de lire Vera Rubin comme un Blackwell + 1 : 288 Go HBM4 au lieu de 192 sur B200, 22 To/s au lieu de 8, NVLink 6 NVLink Interconnexion propriétaire NVIDIA entre GPU. NVLink 5 (Blackwell) atteint 1,8 To/s par lien ; NVLink 6 (Rubin) double à 3,6 To/s. Permet à plusieurs cartes de partager leur mémoire et de se comporter quasi comme un seul accélérateur. au lieu de NVLink 5, 50 PFLOPS NVFP4 dense au lieu de ~15 sur B300. Tous ces chiffres existent, tous sont sourcés, tous comptent. Mais à s’en tenir à cette lecture incrémentale, on rate exactement le changement que NVIDIA a voulu faire à GTC le 16 mars 2026.

Le pivot vrai est ailleurs. La plateforme dévoilée à GTC 2026 contient sept chips, pas un — et l’un d’eux n’est même pas une puce NVIDIA. C’est un LPU Groq, ajouté entre l’annonce CES (six chips, 5 janvier 2026) et l’annonce GTC (sept chips, 16 mars 2026), produit d’un accord licence et talent de 20 milliards de dollars signé avec Groq le 24 décembre 2025. Ce LPU n’est pas là pour l’effet d’annonce : il a un rôle architectural précis dans l’inférence — et c’est lui qui révèle la vraie rupture.

Cette analyse part des spécifications publiées par NVIDIA et des transcripts de Q&A presse pour reconstituer ce que la plateforme Vera Rubin fait physiquement différemment de Blackwell. La conclusion tient en une phrase : pour la première fois dans une plateforme NVIDIA, l’inférence cesse d’être un problème homogène GPU.

Sept chips, une plateforme

Comparer les générations à la puce, c’est ce que NVIDIA a explicitement abandonné. Ian Buck, VP Hyperscale & HPC, l’a posé en Q&A presse à GTC : « In the good old days when I would say “Hopper”, I would hold up a chip… that’s just adorable. When we think “Vera Rubin”, we think the entire system, optimized as one giant system. » La plateforme se compte désormais en systèmes, pas en dies.

Les sept composants Vera Rubin, et le rôle de chacun dans le système :

• Rubin GPU — l’accélérateur principal, successeur direct de Blackwell. Quatre dies (deux pour le calcul, deux pour les entrées/sorties) soudés sur un même package en 3 nm TSMC, packaging CoWoS-L CoWoS Chip-on-Wafer-on-Substrate. Technologie de packaging avancée de TSMC qui empile la HBM et la puce GPU sur un même substrat. C'est elle — pas la lithographie — qui est le vrai goulot de la production GPU IA en 2026 : la capacité CoWoS est réservée jusqu'à mi-2027. . 288 Go de HBM4 HBM High Bandwidth Memory. Mémoire empilée en couches, soudée à proximité immédiate du GPU, avec une bande passante de plusieurs To/s — contre ~50 Go/s pour de la DDR5. Indispensable au-delà d'une certaine taille de modèle. sur 8 stacks, 22 To/s de bande passante ciblée, 50 PFLOPS NVFP4 dense en inférence.
• Vera CPU — le processeur host du nœud, l’équivalent d’un Xeon ou EPYC, mais conçu sur mesure par NVIDIA. 88 cœurs Armv9.2 designés en interne (architecture nommée Olympus), 1,2 To/s de mémoire LPDDR5X. C’est le premier cœur CPU custom NVIDIA depuis dix ans — on y revient en détail plus bas.
• NVLink 6 Switch — le tissu d’interconnexion qui relie les 72 GPU d’un rack entre eux pour qu’ils se comportent comme une seule grosse machine. Cette génération double la bande passante par GPU : 3,6 To/s contre 1,8 To/s sur NVLink 5.
• ConnectX-9 SuperNIC — la carte réseau qui sort du rack, pour interconnecter plusieurs racks entre eux (scale-out). Un SuperNIC est un NIC classique auquel on a ajouté de l’accélération matérielle RDMA pour les transferts massifs entre GPU distants. 1,6 Tb/s, deux fois la génération précédente.
• BlueField-4 DPU — un Data Processing Unit : une carte programmable qui décharge le CPU des tâches d’infrastructure (gestion réseau, stockage, sécurité). Cette génération introduit DOCA Memos, un framework qui permet de stocker le KV cache hors VRAM pour libérer de la mémoire GPU.
• Spectrum-6 Photonics — le switch Ethernet du réseau datacenter. Sa nouveauté : l’optique (la conversion électrique → lumière pour les fibres) est intégrée directement dans le silicium du switch — technique dite co-packaged optics, CPO. Ça réduit la consommation et la latence.
• Groq 3 LPU (LP30) — le seul chip non-NVIDIA de la plateforme, hérité de l’accord de 20 G$ signé avec Groq fin décembre 2025. Le LPU (Language Processing Unit) est un ASIC spécialisé dans la phase decode d’un LLM — c’est précisément le pivot architectural qu’on déplie dans la section suivante. Produit chez Samsung en 4 nm, livré dans un rack séparé appelé LPX, disponibilité Q3 2026.

Trois faits méritent d’être notés avant d’aller plus loin. D’abord, le passage de six à sept chips entre CES et GTC est moins anodin qu’il n’y paraît : ce n’est pas un produit complémentaire, c’est une brique nouvelle dans le pipeline d’inférence — on y revient. Ensuite, deux composants n’existaient pas dans la plateforme Blackwell : le Vera CPU vendu en standalone (Grace n’avait jamais d’équivalent rack 256 CPU sans GPU), et le LPU. La plateforme n’est plus « GPU + accessoires », elle est composite. Enfin, un produit a été retiré. Rubin CPX, accélérateur dédié à l’inférence long-contexte annoncé en septembre 2025, a été « pulled » par Ian Buck en Q&A presse — verbatim Tom’s Hardware. Pas de communiqué d’annulation officiel, juste : « we’ve pulled CPX […] we’ll be thinking about CPX more in the next generation [Feynman] ». Le rôle qu’il devait jouer — accélérer le decode — est repris par le Groq LPU. Ce déplacement n’est pas un détail de roadmap, c’est l’indice de la rupture architecturale.

Le vrai pivot : prefill, decode, orchestration

Pour comprendre pourquoi NVIDIA a ajouté un LPU à sa plateforme et retiré CPX, il faut regarder ce que fait physiquement un LLM quand il sert une requête. L’inférence se découpe en deux phases si différentes qu’elles auraient presque besoin de matériels différents — et c’est exactement ce que Rubin admet pour la première fois.

L’inférence d’un modèle se déroule en deux temps que tout praticien des runtimes (vLLM, TensorRT-LLM, SGLang) connaît.

La phase de prefill prefill Phase initiale d'une inférence LLM : tous les tokens du prompt sont traités d'un coup. Intensité arithmétique élevée — le GPU sature ses Tensor Cores. C'est l'inverse du decode qui suit. traite tout le prompt d’un coup. Tous les tokens d’entrée passent dans le modèle simultanément ; les Tensor Cores tournent à plein régime, et chaque octet de poids lu en mémoire sert à beaucoup d’opérations de calcul. C’est ce qu’on appelle une charge compute-bound : le GPU sature ses unités de calcul, et la mémoire suit sans peine.

La phase de decode decode Phase de génération autorégressive d'un LLM : un token est produit à la fois, en relisant tout le KV cache. Intensité arithmétique très basse — le GPU passe l'essentiel du temps à attendre la mémoire. Un service d'inférence réel est presque toujours dominé par le decode. est exactement l’inverse. Elle génère les tokens un par un, en mode autorégressif — chaque nouveau token dépend de tous les précédents. À chaque token, il faut relire l’intégralité des poids du modèle plus l’ensemble du KV cache KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. accumulé depuis le début de la requête. Pour quelques milliards d’opérations utiles, on traverse des dizaines à des centaines de gigaoctets. C’est une charge memory-bound : les unités de calcul passent l’essentiel du temps à attendre la mémoire. Les FLOPS bruts deviennent presque non pertinents — c’est la bande passante HBM qui fixe le plafond, pas le calcul.

Un GPU qui fait les deux est, par construction, en sous-régime sur l’une des deux phases. Ajouter des Tensor Cores plus rapides accélère le prefill mais ne change presque rien au decode. Ajouter de la bande passante mémoire accélère le decode mais laisse les Tensor Cores partiellement inutilisés en prefill. C’est ce que vLLM, TensorRT-LLM et SGLang ont commencé à exploiter logiciellement avec le disaggregated serving : séparer les requêtes en deux pools sur des nœuds différents, certains nœuds spécialisés prefill, d’autres spécialisés decode. Mais le silicium restait le même partout : un GPU généraliste, jouant tantôt l’un, tantôt l’autre.

Ce que Rubin fait pour la première fois, c’est inscrire cette séparation dans le silicium lui-même.

Le Groq LPU n’est pas un GPU plus petit. Son architecture est héritée des TSP de Groq (Tensor Streaming Processor : un processeur qui exécute un graphe de calcul connu à l’avance, sans le scheduling dynamique d’un GPU). Elle est faite pour une seule chose : enchaîner des opérations déterministes à latence ultra-faible. Sur le decode FFN, où chaque token suit exactement le même chemin avec des poids déjà chargés, ce profil bat un GPU en latence par token — et surtout en énergie par token, ce qui compte encore plus en production. Ian Buck l’a chiffré dans la Q&A presse : « I would add Groq to maybe 25% of my total data center » pour les charges latence-critique, en gardant 100 % Vera Rubin pour le throughput pur.

Le rôle de Vera CPU change en miroir. Il ne s’occupe plus uniquement de présenter les batches au GPU. Il devient l’orchestrateur des charges agentiques qui font de plus en plus le travail entre deux appels au modèle — compilation, génération de variants pour le reinforcement learning, SQL analytics, code agents. Avec son cœur Olympus custom et son support FP8 natif, il prend en charge ce qui était historiquement une charge x86 mal servie par Grace. NVIDIA vend désormais des racks Vera standalone — 256 CPU sans GPU, refroidis liquide — qu’aucun équivalent Grace n’a jamais constitué.

Dynamo 1.0 est la pièce qui rend cohérent l’ensemble : un « inference operating system » qui décide en temps réel quelle requête va sur quel tier, en fonction du batch, de la latence cible et de l’utilisation. C’est ce qui transforme « trois silicium différents » en « une plateforme ».

Le résultat chiffré par NVIDIA : 10× tokens par watt vs Blackwell sur la plateforme entière, 35× tokens par watt sur les charges premium quand le LPX est sollicité — modèles 1 à 2 trillions de paramètres, contextes 400 à 500 k tokens. Ces chiffres sont à manier avec prudence : ils agglomèrent gains hardware, logiciel et orchestration, et SemiAnalysis rappelle qu’ils ne se traduisent pas linéairement en gain workload réel. Mais l’intention narrative est claire : l’efficacité ne vient plus de l’amélioration d’un seul silicium, elle vient de la spécialisation par phase.

Vera CPU : la pièce qui rend l’éclatement viable

L’idée de loger CPU et GPU dans un même nœud n’est pas neuve — Grace avait ouvert la voie. Ce qui change avec Vera, c’est la valeur qu’on attend du CPU.

Grace utilisait des cœurs Arm Neoverse V2 standard, dimensionnés pour préparer les données et orchestrer les transferts vers le GPU. Vera abandonne Neoverse pour Olympus, un cœur 100 % custom NVIDIA, Armv9.2-compatible au sens ISA mais conçu from scratch. C’est le premier cœur CPU custom NVIDIA depuis Denver, presque dix ans en arrière. Plusieurs articles tiers continuent à parler de Neoverse pour Vera — c’est inexact, ServeTheHome et le briefing presse NVIDIA le confirment.

Le profil d’Olympus illustre la cible. Front-end 10-wide avec deux branch predictors. Spatial Multithreading (et non SMT temporel classique) qui partitionne les ressources entre deux threads sans time-slicing. Six unités SVE2 (Scalable Vector Extension 2, le jeu d’instructions vectorielles d’Armv9) 128-bit par cœur. IPC ciblé à 1,5× Grace. Et surtout : le premier CPU à supporter FP8 FP8 Format à virgule flottante 8 bits. Format de travail polyvalent pour l'inférence (et l'entraînement) sur GPU récents. Divise par 2 l'empreinte mémoire et le débit nécessaires par rapport au FP16, pour une perte de précision marginale sur la plupart des modèles. nativement. Ce n’est plus un companion-CPU, c’est un processeur conçu pour des charges qui se sont déplacées vers lui — agents qui raisonnent, pipelines analytics, génération de variants pour le RL, code agents.

Côté mémoire, 1,5 To LPDDR5X par socket via SOCAMM2 (le format module compact que NVIDIA pousse à la place du SO-DIMM serveur classique) et 1,2 To/s de bande passante. Ce n’est pas du niveau HBM, mais pour une charge CPU c’est « une génération en avance sur Intel et AMD » selon le briefing presse NVIDIA — à recouper quand les benchmarks indépendants sortiront. Et NVLink-C2C de 2ᵉ génération — la variante NVLink dédiée au lien cohérent CPU↔GPU dans un même nœud — double la bande passante de cohérence avec le GPU : 1,8 To/s contre 900 Go/s sur Grace.

NVIDIA vend Vera standalone. Des racks 256 CPU sans GPU, refroidis liquide, MGX (le format de châssis modulaire ouvert que NVIDIA promeut pour ses serveurs de référence). Ce produit n’a aucun équivalent dans la gamme Grace, et il dit explicitement : Vera n’est pas l’accessoire de Rubin, c’est un troisième tier de la plateforme.

HBM4 : le memory wall se déplace, chiffré

La conséquence pratique de la HBM4 sur l’inférence se voit à la calculette. Prenons un Llama-3 70B en FP8 : 70 milliards de paramètres × 1 octet = ~70 Go de poids à relire à chaque token de decode. Sur B200 (HBM3E, ~8 To/s), le plancher physique de génération d’un token tient en une division : 70 Go ÷ 8 To/s = ~8,75 ms par token, soit ~114 tokens/seconde au plafond mémoire. Sur Rubin (HBM4, cible 22 To/s), le même calcul donne 3,18 ms par token, soit ~314 tokens/seconde. Une accélération de ~2,75×, qui découle directement du ratio des bandes passantes.

L’autre dimension qui compte est la capacité. Passer de 192 à 288 Go par GPU change la classe de modèles qui tiennent sur une carte. Un modèle de 400 milliards de paramètres en FP4 FP4 Format à virgule flottante 4 bits — la frontière 2026 de l'inférence à haut débit. Quatre fois moins de mémoire que le FP16, mais une portée dynamique très étroite : ne tient qu'avec un scaling fin via formats à blocs (MXFP4, NVFP4). occupe ~200 Go, qui tenait à grand-peine sur deux B300 ou trois B200 — avec NVLink obligatoire, et un all-reduce (la primitive de synchronisation qui agrège les activations partielles entre GPU) à chaque couche d’attention. Le même modèle tient désormais sur un seul Rubin avec marge pour le KV cache. C’est moins du débit qu’une suppression de l’overhead de communication inter-GPU sur tout un segment de modèles.

Trois nuances que la spec officielle 22 To/s ne dit pas, et que SemiAnalysis a documentées publiquement.

D’abord, le pin speed requis par NVIDIA (>11 Gb/s par pin) dépasse le standard JEDEC HBM4 (8 Gb/s). C’est tenable, mais les fournisseurs HBM — Micron, SK hynix, Samsung — atteignent ces vitesses avec difficulté sur les premières runs. SemiAnalysis anticipe un ramp réel proche de 20 To/s sur les premiers GPU livrés plutôt que 22 — estimation crédible, à recouper aux premières datasheets vendor.

Ensuite, la spirale TBP (Total Board Power, l’enveloppe électrique du package complet — analogue au TDP côté CPU). Rubin était initialement positionné à 1 800 W TBP par package. Sous pression compétitive AMD (le MI455X a relevé sa propre cible de 2 300 à 2 500 W), NVIDIA a révisé Rubin à ~2 300 W. NVIDIA n’a jamais communiqué cette révision ; c’est SemiAnalysis qui l’a exposée publiquement. L’écart de bande passante avec le MI455X (22 vs 19,6 To/s annoncés) pourrait être quasi nul en pratique au lancement.

Enfin, capacité contre concurrence. Le MI455X annonce 432 Go HBM4 par package — plus que Rubin. Sur les charges où la capacité totale prime (modèles MoE — Mixture of Experts — au-delà de 1 trillion de paramètres, en très long contexte), l’avantage AMD est réel. Le tissu NVLink 6 et l’écosystème logiciel rebattent les cartes au niveau rack, mais la spec brute par die reste défavorable à NVIDIA sur cette dimension.

Rubin face à Blackwell et AMD MI455X

Trois GPUs, deux constructeurs, une même époque (2026-2027). Le tableau ci-dessous résume les specs publiquement annoncées au 17 mai 2026. Les lignes les plus sensibles aux révisions vendor (TBP, BP HBM réelle au ramp) restent à confirmer au déploiement des premiers serveurs.

Critère	B200 (réf.)	B300 (Blackwell Ultra)	Rubin GPU	AMD MI455X
Procédé TSMC	4NP	4NP	3 nm class	N2 (compute) + N3P (I/O)
Architecture package	2 compute dies	2 compute dies	2 compute + 2 I/O	2 GCD + 2 MCD
HBM capacité	192 Go HBM3E	288 Go HBM3E	288 Go HBM4	432 Go HBM4
HBM bande passante	~8 To/s	~8 To/s	22 To/s ciblé	19,6 To/s
NVFP4 / FP4 dense (inférence)	~10 PFLOPS	~15 PFLOPS	50 PFLOPS	40 PFLOPS
FP8 dense	~5 PFLOPS	~7,5 PFLOPS	17,5 PFLOPS	20 PFLOPS
Interconnect scale-up	NVLink 5, 1,8 To/s	NVLink 5, 1,8 To/s	NVLink 6, 3,6 To/s	UALink + Infinity Fabric
TBP par package	1 000 W	1 200–1 400 W	~2 300 W (révisé)	~2 500 W
Disponibilité	2024	2025	H2 2026	Juillet 2026 (Advancing AI)

Trois lectures se dégagent.

Sur la mémoire, AMD garde l’avantage capacité (+50 %), Rubin garde l’avantage bande passante annoncée (+12 %). Si SemiAnalysis a raison sur le ramp réel à 20 To/s, l’écart bande passante s’efface, et le départage se joue sur la capacité — terrain AMD.

Sur le calcul, Rubin écrase tout en NVFP4 (+25 % vs MI455X, ×3,3 vs B300). En FP8 dense, MI455X reprend l’avantage (+14 % vs Rubin). Le choix du format numérique de référence dicte le verdict.

Sur l’écosystème scale-up, NVLink 6 à 3,6 To/s reste le tissu sans équivalent direct chez AMD pour le rack dense. C’est ce qui permet à NVIDIA d’annoncer un rack VR NVL72 (la convention de nommage des racks « NVLink-72 GPUs ») à 260 To/s de bande passante NVLink scale-up — un domaine cohérent que UALink (le standard ouvert porté par AMD, Intel et le consortium qui le soutient) et Infinity Fabric n’égalent pas encore en bande passante par GPU. C’est la dimension où l’avantage NVIDIA reste structurel, comme déjà détaillé pour MI355X vs B200.

Aucun de ces chiffres n’a encore été soumis à MLPerf. Le prochain cycle d’inférence est attendu pour l’été 2026 — c’est là que les premiers benchmarks indépendants stabiliseront ou contrediront les claims constructeur.

Faut-il attendre Rubin ?

La réponse dépend moins de la spec que de la forme de votre charge.

Pour une équipe qui sert un modèle de 7 à 70 milliards de paramètres en batch interactif moyen — le cas le plus courant en production SaaS aujourd’hui — Blackwell B200 reste largement suffisant. Le gain Rubin sur ces charges est modeste : un peu de latence en moins, un peu de batch en plus. Le surcoût et la complexité d’intégration ne se justifient pas avant que les workloads ne changent de classe.

Pour une équipe qui prépare un service basé sur un modèle 400B+ en NVFP4, ou un MoE 1T+ à très long contexte, Rubin change qualitativement le dimensionnement. Un modèle qui demandait 2 à 3 B200 tient sur un Rubin, le KV cache d’une session 128k contexte tient mieux dans 288 Go de HBM4, et le débit s’écroule moins vite quand le batch grossit.

Pour une équipe qui sert des charges latence-critique avec contrainte stricte sur la TTFT (Time To First Token, le délai entre l’envoi de la requête et le premier token rendu à l’utilisateur) — coding agents, génération interactive premium — l’investissement utile n’est pas dans Rubin GPU seul. C’est dans la combinaison Rubin + Groq LPX, avec Dynamo qui route les requêtes selon leur profil. Ian Buck recommande ~25 % du data center en LPX pour ce cas d’usage ; le reste reste Vera Rubin pur. C’est la première fois que le bon design n’est pas « tout NVIDIA homogène ».

Pour le reste — auto-hébergement local, recherche, fine-tuning ponctuel — la question ne se pose pas : Rubin se loue à l’heure, ne s’achète pas pour un poste. À l’heure de la rédaction, aucun comparateur de prix cloud européen ne le propose encore ; les premières disponibilités annoncées sont chez les hyperscalers US et chez Nebius / Nscale (H2 2026). La souveraineté EU sur Rubin reste un angle mort.

Conclusion

La plateforme Vera Rubin n’est pas un Blackwell plus rapide. C’est la première plateforme NVIDIA qui assume que l’inférence n’est pas une charge homogène, et qui en tire les conséquences silicium : un GPU pour le prefill, un LPU pour le decode, un CPU pour l’orchestration, un orchestrateur logiciel pour les coller ensemble. La rupture est moins dans Rubin GPU que dans le geste de renoncer à la primitive GPU unique. Google a fait le pas analogue côté TPU en scindant sa 8ᵉ génération en deux puces — 8t pour l’entraînement, 8i pour l’inférence —, signe que la spécialisation par phase dépasse un seul fournisseur (voir la pile TPU de Google).

Cette rupture pose une question pour la suite. Si la disaggregation est la direction, la prochaine étape ne sera pas un GPU plus gros — ce sera un quatrième tier. Lequel ? Ian Buck a posé un indice : « we’ll be thinking about CPX more in the next generation [Feynman] ». Un accélérateur dédié au long contexte, conçu pour héberger des KV caches géants, est probablement l’élément que Feynman 2028 réintroduira — précisément ce que Rubin CPX devait être et n’a pas pu rester. La vraie question pour Feynman n’est plus « combien de FLOPS de plus » : c’est quel est le quatrième tier que Rubin n’a pas encore.

Sources et méthode

Cet article s’appuie sur un dossier de recherche interne arrêté au 17 mai 2026. Les principales sources primaires :

• NVIDIA Newsroom — Vera Rubin Platform : nvidianews.nvidia.com/news/nvidia-vera-rubin-platform — communiqué du 16 mars 2026 (specs, calendrier, claims agrégés).
• NVIDIA Newsroom — Vera CPU : nvidianews.nvidia.com/news/nvidia-launches-vera-cpu-purpose-built-for-agentic-ai — 16 mars 2026 (Olympus, 88 cœurs, SCF 2ᵉ gen, FP8 natif).
• NVIDIA Investor Press — CES 2026 : investor.nvidia.com/news/press-release-details/2026/NVIDIA-Kicks-Off-the-Next-Generation-of-AI-With-Rubin—Six-New-Chips-One-Incredible-AI-Supercomputer/default.aspx — annonce six chips du 5 janvier 2026.
• NVIDIA Developer Blog : Inside the NVIDIA Vera Rubin Platform — Transformer Engine 3, adaptive compression NVFP4.
• JEDEC JESD270-4 HBM4 : jedec.org/standards-documents/docs/jesd270-4a — standard officiel, 16 avril 2025.
• Micron HBM4 communiqué : investors.micron.com — High-Volume HBM4 for Vera Rubin — 16 mars 2026 : >11 Gb/s pin speeds, >2,8 To/s par stack, 12-Hi 36 Go.

Sources secondaires fiables :

• SemiAnalysis — Vera Rubin – Extreme Co-Design : newsletter.semianalysis.com — révision TBP 1 800 → 2 300 W, ramp HBM4 ~20 To/s, convention NVL72 vs NVL144.
• Tom’s Hardware Q&A presse GTC 2026 : tomshardware.com — GC 2026 press Q&A transcript — verbatim Ian Buck (« we’ve pulled CPX », recommandation 25 % LPX).
• ServeTheHome — NVIDIA Vera CPU in Detail : servethehome.com — confirmation cœur Olympus 100 % custom (non Neoverse), premier depuis Denver.
• AMD CES 2026 — MI455X / Helios 72-GPU — communiqués AMD du 5 janvier 2026 ; analyse silicium Chips and Cheese — AMD Venice & MI400 lids off.

Tous les chiffres de specs (capacité HBM, bande passante cible, débit NVFP4, NVLink 6, calendrier H2 2026) sont des specs constructeur datées du communiqué NVIDIA du 16 mars 2026 ; tous les verbatim Ian Buck sont transcrits par Tom’s Hardware. La révision TBP 1 800 → 2 300 W, le ramp HBM4 réel anticipé à ~20 To/s, et le nombre de transistors et de SM Rubin relèvent de l’estimation crédible (SemiAnalysis, presse spécialisée), pas du fait vérifié. Les calculs de plancher physique (Llama-3 70B FP8 sur Rubin) et la projection sur Feynman comme « quatrième tier » sont des hypothèses assumées. Aucune soumission MLPerf Rubin n’est disponible à la date de l’article — tous les chiffres de performance restent vendor. Nomenclature : nous utilisons « Rubin GPU » sans suffixe, la convention industrielle étant R200 et la presse de revente R100, NVIDIA n’ayant pas tranché publiquement.