Ces derniers jours, un argument percutant est devenu viral : NVIDIA aurait « admit » que son architecture est « cassée » parce qu’elle a présenté une puce dédiée à l’intelligence artificielle qui omet la mémoire HBM au profit de la mémoire GDDR. Cette déclaration peut faire sensation sur les réseaux sociaux, mais la réalité est plus complexe — et surtout, plus nuancée : NVIDIA réagit à une évolution fondamentale dans la manière dont l’Intelligence Artificielle est déployée en production, où la compétition ne se limite plus à l’entraînement des modèles, mais porte aussi sur leur mise en service rentable quand le contexte s’étend à des centaines de milliers ou millions de tokens.

La pièce centrale de cette évolution est Rubin CPX, un accélérateur spécialement conçu pour une étape précise de l’inférence : le traitement du contexte (pré-remplissage). Plutôt que de tenter d’être « la puce pour tout faire », sa stratégie consiste à segmenter les phases, et par conséquent, à distinguer aussi les coûts.

Qu’est-ce que Rubin CPX et pourquoi suscite-t-il autant d’intérêt ?

Selon NVIDIA, Rubin CPX cible les scénarios d’inférence avec des contextes massifs, où le système « lit » de gros volumes d’informations (documents, référentiels de code, historiques longs, vidéos transcrites, etc.) avant de produire une réponse. Dans cette tâche, le goulet d’étranglement n’est pas nécessairement le même qu’en génération token par token (décodage), et c’est là que l’enjeu économique apparaît : utiliser une mémoire différente de la HBM.

NVIDIA positionne Rubin CPX dans une plateforme à l’échelle d’un rack, Vera Rubin NVL144, où cohabitent des accélérateurs conçus pour différentes stratégies d’inférence. L’entreprise insiste sur l’efficacité : faire en sorte que le matériel corresponde davantage à l’usage réel.

En termes simples : si une étape nécessite beaucoup de puissance de calcul et une autre repose davantage sur le transfert de données, tenter d’utiliser la même « solution » peut devenir coûteux. Rubin CPX témoigne que NVIDIA perçoit un marché où le pré-remplissage n’est plus marginal, mais constitue un facteur de coût qu’il faut maîtriser pour certains workloads.

L’évolution : le pré-remplissage et le décodage ne se comportent plus pareil

Ce changement trouve son origine dans la montée en puissance de l’Intelligence Artificielle en production avec de longs contextes. Lors d’une interaction moderne — en particulier pour les assistants d’entreprise, agents, analyses documentaires ou programmation — le système peut consacrer un temps significatif à « absorber » l’information avant même de commencer à répondre.

Ce flux comprend deux étapes :

• Pré-remplissage (traitement du contexte) : le modèle ingère l’intégralité du prompt et construit des états internes (comme le cache KV) pour pouvoir raisonner sur ce qui a été lu.
• Décodage (génération) : le modèle produit une sortie token par token, en réutilisant ces états.

Le secteur accumule depuis des années une vision unique : tout regrouper sous le terme « inférence », mais l’augmentation du contexte a montré que, pour certains cas, il devient peu pertinent d’optimiser comme si tout était du décodage. La stratégie consistant à « séparer les phases » n’est pas nouvelle : des recherches académiques et des travaux d’ingénierie ont longtemps proposé de traiter pré-remplissage et décodage avec des approches distinctes pour maximiser la performance utile et limiter les interférences entre demandes longues et courtes.

Ici, l’idée d’une « architecture cassée » est largement simpliste. La réalité, c’est que les usages évoluent et que le hardware s’adapte en conséquence.

Le rôle du logiciel : Dynamo et la gestion de l’état

Segmenter les phases paraît simple sur un schéma, mais cela engendre un coût technique important : il faut transférer et synchroniser l’état (par exemple, le cache KV) et coordonner la répartition des tâches entre les nœuds, sans introduire de latences excessives. Si la « taxe » liée à cette coordination annule les économies escomptées, alors la stratégie échoue.

NVIDIA travaille depuis longtemps à optimiser cette gestion avec Dynamo, une couche d’orchestration pour faire évoluer la mise à l’échelle de l’inférence et gérer des composants tels que le routage, la mise en cache ou le transfert de données entre étapes et nœuds. NVIDIA présente cette couche comme un levier pour « désagréger » et améliorer la production de modèles, en s’appuyant sur des bibliothèques et mécanismes destinés à réduire ces coûts opérationnels.

De cette façon, Rubin CPX ne se limite pas à une « puce étrange sans HBM », mais constitue une pièce d’un ensemble où architecture + logiciel + plateforme tentent de s’adapter au nouveau comportement : contextes étendus, multiagents, multimodaux et avec plus de sessions longues.

La compétition : TPUs, Trainium et l’approche « en interne » des géants du cloud

Ce mouvement ne se produit pas dans un vide. Les principaux fournisseurs de cloud investissent depuis des années dans leur propre silicium pour réduire leur dépendance, maîtriser leurs coûts et aligner leur matériel sur leurs besoins réels.

• Google a renforcé ses investissements dans les TPUs, notamment avec Ironwood, une étape pour améliorer efficacité et scalabilité dans les charges modernes d’IA.
• AWS poursuit dans cette voie avec Trainium ; la version 3 de Trainium est désormais accessible pour l’entraînement et la mise en service de modèles dans son écosystème.
• Sur le marché, les politiques de demande évoluent : il a été rapporté que Meta explore des accords pour exploiter des TPUs Google dans certains de ses centres de calcul, une preuve que même ceux qui investissent dans des GPU n’écartent pas la diversification si l’aspect économique le justifie.
• Enfin, des accords à grande échelle entre acteurs de la recherche, des modèles et des fournisseurs d’infrastructure renforcent l’idée que les « siliciums alternatifs » ne sont plus anecdotiques.

Par ailleurs, les projections de croissance du marché de l’inférence — avec des chiffres très ambitieux d’ici la fin de la décennie — alimentent la course à la réduction du coût par token.

Alors, NVIDIA « admet »-t-elle qu’elle s’était trompée ?

Ce qu’on peut affirmer avec certitude, c’est que NVIDIA reconnaît publiquement que certaines charges bénéficient de la séparation des ressources dans l’inférence, en optimisant différemment le traitement du contexte et la génération. Il s’agit d’un changement d’accent important.

Mais il ne faut pas en conclure pour autant que tout ce qui précède était erroné : les GPU avec HBM restent essentiels pour l’entraînement, pour de nombreuses inférences dominées par la bande passante, ou dans des scénarios où l’intégration et la latence interne (incluant les interconnexions avancées) jouent un rôle crucial.

Ce qui paraît évident, c’est que le marché évolue vers un monde où :

1. les contextes longs ne sont plus une exception,
2. la rentabilité se calcule par phases, et
3. les clients — en particulier les hyperescaleurs — demandent des options leur permettant d’éviter de payer un « luxe » inutile.

Rubin CPX apparaît comme la réponse à cette nouvelle dynamique. La confirmation réelle passera moins par les discours que par les déploiements, les indicateurs et les résultats opérationnels.

Questions fréquentes

À quels types d’entreprises s’adresse une approche « pré-remplissage/décodage » séparée ?
Principalement aux organisations avec une forte analyse documentaire, des assistants internes disposant de grands corpus de connaissances, des agents consultant des systèmes sur plusieurs minutes ou heures, ou encore pour des flux où l’utilisateur fournit des contextes volumineux (juridique, conformité, ingénierie, support technique).

Pourquoi est-il pertinent que Rubin CPX utilise de la GDDR plutôt que de la HBM ?
Parce que cela modifie la structure des coûts du accélérateur et son déploiement industriel. L’idée est d’adapter le hardware aux charges où la HBM n’apporte pas l’avantage relatif qu’elle offre dans d’autres contextes.

Cela rendra-t-il l’inférence plus abordable dans le cloud ?
Cela peut contribuer, mais ce n’est pas automatique : cela dépend de la manière dont les services sont packagés (offres managées, prix par token, réservations), de la concurrence (TPUs/Trainium) et du coût opérationnel (réseau, énergie, refroidissement).

Que doit surveiller une équipe IT lors de l’évaluation d’une infrastructure pour l’IA ?
Au-delà du « modèle gagnant », il est crucial d’examiner le coût par token en production, la latence réelle avec de longs contextes, la capacité à faire évoluer les sessions simultanées, et la compatibilité avec des architectures hybrides (GPU + silicium propriétaire du fournisseur).

Source : Shanaka Anslem Perera