BLUF: Produktionsreifes Model Routing ist kein Preisumschalter. Es ordnet jeder Anfrageklasse erlaubte Fähigkeiten, eine Qualitätsuntergrenze sowie Latenz- und Kostenbudgets zu – und erzeugt Nachweise, wenn ein Fallback verwendet wird. Fehlen diese testbaren Grenzen, kann eine Ausfallregel einen kritischen Prozess unbemerkt zu einem Qualitätsversuch machen.
Warum ein einziges „bestes Modell“ keine Produktionsabstraktion ist
Ein Modellportfolio bedient Anfragen mit sehr unterschiedlichen Fehlkosten. Eine Dokumentenextraktion benötigt schema-valide Ergebnisse und kurze p95-Latenz. Eine deutschsprachige technische Antwort braucht eine höhere Qualitätsuntergrenze und oft mehr Kontext. Eine risikoarme interne Zusammenfassung kann bewusst kostenbegrenzt sein. Ein gemeinsamer Alias verschwendet Budget im einfachen Pfad und spezifiziert den schwierigen Pfad nicht ausreichend.
LiteLLM dokumentiert gewichtete, rate-limit-bewusste, latenze- und kostenbasierte Strategien sowie Queues, Cooldowns, Retries und Fallbacks über Deployments hinweg. Das sind nützliche Transportmechanismen. Sie entscheiden jedoch nicht, ob ein Fallback für ein konkretes Geschäftsergebnis zulässig ist. Diese Vorgabe muss Ihre Control Plane liefern.
Die Entscheidungslogik: Policy vor Providerauswahl
Verwenden Sie die Anfrageklasse als Routing-Einheit: etwa extraction.standard, support.de-technical oder incident.advisory – nicht einen Modellnamen. Die Anwendung sendet Klasse und nur erlaubte, nicht sensible Betriebssignale. Der Router löst ein Kandidatendeployment nur auf, wenn alle harten Grenzen erfüllt sind.
Ein praxistauglicher Policy-Eintrag enthält Eigentümer der Klasse, freigegebene Modell- und Deployment-IDs, erforderliche Fähigkeiten, Version der eingefrorenen Evaluierungssuite, Qualitätsuntergrenzen je Segment, p95-Latenz- und Kostenbudget, Residenz- und Tool-Nutzungsgrenzen, Fallback-Reihenfolge und Ablaufdatum. Versionieren Sie diesen Eintrag wie ein Release-Artefakt und schreiben Sie seine Policy-ID in jedes Inferenzereignis.
Diagramm der Routing-Control-Plane
Anfrageklasse + erlaubte Signale → Policy-Lookup → harte Gates (Fähigkeit, Qualität, Residenz, Budget) → zulässige Deployment-Menge → Auswahl → Inferenzereignis + Kostenbeleg → Abgleich und Review.
Harte Gates verwerfen Kandidaten. Erst danach wählt die Selektionslogik. Dadurch kann eine Kosten- oder Latenzheuristik keine Qualitätsuntergrenze überstimmen. Gibt es keinen zulässigen Kandidaten, muss der Router eine kontrollierte Degradierung zurückgeben statt die Klasse stillschweigend zu lockern.
Policy-Tabelle für Anfrageklassen
Strukturierte Extraktion — Erforderlich: JSON-/Schema-Unterstützung; Feld-Qualität der eingefrorenen Suite. Latenz: p95 3 s. Kosten: 0,015 €. Fallback: gleichwertiges Deployment, sonst Queue oder typisierter Fehler.
Deutscher technischer Support — Erforderlich: deutsche und retrieval-gestützte Segmentgrenzen. Latenz: p95 8 s. Kosten: 0,08 €. Fallback: freigegebene Alternative, sonst Übergabe an Menschen.
Interne Zusammenfassung — Erforderlich: Basis-Qualitätsgrenze; keine externen Tools. Latenz: p95 5 s. Kosten: 0,02 €. Fallback: günstigeres freigegebenes Modell zulässig.
Incident Advisory — Erforderlich: Incident-Suite-Grenze; Evidenzlinks erforderlich. Latenz: p95 10 s. Kosten: 0,15 €. Fallback: kein qualitätssenkender Fallback; kontrolliert nicht verfügbar.
Welche Signale eine Route beeinflussen dürfen
Nutzen Sie beobachtbare, autorisierte und auditierbare Signale: Anfrageklasse, deklarierte Sprache, freigegebene Region, geschätzte Promptgröße, Queue-Tiefe, Deployment-Health, verbleibende Rate-Limit-Kapazität, gemessene Latenz und Policy-freigegebene Token-/Kostenschätzung. Routen Sie nicht anhand roher Kundentexte, verdeckt abgeleiteter Sensitivität, Identitätsmerkmalen oder eines intransparenten Provider-„Qualitätslabels“, solange Datenschutz-, Fairness- und Auditfolgen nicht geprüft sind.
Die Generative-AI-Semantic-Conventions von OpenTelemetry sind ein sinnvoller Start für konsistente Telemetrie, aber benannte Spans sind noch keine Governance. Halten Sie ein minimales Routingereignis vor: Anfrageklasse, Policy-Version, Hash der Kandidatenmenge, gewähltes Deployment, Fallback-Grund, Latenz, Tokenkategorien, Kostenschätzung und Ergebnis. Redigieren oder trennen Sie Prompts und Ausgaben; Routinglogs dürfen nicht zur unkontrollierten Kopie von Kundendaten werden.
Ausfallübungen: Entscheiden testen, nicht nur den Retry
LiteLLM dokumentiert geordnete Fallbacks nach Retries und unterscheidet allgemeine, Kontextfenster- und Content-Policy-Fallbacks. Eine Produktionsübung sollte in einer Nichtproduktionsumgebung repräsentative Fehler auslösen: Provider-5xx oder Timeout, Rate Limit, Kontextfensterfehler, fehlerhafte Ausgabe, fehlende Region, veraltete Preismap und ausgeschöpftes Budget. Prüfen Sie jeweils gewählten Fallback, Policy-ID, sichtbare Degradierung, Trace und Finanzbeleg.
Eine Übung besteht nur, wenn das Ergebnis für die Anfrageklasse sicher ist. Für incident.advisory ist ein günstiges Modell mit plausibel klingender, aber nicht qualifizierter Empfehlung ein Fehlschlag, selbst wenn Verfügbarkeit zurückkehrt. Richtig kann „nicht verfügbar“, Queuing oder Eskalation an einen Menschen sein.
Shadow Traffic und Rechnungsabgleich
Nutzen Sie redigierten Shadow Traffic erst nach Freigabe durch die Datenverantwortlichen. Spielen Sie repräsentative Stichproben über Kandidatenrouten, ohne Nutzende zu beeinflussen; behalten Sie Anfrageklasse bei und dokumentieren Sie Vergleichbarkeitsgrenzen. Vergleichen Sie gegen die eingefrorene Suite und messen Sie Policy-Entscheidungen statt nur mittlere Latenz.
Kostentelemetrie ist eine Schätzung, bis sie abgeglichen ist. LiteLLM dokumentiert berechnete Antwortkosten und Spend Logs und empfiehlt bei Abweichungen, Zeiträume und Tokenkategorien einschließlich Cache abzugleichen. Stimmen Sie Providerrechnungen nach Deployment, Modell, Region, Tokenkategorie und Zeitraum ab. Behandeln Sie Differenzen als Datenqualitätsincident: Ursache können Preismap-Änderung, Cache-Buchung, Ingestion-Verzug oder eine nicht freigegebene Route sein.
Fehlermodi, die Price-only-Routing verdeckt
1. Ein Providerausfall leitet Extraktion an ein Modell ohne verifiziertes Structured Output. Gegenmaßnahme: Fähigkeit und Feld-Qualitätsgrenze sind harte Gates, keine Gewichte.
2. Eine Latenzheuristik verschiebt deutsche technische Anfragen auf ein primär englisch evaluiertes Deployment. Gegenmaßnahme: Sprach- und Dokumenttypsegmente bleiben Teil der eingefrorenen Suite.
3. Der Fallback wirkt in Applikationslogs erfolgreich, verdoppelt aber Cache-Token-Kosten. Gegenmaßnahme: Routingereignisse mit Tokenkategorie-Spend verbinden und monatlich gegen Rechnungen abgleichen.
4. Ein Health-Signal ist veraltet. Gegenmaßnahme: zeitgebundene Health-Evidenz, Circuit Breaking, Cooldowns und explizit „kein zulässiger Kandidat“.
5. Shadow Traffic kopiert Promptinhalte in eine breitere Observability-Landschaft. Gegenmaßnahme: freigegebene Redigierung, getrennte restriktive Payload-Speicherung und Aufbewahrungsregeln.
Routing mit Release-Disziplin verbinden
Routing-Policy ist ein Produktionsartefakt. Das Muster des LLM-Release-Bundles liefert das Betriebsmodell: Policy-Version, freigegebene Deployments, Evaluierungsevidenz und Rollback-Bedingung werden gemeinsam gebunden. Der SLO-Ansatz für selbst gehostete LLM-Inferenz liefert Betriebsmetriken: Queueing, Latenz und Error Budgets beeinflussen Kapazität und Eignung nur innerhalb einer freigegebenen Klasse. Für Downstream-Integrationen bleibt nach der Modellantwort das API-Contract-Gate für strukturierte LLM-Ausgaben notwendig; eine qualifizierte Route garantiert noch kein valides Geschäftsobjekt.
Was diese Architektur nicht löst
Eine Routing-Control-Plane beweist nicht, dass ein Modell korrekt, sicher, rechtlich konform oder für eine folgenreiche Entscheidung geeignet ist. Sie kompensiert keine schwachen Quelldaten, fehlende Evaluierungsabdeckung, unsicheren Toolpfad oder unklare menschliche Entscheidungsverantwortung. Datenresidenz, Verträge und regulatorische Pflichten hängen von Rolle, Sektor und Einsatz ab; lassen Sie diese Fragen rechtlich prüfen. Die Engineering-Empfehlung ist enger: Jede Route und jeder Fallback muss begrenzt, beobachtbar, reproduzierbar und reversibel sein.
Beginnen Sie mit vier Klassen statt einem universellen Router
Inventarisieren Sie Ihre volumen- und folgenreichsten Anfragetypen. Definieren Sie vier Klassen, je einen Owner, eine eingefrorene Evaluierungsscheibe, explizite Budgets und eine Antwort für „kein zulässiger Kandidat“. Führen Sie dann eine Ausfallübung durch und gleichen Sie eine Abrechnungsperiode ab, bevor Sie dynamisch optimieren. Ich unterstütze Sie mit einem Routing-Control-Plane-Workshop, der Modellwahl, SLOs und Kostenevidenz in eine implementierbare Policy und einen Testplan überführt.
Quellen
LiteLLM Router- und Load-Balancing-Dokumentation
LiteLLM Provider-Failover-Dokumentation
