LiteLLM-Gateway im Eigenbetrieb: Zwei Lanes statt Wildcard

Unser lokales LiteLLM-Gateway wurde am 19. August konsolidiert. Seitdem gibt es keine Wildcard-Fallback-Lane mehr, sondern nur noch klar definierte Routen: thinking/nothink auf dem 4×-RTX-5090-Host und hermes auf der Einzelkarte. Unbekannte Modellnamen scheitern lautstark statt unbemerkt umgeleitet zu werden.

Nach der Konsolidierung landet jede Anfrage in einer definierten Lane. (Quelle: Eigene Infrastruktur)

Zwei Lanes statt einer Wildcard

Lane	Host	Port	Modell / Format	Einsatzzweck
`thinking` / `nothink`	`kipc5090`	8080	Qwen3.8-27B-FP8	Reasoning und Standardantworten auf dem 4×-RTX-5090-Host
`hermes`	Einzelkarte	8080	Qwen3.8-27B-AWQ-INT4	Coding-Assistent

Die Vision-Aliases wurden ebenfalls auf den .3-Host gezogen, damit Bildverarbeitung und Textgenerierung auf derselben GPU-Gruppe liegen.

MCPs und Hooks

Hinter dem Gateway hängen die lokalen Model Context Provider: docling, excel, erp_lookup, browser_eyes, grounded_docs, searxng, weather und crawl4ai. Zwei Hooks sitzen direkt im Pfad: ein guard_hook für Inhaltsprüfungen und ein OCR-Hook für Dokumente.

Was sich konkret geändert hat

Wildcard entfernt: Kein *-Fallback mehr, unbekannte Modellnamen liefern einen Fehler.
Vision konsolidiert: Bild-Endpoints zeigen auf .3 statt auf verstreute Karten.
Lanes explizit: thinking/nothink vs. hermes sind technisch und semantisch getrennt.
Hooks aktiv: guard_hook und OCR-Hook werden bei jedem Durchlauf ausgeführt.

Fazit

Ein Gateway mit einer Wildcard ist bequem, aber undurchsichtig. Die Konsolidierung macht das Verhalten vorhersehbar: jeder Client-Request muss bewusst zu einer Lane passen. Das erhöht den Konfigurationsaufwand, verhindert aber das stille Abliefern falscher Modelle.

Weiterführende Quellen

Fragen?

Warum wurde die Wildcard-Lane entfernt?+

Früher fing ein Stern-Fallback alle unbekannten Modellnamen ab. Das verbarg Tippfehler in Client-Konfigurationen und lieferte stillschweigend ein anderes Modell. Seit dem 19. August lehnt das Gateway unbekannte Namen hart ab, jede Anfrage muss einer definierten Lane zugeordnet sein.

Was unterscheidet die Lanes thinking/nothink und hermes?+

thinking und nothink landen auf dem 4×-RTX-5090-Host als Qwen3.8-27B-FP8. Sie decken reasoning-lastige und standardmässige Anfragen auf derselben Hardware ab. hermes läuft auf der Einzelkarte als Qwen3.8-27B-AWQ-INT4 und ist als Coding-Assistent justiert.

Welche Rolle spielt der Embedding-Host im Setup?+

Diese Maschine stellt die Embedding- und Rerank-Endpunkte bereit: embed auf Port 8010 und rerank auf Port 8011. Damit bleibt Retrieval und Neuranking von den Generierungskarten getrennt.