Eine API für alle Modelle: Warum LiteLLM Proxy unser Standardbaustein wurde

Wir hatten ein Problem, das jedes Team hat, das ernsthaft mit lokaler KI arbeitet: zu viele Modelle, zu viele APIs, zu viel Konfigurationschaos.

Auf unserem Server laufen gleichzeitig:

• Nemotron-3-Super via Ollama für unsere Hauptanwendungen
• GLM-4.7-Flash via vLLM für parallele Reasoning-Tasks
• Mistral-API für Sprach- und Echtzeit-Features
• Claude für komplexe Analyse und Code

Vier Modelle, vier Provider, vier unterschiedliche API-Formate, vier unterschiedliche Authentifizierungsschemas. Jede Anwendung musste wissen, welches Modell sie wo und wie anspricht.

Das war keine Architektur. Das war ein Kabelwirrwarr.

Die Lösung: Ein Proxy, der alles vereint

LiteLLM Proxy ist ein OpenAI-kompatibler HTTP-Proxy, der sich vor alle Ihre Modelle schaltet. Eine URL. Ein API-Key. Ein Standard.

Anwendung ──▶ LiteLLM Proxy :11437 ──┬──▶ Ollama (Nemotron) :11434
                                       ├──▶ vLLM (GLM-4.7-Flash) :8081
                                       ├──▶ Mistral API (Cloud)
                                       └──▶ Anthropic API (Cloud)

Für die Anwendung sieht alles gleich aus. Sie schickt einen OpenAI-kompatiblen Request an den Proxy — und der Proxy weiß, wohin er ihn weiterleiten muss.

Was das in der Praxis bedeutet

Modellwechsel ohne Code-Änderung.

Wenn wir ein Modell durch ein besseres ersetzen — beispielsweise von Nemotron auf eine neue Nemotron-Version — müssen wir nicht jede Anwendung anfassen. Der Wechsel passiert in der Proxy-Konfiguration, nicht im Code.

# litellm_config.yaml — ein YAML, alle Modelle
model_list:
  - model_name: "default"
    litellm_params:
      model: "ollama/nemotron-mini-4b-instruct"
      api_base: "http://localhost:11434"

  - model_name: "reasoning"
    litellm_params:
      model: "openai/glm-4.7-flash"
      api_base: "http://localhost:8081/v1"

  - model_name: "voice"
    litellm_params:
      model: "mistral/mistral-large-latest"
      api_key: "os.environ/MISTRAL_API_KEY"

Fallback ohne Downtime.

LiteLLM unterstützt automatisches Fallback: Wenn das primäre Modell nicht antwortet (Container startet, GPU-OOM-Error), springt der Proxy automatisch auf das nächste in der Fallback-Liste. Kein manuelles Eingreifen, kein Alarm um 2 Uhr nachts.

Logging und Observability ab Tag 1.

Alle Requests laufen durch den Proxy — und werden dabei geloggt. Latenz, Token-Verbrauch, Modell-Auslastung: alles zentral sichtbar. Wir haben das direkt an unser Grafana angehängt.

Was wir gelernt haben

Der Proxy darf kein Single Point of Failure sein.

Wir haben LiteLLM zunächst als einzelnen Container betrieben — bis er beim ersten Neustart alle Anwendungen gleichzeitig lahm gelegt hat. Heute läuft er als Paar mit Health-Check und automatischem Restart.

Virtuelle Keys für Teams.

LiteLLM unterstützt virtuelle API-Keys, die unterschiedliche Berechtigungen und Budget-Limits haben. Ein Entwickler darf das leichte Modell frei nutzen, aber für das teure Cloud-Modell gibt es ein monatliches Token-Limit. Das klingt kleinteilig — ist aber genau das richtige Governance-Instrument für ein wachsendes Team.

Model-Routing nach Aufgabentyp.

Nicht jede Anfrage braucht das stärkste Modell. Wir haben Routing-Regeln definiert:
- Kurze Klassifikationen und Extraktion → schnelles lokales Modell
- Komplexe Reasoning-Tasks → Nemotron mit Chain-of-Thought
- Echtzeit-Voice → Mistral (niedrige Latenz über Cloud)
- Code-Review und Planung → Claude über Anthropic-API

Das Ergebnis: niedrigere Kosten, schnellere Antwortzeiten, bessere Ergebnisse durch Modell-Spezialisierung.

Warum das für Enterprise-Teams relevant ist

Die meisten Unternehmen, die gerade in KI einsteigen, beginnen mit einem Modell. Das reicht am Anfang.

Aber sobald die Anforderungen vielfältiger werden — Sprache, Text, Code, Analyse, Echtzeit vs. Batch — wächst die Zahl der Modelle. Und damit die Komplexität.

LiteLLM löst das Problem, bevor es entsteht: mit einem einheitlichen API-Layer, der sich genauso anfühlt wie ein einzelnes Modell — aber intern beliebig viele orchestriert.

Self-hosted. Open Source. OpenAI-kompatibel.

Technischer Stack auf einen Blick

Ein LLM-Proxy klingt nach Engineering-Detail. Aber er ist genau das, was aus einem Experiment eine robuste Plattform macht.

Wir haben ihn eingeführt, nachdem ein Modellwechsel uns drei Tage Nacharbeit gekostet hat. Heute kostet er uns zehn Minuten.

Das ist der Unterschied zwischen Basteln und Bauen.

#EnterpriseAI #LocalAI #LiteLLM #LLMOps #OpenSource #BERTALAB #MLOps #KIInfrastruktur #Ollama #vLLM