Für Teams in China gibt es beim Zugang zur OpenAI API im Wesentlichen drei Wege: die offizielle Direktverbindung, einen selbst betriebenen Proxy und ein inländisches KI-Gateway. Die drei Varianten sind nicht einfach „gut oder schlecht“, sondern verlagern die Kosten an unterschiedliche Stellen: Die Direktverbindung verlagert sie in Netzwerk und Zahlungsverkehr, der Proxy in den Betrieb, das Gateway in die Abhängigkeit vom Dienstleister und die Prüfung der Bedingungen.

Dieser Artikel vergleicht Netzstabilität, Zahlung und Rechnungen, Compliance, Wartung, Modellabdeckung und Störungsbehandlung und liefert praktikable Konfigurationen für Timeouts, Wiederholungen und Ausweichrouten sowie eine Checkliste für den Produktivstart. Der Beitrag ist eine technische Gegenüberstellung und keine Rechtsberatung; Verfügbarkeit und Compliance richten sich nach lokalem Recht, regulatorischen Vorgaben und den Bedingungen der Anbieter.

Hinweis: OpenAI, ChatGPT und GPT sind Marken von OpenAI. Der Artikel beschreibt die übliche Lage im Oktober 2026. Preise und Modelllisten entnehmen Sie der Preisübersicht und der Dokumentation des jeweiligen Anbieters; Preise können sich ändern.

1. Was die drei Wege bedeuten

Offizielle Direktverbindung: Sie nutzen ein offizielles OpenAI-Konto und die offizielle Schnittstelle. Netzwerk, Zahlung und Abrechnung laufen vollständig im offiziellen System. Voraussetzung ist, dass das Team die von OpenAI unterstützten Registrierungs- und Zahlungsbedingungen erfüllen kann und lokales Recht sowie Plattformbedingungen den Zugang zulassen.

Eigener Proxy: Das Team mietet einen Server im Ausland und betreibt dort einen Reverse-Proxy oder eine Weiterleitung. Anfragen laufen zuerst über den eigenen Server und dann zum Upstream. Der Proxy löst die Verbindungsstrecke und einen einheitlichen Ausgang, während Konto, Key und Zahlung weiterhin separat geklärt werden müssen.

Inländisches KI-Gateway: Ein Dienstleister stellt eine OpenAI-kompatible Adresse bereit. Teams laden in RMB auf und verwalten ihre Keys im Kundenportal. Das Gateway übernimmt Upstream-Anbindung, Weiterleitung und einen Teil der Störungsbehandlung; auf Kundenseite ist meist nur die Base URL anzupassen. Das ZSQH AI Gateway gehört zu dieser Kategorie; die Registrierung erfolgt über die Registrierungsseite.

2. Die Unterschiede in einer Tabelle

Kriterium Offizielle Direktverbindung Eigener Proxy Inländisches KI-Gateway
Netzstabilität Abhängig von der Auslandsstrecke; Schwankungen müssen selbst analysiert werden Abhängig von Serverroute und Proxy-Qualität Vom Dienstleister betrieben, in der Regel aus China erreichbar
Einstiegshürde Offizielles Konto und nutzbare Zahlungsmethode nötig Server, Domain, Zertifikate und Betrieb nötig Registrierung genügt, niedrigste Hürde
Zahlung und Rechnungen In den von OpenAI unterstützten Währungen und Wegen Serverkosten und Upstream-Kosten getrennt Aufladung in RMB, Rechnungen nach den Regeln des Dienstleisters
Compliance und Bedingungen Direkt an die OpenAI-Bedingungen gebunden Lokales Recht und Upstream-Bedingungen müssen gleichzeitig erfüllt sein Qualifikation und Datenanforderungen des Dienstleisters prüfen
Betriebsaufwand Niedrig, Netzprobleme liegen aber beim Team Hoch: Zertifikate, Monitoring und Updates brauchen Personal Niedrig; Fehlersuche hängt vom Dienstleister ab
Modellabdeckung OpenAI-eigene Modelle Abhängig vom Upstream-Konto, meist nur ein Anbieter Häufig mehrere Anbieter aggregiert, laut Preisübersicht
Störungsbehandlung Offizielle Supportkanäle Selbst lokalisieren und beheben Dienstleister behandelt den Upstream; Nutzer behalten die Request-ID
Geeignet für Teams mit passender Zahlung und Netzanbindung, die nur OpenAI nutzen Teams mit Betriebskompetenz und Bedarf an einheitlichem Ausgang Kleine und mittlere Teams in China, mehrere Modelle, Rechnungen in RMB

Die Tabelle eignet sich nur für eine erste Auswahl. Entscheidend für die Praxis sind Latenz, Fehlerrate und Reaktionszeit bei Störungen in Spitzenzeiten. Testen Sie ein bis zwei Wochen mit echten Geschäftsanfragen, bevor Sie sich festlegen.

3. Netzstabilität: Schwankungen zählen, nicht nur Erreichbarkeit

„Die Seite öffnet sich“ bedeutet nicht „die API lässt sich stabil aufrufen“. Relevant sind Time to First Byte, Gesamtdauer, Timeout-Quote und Abbruchrate beim Streaming. Auslandsstrecken neigen in den Abendspitzen zu höherer Latenz und Paketverlust; das äußert sich in gelegentlichen Timeouts, Verbindungsresets oder abgebrochenen Streams und nicht darin, dass jeder Aufruf scheitert.

Ein eigener Proxy löst das Routenproblem nicht automatisch: Serverstandort, Rückroute und mögliche Drosselung beeinflussen die Stabilität. Der Vorteil eines inländischen Gateways liegt im inländischen Einstiegspunkt und der vom Dienstleister betriebenen Strecke; die tatsächliche Latenz muss dennoch gemessen werden.

Verlassen Sie sich nicht auf Ping. Senden Sie echte Anfragen über einen längeren Zeitraum und erfassen Sie Erfolgsrate, P95-Latenz und Timeout-Zahl. Der folgende Befehl zeigt die Dauer der einzelnen Phasen:

curl -o /dev/null -sS \
  -w "dns=%{time_namelookup}s tcp=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s code=%{http_code}\n" \
  "$OPENAI_BASE_URL/models" \
  -H "Authorization: Bearer $OPENAI_API_KEY"

Langsames DNS deutet auf die Auflösung hin, langsames TCP auf die Route, langsames TLS auf Handshake und Zertifikat, ein langsames erstes Byte meist auf Warteschlangen beim Upstream. Messen Sie morgens, mittags und abends; das ist aussagekräftiger als ein einzelner Lauf.

4. Zahlung, Rechnungen und Budget

Die offizielle Direktverbindung setzt eine von OpenAI unterstützte Zahlungsmethode voraus; Währung, Zahlungsziel und Rechnungsregeln liegen im offiziellen System. Ein eigener Proxy umgeht die Zahlung nicht: Server und Upstream-Konto kosten jeweils Geld, nur eben getrennt. Inländische Gateways unterstützen üblicherweise Aufladung in RMB und inländische Abrechnung; Rechnungen werden nach den Regeln des Dienstleisters ausgestellt, was für Teams mit lokaler Kostenabrechnung praktisch ist.

Unabhängig vom Weg sollten Sie ein Budgetlimit und Nutzungsalarme einrichten. Preise ändern sich; dieser Artikel nennt keine konkreten Stückpreise und verweist auf die Preisübersicht. Die Finanzabteilung sollte drei Punkte klären: ob für Aufladungen ordnungsgemäße Belege ausgestellt werden, ob Restguthaben erstattet wird und ob der Dienst bei Zahlungsverzug gedrosselt oder sofort unterbrochen wird.

5. Compliance und Bedingungen: Grenzen zuerst klären

Dieser Abschnitt beschreibt nur die Prüfmethode und keine Umgehungswege. Teams sollten mindestens vier Punkte klären:

  1. Entspricht die Nutzung lokalem Recht und regulatorischen Anforderungen?
  2. Werden die Bedingungen von OpenAI und der Upstream-Anbieter eingehalten?
  3. Wurde die Datenübermittlung ins Ausland bewertet, und sind personenbezogene oder sensible Daten betroffen?
  4. Verlangt der Dienstleister eine Identitätsprüfung, gibt es einen Datenverarbeitungsvertrag und eine Beschwerdestelle?

Compliance ist keine Zeile in der Auswahltabelle, sondern eine Zulassungsvoraussetzung. Ist einer der Punkte nicht erfüllt, sollte auch ein niedriger Preis keinen Produktivstart rechtfertigen. Bei Unsicherheit fragen Sie Rechtsabteilung oder Fachberatung; technische Maßnahmen ersetzen keine rechtliche Bewertung.

6. Wartungsaufwand: Ein Proxy ist nicht mit der Installation erledigt

Mit dem Start des eigenen Proxy beginnt die Arbeit erst. Danach folgen Zertifikatserneuerung, Programmupdates, Logs und Speicherplatz, Zugriffskontrolle, IP-Wechsel, Ratenbegrenzung sowie Monitoring und Alarmierung. Liegt der Key auf dem Proxy, muss er zusätzlich gegen Offenlegung und Scan-Angriffe geschützt werden. Ohne Bereitschaftsplan treten Störungen häufig nachts auf.

Ein Gateway verlagert diese Ebene zum Dienstleister, doch das Team sollte drei Fähigkeiten behalten: Nutzung einsehen, Request-IDs aufbewahren und bei Störungen auf eine Ausweichstrecke wechseln. Wer sich vollständig auf einen einzigen Zugang verlässt, gibt die Verfügbarkeit aus der Hand; wer alles selbst betreibt, gibt sie an die eigene Personalsituation. Die Wahl hängt davon ab, welche Risiken das Team eher tragen möchte.

7. Modellabdeckung und Störungsbehandlung

Für Teams, die ausschließlich OpenAI nutzen, ist die Modellabdeckung kein Thema. Wer mehrere Anbieter parallel verwendet, profitiert stärker von einem Gateway: eine Base URL, ein Key, eine Rechnung. „Kompatibel“ bedeutet jedoch meist nur kompatibles Anfragoformat; Parameter, Tool-Aufrufe und Streaming-Formate unterscheiden sich zwischen Modellen. Prüfen Sie vor dem Wechsel jeden Punkt einzeln.

Bei Störungen analysieren Direktverbindung und Proxy das Team selbst, beim Gateway lokalisiert der Dienstleister den Upstream. In jedem Fall sollte die Nutzerseite Statuscode, Response-Body und Request-ID aufbewahren. Bei 5xx nicht endlos wiederholen, sondern maximale Versuche und Gesamt-Timeout setzen. Bei einem Stream-Abbruch prüfen Sie zuerst, ob bereits Teilausgaben erzeugt und abgerechnet wurden.

8. Timeouts, Wiederholungen und Ausweichkonfiguration

Das folgende Python-Beispiel ist direkt einsetzbar: Bei einem Fehler auf der Hauptstrecke wird bedingt wiederholt und anschließend auf eine Ersatzadresse gewechselt. Der Modellname kommt aus einer Umgebungsvariable und ist nicht fest verdrahtet.

import os
import random
import time
from openai import OpenAI

PRIMARY = OpenAI(
    api_key=os.environ["PRIMARY_API_KEY"],
    base_url=os.environ["PRIMARY_BASE_URL"],
    timeout=45.0,
    max_retries=0,
)
FALLBACK = OpenAI(
    api_key=os.environ["FALLBACK_API_KEY"],
    base_url=os.environ["FALLBACK_BASE_URL"],
    timeout=45.0,
    max_retries=0,
)
RETRYABLE = {408, 409, 429, 500, 502, 503, 504}

def call(prompt: str) -> str:
    clients = [PRIMARY, FALLBACK]
    last_error = None
    for client in clients:
        for attempt in range(3):
            try:
                resp = client.responses.create(
                    model=os.environ["OPENAI_MODEL"],
                    input=prompt,
                )
                return resp.output_text
            except Exception as exc:
                last_error = exc
                status = getattr(exc, "status_code", None)
                if status not in RETRYABLE:
                    break
                wait = min(2 ** attempt, 8) + random.random()
                time.sleep(wait)
    raise RuntimeError("Haupt- und Ersatzstrecke sind fehlgeschlagen") from last_error

Wichtig: Der Timeout muss kürzer sein als die maximal tolerierte Wartezeit im Geschäftsprozess; wiederholt wird nur bei wiederholbaren Fehlern; die Ersatzstrecke wird vorab konfiguriert und regelmäßig getestet; die Zahl der Versuche bleibt klein, damit bei einer Störung keine Anfragelawine entsteht.

9. Checkliste für den Produktivstart

Der Reihe nach abarbeiten und erst dann den Verkehr hochfahren:

  1. Strecke praktisch getestet; Erfolgsrate und P95-Latenz für Morgen, Mittag und Abend dokumentiert.
  2. Zahlungsmethode funktioniert; Budget- und Guthabenalarme sind eingerichtet.
  3. Keys sind nach Umgebung getrennt und liegen im serverseitigen Secret-Management.
  4. Die Base URL enthält genau ein /v1; Modellnamen stammen aus der Preisübersicht.
  5. Timeout, Wiederholungen und Ausweichroute sind konfiguriert und getestet.
  6. Logs enthalten Request-ID, Modell, Dauer und Statuscode, aber keinen vollständigen Key.
  7. Compliance- und Datenanforderungen sind geprüft, interne Freigaben liegen bei Bedarf vor.
  8. Die Ersatzstrecke ist verfügbar; Umschaltung ist dokumentiert und einer Person zugewiesen.

10. Häufige Fragen

Ist die Direktverbindung für Teams in China zwangsläufig instabil?

Nein. Die Streckenqualität unterscheidet sich stark nach Region, Netzbetreiber und Tageszeit; messen Sie mit eigenen Geschäftsanfragen. Stabilität ist ein Wahrscheinlichkeitsthema.

Muss man beim eigenen Proxy das Upstream-Konto selbst verwalten?

Ja. Der Proxy löst nur Weiterleitung und einheitlichen Ausgang. Upstream-Konto, Key, Zahlung und Einhaltung der Bedingungen bleiben separate Aufgaben und bringen nicht automatisch verfügbares Kontingent.

Was ist weniger aufwendig: Gateway oder Proxy?

In der Regel das Gateway, weil Server, Zertifikate, Updates und ein Teil der Upstream-Störungen beim Dienstleister liegen. Der Preis ist die Abhängigkeit; behalten Sie eine Ersatzstrecke und die Möglichkeit, Nutzungsdaten zu exportieren.

Muss beim Wechsel zum Gateway viel Code geändert werden?

Bei den meisten kompatiblen Gateways nur Base URL und Key; Modellnamen werden laut Preisübersicht ersetzt. Bei nicht standardisierten Parametern oder privaten Schnittstellen ist eine vollständige Regression nötig.

Was prüft man bei einer Störung zuerst?

Zuerst Statuscode und Response-Body, dann die Request-ID und schließlich die Abgrenzung zwischen lokalem Netz, Einstiegspunkt und Upstream. Ohne Request-ID werden Kommunikation und Analyse deutlich langsamer.

Nächster Schritt

Keiner der drei Wege ist grundsätzlich überlegen. Klären Sie zuerst Zahlung, Compliance und Störungsbehandlung und validieren Sie dann mit echtem Verkehr. Wenn Sie Aufladung in RMB und einen einheitlichen Multi-Modell-Zugang benötigen, beginnen Sie mit der Registrierung beim ZSQH AI Gateway; Preise und Modelle entnehmen Sie der Preisübersicht.

Weiterlesen: