Portkey: ein LLM-Gateway für die Produktion, geprüft auf Routing, Guardrails und Kosten

Portkey ist ein LLM-Gateway: ein Proxy zwischen einer Anwendung und den Modellanbietern, die sie aufruft, der Anbieterschlüssel, Retries, Fallbacks, Caching, Guardrails und Kostenattribution in Konfigurationsobjekte statt in Anwendungscode übersetzt. Es ist eines der vollständigsten Gateways am Markt, und seit Palo Alto Networks die Übernahme von Portkey im Mai 2026 abgeschlossen hat, liefert es zugleich als Gateway innerhalb von Prisma AIRS. Die Position: die Routing-Schicht ist die stärkste ihrer Klasse und die operative Abhängigkeit wert, während beim gehosteten Betrieb und bei der Guardrail-Semantik die caveats liegen.

Ersetzt wird der selbstgebaute Retry-Wrapper, den jedes Team im ersten Monat eines LLM-Produkts schreibt: meist ein try-Block mit Sleep, ein fest verdrahteter Anbieterschlüssel und keine Aufzeichnung der entstandenen Kosten. Portkey legt das hinter eine einzige OpenAI-kompatible Basis-URL, sodass OpenAI-SDK, Anthropic-SDK, LangChain oder ein roher fetch-Aufruf denselben Endpunkt sprechen. Der Wettbewerb sind LiteLLM, kostenlos und selbst gehostet, OpenRouter, ein bezahlter Marktplatz statt einer Control Plane, und Cloudflare AI Gateway, das fast nichts kostet, weil es auf Infrastruktur läuft, die die meisten Teams ohnehin bezahlen.

Was es ist

Portkey sind im Grunde zwei Produkte in einem Repository. Das Gateway selbst ist ein MIT-lizenzierter Node-Proxy, der mit einem Befehl startet und auf Port 8787 mit angeschlossener lokaler Konsole läuft; die Control Plane darum ist ein bezahlter Dienst, der Zugangsdaten speichert, die Konfigurationsoberfläche hostet und die Logs führt. Diese Trennung erklärt das meiste. Was der Proxy tut, ist gut dokumentiert und kostenlos, und was die Control Plane tut, ist der Ort, an dem Preis, Guardrail-Katalog und Compliance-Story liegen.

• Startet mit einem Befehl, npx @portkey-ai/gateway, läuft auf localhost:8787 mit einer Konsole unter /public/.
• MIT-lizenziert mit rund 13.100 GitHub-Sternen und 1.300 Forks; das veröffentlichte npm-Paket steht bei Version 1.15.2, ein 2.0-Pre-Release-Zweig ist in Arbeit.
• Ein OpenAI-kompatibler Endpunkt, dazu Anthropics /v1/messages und das Open-Responses-Format. Nur der Modell-String ändert sich, wenn der Anbieter es tut.
• Modell-Strings tragen den Anbieter mit: @openai-prod/gpt-4o löst auf eine gespeicherte Integration auf, samt Budget und Rate-Limit.
• Strategieobjekte verschachteln sich. Ein Fallback kann einen Load Balancer enthalten, der ein weiteres Fallback enthält, jedes mit eigenen Gewichten, Statuscode-Auslösern und Circuit Breaker.
• Guardrails prüfen Eingaben und Ausgaben, entweder asynchron ohne zusätzliche Latenz oder synchron mit dokumentierten Deny-Codes 246 und 446.
• Seit Mai 2026 im Besitz von Palo Alto Networks und als Prisma AIRS AI Gateway im Verkauf, allgemein verfügbar seit 16. Juli 2026.

Wie es funktioniert

Ein Request kommt mit Portkey-API-Key und meist einer Config an. Die Config benennt eine Strategie und eine Liste von Zielen. Das Gateway löst jedes Ziel auf eine gespeicherte Anbieter-Integration auf, wendet Caches und Guardrails nach Vorgabe der Config an, leitet an den gewählten Anbieter weiter und schreibt eine Log-Zeile mit Latenz, Token-Zahlen und Kosten. Der Unterschied zu einem selbstgebauten Proxy liegt nicht im Weiterleiten, sondern darin, dass die Entscheidung Daten sind: dasselbe JSON läuft unverändert im gehosteten Produkt, im Open-Source-Proxy und in einer selbst betriebenen Data Plane.

Der interessante Zweig ist der Guardrail. Läuft er asynchron, was der Standard ist, prüft er parallel zum Modellaufruf, das Ergebnis wird nur protokolliert, und der Statuscode des Anbieters kommt unverändert zurück. Läuft er synchron, blockiert die Prüfung: bei Bestehen 200, bei Fehlschlag 246, wenn deny aus ist, und 446, wenn es an ist. Beide Codes liegen außerhalb dessen, wofür eine Client-Bibliothek geschrieben wurde. Eine Bibliothek, die jeden Status außer 200 als Erfolg wertet, akzeptiert ein 246 stillschweigend, das eigentlich markiert werden sollte; eine, die alles außerhalb von 2xx als Ausnahme behandelt, wirft bei 446 und wiederholt es, als wäre das Netzwerk ausgefallen. Das ist die schärfste Kante im Produkt.

Die andere Hälfte ist das Config-Objekt. Sein Schema ist geschlossen, mit einer festen Enum von vier Strategiemodi, single, loadbalance, fallback und conditional, und einem festen Schlüsselsatz, sodass ein Tippfehler abgelehnt und nicht stillschweigend ignoriert wird. Ziele sind selbst wieder Configs, und genau das macht die Strategien kombinierbar.

{
  "strategy": { "mode": "fallback", "on_status_codes": [429, 500, 503] },
  "retry": { "attempts": 3, "use_retry_after_headers": true },
  "cb_config": { "failure_threshold": 5, "cooldown_interval": 60000 },
  "targets": [
    { "provider": "@openai-prod",
      "override_params": { "model": "gpt-4o" } },
    { "strategy": { "mode": "loadbalance" },
      "targets": [
        { "provider": "@anthropic-prod", "weight": 0.8,
          "override_params": { "model": "claude-sonnet-4-5-20250929" } },
        { "provider": "@bedrock-prod", "weight": 0.2,
          "override_params": { "model": "anthropic.claude-3-5-sonnet-20241022-v2:0" } }
      ] }
  ]
}

Drei Details verdienen eigene Aufmerksamkeit. Gewichte werden auf 100 normalisiert, und ein Gewicht von null hält ein Ziel in der Config, schickt ihm aber keinen Traffic, womit sich ein Canary pausieren statt löschen lässt. Beim Circuit Breaker hat cooldown_interval einen Boden von 30.000 Millisekunden, sodass sich eine Schutzschleife gegen schnelles Flattern nicht in eine enge Retry-Sturm konfigurieren lässt. Und Sticky Routing hasht die benannten Felder mit einer Standard-TTL von einer Stunde, stützt sich aber auf einen zweistufigen Cache aus Memory und Redis und funktioniert ohne Redis nur auf einer Instanz.

Erste Schritte

SDK installieren, einen Anbieter im Model Catalog anlegen, einen String ändern. Das Portkey-SDK ist eine Obermenge des OpenAI-Clients, eine bestehende Integration braucht daher meist nichts außer Basis-URL und Key.

from portkey_ai import Portkey

client = Portkey(api_key="PORTKEY_API_KEY")

answer = client.chat.completions.create(
    model="@openai-prod/gpt-4o",              # @provider-slug/model-name
    messages=[{"role": "user", "content": "Summarise this ticket in one line."}],
)
print(answer.choices[0].message.content)

# Same code, different model: only the string changes
answer = client.chat.completions.create(
    model="@anthropic-prod/claude-sonnet-4-5-20250929",
    max_tokens=512,
    messages=[{"role": "user", "content": "Summarise this ticket in one line."}],
)
print(answer.choices[0].message.content)

Zwei Dinge sind wichtig, bevor das in Produktion geht. Der Provider-Slug wird serverseitig aus dem Model Catalog aufgelöst und nicht aus einem Literal im Request, ein falscher Modell-String schlägt also zur Request-Zeit fehl und nicht zur Deploy-Zeit. Und die Config mit Retries, Caching und Guardrails steht nicht im Snippet: Sie hängt entweder als Config-ID am Client oder als JSON-Blob im Header x-portkey-config, und genau das erlaubt es, Routing-Politik ohne Deploy zu ändern.

Guardrails

Guardrails sind Prüfungen, die an einem Request hängen und auf Eingabe, Ausgabe oder beides angewandt werden. Sie sind der am ehesten falsch konfigurierte Teil von Portkey, unter anderem weil die Funktionsliste breiter klingt als das Verhalten. Die Dokumentation ist bei den Grenzen ungewöhnlich explizit, was die Grenzen zumindest auffindbar macht.

• Ausgewertet wird nur die letzte Nachricht im Request, und davon nur die Textanteile. Bilddaten, base64 oder URL, werden gar nicht geprüft.
• Guardrails laufen nicht auf den Endpunkten für Assistants, Audio, Images, Files, Batch, Fine-tuning, Moderations oder Models. Sie laufen auf Chat Completions, Completions, Embeddings mit nur Eingabe, Messages, Responses und Prompt-Completions.
• Output-Guardrails auf einer gestreamten Antwort sind rein informativ: Das Ergebnis kommt als abschließendes Chunk nach dem Done-Marker und löst weder Fallback noch Retry aus.
• Um Hook-Ergebnisse in einem Stream überhaupt zu sehen, muss die strikte OpenAI-Konformität mit dem Header x-portkey-strict-open-ai-compliance abgeschaltet werden, weil sie sie standardmäßig entfernt.
• Die Stufen folgen dem Tarif: einfache Prüfungen im Developer-Tarif, einfache plus Partner- und Pro-Prüfungen in Production, alles inklusive eigener im Enterprise-Tarif. Die meisten Prüfungen sind deterministisch, Regex, JSON-Schema, Wort- und Zeichenzählung, darüber hinaus LLM-basierte Prüfungen wie Prompt-Injection-Scanning.
• Partner-Guardrails gibt es, darunter Aporia, Pillar Security, SydeLabs, Zscaler AI Guard und Akto, jeweils über HTTP mit eigenem Timeout: 10.000 ms für Zscaler, 5.000 ms für Akto.

Der Anthropic-Pfad hat eine weitere Stolperfalle. Unter /v1/messages kommen die Hook-Ergebnisse als eigenes Event, das das Anthropic-SDK nicht parst; sie zu lesen bedeutet, auf cURL zurückzufallen. Solche kleine Inkonsistenzen entscheiden, ob ein Feature genutzt oder still ignoriert wird, und es lohnt sich, das gegen das eigene SDK zu prüfen, bevor man eine Control auf Guardrail-Basis aufsetzt.

Preis und Latenz

Bei der Latenz laufen Marketing und Messung auseinander. Für dasselbe Produkt existieren drei Zahlen, und sie beschreiben nicht dasselbe. Deshalb nennt die folgende Tabelle zu jeder Zahl ihre Quelle, statt die schmeichelhafteste zu wählen.

Die ehrliche Lesart ist, dass die beiden Zahlen zwei Produkte beschreiben. Unter 1 ms ist die Verarbeitungszeit des Open-Source-Proxys, was wirklich gut ist und das Hauptargument für den Selbstbetrieb liefert. Unter 10 ms ist eine Hosting-Behauptung ohne Methodik. Die plus 93 ms sind die einzige Zahl mit lauffähiger Testumgebung daneben, und dasselbe Repository nennt 50 bis 150 ms als typisch. Gegenüber 400 ms bis zum ersten Token ist das unsichtbar, gegenüber einem 90-ms-Autocomplete- oder Sprachpfad ist es das gesamte Budget. Also auf dem eigenen Traffic messen, nicht von der Preisseite übernehmen.

Zum Preis: abgerechnet wird über protokollierte Logs statt über Requests. Das ist ungewöhnlich und meist unkritisch, denn der Gratis-Tarif liefert nach der Log-Grenze weiter aus und protokolliert nur nicht mehr. In den bezahlten Tarifen wird es relevant, weil die Zusatzmenge je 100.000 Requests auf eine Log-Erlaubnis obendrauf berechnet wird.

Im Enterprise-Tarif wird daraus ein anderes Produkt: eine Data Plane in der eigenen VPC, Helm-Charts auf Kubernetes 1.20 oder neuer, ein bis zwei Kerne und zwei bis vier Gigabyte Speicher pro Instanz, Logs in S3-kompatiblem Object Storage oder MongoDB, und eine Control Plane, von der das Gateway einmal pro Minute synchronisiert, während es Configs und Schlüssel sieben Tage lokal cacht. Die Dokumentation empfiehlt eine volatile-lru-Verdrängungsstrategie, damit aktive Konfiguration bei Speicherdruck überlebt. Das ist ein Betrieb, den man führen muss, kein Container, den man vergessen kann.

Wo es nicht passt

Zuerst die ehrlichen Schwächen, denn sie schließen das Werkzeug für ganze Gruppen von Teams aus. Ein gehostetes Gateway ist ein Single Point of Failure und eine einzige Mandantengrenze für jeden Request einer Anwendung, und auf der Statusseite stehen durchaus Control-Plane-Vorfälle, darunter zwei im August 2026 mit 40 Minuten und zwei Stunden. Semantic Caching hängt an einer Enterprise-Absprache, das kostensparende Feature, mit dem Teams in ihrem Business Case argumentieren, haben sie also nicht. Das Guardrail-Modell liest immer nur die letzte Nachricht und ist damit keine Prompt-Injection-Abwehr für multimodale Konversationen. Und die Config liegt in einem SaaS-Dashboard, womit die Routing-Politik eines Systems nicht mehr in dem Repository reviewbar ist, das das System besitzt.

Die Wahl ist damit weniger eine Feature- als eine Ortsfrage: Wo soll die Politik liegen? Gehören die Routing-Regeln in die Versionsverwaltung neben dem Code, gewinnt LiteLLM in jeder Dimension einschließlich der Kosten. Soll ein Security-Team sie ändern können, sollen Zugangsdaten nie in einer Anwendungsumgebung liegen, oder läuft man in einer regulierten Umgebung, die ohnehin Palo Alto Networks einkauft, spricht für Portkeys Control Plane. Cloudflare AI Gateway ist die dritte Option, die man durchrechnen sollte: Kernfunktionen sind in jedem Tarif kostenlos und die Kosten sind Inferenz statt Plattform, was die Rechnung bei wenig Verkehr umdreht.

Urteil

Portkey ist das vollständigste verwaltete LLM-Gateway am Markt, und allein das Config-Objekt ist ein besseres Design als die meisten selbstgebauten Entsprechungen: verschachtelbare Strategien, geschlossenes Schema, ein harter Boden beim Cooldown des Circuit Breakers. Es lohnt sich, wenn Routing-Politik ein Governance- statt ein Codierungsproblem ist, und man akzeptiert dabei sowohl den Netzwerk-Hop als auch die Tatsache, dass die Routing-Konfiguration nun anderswo liegt als im eigenen Repository. Der polemische Teil: das ist das richtige Standardangebot für Unternehmen und das falsche für ein kleines Team, dem der Gratis-Tarif des Open-Source-Proxys oder LiteLLM mit einem Wochenende Verkabelung besser dient.

1. Portkey nehmen, wenn mehrere Teams Modell-Zugangsdaten teilen und jemand zentral Budgets, Allow-Lists und Rate-Limits verantworten muss. Das ist die eigentliche Aufgabe des Produkts.
2. Es nehmen, wenn ein Security-Team Guardrails ändern und vollständige Request-Logs ohne Deploy einsehen können muss.
3. Nicht nehmen für latenzkritische Completion- oder Sprachpfade, bevor der Hop auf dem eigenen Traffic gemessen ist, denn die veröffentlichte Zusatzzeit liegt bei zweistelligen Millisekunden, die Marketing-Zahl nicht.
4. Nicht auf Guardrails als Prompt-Injection-Kontrolle für multimodale Verkehr bauen. Sie lesen das Bild nie und nur die letzte Nachricht.
5. Weglassen, wenn die Routing-Politik im Code-Review geprüft werden muss. Diese Config gehört ins Repository, und LiteLLM oder das Open-Source-Gateway sind die besseren Werkzeuge.
6. Neu bewerten, sobald die Control Plane zum Engpass wird: bei diesem Volumen ist ein Gateway auf Cloudflare oder ein eigener Proxy in der eigenen VPC billiger und einfacher als der Enterprise-Tarif.

Quellen

1. Portkey-Doku: AI Gateway
2. Portkey-Doku: Erste Schritte mit dem AI Gateway
3. Portkey-Doku: Gateway-Config-Objekt
4. Portkey-Doku: Guardrails
5. Portkey-Doku: Guardrail-Endpunkte und Fähigkeiten
6. Portkey-Doku: Cache, einfach und semantisch
7. Portkey-Doku: Load Balancing
8. Portkey-Doku: Architektur des hybriden Enterprise-Deployments
9. Portkey-Preise
10. Portkey-Gateway auf GitHub, MIT-lizenziert
11. Portkeys eigener Benchmark: Gateway gegenüber direktem Bedrock
12. Portkey-Statusseite
13. Palo Alto Networks schließt die Übernahme von Portkey ab, Mai 2026
14. Palo Alto Networks: Prisma AIRS AI Gateway
15. Preise der Cloudflare AI Gateway
16. LiteLLM-Preise
17. OpenRouter-Preise