Pexon Consulting | 9 Min. Lesezeit | 08.07.2026
TL;DR
MLflow AI Gateway und LiteLLM sind beide OpenAI-kompatible LLM-Gateways mit Routing, Fallbacks und Kostentracking. Der Unterschied: LiteLLM ist der spezialisierte Proxy mit über 100 Providern und Prometheus-Metriken, MLflow bringt das Gateway mit nativem Tracing, Evaluation und Prompt-Management in einer Plattform. Pexon Consulting baut beide DSGVO-konform in Ihre Umgebung.
Das Problem: zwei Werkzeuge, die gleich aussehen und Unterschiedliches lösen
Beide legen sich als OpenAI-kompatible Schicht vor Ihre Modelle, beide können Fallbacks und Budgets. Wer nur die Feature-Liste liest, hält sie für austauschbar. Sind sie nicht. LiteLLM ist als Proxy gebaut, der möglichst viele Provider unter eine API bringt. MLflow AI Gateway ist Teil einer Plattform, die den kompletten AI-Lifecycle abdeckt: Gateway, Tracing, Evaluation, Prompt-Optimierung.
Die falsche Wahl merken Sie erst später. Wer LiteLLM nimmt und dann Observability nachrüstet, klebt ein zweites Tool an. Wer MLflow nimmt, aber einen exotischen Provider braucht, stößt an die Provider-Breite. Unsere klare Position: Die Entscheidung ist keine Feature-Frage, sondern eine Architektur-Frage.
MLflow vs LiteLLM im direkten Vergleich
Die kurze Antwort: LiteLLM gewinnt bei Provider-Breite und Proxy-Spezialisierung, MLflow bei integrierter Observability. Hier die Dimensionen, die in der Praxis den Ausschlag geben.
LiteLLM veröffentlicht wöchentlich, zuletzt v1.91.0 am 4. Juli 2026 mit rund 48 neuen Modellen und einem MCP-Gateway-OAuth-Resolver. Das zeigt den Charakter: ein schnell bewegliches Proxy-Projekt, das Provider-Abdeckung zur Priorität macht. MLflow bewegt sich ruhiger, dafür ist das Gateway seit Version 3.11 ohne LiteLLM als Abhängigkeit lauffähig, und seit 3.13.0 (29. Mai 2026) auf Observability im Maßstab getrimmt.
So sieht die Konfiguration bei beiden aus
Beide konfigurieren Sie über eine config.yaml. Der Unterschied steckt im Ökosystem drumherum, nicht in der YAML-Syntax.
# LiteLLM: model_list mit Fallback
model_list:
- model_name: chat-default
litellm_params:
model: anthropic/claude-sonnet-4-6
api_key: os.environ/ANTHROPIC_API_KEY
router_settings:
fallbacks: [{"chat-default": ["gpt-4.1"]}] # bei Fehler auf OpenAI# MLflow AI Gateway: Endpoint mit Fallback-Kette
endpoints:
- name: chat-default
endpoint_type: llm/v1/chat
model:
provider: anthropic
name: claude-sonnet-4-6
config:
anthropic_api_key: $ANTHROPIC_API_KEY
fallbacks:
- provider: openai
name: gpt-4.1# Beide sprechen dieselbe OpenAI-kompatible API
curl http://localhost:4000/v1/chat/completions
-H "Content-Type: application/json"
-d '{"model":"chat-default","messages":[{"role":"user","content":"Test"}]}'Für die Client-Seite ändert sich nichts. Ihre Anwendung ruft in beiden Fällen einen OpenAI-kompatiblen Endpunkt. Deshalb ist ein späterer Wechsel machbar, aber nicht kostenlos: das Betriebsmodell, die Auth und die Observability unterscheiden sich.
Wann LiteLLM, wann MLflow?
Unsere Empfehlung hängt an einer Frage: Wollen Sie ein Gateway oder eine Plattform?
Nehmen Sie LiteLLM, wenn Sie einen dedizierten Proxy brauchen, viele oder exotische Provider bedienen, Prometheus-Metriken in Ihrem Monitoring-Stack wollen oder das LiteLLM-SDK ohnehin schon nutzen. Für reine Routing- und Kostenkontrolle ist es die pragmatischere Wahl. Wie es sich gegen andere Gateways schlägt, steht in unserem LLM-Gateway-Vergleich mit Kong, Portkey und Helicone und im direkten Vergleich LiteLLM gegen OpenRouter.
Nehmen Sie MLflow AI Gateway, wenn Observability zentral ist, Sie MLflow bereits für Experiment-Tracking nutzen oder Gateway, Tracing und Evaluation in einer Plattform zusammenhaben wollen statt vier Tools zu integrieren. Der Vorteil zahlt sich aus, sobald Sie Kosten mit Evaluationsergebnissen verbinden wollen. Das ist im Kern eine Entscheidung über die LLM-Gateway-Plattform, keine Modell-Entscheidung.
Wir raten davon ab, die Wahl an der reinen Provider-Zahl festzumachen. In der Praxis nutzen die meisten Unternehmen drei bis fünf Provider, nicht hundert. Die spannendere Frage ist, wie sauber Sie Kosten, Qualität und Compliance über diese wenigen Provider hinweg beobachten.
Was beide im Unternehmen nicht mitbringen
Egal welches Tool Sie wählen, der POC-Sprung in die Produktion ist bei beiden derselbe Aufwand. Nativ bringen weder LiteLLM noch MLflow ein fertiges DSGVO-, SSO- und Hochverfügbarkeits-Konzept mit. MLflow bietet out of the box nur HTTP Basic Authentication, LiteLLM setzt auf virtuelle Keys. Für den Betrieb brauchen Sie in beiden Fällen EU-Hosting, Entra-Anbindung, ein sauberes Secrets- und Logging-Modell sowie Monitoring und Skalierung. Das ist die eigentliche Arbeit, und sie ist unabhängig von der Tool-Wahl. Bei uns steckt genau dieser Teil im Pilot, nicht die YAML-Datei.
Häufig gestellte Fragen
Was kostet MLflow AI Gateway oder LiteLLM?
Beide sind Open Source und kostenlos in der Lizenz. LiteLLM hat 52.900 GitHub-Sterne, MLflow über 20.000 (Stand Juli 2026). Kosten entstehen für Betrieb, Provider-Nutzung und die Produktivsetzung mit Auth, HA und DSGVO. Der Modellverbrauch läuft über Ihre Provider-Verträge.
MLflow vs LiteLLM: was ist besser für Observability?
MLflow, wenn Observability der Hauptgrund ist. Bei MLflow wird jeder Gateway-Request automatisch zum Trace und liegt neben Evaluation und Prompt-Management in einer Plattform. LiteLLM liefert Prometheus-Metriken und schreibt über Callbacks an Tools wie Langfuse, LangSmith oder Helicone, die wir im Observability-Vergleich gegenübergestellt haben.
Braucht MLflow AI Gateway noch LiteLLM?
Nein, seit MLflow 3.11 nicht mehr. Das Gateway bringt native Provider-Integrationen für OpenAI, Anthropic, Gemini, Bedrock, Azure OpenAI, Mistral, DeepSeek, Ollama, Vertex und weitere mit, ohne LiteLLM als Abhängigkeit.
Kann ich zwischen LiteLLM und MLflow später wechseln?
Grundsätzlich ja, weil beide dieselbe OpenAI-kompatible API sprechen. Ihre Anwendung merkt den Wechsel kaum. Aufwand entsteht beim Betrieb: Auth, Observability-Anbindung und Deployment sind unterschiedlich und müssen neu aufgesetzt werden.
Welches Gateway unterstützt mehr lokale Modelle?
Beide binden lokale Modelle an. LiteLLM unterstützt vLLM, Ollama und viele weitere self-hosted Backends direkt, MLflow bindet Ollama nativ und andere über OpenAI-kompatible Endpunkte ein. Für ein reines On-Prem-Setup mit vielen lokalen Modellen hat LiteLLM die breitere Abdeckung.
Nächster Schritt
Wenn Sie zwischen MLflow und LiteLLM abwägen, schauen wir uns Ihren Stack an: Provider, Observability-Anforderungen und Compliance. Daraus fällt die Entscheidung meist in einem Gespräch.
Verwandte Themen
