Nemotron 3.5 Super VL : NVIDIA annonce un modèle multimodal de 120 milliards de paramètres
Imagen generada con gpt-image-2.5-sunburst para InferamaSource ↗
01

Un modèle multimodal conçu pour des agents spécialisés

NVIDIA a annoncé Nemotron 3.5 Super VL comme un modèle ouvert et personnalisable, destiné aux flux de travail qui combinent raisonnement, compréhension visuelle et utilisation d’outils. D’après la documentation technique de l’entreprise, il peut traiter du texte, des images, des documents et des vidéos au sein d’un même modèle, afin d’éviter de répartir certaines tâches entre un modèle de langage et un modèle de vision distinct.

Le modèle vise des agents chargés d’exécuter des séquences de travail, et non de répondre uniquement à une question isolée : lire un document, recouper des données et utiliser des outils, par exemple. NVIDIA indique également qu’il peut être adapté à des données, outils et règles propres à chaque organisation. Cela décrit l’usage visé et les capacités présentées par l’entreprise ; cela ne prouve pas que le système fonctionne aussi bien dans tous les secteurs ou toutes les configurations.

Les éléments disponibles n’ont pas tous la même portée. L’annonce de l’entreprise confirme le lancement et situe le modèle dans la famille Nemotron ; l’article technique fournit des chiffres et des détails d’évaluation, mais il s’agit d’un contenu publié par NVIDIA, et non d’une réplication indépendante. Il faut donc considérer ces résultats comme des mesures communiquées par le fabricant, et non comme une garantie générale de performances.

02

Architecture MoE : capacité totale et calcul actif

D’après la documentation technique de NVIDIA, Nemotron 3.5 Super VL compte 120 milliards de paramètres au total et en active 12 milliards par jeton. Dans une architecture à mélange d’experts, ou MoE, différentes parties spécialisées du modèle peuvent participer au traitement d’une entrée. Le nombre de paramètres actifs indique quelle part du modèle est utilisée à chaque étape ; il ne signifie pas que le système ne contient que 12 milliards de paramètres à stocker.

Cette distinction peut aider à trouver un équilibre entre capacité et calcul : le modèle conserve un vaste ensemble de paramètres, tout en n’en activant qu’une fraction pour chaque jeton. Mais le nombre de paramètres actifs ne suffit pas à déterminer les besoins réels en mémoire ou la vitesse. La précision numérique, la longueur du contexte, l’implémentation, la taille des lots et le matériel ont également une influence.

La documentation technique décrit aussi plusieurs techniques d’inférence : le décodage spéculatif LiLiCorr, la prédiction de plusieurs jetons, la réutilisation du contexte et la quantification. Il s’agit d’optimisations distinctes, dont l’effet dépend de la charge de travail. Il ne faut pas attribuer automatiquement à la seule architecture MoE tous les gains inclus dans l’évaluation complète du système.

Comment interpréter les principaux chiffres

Ces chiffres décrivent des aspects différents du modèle. Ils ne sont pas interchangeables et ne suffisent pas, à eux seuls, à estimer les exigences d’un déploiement.

DonnéeSignificationCe qu’elle ne permet pas de conclure
120 milliards de paramètresTaille totale annoncée du modèle.La mémoire nécessaire dans une configuration donnée, sans connaître le format et le déploiement.
12 milliards actifs par jetonParamètres activés pour traiter chaque jeton, selon NVIDIA.Qu’il suffit de stocker 12 milliards de paramètres.
MoEArchitecture qui répartit le traitement entre des experts.Une réduction garantie de la latence ou du coût sur tous les matériels.
03

Benchmarks : des résultats utiles, mais liés à leur configuration

NVIDIA affirme que le modèle offre jusqu’à cinq fois plus de débit de génération sur des tâches agentiques que d’autres modèles ouverts de sa catégorie. L’article technique décrit également des résultats sur des évaluations d’agents, la compréhension de graphiques et l’exécution locale sur DGX Spark. Ces indicateurs ne sont pas équivalents : le débit mesure la production de jetons dans des conditions données, tandis que l’achèvement d’une tâche dépend aussi du nombre d’étapes, des appels aux outils et des jetons consommés.

Pour Hermes Bench, l’article technique indique 63,44 % pour Nemotron 3.5 Super VL, contre 56,33 % pour Nemotron 3 Ultra. Dans les évaluations comportementales de LangChain, il présente respectivement 87,05 % et 84,3 %. La source rattache ces chiffres à ces tests précis ; elle n’établit pas qu’il s’agit d’évaluations indépendantes et ne permet pas de les extrapoler à tous les agents, modèles ou jeux de données.

Pour la compréhension des graphiques, NVIDIA annonce un score de 80,8 % sur CharXiv et de 84 % avec l’interprétation de code Python. Cet écart illustre la dépendance possible des résultats à la méthode d’évaluation. Pour déterminer si le modèle convient à un cas réel, mieux vaut reproduire le test avec ses propres documents, outils, critères de réussite et limites de temps.

04

DGX Spark, NVFP4 et coûts : ce qui reste impossible à comparer

La documentation technique indique que Nemotron 3.5 Super VL a été optimisé pour une exécution locale sur NVIDIA DGX Spark et mentionne une évaluation indépendante d’EXO Labs portant sur l’équilibre entre précision et durée des tâches. Toutefois, les informations fournies ne comprennent pas de tableau complet comparant, dans des conditions homogènes, la latence et le débit à ceux de Bolt 74B-A9B ou Bolt E4B, ni de mesures de consommation électrique comparables sur DGX Spark, RTX 6000 et RTX 8000.

Il n’est donc pas possible d’estimer rigoureusement le coût de chaque tâche sur ces GPU, ni de déterminer quel modèle serait le plus rapide dans une installation donnée. Le résultat dépend du matériel exact, du format des poids, du moteur d’inférence, de la taille des entrées, de la concurrence et de la définition d’une tâche terminée. L’annonce des modèles Bolt ne constitue pas, à elle seule, une comparaison de performances avec Super VL.

NVIDIA décrit une méthode NVFP4 pour l’architecture Blackwell, qui quantifie les poids et les activations sur quatre bits, et indique que la distillation tenant compte de la quantification vise à préserver la précision par rapport au modèle BF16. L’entreprise précise également que le même checkpoint peut être exécuté sur des plateformes non-Blackwell avec des poids sur quatre bits et des activations sur 16 bits. Il s’agit d’une description de méthode et de compatibilité ; les sources disponibles ne donnent pas de mesure indépendante, sur une charge de travail commune, permettant de quantifier les pertes ou les gains de précision et d’énergie.

05

Compatibilité et usages industriels possibles

NVIDIA présente ses propres outils de personnalisation et de déploiement du modèle, notamment NeMo, NVIDIA NIM et Dynamo. La documentation technique mentionne également plusieurs plateformes et frameworks de l’écosystème, parmi lesquels vLLM, SGLang, Ollama et LM Studio. La présence d’un nom dans une liste de partenaires ou d’outils ne prouve pas que toutes les fonctions, tous les formats et toutes les optimisations soient disponibles dans chaque version ; avant un déploiement, il faut vérifier la prise en charge du checkpoint et du backend concernés.

Les usages décrits comprennent l’intelligence documentaire, l’analyse vidéo, la recherche sur le Web, la cybersécurité et l’assistance à des tâches de programmation. Ce sont des applications possibles, et non des résultats garantis. Chaque cas exige aussi d’évaluer le traitement des données sensibles, la fiabilité des réponses, les règles d’accès aux outils et la capacité à gérer les erreurs.

La documentation évoque des adaptations à des flux de travail spécialisés, notamment pour la finance et l’analyse des menaces. Les progrès précis communiqués correspondent à des configurations particulières et à des travaux d’ajustement ultérieurs ; ils ne sont pas automatiquement attribuables au modèle de base. Pour un usage industriel, la validation doit porter sur des données propres à l’organisation et inclure des mesures de sécurité, de qualité et de coût.

Étapes de validation d’un déploiement

Une preuve de concept utile doit distinguer la qualité du modèle des optimisations de l’infrastructure.

  1. 01Définir une tâche, un critère de réussite vérifiable et des limites de latence et de coût.
  2. 02Fixer le matériel, le format des poids, le moteur d’inférence, le contexte et le niveau de concurrence afin de rendre la comparaison reproductible.
  3. 03Tester le modèle de base et la configuration quantifiée avec le même jeu de cas, en enregistrant les erreurs, les durées et la consommation.
  4. 04Répéter les essais avec des entrées représentatives, puis vérifier la compatibilité, la confidentialité et les contrôles des outils avant la mise en production.
06

Conclusion : des capacités prometteuses, des preuves encore limitées

Nemotron 3.5 Super VL associe une taille totale de 120 milliards de paramètres à 12 milliards de paramètres actifs par jeton et à une conception multimodale axée sur les agents. La documentation de NVIDIA décrit des techniques d’accélération de l’inférence et présente des résultats sur des benchmarks précis ; elle indique aussi une possibilité d’exécution locale sur DGX Spark et des options de personnalisation.

La conclusion la plus prudente est que le modèle mérite d’être évalué pour les tâches qui combinent texte, documents ou vidéo avec raisonnement et utilisation d’outils. Mais les éléments disponibles ne permettent pas d’affirmer qu’il est globalement le plus rapide, qu’il consomme moins d’énergie que des solutions précises ou qu’il offre un coût donné sur RTX 6000, RTX 8000 ou DGX Spark. Ils ne fournissent pas non plus de comparaisons spécifiques et homogènes avec Bolt 74B-A9B et Bolt E4B.

Pour comparer des systèmes, la démarche pratique consiste à mesurer la tâche dans son ensemble, et pas seulement les jetons par seconde : exactitude, latence de bout en bout, consommation, coût, stabilité et compatibilité réelle. L’architecture et les chiffres annoncés permettent de formuler des hypothèses ; seuls des essais sur ses propres données et son propre matériel permettent de vérifier si elles se confirment.

Choisir selon l’objectif du déploiement

Un premier guide d’évaluation fondé sur les capacités et les limites documentées.

ObjectifPremières mesures à réaliserPoint de vigilance
Traiter des documents avec images et tableauxExactitude par champ, lecture des graphiques et latence totale.Ne pas déduire les performances en production d’un seul benchmark.
Exécuter des agents en localMémoire, débit, consommation et qualité sur le matériel visé.L’optimisation pour DGX Spark ne détermine pas les résultats sur d’autres GPU.
Comparer NVFP4 et BF16Précision sur les cas difficiles, mémoire et performances à configuration identique.La distillation vise à réduire les écarts, mais cela doit être vérifié sur la tâche visée.
Comparer avec les modèles BoltMêmes entrées, mêmes outils, même matériel et même critère d’achèvement.Les sources fournies ne proposent pas de comparaison complète et homogène.

Questions ouvertes

  • Il n’y a pas assez de données comparables sur la latence, le débit ou la consommation de Super VL face à Bolt 74B-A9B et Bolt E4B sur DGX Spark, RTX 6000 et RTX 8000.
  • Les benchmarks techniques proviennent de contenus publiés par NVIDIA ; les sources fournies ne documentent pas de réplication indépendante complète des principaux chiffres.
  • Les paramètres de charge et de configuration ne sont pas tous précisés avec assez de détail pour extrapoler les résultats de débit à un déploiement concret.
  • La documentation décrit NVFP4 et la distillation tenant compte de la quantification, mais ne fournit pas de mesure indépendante et homogène de leurs effets sur la précision et la consommation énergétique.
07

Poursuivre l’exploration

07

Sources consultées

03

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.

Proposer une correction