OpenAI, Claude und Gemini API zentral verwalten

Mehrere API-Schlüssel, unterschiedliche Antwortformate und unklare Kosten machen Ihren Modellbetrieb schwer wartbar.

Die schnellste belastbare Lösung ist ein internes LLM Gateway zwischen Anwendung und Anbietern: Es vereinheitlicht Modellalias, Authentifizierung, Zeitüberschreitungen, Wiederholungen, Budgets und Protokolle, lässt aber Anbieterunterschiede ausdrücklich sichtbar.

Für wen dieser Leitfaden gedacht ist

Dieser Beitrag richtet sich an Backend-Entwickler, die OpenAI, Claude und Gemini in einer Anwendung einsetzen, an Plattformteams mit zentraler Schlüssel- und Mandantenverwaltung sowie an DevOps- und Architekturverantwortliche, die ein stabiles AI Gateway produktiv betreiben möchten.

Wenn Sie nur einen einzelnen Anbieter in einem kleinen Prototypen aufrufen, genügt zunächst dessen offizielles SDK. Sobald mehrere Teams, Umgebungen oder Geschäftsbereiche beteiligt sind, wird eine zentrale Kontrollschicht jedoch deutlich wichtiger.

Schritt 1: Fähigkeiten, Daten und Abhängigkeiten vor dem Anschluss erfassen

Beginnen Sie nicht mit einer einheitlichen JSON-Struktur, sondern mit einer Bestandsaufnahme Ihrer tatsächlichen Anwendungsfälle. Schreiben Sie für jede Funktion auf, ob sie nur Text erzeugt oder zusätzlich Werkzeuge, strukturierte Ausgaben, Bilder, lange Kontexte, Streaming oder mehrere parallele Tool-Aufrufe benötigt.

Die drei APIs unterscheiden sich bereits bei grundlegenden Details:

Die Tabelle ist kein Kompatibilitätsversprechen. Sie zeigt vielmehr, welche Unterschiede Sie in Ihrem Vertrag abbilden müssen. Prüfen Sie vor der Implementierung die aktuellen Angaben in der OpenAI API-Referenz, der Anthropic-Dokumentation zu Tool Use und der Gemini-Dokumentation zu Function Calling.

Erfassen Sie außerdem die Datenklassifikation. Ein Support-Chat, Quellcode mit Geschäftsgeheimnissen und personenbezogene Kundendaten dürfen nicht automatisch über dieselbe Route laufen. Für jeden Anwendungsfall benötigen Sie mindestens:

• zulässige Anbieter und Regionen,
• erlaubte Modellklassen,
• Aufbewahrungsdauer von Protokollen,
• Anforderungen aus DSGVO, Auftragsverarbeitung und internen Richtlinien,
• Regeln für Eingabe- und Antwortmaskierung,
• Verhalten bei Inhalts- oder Sicherheitsblockierungen.

Achtung: Ein Gateway kann Transport und Zugriff zentralisieren, aber es ersetzt keine Datenschutzprüfung. Wenn ein Anbieter unterschiedliche Speicher- oder Protokollierungsbedingungen für verschiedene Dienste anbietet, muss diese Auswahl in Ihrer Route und nicht nur in einer allgemeinen Datenschutzerklärung sichtbar sein.

Google beschreibt für seine Cloud-Dienste eigene Bedingungen für Prompt-Protokollierung, Zwischenspeicherung und mögliche Aufbewahrung. Prüfen Sie deshalb die Google-Dokumentation zu Datenaufbewahrung und Zero Data Retention, anstatt „Cloud API“ pauschal mit „keine Speicherung“ gleichzusetzen.

Schritt 2: Einen internen API-Vertrag definieren

Ihr interner Vertrag sollte stabiler sein als die Modellnamen der Anbieter. Die Anwendung sollte beispielsweise nicht direkt zwischen verschiedenen Herstellern unterscheiden müssen, nur um eine normale Textantwort zu erhalten.

Ein möglicher Kernvertrag enthält:

{
  "model": "reasoning-standard",
  "messages": [],
  "tools": [],
  "stream": false,
  "tenant_id": "tenant-placeholder",
  "request_id": "req-placeholder",
  "metadata": {}
}

Die Platzhalter sind absichtlich nicht als echte Zugangsdaten gedacht. In der Praxis sollte Ihre Anwendung keine Anbieter-Schlüssel und keine geheimen Verwaltungswerte an diesen Endpunkt senden.

Definieren Sie für jede Anfrage mindestens:

1. einen stabilen Modellalias,
2. eine Nachrichtenstruktur mit klaren Rollen,
3. optionale Werkzeuge und deren JSON-Schema,
4. einen Streaming-Schalter,
5. eine maximale Laufzeit,
6. eine Mandanten- oder Projektkennung,
7. eine eindeutige Request-ID,
8. einen Bereich für kontrollierte Erweiterungen.

Für die Antwort sollten Sie Text, strukturierte Inhalte, Tool-Aufrufe, Nutzungsdaten, Abschlussgrund und Anbieterinformationen trennen. Lassen Sie die Anbieterkennung intern verfügbar, aber geben Sie sie nur an Clients weiter, wenn dies für die Anwendung erforderlich ist.

Die wichtigste Regel lautet: Standardisieren Sie den gemeinsamen Kern, nicht jede Fähigkeit. Wenn ein Anbieter eine spezielle Funktion unterstützt, die andere nicht anbieten, müssen Sie entweder einen expliziten Erweiterungsbereich oder einen eigenen Capability-Schalter verwenden.

Wie verwenden Sie mehrere große Modell-APIs mit einer einheitlichen Schnittstelle?
Sie legen einen internen Vertrag für den gemeinsamen Anwendungsfall fest und bauen für jeden Anbieter einen Adapter. Der Adapter übersetzt Anfrage, Antwort, Tool-Aufrufe, Streaming und Fehler in diesen Vertrag. Er darf nicht einfach unbekannte Parameter verwerfen, weil dadurch ein scheinbar erfolgreicher, tatsächlich aber unvollständiger Aufruf entstehen kann.

Schritt 3: API-Schlüssel und Mandanten sauber trennen

Der Anbieter-Schlüssel gehört ausschließlich in die Gateway-Schicht. Ihre Anwendung erhält stattdessen ein internes Zugangstoken, eine mTLS-Identität oder eine andere kontrollierte Dienstidentität. Die Anbieter dokumentieren serverseitige Schlüsselverwaltung und warnen davor, geheime API-Schlüssel in Browsern oder Client-Anwendungen offenzulegen.

Wie sollte ein LLM Gateway API Keys verwalten?
Legen Sie die Schlüssel in einem Secret Manager ab, verschlüsseln Sie sie bei der Speicherung und erlauben Sie dem laufenden Gateway nur den Zugriff auf die benötigten Geheimnisse. Ein Konfigurationsfile im Git-Repository, ein eingebetteter Schlüssel im Container-Image oder ein Schlüssel in Frontend-JavaScript sind für den Produktivbetrieb keine akzeptablen Varianten.

Trennen Sie mindestens diese Ebenen:

• Anbieter-Schlüssel,
• Gateway-interne Dienstidentität,
• Benutzer- oder Projektidentität,
• Verwaltungszugang,
• Test- und Produktionsumgebung,
• Lese- und Änderungsrechte für Routing und Budgets.

Verknüpfen Sie jede Anfrage mit einem Tenant, Projekt oder Environment. Dadurch können Sie später nachvollziehen, welcher Bereich Kosten verursacht, Limits überschreitet oder ungewöhnlich viele Fehler produziert.

Für die Verwaltungsoberfläche sollten Sie stärkere Kontrollen verlangen als für normale Modellanfragen: Mehrfaktor-Authentifizierung, rollenbasierte Rechte, Audit-Protokolle und eine gesonderte Freigabe für Änderungen an Anbieter-Schlüsseln oder Fallback-Routen.

Eine sinnvolle Schlüsselrotation darf nicht erst nach einem Leck beginnen. Halten Sie deshalb mindestens einen kontrollierten Wechselprozess bereit:

1. neuen Schlüssel beim Anbieter erzeugen,
2. Schlüssel im Secret Manager hinterlegen,
3. Gateway-Konfiguration ohne sofortige Löschung des alten Schlüssels aktualisieren,
4. Testanfrage über die neue Identität ausführen,
5. alten Schlüssel widerrufen,
6. Audit-Eintrag und verantwortliche Person dokumentieren.

Schritt 4: Modelle zunächst deterministisch routen

Beginnen Sie mit einer festen Zuordnung. Ein Alias wie fast-default sollte zunächst genau auf einen geprüften Modellendpunkt zeigen. Erst wenn Sie reale Nutzungsdaten, Fehlerraten und Qualitätswerte besitzen, lohnt sich eine komplexere Strategie mit Lastverteilung, Kostenoptimierung oder dynamischer Anbieterwahl.

Ein Fallback ist nur dann belastbar, wenn Sie vorher festlegen, welche Fehler einen Wechsel auslösen. Ein ungültiges Schema, ein abgelehnter Inhalt oder ein fachlich falscher Modelloutput sollte nicht automatisch an einen anderen Anbieter weitergereicht werden. Ein zeitweiliger Netzwerkfehler oder ein nachweisbarer Anbieterfehler kann dagegen ein Kandidat sein.

Können Sie nach einem fehlgeschlagenen Routing automatisch wechseln?
Ja, aber nur unter definierten Bedingungen. Wechseln Sie nicht bei jeder HTTP-Fehlermeldung. Prüfen Sie Statusklasse, Fehlercode, bereits gesendete Daten, Idempotenz, Streamingstatus und die Frage, ob der erste Anbieter bereits eine externe Aktion ausgelöst haben könnte.

Für reine Textgenerierung kann ein Wiederholungsversuch mit Exponential Backoff vertretbar sein. Bei Tool-Aufrufen, Bestellungen, E-Mails oder Datenbankänderungen müssen Sie dagegen eine Idempotency-ID und eine eindeutige Ausführungslogik verwenden. Nach Beginn eines Streams ist ein transparenter Wechsel besonders schwierig, weil der Client bereits Teile einer Antwort erhalten kann.

Erfahrung aus der Praxis: Ein Fallback, der nur „Anbieter A ist ausgefallen, daher Anbieter B“ implementiert, erzeugt bei einer gemeinsamen Überlastung oft eine Wiederholungsspirale. Begrenzen Sie Versuche, warten Sie zwischen ihnen und zählen Sie jeden Versuch separat im Budget.

Schritt 5: Fehlerformate bewusst normalisieren

OpenAI, Claude und Gemini melden nicht dieselben Zustände mit denselben Feldern. Außerdem sind ein normaler Abschlussgrund und ein technischer Fehler nicht dasselbe Ereignis.

Wie vereinheitlichen Sie OpenAI- und Claude-Fehlerformate?
Führen Sie ein internes Fehlerobjekt mit stabilen Kategorien ein, bewahren Sie aber die ursprüngliche Anbieterantwort als geschützte Diagnoseinformation auf.

{
  "error": {
    "category": "rate_limit",
    "retryable": true,
    "provider": "provider-placeholder",
    "request_id": "req-placeholder",
    "message": "Anbieterlimit erreicht",
    "raw_code": "provider-code-placeholder"
  }
}

Typische interne Kategorien sind:

• authentication,
• authorization,
• invalid_request,
• model_unavailable,
• rate_limit,
• timeout,
• network,
• content_blocked,
• tool_validation,
• provider_error,
• budget_exceeded.

Anthropic unterscheidet in seiner Dokumentation zwischen erfolgreichen stop_reason-Werten und echten HTTP-Fehlern. Diese Trennung sollten Sie auch intern beibehalten. Bei Streaming kommt hinzu, dass der Abschlussgrund erst in einem späteren Ereignis erscheinen kann.

Gemini kann bei der Antwort zusätzlich Sicherheits- oder Inhaltsgründe wie SAFETY, BLOCKLIST oder MALFORMED_FUNCTION_CALL melden. Solche Zustände dürfen nicht pauschal als „Serverfehler“ behandelt werden, weil sonst Ihr Fallback eine gesperrte Anfrage wiederholt.

Schritt 6: Zeitüberschreitungen, Wiederholungen und Streaming testen

Setzen Sie getrennte Zeitlimits für Verbindung, erste Antwort, einzelne Stream-Ereignisse und die gesamte Anfrage. Ein einziger globaler Timeout-Wert sagt Ihnen nicht, ob der Anbieter gar nicht antwortet oder ob die Antwort nur langsam weiterläuft.

Für Wiederholungen brauchen Sie mindestens:

• maximale Versuchszahl,
• Exponential Backoff mit Zufallsanteil,
• Liste wiederholbarer Fehler,
• Abbruch bei nicht idempotenten Aktionen,
• getrennte Regeln für Streaming und Nicht-Streaming,
• Zählung pro Tenant und Anbieter,
• Schutz gegen parallele Wiederholung derselben Anfrage.

Beim Streaming muss Ihr Adapter Ereignisse in ein internes Format überführen, ohne Textfragmente, Tool-Aufrufe oder Abschlussinformationen zu vermischen. Bei gestreamten Tool-Aufrufen können Argumente in Teilstücken eintreffen, die vor der Ausführung zusammengesetzt werden müssen.

Testen Sie daher nicht nur den Fall „Text kommt an“, sondern auch:

• Verbindung wird nach dem ersten Fragment unterbrochen,
• Tool-Argumente kommen in mehreren Teilen,
• Anbieter sendet einen Abschluss ohne vollständigen Text,
• Client bricht die Anfrage ab,
• Gateway erhält eine verspätete Antwort nach einem Timeout,
• Wiederholungsversuch würde eine Aktion doppelt ausführen.

Schritt 7: Budgets, Limits und Beobachtbarkeit einbauen

Ein Gateway ohne Nutzungs- und Kostenkontrolle ist lediglich ein zusätzlicher Proxy. Sie sollten jede Anfrage mit mindestens folgenden Metadaten erfassen:

Setzen Sie Budgets auf mehreren Ebenen:

1. global für die Organisation,
2. pro Umgebung,
3. pro Projekt oder Tenant,
4. pro Modellalias,
5. pro einzelner Anfrage,
6. pro Zeitraum.

Ein Warnbudget informiert das Team. Ein hartes Limit blockiert weitere Anfragen. Eine Anomalieerkennung untersucht plötzliche Änderungen bei Anfragevolumen, Tokenverbrauch, Fehlerrate oder durchschnittlicher Antwortlänge. Diese Mechanismen sollten nicht dieselbe Schwelle verwenden, weil Warnung und Schutz unterschiedliche Aufgaben haben.

Vermeiden Sie vollständige Prompt-Logs als Standard. Maskieren Sie E-Mail-Adressen, Kundennummern, Zugangsdaten und Quellcodefragmente, begrenzen Sie den Zugriff und definieren Sie eine Löschfrist. Die Datenschutzerklärung von ZavCloud kann als Orientierung für die transparente Beschreibung von Datenverarbeitung dienen, ersetzt aber nicht Ihre eigene technische und rechtliche Prüfung.

Schritt 8: Vor dem Produktivstart eine feste Abnahme durchführen

Was müssen Sie vor dem Start eines AI Gateway prüfen?
Sie benötigen einen festen Testdatensatz und eine Abnahmematrix, die alle produktiven Fähigkeiten abdeckt. Ein erfolgreicher einfacher Textprompt reicht nicht aus.

Führen Sie zusätzlich einen Vergleichstest mit identischen Eingaben durch. Bewerten Sie nicht nur, ob beide Modelle eine Antwort liefern, sondern auch Struktur, Tool-Verhalten, Sprache, Sicherheitsverhalten und fachliche Mindestqualität.

Nutzen Sie anschließend diese Entscheidungsbedingungen:

• Wenn alle benötigten Fähigkeiten in der gemeinsamen Vertragsschicht abbildbar sind, dann verwenden Sie einen gemeinsamen Modellalias.
• Wenn eine Funktion nur ein Anbieter unterstützt, dann verwenden Sie ein explizites Capability-Feld oder einen spezialisierten Endpunkt.
• Wenn ein Fallback die fachliche Mindestqualität nicht erreicht, dann deaktivieren Sie den automatischen Wechsel für diesen Anwendungsfall.
• Wenn Datenregion oder Aufbewahrung nicht zur Anwendung passen, dann schließen Sie den Anbieter aus dieser Route aus.
• Wenn ein Tool-Aufruf eine nicht umkehrbare Aktion ausführt, dann ist ein automatischer Wiederholungsversuch nur mit Idempotenzschutz erlaubt.
• Wenn Kosten- oder Fehlerschwellen nicht beobachtbar sind, dann bleibt der Dienst zunächst in Test- oder Schattenausführung.

Schritt 9: Modellalias und Anbieteränderungen langfristig pflegen

Ihre Anwendung sollte nicht direkt auf wechselnde Modellnamen reagieren müssen. Verwenden Sie Aliase wie fast-default, quality-default oder code-analysis. Hinterlegen Sie für jeden Alias den aktuellen Anbieter, die freigegebenen Fähigkeiten, die Datenklasse, die Testversion und ein Ablaufdatum der Prüfung.

Bei einer Modelländerung empfiehlt sich folgende Reihenfolge:

1. neue Version als separaten Zielendpunkt registrieren,
2. festen Testdatensatz ausführen,
3. Qualität, Latenz, Fehler und Nutzung vergleichen,
4. begrenzte Schatten- oder Graustufenausführung starten,
5. Budget- und Sicherheitsgrenzen prüfen,
6. Alias erst danach umschalten,
7. Rückfallversion und Abschaltzeitpunkt dokumentieren.

Überprüfen Sie regelmäßig ungenutzte Endpunkte, alte Anbieter-Schlüssel, zu großzügige Rollen, überlange Logaufbewahrung und Fallbacks, die nie erfolgreich getestet wurden. Die OpenAI API-Referenz, die Anthropic Messages API und die Gemini-API-Dokumentation sollten Bestandteil Ihres technischen Änderungsprozesses sein.

Wann ein Gateway und wann eine direkte Integration sinnvoll ist

Eine direkte Integration bleibt sinnvoll, wenn Sie nur einen Anbieter verwenden, keine Mandantentrennung benötigen und die Anbieterfunktionen vollständig ausnutzen möchten. Sie sparen dann eine zusätzliche Betriebs- und Fehlerquelle.

Ein eigenes LLM Gateway lohnt sich dagegen, wenn mehrere Anwendungen dieselben Anbieter verwenden, Schlüssel zentral verwaltet werden müssen, Budgets pro Team gelten oder Sie Anbieter wechseln können müssen, ohne alle Clients neu zu entwickeln.

Berücksichtigen Sie auch die Betriebsumgebung. Ein Gateway auf einer gemeinsam genutzten Entwicklerstation ist für Tests ausreichend, aber für dauerhaft kritische Aufrufe fehlen dort oft feste Verfügbarkeit, kontrollierte Netzwerkregeln, getrennte Secrets und nachvollziehbare Logs. Ein kleiner dedizierter Mac oder eine verwaltete Remote-Umgebung kann für Entwicklungs-, Integrations- und zeitlich begrenzte Abnahmetests praktischer sein als eine ständig umgebaute lokale Installation. Für die Auswahl einer solchen Umgebung können Sie die Mac-mini-Mietoptionen von ZavCloud anhand von Testdauer, Zugriff und benötigten Werkzeugen prüfen.

Wenn Ihr aktuelles Setup auf lokalen Rechnern oder wechselnden Cloud-Instanzen läuft, entstehen häufig drei konkrete Nachteile: Die Netzwerk- und Secret-Konfiguration ist nicht überall identisch, Fehlerprotokolle verteilen sich über mehrere Systeme und ein längerer Test blockiert die Arbeitsumgebung eines Entwicklers. Eine gemietete Mac-Umgebung von ZavCloud kann für vorübergehende Gateway-Validierung, Integrationsprüfungen und reproduzierbare Entwicklungsphasen die passendere Ergänzung sein. Für einen dauerhaft hohen Produktionsdurchsatz oder besondere physische Schnittstellen sollten Sie dagegen weiterhin eine eigene, langfristig geplante Infrastruktur bewerten.

Wenn Sie die Einführung anhand von Zugriffsrechten, Datenschutz und Betriebsprozessen vorbereiten, finden Sie weitere organisatorische Hinweise im Hilfe-Zentrum von ZavCloud. Entscheidend bleibt jedoch die Reihenfolge: erst Fähigkeiten und Datenregeln erfassen, dann den Vertrag definieren, anschließend Routing und Wiederholungen begrenzen und erst nach einer festen Abnahme in die produktive Nutzung wechseln.