LiteLLM vs. OpenRouter: Kosten, Kontrolle und Ausfallsicherheit

Bei der Wahl eines LLM-Gateways geht es weniger darum, ob LiteLLM und OpenRouter eine OpenAI-kompatible API anbieten. Entscheidend ist, wer die Routing-Schicht betreibt. OpenRouter ist der unkompliziertere Einstieg, wenn im Team noch keine produktive Gateway-Infrastruktur vorhanden ist. LiteLLM rechtfertigt den zusätzlichen Aufwand, sobald private Netzwerke, eigene Richtlinien oder dauerhaft hohe Nutzung so viel Kontrolle erfordern, dass sich der Betrieb personell lohnt.

Die Entscheidung betrifft das Betriebsmodell – nicht das API-Format

LiteLLM ist Open-Source-Software, die entweder als Python-SDK oder als selbst gehosteter Proxy läuft. OpenRouter ist eine verwaltete API mit Modellkatalog: OpenRouter betreibt das Gateway, bündelt den Zugriff auf Provider und stellt ein zentrales Konto für die Modellnutzung bereit.

Beide Lösungen können eine OpenAI-kompatible Schnittstelle bereitstellen. Die Verantwortung liegt jedoch an unterschiedlichen Stellen:

Gerade dieser Unterschied macht auch eine gemeinsame Architektur sinnvoll: LiteLLM kann die interne Policy- und Abrechnungsschicht übernehmen, während OpenRouter ausgewählte Modellzugriffe abwickelt.

Entscheide nach der Einschränkung, die zuerst zum Problem wird

Die richtige Wahl hängt davon ab, welche Anforderung dein Team nicht verhandelbar findet.

Vom Tokenpreis bis zur Engineering-Rechnung

LiteLLM und OpenRouter berechnen unterschiedliche Ebenen. OpenRouter reicht die zugrunde liegenden Modellpreise ohne Inference-Aufschlag durch und erhebt anschließend eine Gebühr von 5,5 % beim Kauf von Guthaben. Der Open-Source-Proxy von LiteLLM hat keine Gateway-Gebühr pro Token. Dafür bezahlst du Infrastruktur und Personal, die für den Betrieb erforderlich sind.

Die Preisseite von OpenRouter ist die aktuelle Quelle für die Gebührenbedingungen. Die Gebühr fällt beim Kauf von Guthaben an – nicht als einfacher Aufschlag von 5 % auf den Tokenpreis jedes Modells.

Wann OpenRouters Gebühr der günstigere Kostenblock ist

Wenn ein Team ausreichend OpenRouter-Guthaben kauft, um die monatliche Inference-Rechnung abzudecken:

• Bei einer monatlichen Nutzung von $500 beträgt die Gebühr von 5,5 % beim Guthabenkauf $27.50.
• Bei $20,000 sind es bei gleichem Prozentsatz $1,100.
• Bei $50,000 fallen $2,750 an.

Diese Werte zeigen, welche Kosten LiteLLM nach Hosting, Deployment, Patching, Alarmierung, Backups und Engineering-Zeit unterbieten muss. Bei $500 pro Monat ist OpenRouter für ein Team ohne bestehendes Gateway häufig die betrieblich einfachere Option – es sei denn, ein privates Netzwerk ist zwingend erforderlich. Bei $20,000 sollte ein Team mit eigener Plattformverantwortung LiteLLM ernsthaft durchkalkulieren.

Wann LiteLLMs Gateway-Gebühr von null tatsächlich günstiger ist

LiteLLM wird finanziell attraktiv, wenn die laufenden Fixkosten bereits durch das Plattformteam abgedeckt sind oder die eingesparte prozentuale Gebühr höher ausfällt als die zusätzlichen Kosten für den Proxy-Betrieb.

Der offizielle Docker-Schnellstart unterscheidet zwischen einem einfachen Proxy ohne Datenbank und einem datenbankgestützten Deployment. Im Compose-Ablauf wird PostgreSQL für Modelle, Schlüssel und Ausgaben-Logs verwendet. Ohne Datenbank stehen laut LiteLLM virtuelle Schlüssel, Ausgaben-Tracking und eine wirksame Budgetdurchsetzung nicht zur Verfügung; ein konfiguriertes max_budget ist dann keine verlässliche harte Obergrenze.

Redis markiert eine weitere Schwelle für den Produktivbetrieb. Die Redis-Anforderungen von LiteLLM empfehlen einen gemeinsamen Redis-Zustand, sobald der Proxy mit mehr als einem Worker oder Replica läuft. Ohne diesen Zustand bleiben Rate Limits, Budgets, Cooldowns, Cache-Einträge und Routing-Beobachtungen auf die einzelnen Worker verteilt. Ein Test mit nur einem Worker ist günstig; ein horizontal skalierter Produktiv-Gateway ist ein deutlich größeres System.

Nutze deshalb diesen Vergleich statt ausschließlich auf den Tokenpreis zu schauen:

LiteLLM total cost = provider bills + infrastructure + operations + security ownership
OpenRouter total cost = provider inference + credit-purchase fee

Einen allgemeingültigen Break-even-Punkt gibt es nicht. Entscheidend sind der monatliche Inference-Umsatz, Hostingkosten, Engineering-Stunden, die Abdeckung des Bereitschaftsdienstes und mögliche Compliance-Aufschläge.

Vergleiche die Control Plane, die du selbst betreiben musst

LiteLLM gibt einem Plattformteam mehr Kontrolle, verschafft ihm aber keinen Providerzugang. OpenRouter vereinfacht Modellentdeckung und zentrale Abrechnung. Der gehostete Katalog ist jedoch nicht dasselbe wie eine direkte Beziehung zu einem Provider.

Bei der Zuverlässigkeit unterscheiden sich die Produkte deutlich

Beide Produkte können Requests wiederholen oder auf andere Ziele ausweichen. Das geschieht jedoch unter unterschiedlichen Verantwortungsmodellen. OpenRouter verwaltet den Provider-Pool; bei LiteLLM definierst du diesen Pool selbst und musst ihn als Teil deines Reliability-Stacks betreiben.

Die Dokumentation zum Provider-Routing von OpenRouter beschreibt das Standardverhalten als Load-Balancing über verfügbare Provider, wobei Preis und aktuelle Provider-Ausfälle berücksichtigt werden. Du kannst die Reihenfolge der Provider anfordern, Fallbacks erlauben oder deaktivieren, bestimmte Parameter voraussetzen, nach Datenrichtlinien filtern oder nach Preis, Durchsatz und Latenz sortieren. Der Leitfaden zu Model-Fallbacks beschreibt eine geordnete models-Liste. Abgerechnet wird das Modell, das die Anfrage letztlich bedient.

Die Routing-Dokumentation von LiteLLM beschreibt gewichtete oder zufällige Auswahl, nutzungsbewusstes Routing, latenzbasiertes Routing, Least-Busy-Routing, kostenbasiertes Routing und eigene Routing-Strategien. Außerdem unterstützt LiteLLM Deployment-Prioritäten, Cooldowns, Retries und Fallback-Gruppen. Diese Möglichkeiten sind programmierbarer, ihre Zuverlässigkeit hängt aber von deiner Konfiguration, den Health Checks, dem gemeinsamen Zustand und deiner Incident-Reaktion ab.

Agentenlatenz, Caching und Provider-Drift

Ein zusätzlicher Netzwerk-Hop fällt bei einer langen Streaming-Antwort möglicherweise kaum ins Gewicht. Anders sieht es aus, wenn ein Agent Dutzende kurze Modellaufrufe ausführt: Gateway-, Netzwerk- und Retry-Verzögerungen summieren sich über die einzelnen Schritte. Ein selbst gehosteter LiteLLM-Proxy kann nahe an der Anwendung laufen; OpenRouter fügt vor dem ausgewählten Provider einen verwalteten Dienst-Hop hinzu. Die allgemeine Dokumentation beider Anbieter ersetzt keinen Test mit deiner Region, deinem Modell, Streaming-Modus und Parallelitätsgrad.

Routing kann auch die Cache-Ökonomie verändern. OpenRouter kann für dasselbe Modell zwischen Provider-Endpunkten wechseln, während LiteLLM Requests auf mehrere konfigurierte Deployments verteilen kann. Wenn ein Workflow auf Prompt-Caching beim Provider angewiesen ist, kann ein Routenwechsel die Cache-Lokalität und damit die Tokenkosten verändern. Behandle das Cache-Verhalten als Teil deines Workload-Tests.

Auch ein gemeinsamer Model-Slug garantiert kein identisches Verhalten. Provider-Implementierungen können sich bei Kontextlimits, Tool-Call-Unterstützung, Latenz, Quantisierung, Caching und provider-spezifischen Parametern unterscheiden. OpenRouter bietet Provider-Filter wie require_parameters, während LiteLLM Provider-Aufrufe auf eine gemeinsame Schnittstelle abbildet. Teste die exakten Tool-Schemas und Modellparameter, die dein Agent verwendet.

Auf diese Ausfälle solltest du vorbereitet sein

Bei OpenRouter werden Infrastrukturvorfälle zur Abhängigkeit von einem Anbieter. Bei LiteLLM werden sie zu Vorfällen, die dein Plattformteam selbst untersuchen und ändern kann.

Observability und Datenschutz haben unterschiedliche Grenzen

„Selbst gehostet“ und „privat“ sind keine Synonyme. Umgekehrt bedeutet „verwaltet“ nicht automatisch, dass jeder Prompt protokolliert wird. Entscheidend ist, welche Schicht Inhalte speichert, welche nur Metadaten erfasst und welche Provider die Anfrage erhalten.

Die Dokumentation zur Zero Data Retention von OpenRouter erklärt, dass sich ZDR kontoweit, nach Modellgruppe, Guardrail oder Request erzwingen lässt. Sie unterscheidet Endpunkte ohne Aufbewahrung von Providern, die Daten zwar nicht zum Training verwenden, sie aber vorübergehend speichern können. ZDR gilt für das Inference-Routing; aktivierte Tools und Plugins müssen separat geprüft werden.

LiteLLM gibt dir mehr Kontrolle über Netzwerk, Datenbank, Authentifizierung und Logs des Gateways. Die Verantwortung liegt dann aber ebenfalls bei dir. Sichere den Proxy ab, halte die Software aktuell, beschränke administrative Routen, schütze Provider-Schlüssel und prüfe die Aufbewahrungs- und Trainingsbedingungen jedes Upstream-Providers.

Der hybride Ansatz ist oft die pragmatische Lösung

Setze LiteLLM vor OpenRouter, wenn du einen stabilen internen Endpunkt und Governance brauchst, aber nicht für jedes Modell und jeden Provider ein direktes Konto anlegen möchtest. Leite sensible oder planbare Zugriffe direkt an freigegebene Provider weiter und schicke explorative oder katalogabhängige Anfragen über OpenRouter.

Ein vereinfachtes Konfigurationsmuster sieht so aus:

model_list:
  - model_name: direct-claude
    litellm_params:
      model: anthropic/claude-sonnet-latest
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: catalogue-model
    litellm_params:
      model: openrouter/<provider>/<model>
      api_base: https://openrouter.ai/api/v1
      api_key: os.environ/OPENROUTER_API_KEY

Damit erhält LiteLLM einen Ort für interne Schlüssel, Budgets, Tags und Logs. Das entfernt weder OpenRouters Gebühr noch den gehosteten Datentransit oder die Provider-Policy-Grenze für Requests über diese Route. Außerdem kommen ein weiterer Hop und eine weitere Fehlerdomäne hinzu. Leite deshalb nicht automatisch jede Anfrage durch beide Schichten.

Eine sinnvolle Aufteilung sieht so aus:

1. Direkte Provider-Routen für sensible Daten, stabile Produktionsmodelle oder ausgehandelte Provider-Verträge.
2. OpenRouter-Routen für Modellentdeckung, weniger verbreitete Provider und verwaltetes Provider-Fallback.
3. LiteLLM-Kontrollen für Anwendungsschlüssel, Teams, Budgets und interne Kostenzuordnung.
4. Getrennte Dashboards und Alarme für direkten Provider-Datenverkehr und OpenRouter-Traffic.

Migrationsaufwand: Was sich ändert – und was nicht

Ein OpenAI-kompatibler Client lässt sich oft mit überschaubarem Aufwand zwischen den beiden Gateways verschieben. Bei einem produktiven Workload reicht es jedoch nicht, nur die Base-URL zu ändern.

from openai import OpenAI
import os

client = OpenAI(
    base_url=os.environ["LLM_BASE_URL"],
    api_key=os.environ["LLM_API_KEY"],
)

OpenRouter verwendet üblicherweise https://openrouter.ai/api/v1 (API-Referenz); ein LiteLLM-Proxy stellt typischerweise einen privaten Endpunkt wie http://localhost:4000 bereit (Proxy-Schnellstart). Modell-IDs, Provider-Präfixe, Authentifizierung und optionale Parameter können trotzdem abweichen.

Bevor du Produktiv-Traffic umstellst, teste:

1. Streaming- und Timeout-Verhalten.
2. Tool Calls mit deinen exakten JSON-Schemas.
3. Strukturierte Ausgaben und den Umgang mit strikt formatiertem JSON.
4. Reasoning, Caching und provider-spezifische Parameter.
5. Das Fallback-Verhalten, wenn das primäre Modell 429, 5xx oder einen Validierungsfehler liefert.
6. Die Kostenzuordnung, weil das Abrechnungsereignis auf einer anderen Ebene stattfinden kann als der Anwendungs-Request.

Die API-Kompatibilität bringt dich durch die erste Integration. Sie garantiert jedoch weder identische Ausgaben und Latenzen noch dieselbe Provider-Auswahl oder identische Abrechnungslogik.

Fragen, die Teams vor der Entscheidung stellen

Lassen sich LiteLLM und OpenRouter gemeinsam nutzen?

Ja. LiteLLM kann OpenRouter als Upstream-Route verwenden. Dadurch übernimmt LiteLLM interne Schlüssel, Budgets, Logging oder Policies, während OpenRouter ausgewählten Modellzugriff und Provider-Routing bereitstellt. Der kombinierte Pfad fügt einen weiteren Hop hinzu und behält für diesen Traffic OpenRouters Gebühr sowie die Grenze durch den gehosteten Datentransit bei.

Welche Lösung ist für eine produktive API günstiger?

Für ein kleines Team ohne bestehende Gateway-Infrastruktur ist OpenRouter häufig die betrieblich günstigere Option. LiteLLM kann bei höherer Nutzung günstiger werden, wenn dein Team die erforderliche Infrastruktur bereits betreibt und prozentuale Gateway-Gebühren vermeiden möchte. Vergleiche die Gesamtkosten, nicht nur die Tokenkosten.

Ermöglicht LiteLLM den Zugriff auf den vollständigen OpenRouter-Katalog?

Nicht von allein. LiteLLM dokumentiert im Proxy-Schnellstart die Unterstützung für 100+ LLMs und zahlreiche Provider. Erreicht werden aber nur die Provider und Zugangsdaten, die du konfigurierst. Wenn du OpenRouter als Upstream hinzufügst, wächst der erreichbare Katalog. Diese Requests folgen dann jedoch der Modell- und Provider-Verfügbarkeit von OpenRouter.

Welche Lösung ist besser für Datenschutz und Compliance?

Ein selbst gehostetes LiteLLM gibt dir mehr Kontrolle über Deployment, Logs, Zugangsdaten und Netzwerkgrenze des Gateways. OpenRouter bietet Kontrollen für Inhaltslogging, Provider-Policy-Filter, ZDR-Routing und regionale EU-/US-Optionen für Enterprise-Kunden. OpenRouter bleibt jedoch Teil des Request-Pfads. Prüfe vor der Entscheidung den konkreten Provider und die jeweiligen vertraglichen Anforderungen.

Wähle die Grenze, die dein Team tatsächlich betreiben kann: Stelle die prozentuale Gebühr deinen realen Gateway-Betriebskosten gegenüber, klassifiziere, welche Anfragen über einen gehosteten Vermittler laufen dürfen, und teste Routing sowie Tool-Call-Verhalten unter realistischen Ausfallbedingungen. Wenn du Datenbank, Redis, Updates und Bereitschaftsdienst von LiteLLM nicht personell abdecken kannst, ist OpenRouter die ehrlichere Standardwahl. Wenn diese Plattformfähigkeiten bereits vorhanden sind, kann LiteLLM oder eine hybride Route Kontrolle zurückgewinnen und wiederkehrende Gateway-Gebühren senken.

Eine breitere Auswahl an Alternativen zu OpenRouter findest du unter OpenRouter alternatives. Dieser Vergleich ist bewusst enger gefasst und konzentriert sich auf die Entscheidung für das passende Betriebsmodell rund um LiteLLM.