La inférence — et pas seulement l’entraînement — devient le véritable facteur limitant de la nouvelle vague d’Intelligence Artificielle. La raison est simple : les agents et les assistants de programmation consomment des jetons à un rythme si élevé qu’il est nécessaire de repenser l’économie du calcul. Selon le rapport State of AI d’OpenRouter, les requêtes liées à la programmation sont passées d’environ 11% du volume total de jetons à plus de 50% ces dernières semaines. Ce changement ne se limite pas aux statistiques : il marque une transition d’usages exploratoires vers des tâches plus concrètes telles que la débogage, la génération de code, le scripting et les flux utilisant des outils intégrés.

Dans ce contexte, NVIDIA a publié de nouveaux chiffres cherchant à quantifier une question qui préoccupe autant les administrateurs système que les équipes plateforme : combien coûte le service d’IA en temps réel quand chaque milliseconde et chaque watt comptent ? La société s’appuie sur les mesures du benchmark SemiAnalysis InferenceX pour affirmer que ses systèmes GB300 NVL72 (plateforme Blackwell Ultra) peuvent offrir jusqu’à 50 fois plus de performance par mégawatt et, par conséquent, jusqu’à 35 fois moins sur le coût par jeton comparé à la génération Hopper, notamment dans des scénarios de faible latence typiques d’applications “agentiques” (multi-étapes, itératives et avec une interaction continue).

Pourquoi ces chiffres ont-ils de l’importance dans un centre de données (et pas seulement en marketing) ?

En situation réelle, la performance brute ne suffit plus. L’attention se porte désormais sur les jetons par watt, le coût par million de jetons, la densité par rack, et la complexité opérationnelle. Lorsqu’une plateforme promet de multiplier la performance “par mégawatt”, le message implicite est que la limite n’est pas la demande, mais l’énergie, la refrigeration et la capacité de déploiement à grande échelle sans que le coût opérationnel ne s’envole.

Pour un professionnel de l’administration systèmes, l’enjeu n’est pas uniquement le “jusqu’à 50 fois”, mais la voie à suivre : NVIDIA insiste sur sa démarche de co-conception extrême (chip + système + logiciel) et souligne que cette amélioration ne provient pas uniquement du matériel, mais aussi de l’optimisation continue de la stack logicielle. La société mentionne des avancées dans des outils et bibliothèques comme TensorRT-LLM, NVIDIA Dynamo, Mooncake et SGLang, visant à améliorer la performance en inférence Mixture-of-Experts (MoE) dans divers objectifs de latence.

En somme : dans la guerre de l’inférence, celui qui gagne n’est pas celui qui dispose du plus grand nombre de FLOPS théoriques, mais celui qui fournit plus de jetons utiles avec moins de watts et une latence qui préserve l’expérience utilisateur.

Le rôle du logiciel : du “noyau” à l’économie du jeton

Un des détails concrets de l’annonce concerne la stabilité des améliorations logicielles. NVIDIA précise que des modifications dans TensorRT-LLM auraient permis d’atteindre jusqu’à 5 fois plus de performance lors de charges de faible latence sur GB200, en comparaison avec il y a seulement quatre mois. Cela donne un aperçu d’une réalité déjà connue par de nombreuses équipes SRE/infra : la performance d’inférence en production dépend d’un subtil mélange de runtime, planification, kernels, communication entre GPU et gestion efficace de la mémoire.

Dans cette optique, NVIDIA met en avant trois éléments techniques, à l’intérêt pratique évident pour toute infrastructure IA :

• Kernel de haute performance optimisés pour l’efficacité et la faible latence, permettant d’exploiter au mieux la GPU quand l’objectif n’est pas le “batch massif”, mais la réponse immédiate.
• NVLink Symmetric Memory, qui offre un accès direct GPU-à-GPU pour favoriser la communication et réduire les pénalités.
• “Programmatic dependent launch”, visant à réduire les temps morts en lançant la phase de préparation du kernel suivant avant la fin de l’actuel.

Ce sont des éléments d’ingénierie qui, bien que rarement mis en avant dans les gros titres, déterminent en fin de compte si un cluster peut faire fonctionner des assistants interactifs avec une latence stable… ou s’il ne reste qu’en phase de démonstration.

Long contexte : quand l’agent “lit” l’intégralité du dépôt

Une autre dimension est celle du long contexte. Si les agents doivent analyser des bases de code entières, le coût en attention et en mémoire explose. NVIDIA affirme que, dans des scénarios avec 128 000 jetons en entrée et 8 000 jetons en sortie — un profil très représentatif pour des assistants de programmation parcourant de vastes dépôts —, GB300 NVL72 peut offrir jusqu’à 1,5 fois moins de coût par jeton par rapport à GB200 NVL72.

Ce qui intéresse les développeurs, c’est la plateforme Blackwell Ultra, qui, selon l’entreprise, offre 1,5 fois plus de performance en NVFP4 et 2 fois plus de vitesse dans le traitement de l’attention, permettant de soutenir des sessions longues sans que le “prix du contexte” ne compromette la viabilité du produit.

Qui déploie cela et que cela implique pour l’exploitation ?

NVIDIA indique que des fournisseurs de cloud et d’inférence ont déjà commencé à déployer ces solutions. Elle cite l’adoption de Blackwell par des acteurs comme Baseten, DeepInfra, Fireworks AI et Together AI, avec des réductions de coût par jeton pouvant atteindre 10 fois dans les générations précédentes. En ce qui concerne Blackwell Ultra, l’entreprise précise que Microsoft, CoreWeave et Oracle Cloud Infrastructure déploient GB300 NVL72 pour des cas de faible latence et long contexte orientés vers la programmation agentique et les assistants interactifs.

Pour les opérations quotidiennes d’une équipe plateforme, cela signifie que la question ne se limite plus à “quelle GPU acheter”, mais devient “quelle architecture déployer” : intégration avec le stack de serving, surveillance des latences, gestion des files d’attente, limites par utilisateur, planification de capacité, et une vérité peu confortable — à demande équivalente, ce n’est plus uniquement les GPU qui déterminent le coût, mais la combinaison énergie + refroidissement + efficacité du runtime.

Prochaine étape : Rubin (et encore une révision des coûts)

Dans son annonce, NVIDIA évoque aussi sa plateforme Rubin, qui promet jusqu’à 10 fois plus de performance par mégawatt en inférence MoE, ce qui reviendrait à 10 fois moins de coût par million de jetons. La société indique également que Rubin pourrait entraîner de grands modèles MoE avec un quart du nombre de GPU comparé à Blackwell. Bien que cela reste ambitieux, c’est cohérent avec la tendance du marché : chaque nouvelle génération vise à rendre l’IA plus abordable, plus accessible, et plus “industrielle”.

Questions fréquentes

Que signifie “coût par jeton” pour un sysadmin ou une équipe plateforme ?
Une mesure pratique traduisant l’infrastructure en coûts : combien coûte la génération ou le traitement de jetons en tenant compte de l’énergie, du matériel, du refroidissement et de l’efficacité logicielle. Utile pour comparer les plateformes et estimer les budgets d’inférence.

Pourquoi “jets par mégawatt” devient-il une métrique clé dans les data centers IA ?
Car beaucoup de déploiements ne sont plus limités par la demande, mais par la puissance disponible et la capacité de refroidissement. Améliorer le rendement par mégawatt permet de servir plus d’utilisateurs ou d’agents sans augmenter outre mesure l’empreinte énergétique.

Dans quels cas le “long contexte” prime-t-il sur la faible latence ?
Lorsque l’assistant doit analyser de grands volumes d’informations (dépôts, documentation volumineuse, historique des incidents). Dans ces cas, le coût en attention et mémoire peut représenter la majorité, et la plateforme qui le gère le mieux gagne en coût final par réponse.

Que surveiller en production si l’on déploie des assistants agentiques ?
Au-delà de la latence p95/p99, il faut également suivre les files d’attente, les jetons par seconde par utilisateur, le ratio de réessais, les temps par étape (récupération, appels aux outils, génération), et les relier à la consommation d’énergie et à la saturation de l’interconnexion GPU-GPU.

via : blogs.nvidia