Ein Kunde rief mich Donnerstag um 8 Uhr an. Sein KI-gestütztes Dokumenten-Zusammenfassungs-Tool gab seit Mitternacht 503er zurück, weil OpenAI einen Teilausfall am gpt-4o-Endpoint hatte. Sie waren in einem £40k/Monat-SaaS-Vertrag und ihr Enterprise-Kunde schrie. Ich hatte genau eine Frage im Kopf: Warum hatte niemand ein Retry-Fallback zu Anthropic eingebaut?
Das war vor acht Monaten. Vercel AI Gateway ist die nächstliegende Lösung für dieses Problem, die ich gesehen habe. Aber „nächstliegend" leistet da viel Arbeit. Lass mich dir sagen, was es wirklich tut, wie die Zahlen aussehen und wo du noch skeptisch sein solltest.
---
Was Vercel AI Gateway wirklich ist
Die meisten Leute sehen den Namen und gehen von einem Proxy mit schönem Logging aus. Es ist etwas mehr als das, aber nicht so viel mehr, wie die Marketing-Copy suggeriert.
Im Kern sitzt Vercel AI Gateway zwischen deinem Anwendungscode und mehreren LLM-Anbietern: OpenAI, Anthropic, Mistral, Google Gemini und anderen. Du sendest eine einzelne Anfrage an den Gateway-Endpoint. Das Gateway entscheidet, welches Modell/welchen Anbieter es aufrufen soll, handhabt Wiederholungen, cached semantische Responses und gibt das Ergebnis zurück. Du bekommst eine Rechnungszeile statt vier API-Dashboards.
Die SDK-Integration ist wirklich sauber. Falls du bereits das Vercel AI SDK nutzt, tauschst du deinen Provider-Import gegen den Gateway-Client aus und übergibst eine Provider-Konfiguration. Vielleicht fünfzehn Minuten Arbeit bei einem bestehenden Projekt.
Was es nicht ist, ist ein magischer Kostensenker an sich. Die Einsparungen kommen aus drei spezifischen Verhaltensweisen: Routing nach Kosten, Caching wiederholter Prompts und Vermeidung von kalten Neustarts nach Anbieterausfällen. Falls du von mindestens einem dieser drei Aspekte keinen Nutzen bekommst, fügt das Gateway Overhead ohne Vorteil hinzu.
---
Wie die Routing-Logik funktioniert
Provider-Priorität und gewichtetes Routing
Du konfigurierst eine Liste von Anbietern mit einer Prioritätsreihenfolge oder einer Gewichtungsverteilung. Prioritäts-Routing ist einfach: versuche Anbieter A, und falls er eine 429 oder eine 5xx zurückgibt, falle auf Anbieter B zurück. Gewichtetes Routing teilt den Traffic nach Prozentsätzen auf, sodass du sagen kannst „70% OpenAI, 30% Mistral" und Kostenunterschiede im echten Traffic testen kannst, ohne eine vollständige Migration.
Ich nutzte gewichtetes Routing bei einem Content-Generation-Tool, das Seahawk letztes Quartal für ein Medienunternehmen baute. Wir liefen gpt-4o-mini zu 60% gegen mistral-medium zu 40% für einen Monat. Mistral war damals etwa 34% günstiger pro Million Token, aber die Ausgabequalität für strukturierte JSON-Extraktion war merklich schwächer. Wir landeten bei 80/20 zugunsten von OpenAI. Der Punkt ist: Das Gateway machte diesen A/B-Test mühelos. Ohne würden wir zwei separate SDK-Clients verdrahten und die Aufteilung in der Anwendungslogik verwalten.
Failover-Verhalten
Failover ist die Headline-Funktion und sie funktioniert wie versprochen, größtenteils. Wenn OpenAI eine 5xx zurückgibt, wiederholt das Gateway auf dem nächsten konfigurierten Anbieter in etwa 800ms in meinen Tests. Bei Streaming-Responses ist es etwas unordentlicher: der Stream kann stillschweigend vom Fallback-Anbieter neu starten, und falls du den Stream auf der Client-Seite nicht korrekt handhabst, kannst du einen duplizierten Opening-Chunk bekommen. Das ist uns einmal passiert.
Eine Sache zum Wissen: Das Gateway führt kein semantisches Failover durch. Es weiß nicht, dass deine Anthropic claude-3-5-sonnet-Response anders formuliert sein könnte als das OpenAI-Äquivalent. Du bist verantwortlich für Prompt-Kompatibilität über Provider hinweg. Für die meisten Chat-artigen Interfaces ist das in Ordnung. Bei strukturierten Outputs mit strikten Schemas teste jeden Anbieter in deiner Failover-Kette unabhängig, bevor du live gehst.
---
Die Caching-Schicht: Wo echtes Geld sitzt
Das ist der Teil, den die meisten Leute unterschätzen. Vercel AI Gateway enthält semantisches Caching, nicht nur exaktes Matching-Caching.
Exaktes Matching-Caching ist table stakes: falls der gleiche Prompt-String das Gateway zweimal trifft, gib die gecachte Response zurück. Semantisches Caching geht weiter. Mit Embedding-Ähnlichkeit erkennt es, dass „fasse diesen Absatz in drei Sätzen zusammen" und „gib mir eine Drei-Satz-Zusammenfassung dieses Absatzes" die gleiche Anfrage sind und serviert das gecachte Ergebnis.
Beim Dokumenten-Summarizer-Projekt (das meinen Kunden fast einen Herzinfarkt beschert hätte) haben wir die Cache-Hit-Rate nach Aktivierung von Semantic Caching mit einem Cosine-Similarity-Schwellwert von 0,92 gemessen. Über zwei Wochen hinweg im Produktivbetrieb: 41% Cache-Hit-Rate. Bei £0,015 pro 1K Output-Tokens auf GPT-4o ist das über 2 Millionen tägliche Output-Tokens hinweg nicht unerheblich.
Machen Sie die Napkin-Rechnung selbst:
- 2.000.000 Output-Tokens/Tag
- 41% aus Cache bereitgestellt = 820.000 Tokens nicht abgerechnet
- Bei £0,015/1K sind das £12,30 gespart pro Tag
- Über einen Monat: ungefähr £370
Nicht lebensverändernd für ein großes Unternehmen. Bedeutsam für einen Indie-SaaS-Betreiber, der die Marge beobachtet. Und das ist ein Projekt, ein Monat.
Die OpenAI-Prompt-Caching-Funktion verwaltet Prefix-Caching jetzt nativ, sodass Sie für lange System-Prompts bereits einen Teil davon kostenlos bekommen. Vercels Semantic Cache ergänzt das und verarbeitet die Variation im Benutzer-Turn-Content.
---
Observability: Better Than Nothing, Not Good Enough Alone
Jede Anfrage über das Gateway wird protokolliert: Latenz, Token-Counts, verwendeter Provider, Cache-Hit/Miss, Kostenschätzung. Sie sehen das im Vercel-Dashboard. Es ist sauber und lesbar.
Hier ist aber die Sache. Wenn Sie ein ernsthaftes Produktionssystem betreiben, haben Sie bereits etwas wie Datadog, Grafana oder mindestens LangSmith in Ihrer Trace-Pipeline. Das Vercel-Dashboard gibt Ihnen Gateway-Level-Sichtbarkeit. Es gibt Ihnen keine Span-Level-Traces über Ihre gesamte Anwendung. Sie können nicht sehen, dass die Anfrage eines bestimmten Benutzers 4,2 Sekunden gedauert hat, weil 3,1 dieser Sekunden im Abrufen-Schritt verbracht wurden, bevor das LLM überhaupt aufgerufen wurde.
Daher behandle ich die eingebaute Observability des Gateways als ersten Filter: Liegt das Problem auf der LLM-Call-Ebene oder anderswo? Für alles Tiefergehende exportiere ich immer noch zu einem richtigen Tracing-Tool.
Eine spezifische Zahl, die es zu kennen lohnt: Das Gateway fügt durchschnittlich etwa 15–30ms Latenz pro Anfrage hinzu, basierend auf meinen Messungen bei EU-Region-Deployments. Für Echtzeit-Voice oder UX-Anforderungen unter 100ms spielt das eine Rolle. Für asynchrone Dokumentenverarbeitung nicht.
---
Was es wirklich kostet, es zu betreiben
Vercel AI Gateway ist im Pro-Plan (£17/Monat zum Zeitpunkt des Schreibens) und höher enthalten. Es gibt keine Pro-Request-Gebühr von Vercel. Sie zahlen die Token-Kosten des zugrunde liegenden Providers weiterhin direkt.
Die versteckten Kosten sind operativ: Sie fügen Vercel als Abhängigkeit in Ihren Inference-Pfad ein. Falls Vercel ein Edge-Network-Problem hat, schlagen Ihre LLM-Calls fehl, unabhängig davon, ob OpenAI vollkommen gesund ist. Ich habe das einmal in den letzten sechs Monaten gesehen, einen etwa 12-minütigen Teilausfall im Vercel-Edge in der EU-West-Region. Für die meisten Apps ist das akzeptabel. Für alles mit SLA-Verpflichtungen gemessen in Nines sollten Sie das berücksichtigen.
Es gibt auch die Frage der Datenresidenz. Ihre Prompts und Completions durchlaufen Vercels Infrastruktur. Für die meisten Consumer-Apps: irrelevant. Für Healthcare, Finance oder alles, das sinnvoll GDPR-sensitive persönliche Daten berührt: Lesen Sie die Datenverarbeitungsvereinbarung sorgfältig, bevor Sie etwas durchleiten. Ich habe zwei Fintech-Kunden sagen müssen, das Gateway ganz zu überspringen und das Routing stattdessen im Anwendungscode zu handhaben.
---
Wann man es nutzt und wann man es überspringt
Ich werde hier direkt sein, weil das Developer-Marketing rund um AI-Tools dazu neigt, zu viel zu versprechen.
Nutzen Sie Vercel AI Gateway, wenn:
- Sie bereits auf Vercel sind und das AI SDK nutzen (null zusätzliche Friction)
- Sie eine Multi-Provider-Strategie haben und Failover ohne Retry-Logik möchten
- Ihre App genug wiederholte oder semantisch ähnliche Prompts hat, damit sich Caching lohnt
- Sie ein Kosten-Dashboard möchten, ohne separate Provider-Billing-Integrationen einzurichten
Überspringen Sie es, oder denken Sie sorgfältig nach, falls:
- Sie strenge Anforderungen an die Datenresidenz haben (GDPR, HIPAA)
- Sie eine Gesamtinferenzlatenz unter 50 ms benötigen und jeder Hop zählt
- Sie auf einer Non-Vercel-Infrastruktur laufen und das Hinzufügen ihres Edge führt zu mehr Komplexität als es löst
- Ihre Prompt-Vielfalt extrem hoch ist und die semantische Cache-Trefferquote ohnehin nahe Null liegen wird
2015 haben wir ein Tool zur Analyse von Rechtsdokumenten auf einem selbstgehosteten Stack für ein Londoner Unternehmen entwickelt. Auch wenn Vercel AI Gateway damals existiert hätte, wäre es sofort vom Tisch gewesen. Die Prompts enthielten privilegierte Kundeninformationen und das IT-Compliance-Team des Unternehmens hätte niemals einem Drittanbieter-Proxy zugestimmt. Wir haben in etwa vier Stunden Arbeit unsere eigene Provider-Abstraktionsschicht aufgebaut. Sie bewältete das Failover über zwei Provider hinweg mit einer einfachen Prioritätswarteschlange. Nicht glamourös. Völlig ausreichend.
---
Das praktische Setup (Kurzversion)
Falls Sie entschieden haben, dass es für Ihr Projekt richtig ist, folge ich dieser Abfolge:
- Aktivieren Sie das Gateway in Ihren Vercel-Projekteinstellungen unter dem Tab „AI"
- Installieren oder aktualisieren Sie
aiund@ai-sdk/openai(und alle anderen Provider-Pakete, die Sie benötigen) auf die neuesten Versionen - Ersetzen Sie die direkte Provider-Client-Instanziierung durch den Gateway-Client aus
@vercel/ai-gateway(überprüfen Sie die offizielle Dokumentation auf den genauen Importpfad, da dieser sich bereits einmal geändert hat) - Definieren Sie Ihre Provider-Liste in Prioritätsreihenfolge im Gateway-Config-Objekt
- Legen Sie Ihren Schwellenwert für semantische Cache-Ähnlichkeit fest: Ich beginne bei 0,90 und passe ihn basierend auf beobachteten Trefferquoten nach einer Woche Datenverkehr an
- Stellen Sie in einer Staging-Umgebung bereit und lösen Sie Provider-Ausfälle absichtlich aus, um zu überprüfen, ob die Failover-Kette wie erwartet funktioniert
- Überwachen Sie Cache-Trefferquote und Latenz-p95 in den ersten zwei Wochen, bevor Sie Schlussfolgerungen ziehen
Das war's. Wirklich nicht kompliziert.
---
FAQ
Unterstützt Vercel AI Gateway Streaming-Responses?
Ja, Streaming funktioniert über das Gateway. Der eine Haken ist Failover während des Streaming: Wenn der primäre Provider während einer Streaming-Response ausfällt, versucht das Gateway erneut beim nächsten Provider, aber der Stream wird neu gestartet. Je nachdem, wie Ihre Client-seitige UI mit Teilinhalten umgeht, kann dies zu einem sichtbaren Flackern oder einem duplizierten ersten Satz führen. Testen Sie dies explizit in Ihrer UI, bevor Sie ausliefern.
Kann ich Vercel AI Gateway ohne das Vercel AI SDK nutzen?
Technisch können Sie den Gateway-Endpoint direkt über HTTP treffen, aber die SDK-Integration ist dort, wo es ergonomisch wird. Ohne das SDK schreiben Sie Ihre eigenen Fetch-Wrapper um die Gateway-URL, verwalten Streaming selbst und handhaben Retries manuell. An diesem Punkt könnten Sie genauso gut Ihre eigene Provider-Abstraktionsschicht bauen. Der Wert des Gateways ist in der Praxis eng an das SDK gekoppelt.
Wie geht semantisches Caching mit sensiblen oder personalisierten Daten um?
Automatisch nicht. Falls Sie Prompts senden, die benutzerspezifische Daten enthalten (Namen, Kontonummern, Session-Kontext), wird der Cache versuchen, semantisch ähnliche Prompts zu finden, unabhängig davon, ob sich diese Daten zwischen Benutzern unterscheiden. Dies kann zu falschen Cache-Treffern in personalisierten Workflows führen. Sie sollten entweder semantisches Caching für diese Routen deaktivieren oder einen benutzerscopten Cache-Schlüssel einfügen, falls das Gateway dies in Ihrem Plan-Tier unterstützt.
Was passiert mit meinen Anfragen, falls Vercel ausfällt?
Sie schlagen fehl. Das Gateway befindet sich im kritischen Pfad. Falls Sie echte Multi-Cloud-Resilienz benötigen, sollten Sie einen Circuit-Breaker auf der Anwendungsebene haben, der das Gateway vollständig umgehen und Provider direkt treffen kann. Ich halte Provider-SDK-Clients als Fallback in jeder App initialisiertwo Auftimezeit wirklich wichtig ist.
---
Die ehrliche Zusammenfassung: Vercel AI Gateway ist eine solide Infrastrukturkomponente, die ihren Platz in einem Vercel-nativen AI-Stack verdient. Sie werden damit Ihre Einheitsökonomie nicht revolutionieren, aber eine Cache-Hit-Rate von 35–40% bei der richtigen Workload plus automatisches Failover ist eine echte operative Verbesserung gegenüber dem manuellen Verbinden aller Komponenten. Wissen Sie einfach, was es nicht kann, bevor Sie sich darauf festlegen. Der Anruf eines verängstigten Kunden um 8 Uhr morgens ist eine elende Art herauszufinden, wo Ihre Annahmen falsch waren.