Les billets de blog des cloud ont un défaut récurrent : ils annoncent un modèle, puis s’arrêtent pile au moment où ça devient intéressant. Nemotron 3.5 Super VL, le dernier-né multimodal de NVIDIA disponible sur AWS, échappe à la règle. Le post t’explique comment le déployer sur Amazon EKS et, surtout, comment calculer le nombre de machines qu’il te faut pour tenir ta latence. C’est sec, c’est chiffré, et ça change des communiqués.
Le bestiau, d’abord. 120 milliards de paramètres en mixture-of-experts, dont 12 milliards activés par token. Le modèle est distillé de Nemotron 3 Ultra et rejoint sur AWS la famille au complet : Nano, Nano Omni, Super, Ultra et 3.5 Lightning. Les poids sont publiés, ainsi que les jeux de données d’entraînement et les recettes de post-entraînement, ce qui permet de l’adapter à un domaine précis et de le faire tourner sur une infrastructure que tu contrôles.
Les scores annoncés par NVIDIA, tirés de son rapport technique : 63,44 % sur Hermes Bench, 87,05 % sur les évaluations d’agents LangChain, 80,8 % sur CharXiv, le banc de raisonnement sur graphiques. Chiffres constructeur, donc à lire pour ce qu’ils sont. Le premier des trois est le moins flatteur, et 63,44 %, ça ne fait pas la couverture d’un magazine.
Mamba, attention et experts dans le même sac
Sous le capot, une architecture hybride Mamba-Transformer : couches Mamba-2, attention et couches d’experts s’entrelacent. Deux conséquences concrètes. L’état des couches Mamba-2 reste de taille constante pendant la génération, donc sa mémoire ne gonfle pas avec la longueur du contexte comme le fait le KV cache. Et une tête de prédiction multi-token, partagée récursivement, ouvre la voie au décodage spéculatif natif.
Maintenant, le point que les tableaux de spec passent sous silence. Activer 12 milliards de paramètres sur 120 ramène le calcul par token au niveau d’un modèle bien plus petit. La mémoire GPU, elle, doit toujours loger les 120 milliards de poids entiers. Ton temps d’inférence baisse, ta facture de VRAM ne bouge pas d’un octet.
Côté déploiement, la recette est identique sur Amazon EKS, EKS Auto Mode et SageMaker HyperPod EKS, avec les mêmes manifests Kubernetes d’une option à l’autre. Les images passent par ECR, les poids par un volume FSx for Lustre partagé, les nœuds GPU se parlent en EFA. NVIDIA Dynamo sert le modèle d’un bloc sur un seul nœud, ou en mode désagrégé avec le prefill et le decode sur deux machines distinctes. L’encodage image et vidéo peut même partir sur son propre nœud. Le tout a été validé sur des p6-b200.48xlarge (8 GPU B200) et des p5en.48xlarge (8 GPU H200).
La partie qui vaut le détour
Pour vérifier qu’un cluster tient debout, un micro-benchmark NCCL all-reduce suffit : si tu vois de l’utilisation sur tous les GPU et du trafic sur toutes les cartes EFA, le réseau fait son job. Pour la performance du modèle, c’est aiperf qui sort les trois indicateurs qui comptent : le temps jusqu’au premier token, la latence entre tokens et le débit. En balayant plusieurs niveaux de concurrence, tu obtiens une courbe au lieu d’une intuition.
Trace ton budget de latence en lignes horizontales. L’exemple du post : TTFT sous 600 ms, ITL sous 100 ms par token. Le point le plus à droite qui reste sous les deux lignes te donne le débit qu’une réplique encaisse dans ton objectif de service, ici c32, environ 320 tokens par seconde. Tu divises ton débit cible par ce chiffre, tu as ton nombre de paires prefill-decode à déployer. Relance le balayage après chaque changement (précision, forme du parallélisme, agrégé ou non, nouvelle version de Dynamo ou de vLLM) et la courbe te dit immédiatement si tu as gagné. Elle te dit même quoi scaler : si l’ITL monte, ajoute du decode ; si le TTFT monte, ajoute du prefill.
Le billet glisse au passage un « TTFT sous 600 ms (environ 1 seconde) ». 600 ms font 0,6 seconde, mais l’intention est claire : le budget est serré. Et le mode désagrégé abaisse le TTFT à ITL comparable sur deux nœuds, autrement dit le confort se paie en machines.
Ouvre, ouvre, il en restera toujours 120 milliards
Reste la question de fond. Publier les poids, les données et les recettes, c’est plus que ce que font la plupart des acteurs qui se disent ouverts. Mais un modèle de 120 milliards garde 120 milliards de poids en mémoire, donc un ticket d’entrée qui ressemble à un nœud complet de huit B200 ou huit H200. L’ouverture ne rend pas le modèle léger. Ceux qui veulent l’affiner sur leur infra paieront la même machine que ceux qui veulent juste le servir. J’ai déjà raconté ici comment des banques et des ministères européens font tourner des modèles ouverts en production sur leurs propres GPU NVIDIA : Nemotron 3.5 Super VL s’inscrit exactement dans ce schéma, avec la même arithmétique à l’entrée.
Et c’est peut-être ça, la vraie nouvelle. Pas un modèle qui écrase les benchmarks, mais un billet qui te donne une division, deux lignes horizontales et une courbe à relire après chaque mise à jour. Dans un secteur qui communique en superlatifs, ça ressemble presque à de l’humilité. Presque : le seul chiffre que tu retiendras vraiment n’est ni 120, ni 12, ni 63,44. C’est 320. À toi de calculer combien de fois tu dois le multiplier.
Sources :
Comments are closed