NVIDIA Nemotron 3.5 Super VL ist jetzt auf Amazon EKS und SageMaker HyperPod EKS verfügbar

Was Nemotron 3.5 Super VL bietet

Laut AWS ergänzt Nemotron 3.5 Super VL die Modelle Nemotron 3 Nano, Nano Omni, Super, Ultra und Nemotron 3.5 Lightning, die auf der Plattform bereits verfügbar sind. Es handelt sich um ein Mixture-of-Experts-Modell (MoE) mit insgesamt 120 Milliarden Parametern, von denen pro Token 12 Milliarden aktiv sind. Es verbindet Reasoning und Tool-Nutzung mit dem Verstehen von Text, Bildern, Dokumenten und Videos, sodass ein einziges Modell sowohl Text- als auch visuelle Aufgaben übernehmen kann.

Das Modell wurde aus Nemotron 3 Ultra destilliert. NVIDIA veröffentlicht die Gewichte, die Trainingsdatensätze und die Post-Training-Rezepte. Damit können Teams es für domänenspezifische Workloads anpassen und auf einer Infrastruktur betreiben, die sie selbst kontrollieren. Als Eingabe dienen Text, Bild, Dokument oder Video, die Ausgabe erfolgt als Text. Die Kontextlänge reicht bis zu 1 Million Token, Checkpoints in BF16 und NVFP4 sind verfügbar.

NVIDIA nennt 63,44 Prozent im Hermes Bench, 87,05 Prozent bei den LangChain-Agent-Evaluationen und 80,8 Prozent im Benchmark CharXiv für das Schlussfolgern über Diagramme.

Architektur und Einsatzszenarien

Das Modell nutzt ein hybrides Mamba-Transformer-MoE-Design, das Mamba-2-, Attention- und Expert-Layer verschränkt, sowie einen RADIO-Vision-Encoder. Da durch das spärliche Routing pro Token nur 12 der 120 Milliarden Parameter aktiv sind, entspricht der Rechenaufwand pro Token dem eines deutlich kleineren Modells, der GPU-Speicher muss aber weiterhin die vollständigen Gewichte aufnehmen. Mamba-2-Layer tragen während der Generierung einen Zustand konstanter Größe mit sich, ihr Speicherbedarf wächst also nicht wie beim KV-Cache mit der Sequenzlänge. Laut AWS bleiben dadurch lange Kontexte bezahlbar. Ein rekursiv geteilter Multi-Token-Prediction-Head (MTP) unterstützt natives Speculative Decoding.

Als Einsatzgebiete nennt AWS Agenten-Workflows, die Reasoning mit visuellem Verständnis verbinden:

• Coding: Code testen und validieren, Fehler analysieren, Korrekturen empfehlen.
• Webrecherche: Von Suchwerkzeugen gelieferte Quellen abgleichen und verifizieren.
• Dokumentenintelligenz: Tabellen, Diagramme und Seitenlayouts lesen, um Zusammenfassungen zu erstellen.
• Cybersicherheit: Schwachstellen identifizieren und Bedrohungen priorisieren.
• Videoverständnis: Suche, Inhalte, Review und Vorfallanalyse.

Über NVIDIA-Referenzimplementierungen, Cookbooks und das NVIDIA Agent Toolkit lässt sich das Modell in die wichtigen offenen Agenten-Frameworks integrieren.

Für vLLM unterscheidet sich die Mindestzahl an GPUs je nach Präzision. Mit BF16 benötigen B200/GB200 acht GPUs, B300/GB300 vier, H200 acht und H100 sechzehn. Mit NVFP4 sind es jeweils 2, 1, 4 und 8.

Bereitstellung auf AWS

Die Referenzimplementierung, Teil des Projekts aws-do-eks, läuft auf Standard-Amazon-EKS, EKS Auto Mode und SageMaker HyperPod EKS. Die Kubernetes-Manifeste sind für alle Orchestrator-Varianten identisch. Mit EKS Auto Mode übernimmt AWS Skalierung sowie GPU- und EFA-Unterstützung im Cluster. Jeder Cluster besteht aus einer Control Plane und einer Data Plane mit CPU- und GPU-Knoten: CPU-Knoten führen System- und Test-Pods aus, GPU-Knoten das Modell. Amazon ECR speichert die Container-Images, ein gemeinsames Amazon-FSx-for-Lustre-Volume enthält die Gewichte, und Elastic Fabric Adapter (EFA) verbindet die GPU-Knoten.

NVIDIA Dynamo stellt das Modell entweder aggregiert auf einem einzelnen Knoten oder disaggregiert bereit, wobei Prefill und Decode auf verschiedenen Knoten laufen. Bei Vision-Language-Modellen kann außerdem die Bild- und Video-Encodierung auf einem eigenen Knoten laufen.

Laut AWS wurde die Architektur auf Instanzen vom Typ p6-b200.48xlarge (8 x NVIDIA B200 GPUs) und p5en.48xlarge (8 x NVIDIA H200 GPUs) validiert. Nutzer können Cluster und Netzwerk mit einem NCCL-All-Reduce-Micro-Benchmark prüfen und das bereitgestellte Modell mit NVIDIAs Tool aiperf vermessen, das Time to First Token (TTFT), Inter-Token-Latenz (ITL) und den Durchsatz in Token pro Sekunde ausgibt.

Kapazitätsplanung mit Concurrency-Sweeps

AWS zeigt einen Concurrency-Sweep, der aggregierte und disaggregierte Deployments auf zwei Knoten vergleicht. Dabei ergab sich für das disaggregierte Setup eine niedrigere TTFT bei etwa gleicher ITL. Der Beitrag schlägt vor, Latenzbudgets als horizontale Linien einzuzeichnen, etwa TTFT unter 600 ms und ITL unter 100 ms pro Token. Der am weitesten rechts liegende Punkt unter beiden Linien gibt den Durchsatz an, den ein Replikat innerhalb des Service Level Objective bewältigen kann. Im Beispiel ist das c32, also rund 320 Token pro Sekunde.

Um ein Deployment zu dimensionieren, teilt man den angestrebten Durchsatz in Token pro Sekunde durch den Durchsatz pro Replikat und erhält so die Zahl der benötigten Prefill-Decode-Paare. Steigt die ITL, spricht das für mehr Decode-Kapazität, steigt die TTFT, für mehr Prefill-Kapazität. Wer den Sweep nach Änderungen an Präzision, Parallelisierungsform oder mit einem neuen Dynamo- oder vLLM-Release wiederholt, sieht den Zielkonflikt sofort.

Was das für Anwender bedeutet

Für Teams, die ein offenes multimodales Modell unter eigener Kontrolle betreiben wollen, bietet der Beitrag einen erprobten Weg, Nemotron 3.5 Super VL auf verwalteten Kubernetes-Diensten im eigenen AWS-Konto auszuführen. Dasselbe Muster lässt sich auf weitere Modelle der NVIDIA-Nemotron-Familie übertragen, zusätzliche Inferenz-Blueprints gibt es im Projekt AI on EKS.