KI-Gateways: LiteLLM, OpenRouter, Portkey, Vercel

Fortgeschritten

Sobald dein Produkt mit mehr als einem Modell spricht, bricht der Direkt-SDK-Ansatz. Jeder Anbieter hat seinen eigenen Key, seine eigenen Rate-Limits, seinen eigenen Ausfallplan und seine eigene Rechnung. Ein KI-Gateway ist das kleine Stück Infrastruktur, das zwischen deinem Code und jedem Modell sitzt — Claude, GPT, Gemini, Llama, Kimi, DeepSeek, dein lokales Ollama — und aus „N brüchigen Integrationen“ „einen Endpoint, den du kontrollierst“ macht. Diese Seite vergleicht die vier Gateways, die 2026 tatsächlich in Produktion deployed werden — LiteLLM, OpenRouter, Portkey und Vercel AI Gateway — und zeigt den Killer-Workflow: richte Claude Code auf deinen eigenen Gateway aus, sodass ein einziger Proxy Routing, Budgets, Logging und Fallback für das ganze Team abwickelt.

What you'll learn

Verstehen, was ein KI-Gateway ist und welche fünf Probleme es löst (viele Anbieter, eine API; Fallback; Virtual Keys; Spend Caps; Observability)
LiteLLM, OpenRouter, Portkey und Vercel AI Gateway nach Latenz, Preismodell, Self-Hostability und Stärken vergleichen
Claude Code über deinen eigenen LiteLLM-Proxy mit ANTHROPIC_BASE_URL und einem Virtual Key verkabeln, sodass das Team geteilte Limits und Logs bekommt
OpenRouter-Fallback konfigurieren, damit ein Claude-Ausfall still auf GPT oder Gemini befördert wird, statt Usern einen 5xx zu zeigen
Den LiteLLM-Supply-Chain-Vorfall vom März 2026 verstehen und wissen, wie man Versionen in Produktion sicher pinnt

Das Problem: ein direkter SDK pro Anbieter skaliert nicht

Die erste Claude-Integration ist eine Zweizeilen-Änderung: pip install anthropic, ANTHROPIC_API_KEY setzen, fertig. Die zweite — sagen wir, du willst auf GPT-5.4 zurückfallen, wenn Anthropic drosselt — ist der Punkt, an dem die Abstraktion bricht. Jetzt hast du zwei SDKs mit unterschiedlichen Request-Formen, zwei Dashboards, zwei Rechnungen, zwei Rotations-Kadenzen für API-Keys und zwei Sätze Retry-Logik. Füge einen dritten für Gemini hinzu und einen vierten für dein lokales Ollama, und jede Produktentscheidung („diesem Team auf 500 $/Monat begrenzen“, „jeden Prompt zur Review loggen“, „einem Kunden erlauben, den eigenen Key mitzubringen“) wird zu N Implementierungen statt einer.

Ein KI-Gateway konzentriert diese Verrohrung an einem Ort. Konkret gibt dir ein Produktions-Gateway:

Eine Request-Form für jeden Anbieter. Die meisten Gateways sprechen die OpenAI-Chat-Completions-API (oder Anthropic Messages oder beide) und übersetzen darunter zum echten Anbieter.
Fallback und Routing. Erst Claude versuchen; bei 429 oder 5xx gegen GPT oder Gemini erneut versuchen, ohne dass der Aufrufer es weiß. Gleiches für Latenz-Obergrenzen und Content-Moderation-Ablehnungen.
Virtual Keys. Vergib einen pro-User- oder pro-Service-Key, der auf eine Teilmenge von Modellen mit eigenem Budget und eigenem Rate-Limit gemappt ist — sodass ein Rogue-Script nicht den ganzen Account leerzieht.
Spend Caps und Logging. Jede Anfrage wird getaggt, gepreist und gespeichert. Du kannst einen Key widerrufen, ohne Anthropic oder OpenAI anzufassen, und Compliance nachweisen, was wohin gesendet wurde.
Caching. Prompt-Caching (Exact-Match) und Semantic-Caching (Near-Match) machen aus Wiederholungsverkehr freie Treffer.

Nicht jedes Team braucht alle fünf. Aber sobald zwei davon auf deiner Roadmap stehen, ist ein Gateway zu betreiben günstiger, als sie pro Anbieter neu zu erfinden.

Die vier Gateways, die in Produktion laufen

Es gibt keinen einzigen „Sieger“ — die vier Führenden besetzen unterschiedliche Ecken des Designraums (self-hosted vs. hosted, Open Source vs. proprietär, minimalistisch vs. Control-Panel).

Gateway	Deploy	Preismodell	Am besten für	Nicht für
LiteLLM	Self-hosted (Docker) oder SDK	Kostenlos (OSS); Enterprise-Tier für SSO/Audit	Team-Proxy mit Virtual Keys, Budgets, kein Per-Token-Markup, funktioniert mit 100+ Anbietern über eine Config	Teams ohne DevOps, um Postgres + Redis zu betreiben
OpenRouter	Nur hosted	Anbieterpreis + ca. 5,5 % Credit-Kauf-Gebühr, kein Per-Request-Markup	Zero-Ops-Zugriff auf 300+ Modelle unter einem Key; ideal für Produkte, die Usern die Modellauswahl lassen	Compliance-Shops, die Self-Hosting oder Data Residency brauchen
Portkey	OSS-Gateway (npx) oder Hosted-Cloud	OSS kostenlos; Cloud hat Nutzungsstufen	Sub-ms-Gateway-Latenz, Semantic-Caching, Guardrails, Canary-Testing — der „Control-Panel“-Blickwinkel	Teams, die nur den einfachsten möglichen Key-Aggregator wollen
Vercel AI Gateway	Nur hosted	Anbieterpreis, kein Token-Markup; kostenlos mit Vercel-Plänen	Devs, die schon auf Vercel sind und AI SDK v5/v6 + Anthropic Messages + OpenAI Responses APIs vereint wollen	Nicht-Vercel-Infrastruktur oder Air-Gapped-Deployments

Die wichtige Achse zuerst: self-hosted vs. hosted. Wenn deine Daten dein VPC nicht verlassen dürfen (regulierte Branchen, EU-Residency, Enterprise-Privacy-Reviews), brauchst du ein self-hostbares Gateway — LiteLLM oder Portkey OSS. Wenn du lieber jemand anderes dafür bezahlst, dass er es betreibt, ist OpenRouter oder Vercel AI Gateway eine Ein-Klick-Sache.

Die zweite Achse: wie viel Control Plane brauchst du wirklich? Wenn du ein Ein-Personen-Produkt bist, das einfach Kimi K3, Claude und Grok nebeneinander ohne drei Signups probieren will, ist OpenRouter die ganze Geschichte. Wenn du eine 20-Personen-Organisation bist, in der Finance monatliche Ausgaben pro Team will, Security Virtual Keys mit Rotation und Platform Grafana-Metriken, baust du auf LiteLLM oder Portkey.

Killer-Workflow: Claude Code auf deinen eigenen LiteLLM-Proxy zeigen

Das bestgehütete Geheimnis über Claude Code ist, dass es ANTHROPIC_BASE_URL und ANTHROPIC_AUTH_TOKEN respektiert. Setze sie auf dein Gateway, und Claude Code hört auf, direkt mit api.anthropic.com zu sprechen — es spricht mit deinem Proxy, der zu Anthropic (oder überall sonst) mit deiner Auth weiterleitet. Für ein Team ändert das drei Dinge auf einmal:

Ein geteilter Virtual Key pro Entwickler. Du vergibst und widerrufst Keys im Proxy-UI. Keine shared Root-Credentials in .env-Dateien.
Per-Entwickler-Budgets und -Logs. Der Proxy taggt jede Anfrage, sodass „wer hat gestern 300 $ ausgegeben“ eine Datenbankabfrage ist, kein Incident.
Modell-Aliasing. Du kannst claude-sonnet-4-6 am Proxy fest verdrahten, sodass eine Modell-Deprecation eine Einzeiler-Config-Änderung ist, kein repo-weites Grep.

Starte einen minimalen Proxy in drei Schritten:

Guided walkthrough1 of 3

In einem frischen venv oder via uv: uv tool install 'litellm[proxy]'. Das zieht den Gateway-Server (FastAPI + Admin-UI) neben dem Client-SDK herein.

Die Config-Datei, die das zum Laufen bringt:

config.yaml — Claude Sonnet/Opus/Haiku hinter LiteLLM

model_list:
- model_name: claude-opus-4-7
  litellm_params:
    model: anthropic/claude-opus-4-7
    api_key: os.environ/ANTHROPIC_API_KEY
- model_name: claude-sonnet-4-6
  litellm_params:
    model: anthropic/claude-sonnet-4-6
    api_key: os.environ/ANTHROPIC_API_KEY
- model_name: claude-haiku-4-5-20251001
  litellm_params:
    model: anthropic/claude-haiku-4-5-20251001
    api_key: os.environ/ANTHROPIC_API_KEY

litellm_settings:
master_key: os.environ/LITELLM_MASTER_KEY
# Optional: enable exact-match prompt caching
cache: true
cache_params:
  type: redis
  host: os.environ/REDIS_HOST

Dann, aus der Shell jedes Entwicklers:

Claude Code auf den Proxy zeigen (per-Entwickler-.env)

export ANTHROPIC_BASE_URL="https://llm.internal.example.com"
export ANTHROPIC_AUTH_TOKEN="sk-team-alice-9f4c..."   # a VIRTUAL key issued by the proxy

# now every Claude Code call goes through YOUR gateway
claude --model claude-sonnet-4-6

Der nicht offensichtliche Gewinn ist der Virtual Key. Der Master-Key ist Admin-only und landet nie auf Laptops. Jeder Entwickler bekommt einen Virtual Key, der auf nur die Modelle, die du erlaubst gemappt ist, sein eigenes monatliches Budget hat und in Sekunden widerrufbar ist, ohne den darunterliegenden Anthropic-Key zu rotieren. Wenn ein Laptop verloren geht, killst du eine Zeile in Postgres — nicht den Zugriff des gesamten Teams.

Vorsicht: Dieselben Env-Vars funktionieren mit Anthropics Bedrock- und Vertex-Integrationen, aber es gibt Randfälle mit experimentellen Beta-Features. Für Bedrock-Deployments empfiehlt die LiteLLM-Doku, CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 in ~/.claude/settings.json zu setzen, um Header-Kompatibilitätsprobleme zu vermeiden.

Killer-Workflow #2: stiller Fallback mit OpenRouter

Wenn du nichts hosten willst, ist OpenRouters Fallback-Array der kürzeste Pfad zu „still ein anderes Modell versuchen, wenn Claude 429 schickt“. Du sendest eine geordnete Liste; OpenRouter geht sie von oben nach unten durch und gibt das erste Modell zurück, das geantwortet hat.

Claude → GPT → Gemini-Fallback in einer Anfrage (OpenRouter)

import openai

client = openai.OpenAI(
  api_key="YOUR_OPENROUTER_KEY",
  base_url="https://openrouter.ai/api/v1",
)

response = client.chat.completions.create(
  model="anthropic/claude-sonnet-4.5",
  extra_body={
      # Ordered fallback. If the first model 429s, is down, or is
      # rejected by moderation, OpenRouter tries the next one.
      "models": [
          "anthropic/claude-sonnet-4.5",
          "openai/gpt-5.4",
          "google/gemini-2.5-pro",
      ],
  },
  messages=[{"role": "user", "content": "Explain B-trees in one paragraph."}],
)

# 'model' in the response tells you which one actually answered.
print(response.model, "->", response.choices[0].message.content)

Drei Dinge, die Leute beim ersten Versuch übersehen:

Die Abrechnung folgt dem Modell, das geantwortet hat, nicht dem, das du gefragt hast. Wenn Claude scheitert und GPT-5.4 antwortet, zahlst du für diese Anfrage OpenRouters GPT-5.4-Rate.
Der Fallback triggert bei mehr als 5xx. Rate-Limiting, Anbieter-Downtime, Context-Length-Validierungsfehler und Content-Moderation-Ablehnungen befördern alle zum nächsten Modell. Diese letzte ist die schärfste Kante — eine „Moderation“-Ablehnung von einem Anbieter kann still zu einem permissiveren routen, was du willst oder auch nicht. Prüfe deine Fallback-Liste mit der gleichen Sorgfalt wie eine ACL.
Du kannst models nicht mit fallbacks mischen. Der Anthropic-Format-Messages-Endpoint nutzt ein anderes fallbacks-Array. Beide Keys in derselben Anfrage zu senden liefert einen 400. Wähle das Format, das dein Client spricht, und bleibe dabei.

Der LiteLLM-Supply-Chain-Vorfall vom März 2026: was tatsächlich zu tun ist

Am 24. März 2026 um 10:39 UTC wurden zwei bösartige PyPI-Releases von LiteLLM — v1.82.7 und v1.82.8 — von einem Angreifer veröffentlicht, nachdem er die PyPI-Credentials des Maintainers über eine vorherige Kompromittierung von Trivy gestohlen hatte, einem Security-Scanner in LiteLLMs CI/CD-Pipeline. PyPI hat die Pakete um 13:38 UTC (etwa drei Stunden später) unter Quarantäne gestellt. Während des Expositionsfensters passierten Zehntausende Downloads. Die Payload war ein Infostealer mit einem Persistenzmechanismus (eine litellm_init.pth-Datei, die bei jedem Python-Aufruf lief, Credentials erntete und ein systemd-Backdoor installierte). Die Zuschreibung geht an eine Gruppe, die als TeamPCP getrackt wird und auch Trivy und Checkmarx KICS kompromittiert hat.

Wenn du LiteLLM in irgendeiner Umgebung betreibst, wende das einmal an und behalte es dann in deinem Platform-Playbook:

Guided walkthrough1 of 5

v1.82.6 und früher sind sauber. v1.83.0 und später (veröffentlicht über LiteLLMs neu gebaute CI/CD-v2-Pipeline) sind sauber. Alles dazwischen sollte deinstalliert und die Umgebung als kompromittiert betrachtet werden. Das offizielle Docker-Image (ghcr.io/berriai/litellm) war NICHT kompromittiert — der Vorfall war PyPI-only.

Die weitere Lektion ist nicht „nutze LiteLLM nicht“ — sie ist „nimm an, dass jede Abhängigkeit in deinem KI-Stack, inklusive Security-Scanner, ein Auslieferungsvektor sein kann.“ Pinne Versionen, signiere Images und stelle dein Gateway auf ein Netzwerksegment, das nur die Modell-Anbieter erreicht.

Wähle das richtige Gateway für deine Situation

Guided walkthrough1 of 5

Ein oder zwei Anbieter mit einem kleinen Team → das Gateway überspringen; direkte SDKs sind okay. Drei+ Anbieter ODER ein Team, wo ‚wer hat den Key' zählt → Gateway. Wenn du DevOps und Datenschutzanforderungen hast, self-host LiteLLM oder Portkey OSS. Wenn du es lieber jemand anderem überlässt, OpenRouter (hosted-only) oder Vercel AI Gateway (super, wenn du eh dort deployst).

Gängige Kombinationen, die in Produktion laufen:

Solo-Dev / Prototyp: OpenRouter direkt. Ein Key, 300+ Modelle, fertig.
Kleines Team, Claude-first: LiteLLM-Proxy mit Anthropic + einem Fallback-Anbieter, Virtual Keys pro Ingenieur, Redis-Prompt-Caching.
Vercel-natives Produkt: Vercel AI Gateway mit dem AI SDK; füge OpenRouter als provider-options-Fallback für exotische Modelle hinzu.
Reguliert / EU: Self-hosted LiteLLM oder Portkey OSS in-VPC mit Presidio-PII-Masking davor (siehe Claude + lokale Modelle für das Redaction-Muster).
KI-Produkt mit heavy Repeat-Traffic: Portkey (Semantic-Caching treibt bei Chat-Style-Workloads üblicherweise 30–50 % Kostenreduktion, laut Portkeys eigenen Case Studies — auf deinem Traffic verifizieren, bevor du Schlagzeilenzahlen glaubst).

Was ein Gateway NICHT löst

Gateways sind Middleware — sie ändern, wie du Modelle erreichst, nicht welches Modell richtig ist. Zwei Dinge brauchen noch echte Arbeit:

Prompt-Portabilität. Claude, GPT und Gemini beantworten denselben Prompt unterschiedlich, und System-Prompt-Konventionen variieren. Ein Gateway schreibt deinen Prompt nicht für den Fallback-Anbieter um — dafür sind Prompts über Modelle portieren und Cross-AI-Übersetzung da.
Evals. Das Gateway macht es einfach, zwei Modelle auf derselben Anfrage A/B zu testen. Es kann dir nicht sagen, welches auf DEINER Task tatsächlich besser war. Führe eine echte Eval durch (siehe Evals), bevor du Defaults wechselst.

Ein häufiger Fehler ist, ein Gateway zu installieren und „multi-model“ für erledigt zu halten. Das Gateway ist die Transport-Schicht; Portabilität und Evals sind die Produkt-Schicht.

Selbstcheck

0/5

Was ist der primäre Grund, ein KI-Gateway zwischen deine App und die Modell-Anbieter zu stellen, sobald du mehr als zwei nutzt?
Du richtest Claude Code über ANTHROPIC_BASE_URL auf einen LiteLLM-Proxy. Was muss ANTHROPIC_AUTH_TOKEN sein?
OpenRouters Fallback-Array befördert zum nächsten Modell, wenn das erste scheitert. Bei welchem davon triggert es?
Du musst LiteLLM in Produktion installieren. Welche Versionen sind nach dem Vorfall im März 2026 sicher?
Du bist Solo-Dev auf Vercel und willst Claude, GPT und Gemini an einem Nachmittag probieren. Beste Wahl?

KI-Gateways auf einen Blick

Drücke Enter oder die Leertaste, um die Karte umzudrehen. Nutze die Pfeiltasten links und rechts, um zwischen den Karten zu wechseln.Begriff angezeigt.

1 / 9

Key takeaways

Ein KI-Gateway ist der fehlende Router zwischen deiner App und jedem Modell — es existiert, um Virtual Keys, Budgets, Fallback, Logging und Caching zu einer Implementierung statt N pro Anbieter zu machen
Wähle zuerst auf ZWEI Achsen: self-hosted vs. hosted (LiteLLM/Portkey OSS vs. OpenRouter/Vercel) und minimalistisch vs. Control-Panel (OpenRouter/Vercel vs. LiteLLM/Portkey)
Der Claude-Code-Killer-Workflow: richte ANTHROPIC_BASE_URL auf deinen eigenen LiteLLM-Proxy und vergib Per-Entwickler-Virtual-Keys — das Team bekommt geteilte Limits, Logs und Ein-Klick-Widerruf, ohne den Root-Anthropic-Key anzufassen
OpenRouters models[]-Array ist der kürzeste Pfad zu stillem Claude → GPT → Gemini-Fallback, aber beachte, dass Moderation-Ablehnungen ebenfalls Fallback-Trigger sind — prüfe die Liste wie eine ACL
Nach dem LiteLLM-Supply-Chain-Angriff vom März 2026 auf v1.82.6 oder früher oder v1.83.0+ pinnen; das signierte Docker-Image dem pip vorziehen; den Proxy per Egress-Allowlist absichern
Ein Gateway ist Transport, kein Produkt — Prompt-Portabilität und Evals brauchen weiter echte Arbeit, egal wie viele Modelle du jetzt erreichen kannst

Quellen & weiterführende Lektüre

LiteLLM — GitHub (BerriAI/litellm) — das Source-Repo und aktuelle Release Notes
LiteLLM Proxy — offizielle Docs — Install, config.yaml, Virtual Keys, Budgets
Claude Code über LiteLLM — offizieller Quickstart — ANTHROPIC_BASE_URL-Setup, Verification-curl, Security Notes
LiteLLM-Anthropic-Provider-Docs — unterstützte Claude-Modelle und Optionen
Security Update: Suspected Supply Chain Incident (March 2026) — LiteLLM Blog — offizieller Incident-Post, Safe-Version-Guidance, Remediation
Incident Report: LiteLLM/Telnyx-Supply-Chain-Angriffe — PyPI-Blog — PyPIs Timeline und Mitigationen
LiteLLM compromised on PyPI — Datadog Security Labs — Malware-Analyse (litellm_init.pth, Egress-Domains)
OpenRouter — Model-Fallbacks-Dokumentation — das models[]-Array, Trigger, Abrechnungsregeln
OpenRouter — Provider Preferences — fortgeschrittene Routing-Steuerung
Portkey AI Gateway — offizielle Docs — Semantic-Caching, Guardrails, Canary
Portkey Gateway — GitHub (OSS) — self-hostbares Open-Source-Gateway
Vercel AI Gateway — offizielle Docs — Modelle, Anbieter, BYOK, Observability
Vercel AI Gateway — Anthropic-Messages-API-Kompatibilität — Nutzung des Anthropic-SDKs durch Vercel AI Gateway

Verwandt auf dieser Seite: Claude + lokale Modelle: Hybride Muster · Prompts über Modelle portieren · Cross-AI-Übersetzung · Evals · Was KI bei verschiedenen Anbietern kostet

Das Problem: ein direkter SDK pro Anbieter skaliert nicht​

Die vier Gateways, die in Produktion laufen​

Killer-Workflow: Claude Code auf deinen eigenen LiteLLM-Proxy zeigen​