Die Auswahl eines AI-API-Gateways ist heute nicht mehr dasselbe Problem wie vor zwei Jahren. Im Jahr 2024 riefen die meisten Entwickler entweder OpenAI direkt an oder betrieben LiteLLM lokal. Jetzt gibt es gehostete Optionen mit Preisdashboards, kreditbasierten Limits pro Schlüssel und Modellkatalogen, die Dutzende Anbieter umfassen. Die Kategorie ist so weit gewachsen, dass eine falsche Wahl bedeutet, später echte Integrationsarbeit rückgängig machen zu müssen.
Dieser Artikel vergleicht vier Gateways, die in Entwicklerdiskussionen wiederholt auftauchen: CometAPI, Portkey, LiteLLM und Cloudflare AI Gateway. Ziel ist nicht, einen Sieger zu küren — jedes passt zu einer anderen Situation — sondern darzulegen, was jedes tatsächlich leistet, damit Sie das Werkzeug Ihrem Anwendungsfall zuordnen können.
Hinweis zu Modellnamen: Die in diesem Artikel verwendeten Modellkennungen (wie
gpt-5.4,claude-opus-4-7) sind Plattformkennungen von CometAPI. Es sind keine offiziellen Namen von OpenAI oder Anthropic, deren eigene Namenskonventionen abweichen.
Was diese Tools tatsächlich tun
Bevor man Funktionen vergleicht, hilft es, präzise zu sein, was ein AI-API-Gateway tut. Mindestens: Es sitzt zwischen Ihrer Anwendung und einem oder mehreren AI-Anbietern, leitet Anfragen weiter und gibt Antworten zurück. Darüber hinaus divergieren Gateways deutlich.
Einige Gateways — etwa Cloudflare AI Gateway — sind primär eine Pass-Through-Schicht, die Logging und Caching hinzufügt, ohne Ihren API-Schlüssel oder die Preisgestaltung anzutasten. Andere, wie CometAPI, agieren als Reseller: Sie bezahlen sie, sie bezahlen den zugrunde liegenden Anbieter, und die Preisdifferenz ist Teil des Wertversprechens. LiteLLM ist wiederum anders — es ist Software, die Sie selbst betreiben, kein gehosteter Dienst.
Diese Unterscheidung zu verstehen, ist wichtig, bevor Sie eine bestimmte Funktion bewerten.
Funktionsvergleich
Die folgende Tabelle nutzt Informationen aus der offiziellen Dokumentation oder den öffentlich zugänglichen Dashboards der jeweiligen Produkte mit Stand Mai 2026. Funktionen, die mit einem Gedankenstrich (—) gekennzeichnet sind, waren zum Zeitpunkt der Erstellung in offiziellen Quellen nicht bestätigt.
| Funktion | CometAPI | Portkey | LiteLLM | Cloudflare AI Gateway |
|---|---|---|---|---|
| Bereitstellung | Gehostet (SaaS) | Gehostet + Self-Host | Self-Hosted (Open Source) | Gehostet (Cloudflare Edge) |
| Modellkatalog | 500+ Modelle über Anbieter hinweg | 1.600+ LLMs über einheitliche API | Abhängig von Ihrer Konfiguration | OpenAI, Anthropic, Workers AI |
| Preismodell | Reseller (Bezahlung an CometAPI) | Durchleitung + Plattformgebühr | Nur Infrastrukturkosten | Durchleitung (kostenlose Stufe verfügbar) |
| OpenAI-kompatible API | Ja (api.cometapi.com/v1) | Ja (api.portkey.ai/v1) | Ja (lokal oder remote) | Ja (über Gateway-URL) |
| Kreditlimits pro Schlüssel | Ja (Dashboard) | Ja | Ja (per Konfiguration) | — |
| Gruppenbasierte Preisverhältnisse | Ja (0.8x Standard, 0.1x intern) | — | — | — |
| Anfrageprotokollierung | Ja (4 Log-Typen) | Ja | Ja | Ja |
| Erfolgsratenüberwachung | Ja (30-Tage-Uptime-Ansicht) | Ja | Ja | Ja |
| Kostenlose Stufe | Ja (neue Konten) | Ja | Open Source (Infrastrukturkosten) | Ja |
| Self-Hosting-Option | Nein (Enterprise: dedizierter Server) | Ja | Ja (Kernanwendungsfall) | Nein |
Quellen: CometAPI Dashboard, Portkey Homepage, LiteLLM GitHub, Cloudflare AI Gateway Dokumentation
Verbindung mit jedem Gateway
Alle vier Gateways stellen einen OpenAI-kompatiblen Endpunkt bereit, was bedeutet, dass für alle dieselbe Client-Struktur funktioniert — Sie ändern die base_url, die Zugangsdaten und bei Portkey die Art, wie Sie das Modell angeben.
Python
import osfrom openai import OpenAIdef require_env(name: str) -> str: """Raise a clear error if a required environment variable is missing.""" val = os.environ.get(name) if not val: raise ValueError(f"Missing required environment variable: {name}") return val# ── CometAPI ────────────────────────────────────────────────────────────────# Hosted reseller with 500+ models. Use CometAPI model identifiers (e.g. "gpt-5.4").cometapi_client = OpenAI( base_url="https://api.cometapi.com/v1", api_key=require_env("COMETAPI_KEY"),)# ── Portkey ─────────────────────────────────────────────────────────────────# Hosted gateway with observability and 1,600+ LLMs.# Route to a provider by prefixing the model name: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet", etc.# x-portkey-api-key is required; it authenticates requests to Portkey's gateway.portkey_client = OpenAI( base_url="https://api.portkey.ai/v1", api_key=require_env("PORTKEY_API_KEY"), default_headers={ "x-portkey-api-key": require_env("PORTKEY_API_KEY"), },)# ── LiteLLM ──────────────────────────────────────────────────────────────────# Self-hosted proxy. Provider credentials (OPENAI_API_KEY etc.) are set server-side.# By default the proxy does not validate the client API key — "anything" works.# If you have enabled virtual keys on your LiteLLM instance, pass a virtual key instead.litellm_client = OpenAI( base_url=os.environ.get("LITELLM_BASE_URL", "http://localhost:4000"), api_key=os.environ.get("LITELLM_API_KEY", "anything"),)# ── Cloudflare AI Gateway ───────────────────────────────────────────────────# URL-based pass-through. Keep your real provider API key — Cloudflare does not replace it.cf_account_id = require_env("CF_ACCOUNT_ID")cf_gateway_id = require_env("CF_GATEWAY_ID")cloudflare_client = OpenAI( base_url=( f"https://gateway.ai.cloudflare.com/v1" f"/{cf_account_id}/{cf_gateway_id}/openai" ), api_key=require_env("OPENAI_API_KEY"),)def ask(client: OpenAI, model: str, question: str) -> str: """ Minimal wrapper showing the common call pattern across all four gateways. Model format varies by gateway: CometAPI: "gpt-5.4", "claude-opus-4-7", etc. (CometAPI identifiers) Portkey: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet", etc. LiteLLM: whatever model names you configured in your proxy Cloudflare: standard OpenAI model names, e.g. "gpt-4o" This function does not handle finish_reason, tool_calls, or provider errors. For production error handling, see: How to Debug Failed AI API Generations. """ response = client.chat.completions.create( model=model, messages=[{"role": "user", "content": question}], ) return response.choices[0].message.content or ""
Node.js
import OpenAI from "openai";function requireEnv(name) { const val = process.env[name]; if (!val) throw new Error(`Missing required environment variable: ${name}`); return val;}// ── CometAPI ────────────────────────────────────────────────────────────────const cometClient = new OpenAI({ baseURL: "https://api.cometapi.com/v1", apiKey: requireEnv("COMETAPI_KEY"),});// ── Portkey ─────────────────────────────────────────────────────────────────// Route to a provider by prefixing the model: "@openai/gpt-4o", "@anthropic/claude-3-5-sonnet"const portkeyClient = new OpenAI({ baseURL: "https://api.portkey.ai/v1", apiKey: requireEnv("PORTKEY_API_KEY"), defaultHeaders: { "x-portkey-api-key": requireEnv("PORTKEY_API_KEY"), },});// ── LiteLLM ──────────────────────────────────────────────────────────────────// Self-hosted. Default mode accepts any API key value.// Set LITELLM_BASE_URL if your server runs on a different host or port.const litellmClient = new OpenAI({ baseURL: process.env.LITELLM_BASE_URL ?? "http://localhost:4000", apiKey: process.env.LITELLM_API_KEY ?? "anything",});// ── Cloudflare AI Gateway ───────────────────────────────────────────────────const cfClient = new OpenAI({ baseURL: `https://gateway.ai.cloudflare.com/v1/${requireEnv("CF_ACCOUNT_ID")}/${requireEnv("CF_GATEWAY_ID")}/openai`, apiKey: requireEnv("OPENAI_API_KEY"),});/** * Minimal wrapper showing the common call pattern. * Model format varies by gateway — see Python example above for details. * Does not handle finish_reason or error recovery; add those for production use. */async function ask(client, model, question) { const response = await client.chat.completions.create({ model, messages: [{ role: "user", content: question }], }); return response.choices[0].message.content ?? "";}
Das Verbindungsprinzip ist bei allen vier gleich. Die wesentlichen Unterschiede zeigen sich an anderer Stelle: was Sie beobachten können, was Sie steuern können und was passiert, wenn etwas schiefgeht.
Worin jedes Tool tatsächlich gut ist
CometAPI
Das Hauptangebot von CometAPI ist ein gehosteter Katalog mit über 500 Modellendpunkten, einschließlich Bild- und Video-Generierungsmodellen neben Textmodellen. Die Preisgestaltung erfolgt über ein gruppenbasiertes Verhältnis-System — die Standardgruppe wendet einen 0.8x-Multiplikator auf die Basispreise von CometAPI an. Sie können unterschiedliche Verhältnisgruppen für die interne Nutzung (0.1x) gegenüber zahlenden Kunden konfigurieren, was es praktikabel macht, ein gestuftes Produkt aufzubauen, ohne separate Konten zu verwalten.
Das Dashboard bietet vier Arten von Logs (Standard-API-Aufrufe, Bildgenerierung, Videogenerierung, Midjourney), eine 30-Tage-Uptime-Ansicht und kreditbasierte Limits pro Schlüssel. Kreditlimits ermöglichen es Ihnen, API-Schlüssel an Kunden oder Auftragnehmer auszugeben, mit einer harten Ausgabedeckelung — das löst ein reales Problem, wenn Sie Zugriff auf ein gemeinsames Konto verteilen.
Was CometAPI nicht bietet: Self-Hosting (Enterprise-Kunden können einen dedizierten Server anfragen, dies ist jedoch keine standardmäßige Self-Hosting-Option), Rate Limiting auf Gateway-Ebene oder SSO.
Best fit: Indie-Entwickler und kleine Teams, die über ein einziges API-Schlüssel und eine einzige Abrechnungsbeziehung auf viele Modelle — einschließlich Bild und Video — routen möchten und pro Schlüssel Budgetkontrollen benötigen.
Portkey
Portkey ist ein gehostetes Gateway, das um Observability herum gebaut ist. Es bietet Zugriff auf 1.600+ LLMs über eine einheitliche API, wobei das Routing durch Präfixe im Modellnamen mit dem Anbieter erfolgt (@openai/gpt-4o, @anthropic/claude-3-5-sonnet). Das bedeutet, Sie benötigen keine separaten Client-Konfigurationen für jeden Anbieter — ein Portkey-Client deckt alle ab, und Sie tauschen nur den Modell-String.
Über das Routing hinaus bietet Portkey Request Tracing, Prompt-Versionierung und Fallback-Routing, das Sie im Dashboard statt im Code konfigurieren. Die Self-Hosting-Option bedeutet, dass Sie Portkey auf Ihrer eigenen Infrastruktur betreiben können, wenn dies aus Compliance-Gründen erforderlich ist.
Das GitHub-Repository für Portkeys Open-Source-Gateway wird aktiv gepflegt — prüfen Sie die aktuelle Sternanzahl direkt, statt sich auf hier angegebene Zahlen zu verlassen, da sie sich häufig ändern.
Best fit: Teams, die Audit Trails benötigen, Multi-Provider-Routing aus einer einzigen Client-Konfiguration heraus oder die die API-Schlüssel-Exposition über Entwickler hinweg verwalten möchten.
LiteLLM
LiteLLM ist ein Python-Paket und Proxy-Server, kein gehosteter Dienst. Sie betreiben es selbst. Dies ist eine wesentliche Unterscheidung: Es gibt keine Drittpartei, die Ihre Anfragen verarbeitet oder Ihre API-Schlüssel hält. Anbieter-Credentials (Ihr echter OpenAI-Schlüssel, Anthropic-Schlüssel usw.) werden als Server-seitige Umgebungsvariablen gesetzt; der Client zeigt lediglich auf den lokalen Proxy.
Standardmäßig validiert LiteLLM den vom Client gesendeten API-Schlüssel nicht — jeder Wert funktioniert. Wenn Sie das Management virtueller Schlüssel aktivieren, übermitteln Clients virtuelle Schlüssel, die LiteLLM gegen seine eigene Datenbank validiert. In jedem Fall übersetzt der Proxy Anfragen im OpenAI-Format in das Format, das der Upstream-Anbieter erwartet, sodass sich Ihr Anwendungscode nicht verändert, wenn Sie einen neuen Anbieter hinzufügen.
Der Trade-off ist betrieblicher Aufwand: Sie sind für Betrieb, Skalierung und Aktualisierung des Servers verantwortlich.
Best fit: Teams mit DevOps-Kapazität, Organisationen mit Compliance-Anforderungen, die Drittanbieter-API-Proxys verbieten, oder alle, die Cross-Provider-Routing wollen, ohne den Anfrageinhalt einem SaaS-Anbieter anzuvertrauen.
Cloudflare AI Gateway
Cloudflare AI Gateway ist strukturell anders als die anderen drei. Sie ändern Ihren API-Schlüssel nicht und bezahlen Cloudflare nicht für den Modellzugang. Stattdessen ersetzen Sie die Basis-URL des Anbieters durch eine Cloudflare-gemanagte URL, die Logging, Caching und Rate Limiting am Edge hinzufügt.
Da Cloudflare zwischen Ihrer Anwendung und dem Anbieter sitzt, kann es identische Anfragen cachen — nützlich, wenn Ihre Anwendung dieselben Prompts wiederholt sendet. Die kostenlose Stufe deckt die meisten Indie-Entwickler-Anwendungsfälle ab. Die Einschränkung ist der Umfang: Cloudflare aggregiert keine Modelle über Anbieter hinweg. Sie benötigen weiterhin separate Anbieter-Konten und -Schlüssel für jeden verwendeten Anbieter.
Best fit: Entwickler, die bereits auf Cloudflares Infrastruktur sind, oder alle, die Caching und Logging zusätzlich zu bestehenden Anbieter-Konten möchten, ohne eine neue Abrechnungsbeziehung einzuführen oder API-Schlüssel zu ändern.
Szenarioabgleich
| Szenario | Empfohlenes Tool | Begründung |
|---|---|---|
| Indie-App, möchte mit einem API-Schlüssel 10+ Modelle testen | CometAPI | Breiter Katalog, einfache Einrichtung, Kreditlimits pro Schlüssel |
| Bild- + Videoerzeugung in derselben Integration | CometAPI | Vereinheitlichter Endpunkt für Text-, Bild- und Videomodelle |
| Team von 5, möchte verfolgen, wer welches Modell nutzt | Portkey | Request Tracing, Team-Management |
| Routing zu 1.600+ LLMs mit einer Client-Konfiguration | Portkey | @provider/model-Routing, keine Einrichtung pro Anbieter |
| Fallback-Routing über Anbieter ohne Codeänderungen | Portkey | Deklarative Fallback-Konfiguration im Dashboard |
| Enterprise mit Datenresidenz-Anforderungen | LiteLLM (Self-Hosted) | Keine Drittpartei verarbeitet den Traffic |
| Budget ist null, wohl mit Selbstverwaltung | LiteLLM | Open Source, keine Plattformkosten |
| Bereits direkte OpenAI-Nutzung, möchten Caching | Cloudflare AI Gateway | Nur URL-Tausch, keine neue Abrechnungsbeziehung |
| RBAC für mehrere Teams benötigt | Portkey oder LiteLLM | Beide haben Team-/Rollen-Management; CometAPI und Cloudflare nicht |
Was diese vier nicht abdecken
Dieser Vergleich deckt Gateways ab, die in Indie-Entwicklerdiskussionen am häufigsten erscheinen. Der Markt umfasst weitere erwähnenswerte Optionen: Helicone konzentriert sich auf Observability, ohne als Proxy zu agieren, OpenRouter spezialisiert sich auf Routing zu Open-Weight- und Forschungsmodellen, und AWS Bedrock ist Amazons verwalteter AI-Dienst, der auf Enterprise-Workloads ausgerichtet ist. Wenn Ihre Anforderungen zu keinem der vier oben passen, sind dies die nächsten Anlaufstellen.
Der Wechsel
Wenn Sie derzeit einen Anbieter direkt anrufen und ein Gateway in Betracht ziehen, ist die Codeänderung klein. Für CometAPI fügen Sie eine Umgebungsvariable hinzu und ändern die base_url. Für Portkey fügen Sie einen Header hinzu und ändern die Art, wie Sie das Modell angeben (@openai/gpt-4o statt gpt-4o). Für Cloudflare ändern Sie die URL, ohne Ihren Anbieter-API-Schlüssel anzutasten. Für LiteLLM betreiben Sie zunächst einen lokalen Server und richten dann Ihren Client darauf aus.
Die größere Frage ist nicht, wie man den Wechsel vollzieht, sondern ob man ihn braucht. Wenn Sie einen einzelnen Anbieter anrufen, keine Probleme mit Kostentransparenz haben und kein Cross-Modell-Routing benötigen, fügt ein Gateway Komplexität ohne Nutzen hinzu. Wenn Sie mehrere Anbieter ansteuern, Schlüssel an Auftragnehmer verteilen oder feststellen, dass unerwartete Rechnungen ein wiederkehrendes Problem sind, lohnt sich der Integrationsaufwand.
FAQ
Kann ich diese Gateways zusammen verwenden?
Ja. Manche Teams betreiben LiteLLM selbst für sensible Workloads und CometAPI für alles andere. Cloudflare AI Gateway kann vor CometAPI-Anfragen sitzen, wenn Sie Cloudflares Caching-Schicht darüber möchten — dies fügt jedoch einen Netzwerk-Hop hinzu.
Speichern diese Gateways meine Prompts?
Kommt auf das Tool und Ihre Konfiguration an. Portkey und CometAPI loggen Anfragen standardmäßig; beide haben Aufbewahrungseinstellungen. LiteLLM speichert nur, was Sie konfigurieren — auf Ihrer eigenen Infrastruktur. Cloudflares Logging-Verhalten ist in deren AI-Gateway-Dokumentation beschrieben. Lesen Sie die Datenschutzbedingungen für jeden gehosteten Dienst, bevor Sie sensible Inhalte darüber senden.
Was passiert, wenn das Gateway ausfällt?
Bei gehosteten Gateways (CometAPI, Portkey, Cloudflare) bedeutet Gateway-Ausfall, dass Ihre Anwendung den AI-Anbieter über diesen Pfad nicht erreichen kann. Lokal laufendes LiteLLM hat die gleichen Verfügbarkeitsmerkmale wie Ihr eigener Server. Prüfen Sie vor dem Einsatz eines gehosteten Gateways in der Produktion dessen SLA und ob es einen Direktanbieter-Fallback bietet, falls das Gateway selbst nicht verfügbar ist.
Gibt es eine kostenlose Möglichkeit, jedes vorab zu evaluieren?
Ja. CometAPI und Portkey haben kostenlose Stufen. LiteLLM ist Open Source und kostet nur die Infrastruktur, auf der Sie es betreiben. Cloudflare AI Gateway ist innerhalb großzügiger Limits kostenlos. Sie können alle vier mit denselben Test-Prompts ausprobieren, bevor Sie eine Entscheidung treffen.
Wie wähle ich die richtigen Modellnamen für jedes Gateway?
Jedes Gateway hat seine eigene Konvention. CometAPI nutzt eigene Kennungen (gpt-5.4, claude-opus-4-7). Portkey nutzt das Format @provider/modellname (@openai/gpt-4o, @anthropic/claude-3-5-sonnet). LiteLLM nutzt die Modellnamen, die Sie in Ihrer Proxy-Konfiguration definieren. Cloudflare lässt Standard-Modellnamen der Anbieter unverändert durch. Prüfen Sie vor dem Schreiben von Code die aktuelle Modellsammlung in der Dokumentation des jeweiligen Gateways.
Beeinflusst der Wechsel des Gateways meine bestehenden Rate Limits?
Ja. Wenn Sie von direkten OpenAI-Aufrufen zu einem Gateway wechseln, das die Anbieterbeziehung verwaltet (wie CometAPI), werden Ihre effektiven Rate Limits durch das Konto des Gateways bei OpenAI bestimmt, nicht durch Ihr persönliches Konto. Verifizieren Sie das Verhalten der Rate Limits mit dem Gateway, bevor Sie Produktivtraffic migrieren.