LLM-Router: Modelle austauschen ohne Vendor-Lock-in

Das Problem: Abgekündigte Modelle legen Deployments lahm

Ein Provider kündigt ein Modell. Jedes Deployment, das hart darauf verweist, fällt aus. Bei zehn Kunden gleichzeitig — fährt alles gleichzeitig an die Wand. Bei 300 Entwicklern, die jeder eigene Modelle und Keys einbauen — endlose Diskussionen, keine zentrale Kostenzuordnung.

Die Halbwertszeit von Modellen sinkt auf Wochen. Ein Model Switch wird zum regelrechten Migrationsprojekt, wenn er nicht geplant ist.

Warum ungesteuerte Individualisierung eskaliert

Wenn 300 Entwickler frei nach ihren eigenen Vorlieben KI-Modelle in ihre Apps einbauen, entstehen drei Probleme:

1. Endlose Modell-Diskussionen — Jede Modellwahl wird zum internen Politikum
2. Keine Kostenzuordnung — Niemand weiss, welche Abteilung welche Tokens verbrennt
3. Keine Governance — Kein Audit-Trail, kein Fallback, kein Hardening

In einem Konzern mit über 1.000 IT-Mitarbeitenden kostet jede Modellwahl Wochen an Abstimmung, wenn es keine verbindliche Whitelist gibt.

Die Lösung: Ein zentraler LLM-Router

Alle Anwendungen routen über eine einheitliche Plattform. Ein Modell-Alias entkoppelt Anwendungscode vom konkreten Provider-Modell. Der Switch passiert über den Alias — kein Code-Change nötig.

Zentrale Überwachung, Authentifizierung, Logging

Ein Kontrollpunkt für alle Calls statt verstreuter Keys in jedem Repository. Nur freigegebene Modelle sind erreichbar.

Fallback und Hardening

Fällt ein Modell aus, greift automatisch das nächste erlaubte — produktionsgehärtet. Kein Ausfall, kein Workaround.

Whitelist erlaubter Modelle plus Modell-Alias

Nur freigegebene Modelle sind erreichbar. Der Switch passiert über den Alias ohne Code-Änderung. Der Modell-Switch dauert Minuten statt Wochen.

Kostenkontrolle: Fair-Use-Reporting und Chargeback

Token-Monitoring pro Abteilung mit Fair-Use-Reporting und interner Weiterverrechnung. Ohne diese zentrale Instanz weiss niemand, welche Abteilung welche Tokens verbrennt.

Governance: NIS2 und TISAX

Der Router als Kontroll- und Logging-Punkt liefert die Nachweise, die NIS2- und TISAX-Anforderungen verlangen. Jeder KI-Call wird protokolliert: Nutzer, Zeitstempel, Modell, Tokens, Kosten, Quelle.

Warum nicht selbst bauen?

Grundsätzlich baubar — LiteLLM ist offen. Aber wir vermeiden die Standardfehler, in die man beim ersten Mal tritt. Der Aufwand steckt im produktiven Hardening: Fallback, Auth, Logging, EU-Deployment und Governance. Wir bringen das aus laufenden Setups mit.

Deployment: EU/Azure Foundry oder lokal

Betrieb auf Azure AI Foundry in der EU oder mit lokalen Modellen, je nach Datenschutz- und Compliance-Lage. Der Router ist keine eigene Applikationslogik, sondern reine Vermittlungs- und Kontrollschicht.

FAQ: LLM-Router und Modellwechsel

Was passiert, wenn mein KI-Modell abgekündigt wird?

Ohne Router fällt jedes Deployment aus, das hart auf das Modell zeigt. Mit einem zentralen LLM-Router zeigt dein Code auf einen Modell-Alias statt auf das konkrete Modell. Du tauschst hinter dem Alias das Modell aus — der Switch dauert Minuten statt Migrationsprojekt.

Wie steuere ich 300 Entwickler, die jeder eigene KI-Modelle einbauen?

Über eine Whitelist erlaubter Modelle plus zentrale Authentifizierung. Alle Anwendungen routen über eine einheitliche Plattform. Damit enden die endlosen internen Modell-Diskussionen, und jeder Call läuft über einen Kontrollpunkt mit Logging.

Wie bekomme ich eine Kostenzuordnung pro Abteilung?

Der Router loggt jeden Call zentral und ordnet Tokens der aufrufenden Abteilung zu. Daraus entsteht Fair-Use-Reporting und Chargeback. Ohne diese zentrale Instanz weiss niemand, welche Abteilung welche Tokens verbrennt.

Erfüllt ein LLM-Router NIS2- und TISAX-Anforderungen?

Ja. Der Router ist der zentrale Kontroll- und Logging-Punkt, über den jeder KI-Call läuft. Damit lassen sich Zugriffe authentifizieren, protokollieren und auf freigegebene Modelle beschränken — genau das, was beide Standards fordern.

Wo läuft der Router und bleiben die Daten in der EU?

Betrieb auf Azure AI Foundry in der EU oder mit lokalen Modellen im eigenen Netz. Der Router ist reine Vermittlungs- und Kontrollschicht. Die Datenhoheit bleibt bei dir und die Modellwahl flexibel.