NVIDIA Nemotron 3.5 Super VL : 120 milliards de paramètres, 12 milliards actifs, déploiement sur AWS

NVIDIA a publié le modèle multimodal Nemotron 3.5 Super VL, et l'équipe d'AWS a détaillé comment l'exécuter dans ses propres clusters Kubernetes. Le modèle compte 120 milliards de paramètres, mais seulement 12 milliards travaillent pour chaque token (fragment de mot).

C'est un schéma mixture-of-experts : le réseau contient des groupes d'« experts », et pour chaque token, un routeur dédié n'en sélectionne que quelques-uns. Le coût de calcul est celui d'un petit modèle, mais la mémoire GPU doit malgré tout contenir l'ensemble des 120 milliards de poids. Le modèle comprend le texte, les images, les documents et la vidéo, et produit du texte.

Il est ouvert : NVIDIA publie les poids, les jeux de données d'entraînement et les recettes de fine-tuning. Il a été obtenu par distillation à partir du modèle plus gros Nemotron 3 Ultra : il a donc été entraîné à imiter le comportement d'un grand modèle « enseignant ».

Dans la gamme Nemotron, AWS propose déjà Nemotron 3 Nano, Nano Omni, Super, Ultra et Nemotron 3.5 Lightning. Super VL vient compléter cette liste.

Architecture hybride et résultats annoncés

Trois types de couches alternent à l'intérieur du modèle : Mamba-2, l'attention classique (attention) et des couches d'experts. La vision repose sur l'encodeur RADIO. L'avantage de Mamba-2 est qu'elle conserve, pendant la génération, un état de taille fixe. Avec l'attention classique, la mémoire consacrée au KV-cache (qui retient le contexte déjà lu) croît avec la longueur du texte. Un contexte allant jusqu'à 1 million de tokens coûte donc nettement moins cher que dans un transformeur pur. Le modèle intègre aussi une tête Multi-Token Prediction, qui permet le décodage spéculatif : le modèle propose plusieurs tokens d'avance, puis les vérifie.

NVIDIA avance les résultats suivants (ce sont les données de l'entreprise elle-même ; l'article ne contient aucune mesure indépendante) :

• 63,44% sur Hermes Bench, un test de tâches agentiques ;
• 87,05% sur les évaluations d'agents LangChain, c'est-à-dire des vérifications du fonctionnement dans un framework populaire pour agents ;
• 80,8% sur CharXiv, un jeu de questions portant sur des graphiques issus d'articles scientifiques.

Cas d'usage annoncés : vérification et débogage de code, recoupement de sources après une recherche web, lecture de tableaux et de schémas dans des documents, analyse de vulnérabilités et de menaces en cybersécurité, détection et analyse d'incidents dans des vidéos.

Combien de GPU faut-il, et comment le cluster est-il conçu

Voici les configurations minimales pour vLLM (serveur d'inférence) :

• B200/GB200 : 8 GPU en BF16, 2 GPU en NVFP4 ;
• B300/GB300 : 4 GPU en BF16, 1 GPU en NVFP4 ;
• H200 : 8 GPU en BF16, 4 GPU en NVFP4 ;
• H100 : 16 GPU en BF16, 8 GPU en NVFP4.

NVFP4 est un format de nombres sur 4 bits. Il compresse les poids d'environ un facteur quatre par rapport au BF16, et nécessite donc de deux à quatre fois moins de cartes. Sur H100, le BF16 impose de prendre deux nœuds de 8 GPU.

L'architecture type décrite par AWS se présente ainsi. Le plan de contrôle Kubernetes (control plane) gère l'API. Les nœuds CPU hébergent les pods de service et de test, et les nœuds GPU exécutent le modèle.

Les images de conteneurs sont stockées dans Amazon ECR, les poids sur un volume partagé Amazon FSx for Lustre, et les nœuds GPU sont reliés par le réseau Elastic Fabric Adapter (EFA). Les manifestes Kubernetes sont identiques pour les trois modes d'orchestration : EKS classique, EKS Auto Mode (où AWS gère elle-même la mise à l'échelle, les pilotes GPU et EFA) et SageMaker HyperPod EKS. Le schéma a été testé sur des instances p6-b200.

48xlarge (8 GPU B200) et p5en.48xlarge (8 GPU H200). Le guide pas à pas se trouve dans le projet aws-do-eks.

Planifier la capacité à partir des courbes de latence

Le modèle est servi par NVIDIA Dynamo. Celui-ci fonctionne selon deux modes : sur un seul nœud, de bout en bout, ou en mode désagrégé, où le prefill (lecture du prompt) et le decode (génération de la réponse) tournent sur des nœuds distincts. Pour les modèles avec vision, l'encodage des images et des vidéos peut en outre être déporté sur un nœud séparé.

On commence par valider le cluster avec un microbenchmark NCCL all-reduce. Si tous les GPU sont sollicités pendant le test et que le trafic passe par tous les adaptateurs EFA, le réseau est correctement configuré. L'outil aiperf mesure ensuite :

• le TTFT, le temps avant le premier token ;
• l'ITL, le délai entre deux tokens ;
• le TPS, le débit global en tokens par seconde.

Les mesures sont répétées avec un nombre variable de requêtes simultanées (concurrency sweep). AWS donne un exemple de planification. On fixe des limites : TTFT jusqu'à 600 ms, ITL jusqu'à 100 ms par token. On cherche le point le plus à droite de la courbe qui respecte ces deux limites. Dans l'exemple, il s'agit de 32 requêtes simultanées et d'environ 320 tokens par seconde par réplique, c'est-à-dire par paire prefill-decode. Le reste n'est que de l'arithmétique : on divise le débit cible par ces 320 et l'on obtient le nombre de paires.

Sur deux nœuds, le mode désagrégé a donné un TTFT inférieur à celui du mode combiné, tandis que l'ITL est resté quasiment identique. Une hausse de l'ITL indique qu'il faut ajouter de la capacité decode, une hausse du TTFT, de la capacité prefill.

Conclusion pratique pour les ingénieurs : pour le modèle quantifié, une seule carte B300 récente suffit, et le choix entre les modes doit se faire sur vos propres mesures, en répétant le test après tout changement de précision, de schéma de parallélisme ou de version de Dynamo et de vLLM. Les chiffres de qualité sont pour l'instant ceux annoncés par NVIDIA elle-même, et l'article fait partie de la documentation partenaire d'AWS. Pour comparer le modèle à ses concurrents, mieux vaut le faire sur vos propres tâches.