Nemotron 3.5 Lightning ist nicht der Denker – sondern der schnelle Ausführer

NVIDIA Nemotron 3.5 Lightning ist am besten als schnelles Arbeitsmodell für autonome KI-Agenten zu verstehen. Das am 11. August 2026 veröffentlichte offene Mixture-of-Experts-Modell (MoE) besitzt insgesamt 30 Milliarden Parameter, nutzt bei der Erzeugung eines Tokens aber ungefähr 3 Milliarden davon.

Der entscheidende Punkt: Lightning soll kein universeller Ersatz für die größten Reasoning-Modelle sein. Es ist für die vielen kleineren Arbeitsschritte gedacht, die ein lang laufender Agent nach der eigentlichen Planung erledigen muss – etwa Tools aufrufen, Felder aus Dokumenten extrahieren, Richtlinien prüfen, Daten umwandeln oder Antworten in ein festgelegtes Format bringen.

Was Nemotron 3.5 Lightning auszeichnet

NVIDIA beschreibt die Nemotron-Familie als offen: Gewichte, Trainingsdaten und Trainingsrezepte sollen Entwicklern zur Evaluierung und Anpassung vor dem Einsatz zur Verfügung stehen. Lightning wurde in den Formaten BF16 und NVFP4 veröffentlicht.

Die Architektur kombiniert laut den verfügbaren Modellangaben zustandsraum- beziehungsweise Mamba-artige Verarbeitung, Attention und geroutete Experten. Damit soll das Modell die Kapazität einer größeren Parameterklasse bieten, ohne bei jedem Token das gesamte Netzwerk zu aktivieren.

Die beiden Größenangaben bedeuten konkret:

• 30 Milliarden Gesamtparameter: Das ist der vollständige Pool gelernter Modellparameter.
• Rund 3 Milliarden aktive Parameter: Nur dieser ungefähre Anteil wird pro Schritt der Token-Erzeugung verwendet.

Diese dünn besetzte Ausführung kann den Rechenaufwand pro ausgegebenem Token senken. Sie macht das gesamte Modell allerdings nicht automatisch klein: Die vollständigen Parameter müssen weiterhin gespeichert und verwaltet werden. Der Vorteil liegt vor allem im Inferenzaufwand.

Warum Lightning für die Ausführungsschicht gedacht ist

Ein Agent erledigt eine einzelne Aufgabe selten mit nur einem Modellaufruf. Auf die anfängliche Planung folgen häufig viele wiederholte Aktionen: Werkzeug auswählen, strukturierte Informationen extrahieren, Ergebnisse kontrollieren und die Ausgabe formatieren.

Würde für jeden dieser Schritte ein besonders großes Modell eingesetzt, könnten Latenz und Betriebskosten schnell steigen. Lightning soll deshalb den vorhersehbaren, häufig wiederkehrenden Teil übernehmen. Für unklare Situationen oder anspruchsvolle Schlussfolgerungen bleibt ein leistungsfähigeres Modell zuständig.

Eine typische Arbeitsteilung könnte so aussehen:

1. Ein größeres Reasoning-Modell interpretiert das Ziel und erstellt einen Plan.
2. Lightning führt die Routineaufgaben mit Tools, Dokumenten oder strukturierten Daten aus.
3. Bei Ausnahmen, Unsicherheit oder schwierigen Entscheidungen wird wieder das größere Modell aufgerufen.

NVIDIA stellt Nemotron 3 Ultra – ein MoE-Modell mit 550 Milliarden Gesamtparametern und 55 Milliarden aktiven Parametern – als Modell für Frontier-Reasoning und Orchestrierung heraus. Der Vergleich macht die unterschiedliche Rolle der beiden Systeme deutlich.

Welche Rolle NeMo Switchyard spielt

Damit eine solche Architektur funktioniert, muss ein Agent je nach Arbeitsschritt das passende Modell auswählen können. Genau hier setzt NeMo Switchyard an.

Das SDK ist anbieterunabhängig und kann Anfragen abbilden, verfügbare Modellziele definieren sowie Aufrufe an den jeweils ausgewählten Anbieter oder die entsprechende Modell-ID verwalten. So lässt sich eine Hierarchie aufbauen, in der Lightning Routineanfragen bearbeitet, während komplexere Fälle an ein größeres Modell weitergeleitet werden.

Das ist für die Einordnung wichtig: Lightning ist weniger als isolierter Chatbot interessant, sondern als Baustein eines gerouteten Systems mit mehreren Modellen. Seine Stärke liegt in der Zusammenarbeit mit einem leistungsfähigeren Planungs- und Orchestrierungsmodell.

Kontextfenster und Bereitstellung

Für Lightning wird eine Kontextkapazität von bis zu 1 Million Token angegeben. Das kann für Agenten relevant sein, die lange Gesprächsverläufe, umfangreiche Dokumente oder große Mengen an Aufgabenstatus verarbeiten. Wie viel davon in der Praxis nutzbar ist, hängt jedoch vom Serving-Stack und der jeweiligen Konfiguration ab.

Die NVFP4-Version ist für die Inferenz gedacht und nutzt spezialisierte NVIDIA-Kernel auf unterstützten GPU-Generationen. NVIDIA nennt lokale Infrastruktur, Workstations, Rechenzentren und Cloud-Umgebungen als Einsatzorte. Das Modell ist außerdem über Hugging Face und gehostete Dienste verfügbar.

AWS stellt Nemotron 3.5 Lightning über SageMaker JumpStart bereit. Der Dienst ermöglicht die Bereitstellung über die SageMaker-Konsole oder das Python-SDK. Eine separate Option bietet NVIDIA über containerisierte NIM-Dienste. Dafür werden unter anderem Ubuntu 22.04 oder neuer, CUDA 12.9 oder neuer, ein NVIDIA-Treiber ab Version 580 und Docker 24.0 oder neuer empfohlen beziehungsweise vorausgesetzt.

Die Hardwareversprechen sollten dennoch nicht pauschal verstanden werden. Ein quantisiertes Modell kann den praktischen Einsatz erleichtern, doch ob der Betrieb auf einer einzelnen GPU möglich und sinnvoll ist, hängt unter anderem von Grafikspeicher, Kontextlänge, Quantisierung, Batch-Größe und Serving-Software ab. Aussagen zu konkreten Speicherersparnissen oder einer breiten Unterstützung von GeForce-RTX-Systemen sollten daher anhand der aktuellen Modellkarte und Bereitstellungsanleitung geprüft werden.

NVIDIA nennt hohe Geschwindigkeitsgewinne – mit Vorbehalt

NVIDIA und AWS werben für die anvisierten Agenten-Workloads mit bis zu viermal höherem Durchsatz und bis zu 30 Prozent schnellerer Aufgabenerledigung. Diese Werte sind keine allgemeingültige Messung der Modellintelligenz und auch keine Garantie für die Leistung in einer produktiven Umgebung.

Das tatsächliche Ergebnis kann sich verändern durch:

• das als Vergleich verwendete Basismodell,
• GPU-Generation und Speicherausstattung,
• Batch-Größe und gleichzeitige Anfragen,
• Länge von Prompt und Kontext,
• Verzögerungen durch Tools und Netzwerke,
• Einstellungen für die Token-Erzeugung sowie
• die für den jeweiligen Anwendungsfall akzeptable Fehlerquote.

Teams sollten Lightning deshalb nicht nur nach Tokens pro Sekunde beurteilen. Aussagekräftiger sind Messungen im eigenen Agentenablauf: Wie zuverlässig werden Tools aufgerufen? Wie gut funktioniert die Extraktion? Werden strukturierte Ausgabeformate eingehalten? Und wie lange dauert die Aufgabe vom Start bis zum fertigen Ergebnis?

Die Kosten hängen vom Anbieter ab

Für hochvolumige Inferenz kann auch der Preis interessant sein. DeepInfra listet Nemotron 3.5 Lightning mit 0,05 US-Dollar pro 1 Million Eingabetoken und 0,20 US-Dollar pro 1 Million Ausgabetoken. Abgerechnet wird nutzungsabhängig; eigene GPU-Infrastruktur muss dort nicht verwaltet werden.

Diese Preise sind jedoch keine feste Eigenschaft des Modells. Andere Anbieter nennen andere Tarife, und auch Provider, Präzision, Caching sowie die gewählte Route beeinflussen die effektiven Kosten. Für einen fairen Vergleich mit größeren Modellen müssen außerdem Wiederholungen, Tool-Aufrufe, Routing und jene Anfragen eingerechnet werden, die weiterhin ein leistungsfähigeres Modell benötigen.

Fazit: ein Worker, kein Universalgenie

Nemotron 3.5 Lightning ist ein schnelles, anpassbares Arbeitsmodell für Agentensysteme. Sein Einsatz ergibt besonders dann Sinn, wenn eine Anwendung sehr viele ähnliche Aufrufe erzeugt und die Aufgaben spezialisiert, stark eingeschränkt oder nachtrainierbar sind.

Für komplexe Planung, unsichere Bewertungen und Entscheidungen mit hohen Fehlerkosten bleibt ein größeres Modell wie Nemotron 3 Ultra oder ein anderes Frontier-System die naheliegendere Wahl.

Das praktische Urteil fällt daher klar aus: Lightning ist als latenzarme Ausführungsebene in einem gerouteten Multi-Modell-Stack interessant. Die Kombination aus 30 Milliarden Gesamtparametern, rund 3 Milliarden aktiven Parametern, offenen Modellmaterialien, quantisierter Inferenz und mehreren Bereitstellungswegen zielt darauf, Routinearbeit von KI-Agenten günstiger und schneller zu machen. Die beworbenen Zugewinne sollten vor einem produktiven Einsatz jedoch immer am konkreten Workflow überprüft werden.