NVIDIA Switchyard: Warum KI-Agenten nicht jede Aufgabe an das teuerste Modell schicken sollten

NVIDIA zeigt mit NeMo Switchyard, wie KI-Agenten Aufgaben auf verschiedene Modelle verteilen. Der Test zeigt aber auch klare Qualitätsgrenzen.

Von Wolfgang

14. Aug. 20267 Min. Lesezeit

NVIDIA zeigt mit NeMo Switchyard, wie KI-Agenten Aufgaben auf verschiedene Modelle verteilen. Der Test zeigt aber auch klare Qualitätsgrenzen.

Ein KI-Agent muss nicht jede Teilaufgabe an das stärkste und teuerste Modell schicken. Genau dort setzt NVIDIA mit NeMo Switchyard an: Eine Routing-Schicht soll zwischen Aufgabe und Modell entscheiden. Das kann Routinearbeit günstiger machen. Es verschiebt aber die technische Frage: Woran erkennt das System, dass ein kleineres Modell noch ausreicht – und wann muss es eskalieren?

Das Wichtigste in 30 Sekunden

NVIDIA hat NeMo Switchyard am 11. August 2026 als offene Routing-Bibliothek für KI-Agenten vorgestellt.
Der Router verteilt einzelne Anfragen oder Workflow-Schritte auf unterschiedliche Modelle und kann schwierige Fälle an ein stärkeres Modell weitergeben.
Ein LangChain-Test mit 145 mehrstufigen Agentenaufgaben meldete 3,00 statt 11,45 US-Dollar pro Run – bei 80,0 statt 86,0 Prozent Genauigkeit.
Das Repository ist öffentlich, warnt aber vor Pre-Alpha-Status und dem Einsatz in Produktion.

Unmarkierter Serverraum mit zwei getrennten Rechenpfaden und einer Person, die einen Agenten-Workflow prüft — Ein KI-Agenten-Workflow zwischen zwei unmarkierten Rechenpfaden macht Modellwahl als eigene Betriebsschicht sichtbar – durch KI erzeugt

Die neue Schicht sitzt zwischen Agent und Modell

Bei einem Agenten-Workflow entsteht die Modellfrage nicht nur einmal. Ein System kann zunächst eine Anfrage klassifizieren, danach ein Tool aufrufen, Ergebnisse prüfen und bei einem Fehler einen zweiten Versuch starten. Werden all diese Schritte an dasselbe Frontier-Modell geschickt, ist die Architektur zwar übersichtlich, aber nicht automatisch passend zur Aufgabe.

Switchyard verschiebt diese Entscheidung in eine eigene Schicht. Die Bibliothek kann Anfragen über verschiedene offene, proprietäre und NVIDIA-Modelle verteilen. NVIDIA beschreibt sie als anbieteragnostische Schnittstelle, die Routinglogik von den eigentlichen Endpunkten trennt. Dabei können unter anderem Fähigkeiten, Preis, Latenz, Auslastung, Fehler, Tool-Ergebnisse und der bisherige Agenten-Trace einfließen.

Das ist kein neues Foundation-Modell und auch kein Modelltraining. Die Routing-Schicht bewertet den nächsten Arbeitsschritt, wählt ein Ziel und reicht Anfrage und Antwort weiter.

So läuft die Entscheidung im Agenten-Workflow

Technisch lässt sich der Ablauf auf fünf Stationen reduzieren. Der Router muss dabei nicht „das beste Modell“ im abstrakten Sinn finden. Er muss eine für den konkreten Schritt vertretbare Wahl treffen und bei Unsicherheit sichtbar reagieren.

1. Aufgabe: Der Agent erkennt, ob als Nächstes etwa Klassifikation, Recherche, Tool-Nutzung oder eine anspruchsvolle Schlussfolgerung ansteht.
2. Router: Eine Regel, ein LLM-Classifier, ein Stage Router oder ein Escalation Router bewertet den Schritt und die verfügbaren Modelle.
3. Modell: Eine kleinere oder spezialisierte Variante übernimmt den Schritt. Für schwierige Fälle kann der Router ein stärkeres Modell auswählen.
4. Ergebnisprüfung: Tool-Fehler, unvollständige Antworten, Qualitätsgrenzen und Laufzeit werden als Signale für den weiteren Verlauf erfasst.
5. Fallback: Wenn die Antwort nicht genügt, folgt ein Retry, eine Eskalation oder ein Wechsel auf einen freigegebenen lokalen beziehungsweise externen Endpoint.

Erklärdiagramm mit den Stationen Aufgabe, Router, Modell, Ergebnisprüfung und Fallback — Die Kette vom nächsten Arbeitsschritt über Router und Modell bis zur Ergebnisprüfung – durch KI erzeugt

Die 74 Prozent sind eine Messung, kein Sparversprechen

Wie stark Routing wirkt, hängt vom Modellmix und vom Arbeitsablauf ab. LangChain testete eine konkrete Escalation-Konfiguration auf 145 mehrstufigen Deep-Agents-Aufgaben. 93 Prozent der Model-Calls gingen dabei an Nemotron 3.5 Lightning, 7 Prozent an Opus 4.8. Die Kosten lagen bei 3,00 statt 11,45 US-Dollar pro Run. Gleichzeitig sank die gemessene Genauigkeit von 86,0 auf 80,0 Prozent.

Aspekt	Was gemessen oder beschrieben wurde	Was offen bleibt
Modellverteilung	93 Prozent Nemotron 3.5 Lightning, 7 Prozent Opus 4.8	Ob diese Verteilung bei anderen Aufgaben stabil bleibt
Kosten	3,00 statt 11,45 US-Dollar pro Run, also 74 Prozent weniger im Test	Gesamtkosten mit anderen Preisen, Retries und Workflows
Qualität	80,0 statt 86,0 Prozent Genauigkeit	Welche Fehler für den jeweiligen Einsatz akzeptabel sind
Betrieb	Zusätzliche Judge-Anfrage und Routing-Logik	Ob die Latenz und der Wartungsaufwand den Nutzen aufwiegen

Die Zahl ist deshalb nur zusammen mit ihrem Versuchsaufbau aussagekräftig. Ein günstigerer Modellaufruf bildet nicht die gesamte Rechnung. Judge-Calls, Retries, Eskalationen, längere Antworten und die zusätzliche Infrastruktur gehören ebenfalls dazu. LangChain berichtet außerdem, dass der Anteil der Frontier-Aufrufe in fünf Läufen zwischen 4,1 und 9,1 Prozent schwankte. Der Router spart also nicht automatisch.

Qualität muss vor Kosten kommen

Der Abstand zwischen 80,0 und 86,0 Prozent ist kein Detail, das nach dem Rollout folgenlos bleibt. Bei einer unverbindlichen Recherche kann er vertretbar sein. Bei einer Antwort, die einen Tool-Aufruf auslöst, Kundendaten verarbeitet oder eine interne Entscheidung vorbereitet, kann derselbe Abstand den gesamten Ablauf entwerten.

Ein produktiver Router braucht deshalb klare Grenzen: Welche Aufgaben darf die kleinere Variante allein bearbeiten? Welche Fehler lösen eine Eskalation aus? Wie werden halluzinierte Tool-Ergebnisse erkannt? Und wie wird gemessen, ob ein Modellwechsel tatsächlich hilft oder nur zusätzliche Aufrufe produziert?

Die Signale müssen im Trace sichtbar sein. Dazu gehören ausgewähltes Modell, Begründung, Tokens, Latenz, Fehler, Fallbacks und die Kosten pro vollständigem Run. Ohne diese Daten bleibt unklar, ob ein vermeintlicher Vorteil aus dem Routing, aus einem schnelleren Modell oder schlicht aus einer veränderten Aufgabenverteilung stammt.

Open Source heißt nicht automatisch produktionsreif

Das öffentliche Repository und die Apache-2.0-Lizenz machen Switchyard zugänglich. Sie beantworten aber nicht alle Betriebsfragen. Das README bezeichnet den Stand als Pre-Alpha, schnell veränderlich und nicht für den Produktionseinsatz geeignet. Für ein Team ist das eine konkrete Warnung: Schnittstellen, Verhalten und Integrationsaufwand können sich noch verändern.

Auch die Lizenz der Bibliothek ist nicht gleichbedeutend mit der Lizenz der verwendeten Modelle oder Datensätze. Ebenso bleiben Hosting, Telemetrie, Provider-Verträge und personenbezogene Eingaben eigene Prüfbereiche. Ein lokaler Router kann Datenwege besser kontrollierbar machen; er macht sie nicht von selbst korrekt.

Entscheidungsmatrix für Modellwahl mit den Prüffeldern Qualität, Kosten, Latenz, Datenweg und Fallback — Ein Prüfraster für Qualität, Kosten, Latenz, Datenweg und Rückfallebene vor dem produktiven Einsatz – durch KI erzeugt

Was deutsche und europäische Teams vorab prüfen sollten

Für Unternehmen in Deutschland und Europa liegt die Relevanz daher weniger in einer bereits belegten lokalen Nutzung als in der Architekturentscheidung. Vor einem Pilotprojekt sollten mindestens diese Fragen beantwortet werden:

Welche Datenklasse darf an welchen Provider oder lokalen Endpoint gelangen?
Welche Qualitätsgrenze gilt für jede Aufgabenklasse, und wie wird sie mit realen Traces gemessen?
Wie werden Providerwechsel, Fallbacks, Aufbewahrung und Audit-Logs dokumentiert?
Welche Modell- und Datensatzlizenzen gelten neben der Apache-2.0-Lizenz des Repositories?
Wie wird ein Routing-Fehler erkannt, zurückgerollt und einem Menschen zur Prüfung vorgelegt?

Die Quellen belegen weder einen konkreten europäischen Rollout noch automatische EU- oder DSGVO-Konformität oder Energieeinsparung.

Wann ein direkter Modellaufruf sinnvoller bleibt

Der stärkste Einwand gegen eine Routing-Schicht ist ihre zusätzliche Komplexität. Für wenige, klar definierte Modellaufrufe kann ein direktes Setup robuster sein: weniger Komponenten, weniger Messfehler und weniger Fallback-Pfade. Ein Router lohnt sich nicht schon deshalb, weil mehrere Modelle verfügbar sind.

Sein Nutzen entsteht dort, wo ein Agent viele unterschiedliche Schritte ausführt und die Auswahl nachweisbar schwankt. Dann kann eine Kontrollschicht Routinearbeit abgeben und schwierige Fälle eskalieren. Voraussetzung sind aber Tests, Beobachtbarkeit und eine Qualitätsgrenze, die nicht erst nach dem Kostenreport sichtbar wird.

Die eigentliche Entscheidung liegt im Betrieb

NVIDIA macht mit NeMo Switchyard eine Architekturidee greifbar, die bisher oft in einzelnen Anbieterfunktionen verborgen blieb: Die Modellwahl wird zu einem eigenen Bestandteil des Agentenbetriebs. Das kann Flexibilität schaffen, ist aber kein Ersatz für Evaluation und Verantwortlichkeit.

Wer Routing prüfen will, sollte deshalb nicht mit der versprochenen Prozentzahl beginnen. Besser ist ein begrenzter Test mit echten Aufgaben, klarer Datenklasse, gemessener Gesamt-Latenz, Fehlerbudget und dokumentiertem Fallback. Erst dann lässt sich sagen, ob eine kleinere Modellvariante wirklich Arbeit übernimmt – oder nur einen weiteren Kontrollpfad eröffnet.