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`	192.168.180.3	8080	Qwen3.8-27B-FP8	Reasoning und Standardantworten auf dem 4×-RTX-5090-Host
`hermes`	192.168.180.202	8080	Qwen3.8-27B-AWQ-INT4	Coding-Assistent auf der Einzelkarte

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 (192.168.180.3) als Qwen3.8-27B-FP8. Sie decken reasoning-lastige und standardmässige Anfragen auf derselben Hardware ab. hermes läuft auf der Einzelkarte (192.168.180.202) als Qwen3.8-27B-AWQ-INT4 und ist als Coding-Assistent justiert.

Welche Rolle spielt die 192.168.180.211 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.