NVIDIA Switchyard: Self-Hosted AI Model Routing erklärt

Yulei Chen

7 min

Für jeden AI-Request dasselbe Frontier Model zu nutzen ist einfach. Es ist aber auch teuer, bindet dich an einen Provider und verschwendet starke Modelle an Routinearbeit. Ein kleines Modell für einfache Requests und ein stärkeres Modell für schwierige Aufgaben klingt besser. Dann musst du allerdings den Router selbst bauen.

NVIDIA Switchyard ist ein neuer Open-Source-Versuch, genau diesen Layer wiederverwendbar zu machen. Switchyard sitzt zwischen deiner App oder deinem Coding Agent und mehreren Model Endpoints. Der Client nutzt weiter ein OpenAI- oder Anthropic-API-Format. Switchyard entscheidet, welches konfigurierte Backend antwortet.

Der Zeitpunkt ist spannend. NVIDIA hat Switchyard v0.2.0 am 10. August 2026 veröffentlicht. Seitdem hat das Projekt ungefähr 1.600 GitHub Stars erreicht. Auf GitHubs wöchentlicher Trending-Seite kamen in der Woche bis zum 16. August 1.326 Stars dazu. In einer ausführlichen LocalLLaMA-Diskussion wurde Switchyard außerdem mit Tools wie llama-swap verglichen. Die Community diskutierte dort auch, ob automatisches Routing überhaupt zuverlässig genug ist. Das ist ein deutlich stärkeres Signal als nur eine Launch-Ankündigung.

Hier schauen wir uns an, was Switchyard wirklich macht, wo es in einen Self-Hosted-AI-Stack passt und warum du es noch als Experiment behandeln solltest.

Was ist NVIDIA Switchyard?

Switchyard ist ein LLM Traffic Proxy und eine Rust Library unter der Apache-2.0-Lizenz. Laut offizieller Projekt-Dokumentation kann das Tool:

Requests für OpenAI Chat Completions, OpenAI Responses und Anthropic Messages annehmen;
Requests und gestreamte Responses zwischen diesen API-Formaten übersetzen;
Traffic an vLLM, NVIDIA NIM, Ollama oder andere OpenAI-kompatible Endpoints schicken;
Prometheus Metrics für Requests, Errors, Latenz, Tokens und Routing Overhead bereitstellen;
als eigenständiger Proxy laufen oder seine Routing-Algorithmen in eine andere Rust App einbetten.

Damit unterscheidet sich Switchyard von einem Inference Server. Es lädt keine Model Weights und stellt keine GPU Compute bereit. Du brauchst weiterhin einen oder mehrere Model Endpoints. Das können lokale Services, private GPU Server oder gehostete APIs sein.

Du kannst dir Switchyard als Control Plane für Model Calls vorstellen:

Deine App schickt einen Request an einen stabilen Endpoint.
Switchyard normalisiert den Request und wendet eine Routing Policy an.
Der Proxy ruft das gewählte Model Backend im passenden Format auf.
Die Antwort wird wieder in das Format übersetzt, das dein Client erwartet.

Diese Trennung ist praktisch, wenn deine App nicht wissen soll, ob ein Request zu einem lokalen Ollama Model, einem vLLM Cluster oder einem gehosteten Provider ging.

Vier Routing-Strategien

Switchyard v0.2.0 bringt vier nützliche Routing Patterns mit. Diese Patterns lösen unterschiedliche Probleme. "Smart Routing" ist also nicht einfach ein einzelner Automatikmodus.

Strategie	So funktioniert sie	Guter erster Einsatz
Random	Schickt einen festgelegten Anteil des Traffics an jedes Target	A/B-Tests und Baselines
LLM Classifier	Ein Judge Model wählt zwischen Model Tiers	Routing nach Schwierigkeit oder benötigten Fähigkeiten
Stage Router	Nutzt Tool Results, Errors und Fortschritt aus einem Agent Run	Routine-Turns an ein günstigeres Modell geben
Escalation	Startet mit dem effizienten Modell, danach entscheidet ein Judge über einen zweiten Versuch	Workloads, bei denen ein Retry okay ist

Besonders interessant für Coding Agents ist die Stage-Router-Dokumentation. Der Router schaut auf Signale wie wiederholte Errors, Exploration und zuletzt erledigte Arbeit. Schwierige Recovery-Schritte können zum stärkeren Tier wechseln. Mechanische Folgearbeit bleibt beim effizienten Tier.

Damit brauchst du nicht bei jedem Turn einen zusätzlichen Classifier Call. Trotzdem basiert die Policy nur auf indirekten Signalen. Ein Request kann einfach aussehen und bei einer falschen Antwort trotzdem teure Folgen haben. Du musst die Routing-Qualität mit deinem eigenen Workload testen. Weniger Token-Kosten machen noch kein besseres System.

Was ist neu in v0.2.0?

Version 0.2.0 ist mehr als ein kleines Feature Release. NVIDIA beschreibt sie als Redesign aus 193 Commits. Im Zentrum stehen jetzt ein nativer Rust Server und mehrere wiederverwendbare Libraries. Damit sind Protocol Handling, API Translation, Model Transport und Routing-Algorithmen voneinander getrennt.

Die Release Notes nennen mehrere Punkte, die für Deployments wichtig sind:

Health Checks, Graceful Shutdown, begrenzte Retries und Model Discovery;
Prometheus Metrics, OpenTelemetry Spans und strukturierte Routing Statistics;
optionale dauerhafte JSONL Routing Logs für Evaluations;
Session-aware Routing und Context-Window-Recovery;
Launcher für Claude Code, Codex CLI und OpenClaw;
eine experimentelle LiteLLM Integration.

Genau diese Bausteine machen aus einem Routing-Algorithmus einen betreibbaren Service. Observability ist dabei besonders wichtig. Wenn du nicht weißt, welches Modell einen Request verarbeitet hat, wie lange es gebraucht hat und ob Fehler aufgetreten sind, kannst du den Nutzen des Routers nicht bewerten.

Wo passt Switchyard in einen Self-Hosted Stack?

Switchyard ist am interessantesten, wenn du bereits mehrere Endpoints hast. Du könntest zum Beispiel ein kleines Modell über Ollama für Routinearbeit nutzen und ein gehostetes Frontier Model als Fallback behalten. Falls du noch eine lokale Runtime suchst, zeigt unser Vergleich der Ollama-Alternativen die wichtigsten Optionen. Für einen Chat Layer kannst du auch Open WebUI mit Ollama selbst hosten.

Das Gateway kann außerdem vor europäischer Inference-Infrastruktur laufen. Unser erster Blick auf Hetzner Inference zeigt, warum OpenAI-kompatible Endpoints einen Provider-Wechsel erleichtern. Switchyard geht einen Schritt weiter: Die Client API bleibt stabil, während eine Policy zwischen mehreren Endpoints entscheidet.

Routing macht deinen Stack aber nicht automatisch privat oder GDPR-friendly. Die Daten gehen weiterhin an das Upstream Backend, das die Policy auswählt. Wenn ein lokaler Prompt auf einen US-gehosteten Provider zurückfallen kann, gehört dieser Provider zu deiner Data Boundary. Du brauchst klare Target Allowlists, eigene Policies für sensible Workloads, dokumentierte Retention Settings und Logs, mit denen du das gewählte Backend nachvollziehen kannst.

Der wichtigste Satz im offiziellen README ist die Warnung zum Reifegrad: Switchyard ist pre-alpha, experimentell und nicht für Production gedacht. APIs und Config können sich vor Version 1.0 stark ändern.

Dazu kommen praktische Lücken:

Der aktuelle Quick Start dokumentiert ein Python Tool und einen per Cargo installierten Rust Server, aber noch keinen offiziellen Container-Weg.
Ein Gateway wird zur wichtigen Secret Boundary, weil es Credentials für Upstream Provider braucht.
Protocol Translation muss Tool Calls, Streaming Events, Reasoning Items, Token Counts und Error-Verhalten korrekt erhalten. Nur Text weiterzureichen reicht nicht.
Automatisches Routing braucht Quality Tests und nicht nur Dashboards für Kosten und Latenz.
Ein zentraler Proxy kann zum Single Point of Failure werden. Du brauchst Health Checks, Replicas, Timeouts und kontrolliertes Fallback-Verhalten.

Aktuell ist eine abgeschottete Testumgebung der sinnvolle Weg. Spiel repräsentativen Traffic erneut ab. Vergleich jedes geroutete Ergebnis mit einer Fixed-Model-Baseline und schau dir die Fehler genau an. Miss Answer Quality zusammen mit Kosten, Latenz, Retries und Routing Overhead. Schick keine sensiblen Production Prompts durch den Router, bevor du Backend-Auswahl und Logging geprüft hast.

Der praktische Sliplane-Winkel

Switchyard ist heute keine One-Click-App für Sliplane. Das Upstream-Projekt dokumentiert auch noch kein offizielles Docker Image. Sobald du den Service selbst paketierst und absicherst, passt die Architektur aber zu einem normalen gehosteten Control-Plane-Service: stateless Proxy, Health Endpoint, Secrets über Environment Variables, Metrics und externe Model Endpoints.

Wenn du diesen Container baust, kann Sliplane das Gateway und deine umliegenden Dockerized APIs oder Worker auf europäischer Infrastruktur betreiben. Leg Provider Keys als Secrets ab, mach nur den Client Endpoint erreichbar und schick Metrics an deinen bestehenden Observability Stack. Für die experimentelle Phase ist ein privater Test Service sinnvoller als ein öffentliches Production Gateway.

Fazit

Switchyard verdient Aufmerksamkeit, weil es ein echtes Deployment-Problem angeht: AI Apps brauchen immer öfter mehrere Modelle, ohne Provider-Logik in jeden Client einzubauen. Protocol Translation, Agent-aware Routing und integrierte Observability machen v0.2.0 technisch interessant.

Auch das Interesse ist real. Mehr als 1.300 neue Stars in einer Woche und eine inhaltliche Community-Diskussion zeigen, dass Entwickler aktiv nach offener Model-Routing-Infrastruktur suchen.

Aufmerksamkeit ist aber keine Reife. Switchyard ist heute eher ein messbares Routing Lab als ein fertiges Production Gateway. Test es mit deinen eigenen Prompts, halt Data Residency explizit und verlang echte Quality-Daten, bevor ein automatischer Router entscheidet, wohin wichtige Arbeit geht.