LiteLLM-Alternativen (2026) — gehostete Gateways, BYO-Key-Kontrollinstanzen und wann Sie bleiben sollten

LiteLLM ist ein Open-Source-Proxy mit OpenAI-Kompatibilität, den Sie selbst betreiben: Er sitzt vor Ihren eigenen Providerkonten und bietet Ihrem Code über diese hinweg einen Endpunkt und ein einheitliches Schlüsselformat (seine Dokumentation). Teams suchen aus zwei voneinander unabhängigen Gründen nach Alternativen. Betrieb: Ein selbst gehosteter Proxy ist ein weiterer Dienst, der gepatcht und skaliert werden muss und für den Bereitschaftsalarm ausgelöst werden können. Lieferkette: Am 24. März 2026 veröffentlichte ein Angreifer zwei manipulierte LiteLLM-Releases auf PyPI, und der Vorfall führte vielen Teams die Angriffsfläche von „einem Paket in Ihrem Build“ vor Augen, die sie zuvor nicht einkalkuliert hatten. Diese Übersicht ordnet jedes Motiv dem Tool zu, das es tatsächlich beantwortet – einschließlich des Falls, bei LiteLLM zu bleiben, der stärker ist, als die sieben Anbieter-Listicles in dieser Suche vermuten lassen.

Offengelegte Voreingenommenheit: Kunavo ist unser Produkt und wird zuerst aufgeführt. Für jedes andere Tool weiter unten gibt es eine echte Empfehlung; die von uns geprüften Details stehen auf den Vergleichsseiten, und die beiden Anbieter, die wir nicht bewertet haben, werden nur auf dem Niveau beschrieben, das ihre eigenen Websites angeben.

Die engere Auswahl

Die Unterscheidung, die den größten Teil der Arbeit erledigt

LiteLLM erfüllt zwei Aufgaben gleichzeitig, und die meisten Ersatzlösungen nur eine davon. Es ist ein Proxy (ein Endpunkt über viele Provider hinweg) und ein BYO-Schlüssel-Tool (die Providerkonten bleiben Ihre). Ein gehostetes Inference-Gateway – Kunavo, OpenRouter – ersetzt beides: Es gibt keinen Proxy zu betreiben und kein Providerkonto zu verwalten, weil das Gateway die Zugangsdaten der Upstream-Anbieter hält und Ihnen die Nutzung in Rechnung stellt. Eine gehostete Control Plane – Portkey, TrueFoundry – ersetzt nur den ersten Teil: Sie stellen den Proxy-Betrieb ein, behalten aber die Konten. Wenn Sie wissen, welche Hälfte Sie ersetzen, klärt das den größten Teil dieser Liste. Das Muster wird im Leitfaden zu LLM-Gateways erläutert.

Was die Leute tatsächlich zur Suche geführt hat

Das Top-Ergebnis dieser Suche ist kein Listicle, sondern ein Reddit-Thread über den Angriff auf die Lieferkette. Hier ist, was laut LiteLLMs eigenem Sicherheitsupdate geschah: Am 24. März 2026 veröffentlichte ein Angreifer litellm==1.82.7 und litellm==1.82.8 auf PyPI, mit in die verteilten Wheels injiziertem Schadcode. Sie waren ab 10:39 UTC ungefähr 40 Minuten lang aktiv, bevor PyPI sie unter Quarantäne stellte. Die Kompromittierung wurde auf die Trivy-Abhängigkeit im CI/CD-Workflow von LiteLLM zur Sicherheitsprüfung zurückgeführt; der Angreifer umging den offiziellen Release-Workflow und lud die Pakete direkt auf PyPI hoch. Laut SecurityWeek waren mehr als 2.500 Organisationen betroffen.

LiteLLMs Maßnahmen zur Behebung sind dokumentiert und umfangreich: Kompromittierte Pakete wurden entfernt, Zugangsdaten der Maintainer rotiert, Mandiant für die forensische Untersuchung hinzugezogen und v1.83.0 über eine neu aufgebaute CI/CD-Pipeline mit isolierten Build-Umgebungen, strengeren Release-Gates und mit cosign signierten Docker-Images veröffentlicht. Wenn Sie Version 1.83.0 oder höher verwenden und während dieses 40-minütigen Zeitfensters keine manipulierte Version ausgeführt haben, ist der Vorfall für Sie abgeschlossen.

Der Grund, warum der Vorfall weiterhin Menschen zu dieser Suche führt, ist struktureller Natur und bezieht sich nicht speziell auf LiteLLM. Ein selbst gehosteter Proxy ist ein Paket in Ihrem Build, wodurch Ihr CI/CD-System und Ihr Cluster Teil seines Schadensradius werden. Das ist der Satz, über den man nachdenken sollte – er gilt gleichermaßen für jede selbst gehostete Alternative auf dieser Seite, einschließlich MLflow AI Gateway, und er beschreibt das eine, was ein gehosteter Endpunkt entfernt: Sie rufen eine HTTPS-URL auf, sodass es kein Paket zu vergiften gibt und nichts vom Gateway in Ihrem Netzwerk ausgeführt wird.

Die ehrliche andere Hälfte: Ein gehostetes Gateway ist nicht sicherer, sondern auf andere Weise exponiert. Ihr API-Schlüssel und Ihr Prompttext durchlaufen die Infrastruktur eines anderen Anbieters, und Sie übernehmen dessen Einbruchsrisiko anstelle Ihres eigenen Risikos durch erforderliche Patches. Wenn Prompttext Ihre Infrastruktur nicht verlassen darf, ist Self-Hosting die richtige Antwort, und beim Rest dieser Seite geht es um einen Kompromiss, den Sie nicht eingehen sollten.

1. Kunavo – kein Proxy, keine Providerkonten

Kunavo ist ein gehostetes Inference-Gateway: eine OpenAI-kompatible Basis-URL, ein sk-kn- Schlüssel, ein Pay-as-you-go-Guthaben, und wir verwalten die Zugangsdaten der Upstream-Provider an Ihrer Stelle. Im Vergleich zu LiteLLM bedeutet das eine andere Arbeitsteilung – Sie betreiben keinen Proxy und verwalten keine separaten Konten bei Anthropic, Google und OpenAI.

Preis: Der größte Teil des Katalogs liegt unter den offiziellen Tarifen der Provider – Claude Sonnet 4.6 bei $2,10 / $10,50 pro 1 Mio. Tokens gegenüber Anthropics Tarifen von $3,00 / $15,00. LiteLLM erhebt keinen Aufschlag, weil es nichts weiterverkauft; Ihre Kosten richten sich nach Ihrem eigenen Providervertrag. Der Vergleich lautet daher unser Tarif gegenüber Ihrem direkten Tarif, nicht gegenüber null. Abdeckung: Chat-, Bild-, Video- und Musikmodelle mit demselben Schlüssel und Guthaben. Was es nicht tut: Ihre eigenen Provider-Schlüssel routen – das ist die BYO-Schlüssel-Hälfte, die LiteLLM beibehält und die wir nicht ersetzen. Details: Kunavo vs LiteLLM.

2. OpenRouter – die längste Modellpalette

Das andere gehostete Inference-Gateway und die richtige Wahl, wenn die Katalogbreite wichtiger ist als der Stückpreis: Hunderte Modelle aus einer großen Auswahl an Providern mit einem einzigen Guthaben, dazu kostenlose Kontingente und Routing mit eigenen Schlüsseln, die Kunavo nicht anbietet. Wenn Sie LiteLLM verlassen, weil Sie keine Konten mehr verwalten möchten, sind OpenRouter und Kunavo die beiden realistischen Formen. Kunavo vs OpenRouter stellt beide direkt gegenüber, und die OpenRouter-Übersicht behandelt den Rest dieses Feldes.

3. Portkey – behalten Sie Ihre Schlüssel, geben Sie den Betriebsaufwand ab

Eine gehostete Control Plane über bereits vorhandene Providerkonten: Routing, Fallbacks, Guardrails und Observability, ohne einen eigenen Proxy betreiben zu müssen. Dies ist der naheliegendste Ersatz, wenn Sie LiteLLM wegen seiner Routing- und Budgetfunktionen gewählt haben und lediglich den Betrieb abgeben möchten. Details: Kunavo vs Portkey.

4. Helicone – wenn Observability der gesamte Grund war

Viele LiteLLM-Deployments existieren, weil jemand Request-Logs und eine teambezogene Kostenzuordnung benötigte und der Proxy der Weg dorthin war. Wenn das auf Ihr Deployment zutrifft, ist eine Observability-Schicht über Ihren bestehenden Provideraufrufen deutlich kleiner zu betreiben als ein Gateway. Details: Kunavo vs Helicone.

5. TrueFoundry – wenn der Einkauf einen Anbieter benötigt

Belegt in dieser Suche mit seinem eigenen LiteLLM-Vergleich Platz 2. Es ist ein Enterprise-KI-Gateway, das mit Latenz-Overhead, Deployment-Flexibilität, SLAs, Governance und revisionssicheren Kontrollen vermarktet wird (seine Produktseite). Wir haben es nicht bewertet, daher ist dieser Eintrag ein Verweis und keine Empfehlung: Wenn Ihr Hindernis darin besteht, dass ein Open-Source-Proxy keinen Supportvertrag bietet, ist dies die Kategorie, die das Problem löst. Der Vergleich ist lesenswert, sofern Sie berücksichtigen, dass er vom Anbieter selbst verfasst wurde.

6. MLflow AI Gateway – der vergleichbare Open-Source-Austausch

Platz 3 und auf dieser Seite das, was LiteLLM selbst am nächsten kommt: ein Open-Source-Gateway, das selbst gehostet wird und Ihre eigenen Provider-Schlüssel vorlagert, als Teil des MLflow-Projekts gepflegt. Es sollte klar benannt werden: Wenn Sie einen selbst gehosteten Proxy durch einen anderen ersetzen, behalten Sie das Deployment-Modell und damit auch die oben beschriebene Angriffsfläche. Das ist eine legitime Entscheidung – sinnvoll, wenn Ihnen das Projekt und nicht das Modell missfallen hat.

7. Cloudflare AI Gateway – Caching und Limits am Edge

Ein schlanker Proxy vor bereits vorhandenen Providerkonten: Antwort-Caching, Ratenbegrenzung, Wiederholungen und Analysen, ohne Inference weiterzuverkaufen. Es lässt sich mit jeder Inference-Quelle kombinieren, statt eine zu ersetzen, einschließlich Kunavo oder OpenRouter. Details: Kunavo vs Cloudflare AI Gateway.

Wann LiteLLM weiterhin die richtige Wahl ist

• Prompttext darf Ihre Infrastruktur nicht verlassen. Regulierte Daten, Air-Gap-Umgebungen oder eine Richtlinie, die ein gehostetes Gateway schlicht nicht erfüllen kann. Self-Hosting ist die Antwort; die einzige Frage ist, welchen selbst gehosteten Proxy Sie wählen.
• Sie haben Providerverträge ausgehandelt. Vertraglich zugesagte Abnahmen oder Enterprise-Tarife bei Anthropic, OpenAI oder Google sind mehr wert als alles, was ein Wiederverkäufer anbietet, und BYO-Schlüssel-Tools ermöglichen Ihnen, diese Verträge weiter zu nutzen.
• Sie verwenden Budgets pro Schlüssel und Team-Routing. Diese Funktionen sind der Grund, warum viele LiteLLM-Deployments existieren. Prüfen Sie, ob Ihr Ersatz sie abdeckt, bevor Sie annehmen, dass der Austausch der Basis-URL die gesamte Migration ist.
• Sie möchten Quellcode, den Sie lesen und anpassen können. Ein Open-Source-Proxy unter Ihrer Kontrolle ist eine echte Eigenschaft, und der Vorfall im März 2026 nimmt sie nicht weg – es war eine inzwischen behobene Kompromittierung der Release-Pipeline, kein Fehler im Proxy selbst.

Der Wechsel dauert zwei Zeilen

Jede hier aufgeführte Alternative, die Inference weiterverkauft, spricht das OpenAI-Wire-Protokoll. Daher ist der Wechsel von einem LiteLLM-Proxy ein base_url- und Schlüssel-Austausch – die Formen von Anfrage und Antwort bleiben unverändert:

# Before: your own LiteLLM proxy, your own provider keys,
# your own container to patch.
client = OpenAI(
    api_key=os.environ["LITELLM_MASTER_KEY"],
    base_url="http://litellm.internal:4000",
)

# After: a hosted endpoint. No package in your build, no proxy to run.
client = OpenAI(
    api_key=os.environ["KUNAVO_API_KEY"],
    base_url="https://api.kunavo.com/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-5",
    messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)

Der Teil, der nicht in zwei Zeilen erledigt ist, betrifft alles, was LiteLLM über das Routing hinaus getan hat: Budgets pro Schlüssel, Team-Verteilung und benutzerdefinierte Callbacks. Erfassen Sie diese Punkte zuerst. Die Details auf Wire-Ebene stehen im Leitfaden zur OpenAI-kompatiblen API, und was ein Gateway für Sie übernehmen sollte behandelt den Funktionsumfang, anhand dessen Sie einen Ersatz prüfen sollten.

Häufig gestellte Fragen