Nemotron 3.5 Super VL dans SageMaker : un modèle de 120B pour les documents et les agents GUI en 10 minutes

Si vous développez un agent qui ne doit pas seulement bavarder, mais regarder une capture d'écran, lire une facture ou analyser un graphique, il faut généralement assembler tout un bric-à-brac : un OCR à part, un modèle de langage à part, et de la colle entre les deux. NVIDIA et AWS proposent une autre voie. Nemotron 3.5 Super VL est désormais disponible dans SageMaker JumpStart, et on peut la déployer en quelques clics dans Studio ou en quelques lignes de Python.

Sous le capot

Il s'agit d'un modèle multimodal : il prend en entrée des images, des vidéos et du texte, et produit du texte en sortie. Il compte 120 milliards de paramètres au total, mais grâce à l'architecture Mixture-of-Experts, seuls 12 milliards travaillent pour chaque token. La partie langage est hybride : des couches Mamba-2 alternent avec des couches MoE, auxquelles s'ajoutent huit couches d'attention. La vision est confiée à l'encodeur C-RADIO. Le contexte annoncé atteint 1 million de tokens, mais nous reviendrons sur ce chiffre.

Le modèle sait appeler des outils, produire du JSON selon un schéma donné, et le raisonnement s'active ou se désactive à chaque requête via le paramètre enable_thinking. Pour extraire les champs d'une facture, mieux vaut désactiver le raisonnement : c'est plus rapide et moins cher. Pour des questions complexes sur un graphique, il vaut mieux le laisser actif.

JumpStart propose deux variantes. La version NVFP4 pèse environ 75 Go et vise l'inférence rapide ; la version BF16 occupe environ 249 Go et s'adresse à ceux qui veulent fine-tuner le modèle, le distiller ou réaliser leur propre quantification.

Matériel, vitesse et qualité

Par défaut, la version NVFP4 tourne sur ml.g7.24xlarge : quatre GPU RTX PRO 4500 Blackwell, 128 Go de mémoire. La version BF16 exige une ml.p5en.48xlarge avec huit H200. Selon les mesures d'AWS (250 tokens en entrée, 1 500 en sortie, cinq flux parallèles), le tableau est le suivant :

• g7.24xlarge, NVFP4 : environ 63 tokens/s par requête, 0,45 s avant le premier token ;
• g7.48xlarge, NVFP4 : environ 64 tokens/s, 0,51 s ;
• p5en.48xlarge, BF16 : environ 141 tokens/s, 0,53 s.

Il n'est pas honnête de comparer NVFP4 et BF16 d'après ces chiffres : le matériel diffère. En revanche, côté qualité, la version quantifiée perd très peu. Sur MMLongBench-Doc, les deux obtiennent 62,82 ; sur CharXiv, NVFP4 est un peu en retrait (79,88 contre 80,82) ; et sur OSWorld-Verified, le test de contrôle d'ordinateur, elle fait même légèrement mieux (52,30 contre 51,14). Ces métriques proviennent des fiches de NVIDIA : considérez-les comme déclarées, et non comme vérifiées de manière indépendante.

Les pièges à connaître avant le déploiement

Premièrement : vous n'aurez pas le million de tokens de contexte dans JumpStart. Les configurations de service sont calibrées pour 520 à 15 600 tokens. Une page de 1536×1024 consomme environ 1536 tokens, donc un long document de plusieurs pages ne tiendra pas dans une seule requête.

Deuxièmement : une requête n'accepte qu'une seule image et une seule vidéo. Le modèle ne comprend pas les PDF bruts : il faut les convertir à l'avance en images page par page. Les médias ne sont transmis qu'en inline en base64, car l'endpoint fonctionne en isolation réseau et ne peut pas suivre de liens.

Troisièmement : les longs prompts ralentissent le modèle. Avec 10 000 tokens en entrée, le délai avant le premier token sur g7.24xlarge est de 12,6 secondes. C'est beaucoup pour un chat interactif, mais tolérable pour le traitement de documents par lots.

Quatrièmement : la tête MTP pour le speculative decoding est présente dans le checkpoint, mais n'est pas activée dans la configuration JumpStart. L'endpoint ne charge pas les adaptateurs LoRA : seuls les poids de base sont servis. Les quotas d'instances g7 démarrent à zéro sur les nouveaux comptes, il faut donc demander une augmentation à l'avance. Le SDK requiert SageMaker Python SDK v3, version 3.25 ou supérieure, et le type d'instance doit être indiqué explicitement dans Compute, faute de quoi la construction échouera sur ml.m5.large par défaut.

Que faire de tout cela

Si vous avez un flux de factures, de contrats ou de rapports et que vous ne voulez pas faire sortir les données d'AWS, c'est un moyen rapide de tester une hypothèse : déployer NVFP4 sur g7.24xlarge, rendre les pages en PNG et demander du JSON. Pour les agents GUI, un résultat d'environ 52 % sur OSWorld indique que le modèle convient à l'expérimentation, mais pas à l'automatisation sans surveillance. La licence est OpenMDW 1.1 ; lisez-la impérativement sur la fiche du modèle avant le déploiement. Quant au product owner, il a intérêt à calculer d'avance le budget des temps d'inactivité de l'endpoint : un modèle de 120B sur quatre GPU coûte de l'argent, même quand personne n'envoie de requêtes.