Vera Rubin NVL72 produit 5 fois plus de tokens par GPU que le GB300 sur DeepSeek V4.1 Flash

On a l'habitude de comparer les accélérateurs avec un seul chiffre : « tant de fois plus rapide ». Les dernières données d'Artificial Analysis sur Vera Rubin NVL72 montrent bien pourquoi un seul chiffre ne suffit pas. NVIDIA a soumis des configurations Rubin mises à jour pour le modèle DeepSeek V4.1 Flash, et le résultat dépend de la vitesse que vous promettez à chaque utilisateur ou agent.

Ce qui a été mesuré

La métrique est ici le débit par GPU (tokens par seconde) pour une vitesse donnée par agent. C'est une nuance importante. On peut charger la carte pour qu'elle produise un maximum de tokens au total, mais chaque requête individuelle sera alors lente. À l'inverse, on peut maintenir une vitesse élevée par agent, et le rendement global par GPU diminue. Toute plateforme évolue sur une courbe entre ces deux extrêmes, et il faut comparer des points situés à la même vitesse.

La comparaison est faite avec les résultats améliorés du GB300, c'est-à-dire face à une génération déjà optimisée côté logiciel. C'est plus honnête que de la comparer à ses chiffres de lancement.

Les chiffres

À 260 tokens par seconde par agent, Vera Rubin produit 5,0 fois plus de tokens par GPU que le GB300. À 80 tok/s, l'écart se réduit à 1,7x. Pour le cas d'un seul agent, le résultat est le suivant : 1 249 tok/s pour Rubin contre 848 pour le GB300, soit 1,47x.

Le tableau est clair. Plus la vitesse à garantir à chaque agent est élevée, plus la nouvelle architecture l'emporte. À basse vitesse, l'avantage est plus modeste ; à haute vitesse, il est multiple. Le billet n'explique pas pourquoi, et il vaut mieux ne pas spéculer sur les causes sans le détail des configurations. Mais la conclusion pratique reste la même.

Pourquoi c'est important pour les agents

Les scénarios agentiques sont sensibles à la vitesse par session. Un agent enchaîne des dizaines d'appels : il planifie, utilise des outils, vérifie le résultat, réécrit. Si chaque étape est générée lentement, les délais s'additionnent et l'utilisateur attend des minutes au lieu de secondes. Le mode « rapide et pour chacun » est donc plus proche de la réalité des agents que le mode « maximum de tokens au total », pratique pour le traitement par lots.

C'est dans ce mode, d'après les chiffres, que Rubin se révèle : 5x par GPU signifie que le même volume de sessions agentiques rapides peut être servi avec un parc de cartes nettement plus réduit. Pour un fournisseur d'inférence, cela influe directement sur le coût du token et sur les offres à vitesse garantie qu'il peut se permettre.

Limites

Quelques points sont à garder en tête. Premièrement, ces résultats ont été soumis par NVIDIA elle-même, et les configurations sont adaptées à un modèle précis, DeepSeek V4.1 Flash. Avec un autre modèle ou une autre taille de contexte, les rapports peuvent différer. Deuxièmement, le billet donne des ratios, pas un prix : le coût d'un rack NVL72 sur Rubin et sa date de disponibilité dans les clouds ne ressortent pas des données. Troisièmement, les 1,47x pour un seul agent montrent que, pour une charge à faible parallélisme, la mise à niveau apporte un effet bien moindre.

Que faire en pratique

Si vous construisez un produit à base d'agents et louez vous-même de l'inférence, demandez à votre fournisseur non pas « combien de tokens par seconde », mais « combien par GPU à ma vitesse cible par agent ». Déterminez la vitesse dont vous avez besoin : 80 tok/s et 260 tok/s donnent une économie totalement différente. Si vous planifiez des achats ou des contrats longs, partez du principe que le gain de la nouvelle génération n'est pas linéaire et se manifeste surtout dans les scénarios interactifs rapides. Et si votre charge est un traitement par lots en arrière-plan, attendre Rubin pour un effet multiple n'en vaut probablement pas la peine : l'écart y sera plus modéré.