Artificial Analysis ArticlesMis à jour le

Premiers résultats AA-AgentPerf pour NVIDIA Vera Rubin NVL72

Artificial AnalysisTous les articles 15 octobre 2026Premiers résultats AA-AgentPerf pour NVIDIA Vera Rubin NVL72 Les résultats initiaux pour le Vera Rubin NVL72 de NVIDIA sont désormais en ligne sur A

Source de l’image · Artificial Analysis Articles
Artificial Analysis

Tous les articles

15 octobre 2026

Premiers résultats AA-AgentPerf pour NVIDIA Vera Rubin NVL72

Les résultats initiaux pour le Vera Rubin NVL72 de NVIDIA sont désormais en ligne sur AA-AgentPerf. Il délivre jusqu'à ~5,7x le débit total par mégawatt de son prédécesseur GB300 NVL72 sur DeepSeek V4 Pro, ~5,4x sur DeepSeek V4.1 Flash, ~3,0x sur GLM-5.2 et ~2,8x sur Kimi K3. Vera Rubin est le successeur de Blackwell chez NVIDIA, et Vera Rubin NVL72 est son système à l'échelle d'un rack, avec 72 GPU Rubin et 36 CPU Vera.

Plus grand écart de débit par MW face au GB300 NVL72, au 15 octobre 2026

  • ~5,7xDeepSeek V4 Proà ~190 tok/s par utilisateur
  • ~5,4xDeepSeek V4.1 Flashà ~580 tok/s par utilisateur
  • ~3,0xGLM-5.2à ~165 tok/s par utilisateur
  • ~2,8xKimi K3à ~67 tok/s par utilisateur
Classement AA-AgentPerfLire la méthodologieParcourir les configsCet article et ses graphiques reflètent les résultats AA-AgentPerf au 15 octobre 2026. Pour les derniers résultats sur tous les systèmes, consultez le classement AA-AgentPerf.

Les charges de travail de codage agentique sont difficiles à servir efficacement

Les agents de codage travaillent en boucle : le modèle raisonne et appelle un outil, le harnais exécute cet outil et ajoute sa sortie à la conversation, et toute la conversation retourne au modèle pour l'étape suivante. Comme chaque requête transporte tout ce qui la précède, le contexte continue de croître à mesure que l'agent lit des fichiers, exécute des tests et fait des modifications (les réponses du modèle restant courtes), de sorte que le trafic agentique est très différent du chat ou des prompts de longueur fixe que beaucoup de benchmarks d'inférence utilisent.

AA-AgentPerf rejoue de vraies trajectoires d'agents de codage (générées par des agents résolvant des problèmes dans des dépôts de code publics) à différents niveaux de concurrence, chaque agent simulé travaillant sur trois trajectoires en séquence et marquant une pause après chaque réponse pour un temps d'appel d'outil tiré des durées réelles d'appels d'outils. Les requêtes transportent jusqu'à 132K tokens d'entrée tandis que les réponses ne sont souvent qu'un court appel d'outil, et en moyenne 97% des tokens d'entrée d'une requête répètent la requête précédente.

Si une pile de service conserve ce préfixe répété dans son KV cache, elle n'a qu'à préremplir les tokens ajoutés à chaque tour, plutôt que de retraiter tout le contexte à chaque fois. Dans l'exemple ci-dessous, l'une des trajectoires les plus longues passe de 10K à 116K tokens de contexte sur 118 requêtes, l'agent envoyant 9,7M tokens d'entrée au modèle au total (dont seulement 116K nouveaux) et le modèle générant 20K tokens de sortie sur l'ensemble de ses réponses.

Tokens d'entrée par requête dans une session d'agent

Une trajectoire AA-AgentPerf, divisée entre le préfixe répété de la requête précédente et les tokens ajoutés depuis (tokenisé avec o200k_base)
  • Répété depuis la requête précédente
  • Nouveau depuis la requête précédente

Certaines des caractéristiques uniques de l'inférence agentique, qui nécessitent un traitement spécifique lors du benchmarking, sont :

  • La capacité et la réutilisation du KV cache, car des milliers d'agents concurrents peuvent chacun détenir des dizaines de milliers de tokens de contexte, qui doivent rester en cache pendant les pauses d'appel d'outil et être retrouvés pour la requête suivante
  • Le préremplissage inégal, chaque tour ajoutant de quelques tokens à des dizaines de milliers (par exemple lorsqu'un outil renvoie un gros fichier) au-dessus d'un long préfixe en cache
  • Les sorties courtes, car beaucoup de réponses sont de brefs appels d'outils, ce qui rend le temps jusqu'au premier token et la surcharge d'ordonnancement plus importants que dans la génération de longs textes

La charge de travail d'AA-AgentPerf capture ces caractéristiques :

Jusqu'à132K

Tokens d'entrée par requête, avec des contextes de 1M tokens bientôt disponibles

Jusqu'à182

Requêtes en une seule trajectoire

Jusqu'à11M

Jetons d'entrée envoyés au modèle au cours d'une seule trajectoire

Jusqu'à69K

Nouveaux jetons d'entrée ajoutés en un tour, lorsqu'un outil renvoie une sortie volumineuse

Jusqu'à5 s

Pause pour un appel d'outil entre une requête et la suivante

97%

Part des jetons d'entrée répétés depuis la requête précédente, en moyenne

Statistiques de charge de travail AA-AgentPerf sur 500 trajectoires et 18,997 requêtes, tokenisées avec o200k_base. Voir notre méthodologie pour tous les détails.

Vera Rubin NVL72 devance GB300 NVL72 jusqu'à ~5.7x par MW

Vera Rubin NVL72 conserve la conception à l'échelle du rack de GB300 NVL72, avec 72 GPU et 36 CPU dans un seul domaine NVLink. Chaque GPU Rubin dispose de la même mémoire de 288 Go que Blackwell Ultra, mais avec 2.4x la bande passante mémoire (grâce à HBM4), 1.7x la bande passante NVLink et 2.3x la puissance de calcul dense NVFP4, et le CPU Vera double la bande passante NVLink-C2C vers ses GPU, le lien qui transporte tout cache KV déchargé vers la mémoire CPU.

Par GPURubin (Vera Rubin NVL72)Blackwell Ultra (GB300 NVL72)
Mémoire GPU288 Go HBM4288 Go HBM3E
Bande passante mémoire19.2 To/s8 To/s
Bande passante NVLink3.0 To/s (NVLink 6)1.8 To/s (NVLink 5)
Calcul dense NVFP435 PFLOPS15 PFLOPS
Calcul sparse NVFP450 PFLOPS20 PFLOPS
CPUVera, 88 cœursGrace, 72 cœurs
Lien CPU vers GPU par superchip1.8 TB/s NVLink-C2C0.9 TB/s NVLink-C2C
Puissance mesurée dans ces résultats0,5 à 1,9 kW0,3 à 1,0 kW

Spécifications provenant des pages Vera Rubin NVL72, Blackwell Ultra et GB300 NVL72 de NVIDIA en date d'octobre 2026. La puissance mesurée est la consommation électrique propre de chaque GPU sous charge (le GPU et sa HBM, tels que rapportés par la télémétrie DCGM/SMI de NVIDIA, hors CPU, réseau et refroidissement), sur les configurations en frontière de chaque système pour les quatre modèles.

Résultats sur les quatre modèles

Chaque graphique ci-dessous trace le débit total par MW de puissance GPU mesurée en fonction de la vitesse de sortie par utilisateur. Le débit total compte les tokens d'entrée (en cache et nouvellement préremplis) et les tokens de sortie, dont ~96% sont des entrées en cache, et la vitesse par utilisateur est le 25e centile (p25) sur les requêtes, hors temps jusqu'au premier token, qui est la vitesse que nous citons partout. Chaque point est une configuration de service à un nombre fixe d'agents, et la flèche marque la plus grande avance de Vera Rubin sur GB300.

  • Au débit de pointe, Vera Rubin NVL72 sert 272M tokens/s par MW sur DeepSeek V4 Pro contre 239M pour GB300 NVL72 (1,14x), 571M contre 395M sur DeepSeek V4.1 Flash (1,45x), 272M contre 201M sur GLM-5.2 (1,35x) et 70M contre 56M sur Kimi K3 (1,26x)
  • L'avance de Vera Rubin est la plus grande là où le débit de GB300 s'effondre, atteignant ~5,7x sur DeepSeek V4 Pro à ~190 tok/s par utilisateur, ~5,4x sur DeepSeek V4.1 Flash à ~580 tok/s, ~3,0x sur GLM-5.2 à ~165 tok/s et ~2,8x sur Kimi K3 à ~67 tok/s. Passer de ~120 à ~165 tok/s par utilisateur sur DeepSeek V4 Pro coûte à GB300 81% de son débit par MW, contre 16% pour Vera Rubin
  • Par GPU, l'avance de Vera Rubin est encore plus large : 2,0x à 2,5x au débit de pointe, et jusqu'à ~12x sur DeepSeek V4 Pro à ~165 tok/s par utilisateur, ~18x sur DeepSeek V4.1 Flash à ~580 tok/s, ~7x sur GLM-5.2 entre ~200 et ~310 tok/s et ~7x sur Kimi K3 à ~176 tok/s
  • Les configurations les plus rapides de Vera Rubin établissent les vitesses les plus élevées par utilisateur de notre classement pour DeepSeek V4.1 Flash (906 tok/s, le résultat le plus rapide pour tous modèles confondus), GLM-5.2 (408 tok/s) et Kimi K3 (255 tok/s)

Une meilleure efficacité énergétique réduit le coût d'exploitation du service de chaque token, et comme les datacenters d'IA sont de plus en plus limités par la puissance qu'ils peuvent soutirer plutôt que par le nombre d'accélérateurs qu'ils peuvent installer, elle permet aussi de servir plus d'agents depuis le même datacenter. À ~165 tok/s par utilisateur, par exemple, le même budget de puissance GPU sert ~5x plus de tokens DeepSeek V4 Pro sur Vera Rubin NVL72 que sur GB300 NVL72. Chaque point de notre classement est accompagné de sa configuration de service dans notre navigateur de configurations, afin que les équipes puissent partir d'une configuration optimisée pour leur propre matériel plutôt que de mener leur propre étude de performance.

Les résultats de DeepSeek V4 Pro montrent la plus grande avance à haute vitesse

DeepSeek V4 Pro compte 1,6T de paramètres au total et 49B actifs, et utilise un hybride d'attention sparse compressée et fortement compressée pour garder son cache KV petit en contexte long.

Débit total par MW vs vitesse de sortieDeepSeek V4 Pro 0813 (max)

Débit total du serveur (tokens d'entrée + sortie par seconde) par mégawatt de puissance d'accélérateur en fonction de la vitesse de sortie p25 par requête. Les tokens d'entrée incluent les hits de cache KV. La vitesse de sortie exclut le temps jusqu'au premier token.

Le taux de décodage par requête, c'est-à-dire les tokens de sortie par seconde que chaque requête reçoit après l'arrivée du premier token (hors temps d'attente jusqu'à réception du premier token). Les graphiques affichent par défaut le 25e centile sur les requêtes, la vitesse que trois quarts des requêtes ont dépassée.

  • Au débit de pointe, Vera Rubin NVL72 sert 272M tokens/s par MW à 69 tok/s par utilisateur, soit 1,14x les 239M de GB300 NVL72 à 67 tok/s, et reste ~1,1x devant jusqu'à ~120 tok/s par utilisateur
  • L'écart se creuse au-delà de ~130 tok/s par utilisateur à mesure que le débit de GB300 s'effondre, Vera Rubin servant 174M tokens/s par MW à ~165 tok/s par utilisateur contre 34M pour les configurations GB300 de NVIDIA (5,1x), et 132M à ~190 tok/s contre ~23M pour GB300 (~5,7x). Les configurations en rack GB300 de NVIDIA plafonnent à ~163 tok/s par utilisateur, donc au-delà la ligne GB300 provient de petites configurations 4-GPU que nous avons construites
  • La configuration la plus rapide de Vera Rubin tourne à 298 tok/s par utilisateur, et au-delà de ~255 tok/s par utilisateur ces configurations GB300 4-GPU servent plus de tokens par MW que Vera Rubin, étendant les résultats de GB300 à 340 tok/s
  • Les configurations de Vera Rubin mettent plus de temps à renvoyer le premier token (une médiane de 1,65 s à ~165 tok/s par utilisateur, contre 1,08 s pour GB300), et mesuré en vitesse de bout en bout, qui inclut cette attente, GB300 égale ou dépasse le débit par MW de Vera Rubin à la plupart des vitesses

Les résultats de DeepSeek V4.1 Flash établissent les débits et vitesses les plus élevés de notre classement

DeepSeek V4.1 Flash compte 552B de paramètres de backbone, dont il active 8B par token pendant le préremplissage et 16B pendant le décodage, plus une mémoire Engram de 196B de paramètres qu'il lit par recherche de token. Son attention sparse et son cache KV FP4 maintiennent le cache KV à ~890 octets par token, environ un quart de celui de DeepSeek V4 Flash.

Débit total par MW vs vitesse de sortieDeepSeek V4.1 Flash (max)

Débit total du serveur (tokens d'entrée + sortie par seconde) par mégawatt de puissance d'accélérateur en fonction de la vitesse de sortie p25 par requête. Les tokens d'entrée incluent les hits de cache KV. La vitesse de sortie exclut le temps jusqu'au premier token.

Le taux de décodage par requête, c'est-à-dire les tokens de sortie par seconde que chaque requête reçoit après l'arrivée du premier token (hors temps d'attente jusqu'à réception du premier token). Les graphiques affichent par défaut le 25e centile sur les requêtes, la vitesse que trois quarts des requêtes ont dépassée.

  • Vera Rubin NVL72 atteint un pic de 571M de tokens/s par MW à 68 tok/s par utilisateur, le débit le plus élevé par MW de notre classement pour l'ensemble des quatre modèles, devant le pic de B300 à 433M et celui de GB300 NVL72 à 395M (à 31 et 23 tok/s par utilisateur)
  • L'avance de Vera Rubin sur le GB300 s'accroît avec la vitesse par utilisateur, d'environ 1,8x à 68 tok/s à environ 2,9x à ~165 tok/s et 3,4x à 3,6x entre ~230 et ~350 tok/s, atteignant ~5,4x à ~580 tok/s par utilisateur avec une configuration à 12 GPU qui répartit le décodage sur cinq workers
  • Le résultat le plus rapide de Vera Rubin, 906 tok/s par utilisateur depuis un seul serveur à 4 GPU servant un agent, est le résultat le plus rapide de notre classement pour tous les modèles, devant 669 tok/s sur B200 et 596 tok/s sur GB300 pour DeepSeek V4.1 Flash
  • Par GPU, Vera Rubin sert 651K tokens/s au pic, soit 2,3x les 284K du GB300, et environ 6,5x la ligne du GB300 à ~300 tok/s par utilisateur

NVIDIA a fait fonctionner Vera Rubin sur DeepSeek V4.1 Flash avec des réponses plafonnées à 2,048 tokens de sortie, contre 16,384 pour les autres résultats de DeepSeek V4.1 Flash sur notre classement. Environ 2 % des réponses ont atteint le plafond et la réponse moyenne était environ un dixième plus courte (275 à 301 tokens contre 319 à 335), ce qui favorise modestement le débit de Vera Rubin.

Les résultats de GLM-5.2 montrent une avance d'environ 3x aux vitesses élevées

GLM-5.2 compte 753B de paramètres au total et 40B actifs avec une attention creuse de style DeepSeek. Nous traçons GLM-5.2 et GLM-5.3 sur un même graphique de classement car ils partagent une architecture.

Débit total par MW vs. vitesse de sortie GLM-5.2 & 5.3 (max)

Débit total du serveur (tokens d'entrée + sortie par seconde) par mégawatt de puissance d'accélérateur vs. vitesse de sortie p25 par requête. Les tokens d'entrée incluent les accès au cache KV. La vitesse de sortie exclut le temps jusqu'au premier token.

Le taux de décodage par requête, c'est-à-dire les tokens de sortie par seconde que reçoit chaque requête après l'arrivée du premier token (hors temps d'attente jusqu'à la réception du premier token). Les graphiques affichent par défaut le 25e centile sur les requêtes, la vitesse que trois quarts des requêtes ont dépassée.

  • Vera Rubin NVL72 atteint un pic de 272M tokens/s par MW à 84 tok/s par utilisateur, soit 1,35x les 201M du GB300 NVL72 à 68 tok/s par utilisateur
  • À ~165 tok/s par utilisateur, Vera Rubin sert 159M tokens/s par MW, soit environ 3,0x la ligne du GB300 à la même vitesse (~53M), et l'écart reste entre environ 2,7x et 3x jusqu'à ~310 tok/s par utilisateur
  • Le résultat le plus rapide de Vera Rubin, 408 tok/s par utilisateur, est le résultat le plus rapide pour GLM-5.2 de notre classement, devant 333 tok/s sur B300 et 330 tok/s sur GB300
  • Mesuré par rapport à la vitesse de bout en bout, qui inclut le temps jusqu'au premier token, Vera Rubin sert toujours de 1,1x à 1,8x le débit par MW du GB300 sur toute la plage

Les résultats de Kimi K3 montrent une avance d'environ 2,8x aux vitesses modérées

Kimi K3 est le plus grand modèle que nous présentons, avec 2.8T de paramètres au total et 104B actifs, et une conception hybride qui utilise l'attention linéaire dans 69 de ses 93 couches.

Débit total par MW vs. vitesse de sortie Kimi K3 (max)

Débit total du serveur (tokens d'entrée + sortie par seconde) par mégawatt de puissance d'accélérateur vs. vitesse de sortie p25 par requête. Les tokens d'entrée incluent les accès au cache KV. La vitesse de sortie exclut le temps jusqu'au premier token.

Le taux de décodage par requête, c'est-à-dire les tokens de sortie par seconde que reçoit chaque requête après l'arrivée du premier token (hors temps d'attente jusqu'à la réception du premier token). Les graphiques affichent par défaut le 25e centile sur les requêtes, la vitesse que trois quarts des requêtes ont dépassée.

  • Chaque système sert beaucoup moins de tokens par MW sur Kimi K3 que sur les trois autres modèles, avec Vera Rubin NVL72 culminant à 70M tokens/s par MW à 41 tok/s par utilisateur, soit 1,26x le pic de 56M du GB300 NVL72 à 40 tok/s
  • À ~67 tok/s par utilisateur, Vera Rubin sert environ 2,8x le débit par MW de la ligne GB300 (59M contre ~21M), et sa configuration à 30 agents sert environ 2,4x la ligne GB300 à 176 tok/s par utilisateur (9,6M contre ~4,0M). Les configurations actuelles de Vera Rubin de NVIDIA laissent un vide entre ~74 et ~176 tok/s par utilisateur
  • Le résultat le plus rapide de Vera Rubin, 255 tok/s par utilisateur depuis un seul serveur vLLM à 8 GPU, est le résultat le plus rapide pour Kimi K3 de notre classement, devant B300 (235) et GB300 (194)
  • Le temps jusqu'au premier token est long au débit de pointe sur les deux systèmes, avec un p95 de 9.3 s pour la configuration à 2,048 agents de Vera Rubin et 19 s pour la configuration à 768 agents du GB300

NVIDIA a optimisé sa pile Vera Rubin pour les charges de travail agentiques

NVIDIA a expliqué comment il a construit ses configurations Vera Rubin et GB300. L'ensemble actuel de configurations est très similaire entre Vera Rubin et GB300, la majeure partie de la différence de performance provient donc du matériel amélioré de la nouvelle génération de racks, accompagné de premiers kernels spécifiques à Rubin et de réglages. Les techniques comprennent :

  • Cache KV à travers les niveaux de mémoire. Avec en moyenne 97 % des tokens d'entrée d'une requête répétés depuis la requête précédente, le cache de préfixe est essentiel, et les déploiements ont besoin de tous les niveaux de mémoire, de la HBM à la mémoire hôte (et éventuellement le disque). La plupart des configurations Vera Rubin déchargent le cache KV vers la mémoire CPU via NVLink-C2C, que Vera double à 1,8 To/s par superchip, les transferts se chevauchant avec d'autres travaux GPU, les longs contextes agentiques exposant la bande passante GPU-vers-CPU d'une manière que de courts prompts synthétiques ne font pas. Les workers de prefill de DeepSeek V4 Pro disposent de 120 à 200 GiB de mémoire hôte configurés pour le cache KV. Les configurations de DeepSeek V4.1 Flash conservent en revanche la mémoire Engram du modèle, de 196B de paramètres, dans la mémoire CPU plutôt que la HBM.
  • Routage conscient des sessions avec NVIDIA Dynamo. Les sessions d'agents reviennent au même contexte tour après tour, il est donc avantageux d'envoyer chaque requête au worker qui détient déjà son cache. Chaque configuration Vera Rubin fonctionne derrière NVIDIA Dynamo, le framework de service open source de NVIDIA, qui maintient les tours de chaque agent sur le même worker de prefill et, sur DeepSeek V4 Pro, GLM-5.2 et Kimi K3, envoie chaque requête au worker détenant la plus grande partie de son préfixe en cache. Les couches d'attention linéaire de Kimi K3 ajoutent une complication, car leur état récurrent ne peut pas être ramené à un point antérieur comme un cache KV standard, donc sa réutilisation nécessite un instantané sauvegardé au bon endroit.
  • Service désagrégé avec un large parallélisme d'experts. Un tour de conversation peut ajouter de quelques tokens à des dizaines de milliers, donc dans toutes les configurations sauf celles à très faible concurrence, le préremplissage (prefill) s'exécute sur des workers séparés, où une sortie d'outil volumineuse ne bloque pas le décodage de tous les autres agents. NVIDIA dimensionne chaque côté selon le niveau de concurrence, ce qui pour DeepSeek V4 Pro signifie de un à six workers de prefill à 4 GPU à mesure que la concurrence augmente, avec les experts du modèle répartis sur jusqu'à 32 GPU de décodage et le cache KV de chaque requête transmis du prefill au décodage via NVLink. Les configurations au débit le plus élevé de Kimi K3 utilisent également le DWDP (distributed weight data parallelism), une technique de prefill de TensorRT-LLM décrite dans cet article.
  • Décodage spéculatif ajusté à la taille de lot. Les quatre modèles utilisent le décodage spéculatif (modèles de brouillon DSpark pour DeepSeek V4 Pro et Kimi K3, génération de brouillon DSpark intégrée à DeepSeek V4.1 Flash et couches de prédiction multi-tokens propres à GLM-5.2), avec une longueur de brouillon ajustée pour chaque niveau de concurrence, par exemple de 7 tokens à plus faible concurrence à 3 au plus haut niveau sur DeepSeek V4 Pro, car la spéculation porte ses fruits surtout quand les lots sont petits et que les GPU ont du calcul disponible. La configuration derrière le résultat d'environ 5.7x sur DeepSeek V4 Pro, à environ 190 tok/s par utilisateur, génère un brouillon de 7.
  • Noyaux optimisés pour Rubin. Les checkpoints NVFP4 de NVIDIA exécutent les experts MoE en précision 4 bits sur des noyaux NVFP4 optimisés pour Rubin, ainsi que des noyaux fusionnés pour l'architecture de chaque modèle (comme l'attention parcimonieuse et les Hyper-Connections de DeepSeek V4 Pro). Le même noyau d'attention doit gérer des entrées allant de quelques tokens à 1M, donc l'autotuning doit couvrir des plages de formes au lieu de se spécialiser sur des formes fixes, ce que les charges de travail agentiques réelles exigent et que les benchmarks à forme fixe n'exercent pas.
  • Gestion rapide des requêtes côté hôte. Chaque requête transporte toute la conversation jusqu'ici (jusqu'à 132K tokens dans notre charge de travail), donc le frontal de service doit tokeniser et transmettre un long historique à chaque tour. Le routeur de Dynamo est écrit en Rust pour maintenir une faible latence côté hôte, et les configurations de DeepSeek V4 Pro et GLM-5.2 ajoutent un tokenizer rapide avec un cache de tokenisation et un transport de requêtes rationalisé, tandis que les configurations des autres modèles épinglent chaque worker aux cœurs CPU et à la mémoire les plus proches de ses GPU.

Voici des premiers résultats sur Vera Rubin, avec des noyaux et des optimisations spécifiques à Rubin encore à un stade précoce, et NVIDIA s'attend à ce que les performances continuent de s'améliorer à mesure que d'autres optimisations arrivent.

Vue d'ensemble des configurations Vera Rubin pour chaque modèle

DeepSeek V4 ProDeepSeek V4.1 FlashGLM-5.2Kimi K3
Stack de serviceTensorRT-LLM avec NVIDIA DynamovLLM avec NVIDIA DynamoTensorRT-LLM avec NVIDIA DynamoTensorRT-LLM, et vLLM pour 1 agent, tous deux avec NVIDIA Dynamo
PoidsCheckpoint NVFP4 de NVIDIACheckpoint de publication DeepSeek (MXFP4)Checkpoint NVFP4 de NVIDIACheckpoint NVFP4 de NVIDIA
Prefill et décodageDésagrégé. Workers de prefill DEP4, décodage à large parallélisme d'experts (DEP16 ou DEP32), TP4/EP4 en décodage à 34 agentsAgrégé TP4 ou TP2 pour 1 et 2 agents. Désagrégé à partir de 64 agents, avec un ou deux workers de prefill TP2 et un décodage DEP4 (ou cinq workers de décodage TP2)Désagrégé. 1 à 3 workers de prefill (TP2/EP2 ou DEP4), décodage sur TP8, TP4/EP4 ou DEP8Agrégé TP8 sur vLLM pour 1 agent. Désagrégé à partir de 16 agents : un worker de prefill TP8 avec trois workers de décodage TP8 à 16 et 30 agents, et un prefill DWDP16 (un ou deux groupes) avec décodage DEP16 à partir de 512 agents
Décodage spéculatifDSpark, 3 à 7 tokens de brouillonGénération de brouillon DSpark intégrée, 6 tokens de brouillonMTP, 4 à 8 tokens de brouillonDSpark, 3 à 7 tokens de brouillon
Cache KVFP8, déchargé vers la mémoire hôte sur les workers de préremplissageConservé en mémoire GPU, avec la mémoire Engram du modèle déchargée vers la mémoire de l'hôteFP8, déchargé vers la mémoire de l'hôte sur les workers de prefill dans toutes les configurations sauf uneFP8, déchargé vers la mémoire de l'hôte dans les configurations TensorRT-LLM
RoutageSensible aux KV, avec affinité de sessionSensible aux KV sur deux workers de prefill à 1,024 agents, un seul worker de prefill sinonSensible aux KV, avec affinité de sessionSensible aux KV, avec affinité de session
GPU par configuration32 à 562 à 1210 à 208 à 48

Pour aller plus loin

Lisez les derniers

Reflection a publié Beam, le premier lancement de modèle de l'entreprise

Le premier modèle de Reflection, Beam, obtient un score de 30 sur l'Artificial Analysis Intelligence Index, le plaçant à la 2e place parmi les modèles à poids ouverts américains

16 octobre 2026

Premiers résultats AA-AgentPerf-Local pour un ordinateur portable NVIDIA RTX Spark N1X

Un ordinateur portable NVIDIA RTX Spark N1X accomplit notre charge de travail agent locale sur Qwen3.8 27B en 18.7 minutes.

15 octobre 2026

NVIDIA publie Nemotron 3.5 Super VL et Nemotron 3.5 Bolt 74B A9B

Le Nemotron 3.5 Super VL de Nvidia est désormais le principal modèle à poids ouverts américain, avec un score de 26 sur l'Artificial Analysis Intelligence Index

15 octobre 2026

Source originale

Artificial Analysis Articles

À propos du contenu

La publication originale et les droits appartiennent à la source.

Traduction automatique · Consultez l’original