Embedding API aus China: Direktverbindung, Gateway, Stabilität (2026)

Für Teams in China liegt die Schwierigkeit beim Anschluss einer Embedding API selten im SDK. Zeit kosten vielmehr die Stabilität der Verbindungsstrecke, die Bezahlung, die Rechnungsstellung und die Frage, was zu tun ist, wenn die Vektorisierung von Hunderttausenden Texten zur Hälfte scheitert. Embedding-Anfragen sind kurz, parallelitätsstark und volumenreich; die Auswahlkriterien unterscheiden sich daher von denen einer Chat-API.

Dieser Artikel vergleicht drei gängige Wege – offizielle Direktverbindung, selbst betriebener Proxy und inländisches KI-Gateway – und behandelt Zuverlässigkeitsdesign für Batch-Aufgaben, Grenzen des Ausfallswechsels sowie eine Startcheckliste. Modelle, Dimensionen und Abrechnung richten sich nach der Preisübersicht.

Hinweis: OpenAI und andere Modell- und Dienstnamen sind Marken der jeweiligen Rechteinhaber; dieser Artikel steht in keiner Verbindung zu den Anbietern. Grenzüberschreitende Netzwerke, Datenausfuhr und Zahlungsabwicklung unterliegen dem lokalen Recht und den Plattformbedingungen. Ziehen Sie vor der Umsetzung Rechts- und Compliance-Fachleute hinzu.

1. Die drei Wege im Überblick

Offizielle Direktverbindung: Sie rufen die Schnittstelle des Modellanbieters direkt auf. Die Strecke ist am kürzesten, Dokumentation und Funktionen sind aktuell. Geeignet für Teams mit grenzüberschreitendem Netzwerk, Auslandszahlungsweg und Spesenprozess. Der Preis dafür: Netzqualität, Dollarbeträge, Wechselkurs und Rechnungen liegen bei Ihnen.

Selbst betriebener Proxy: Auf einem regelkonformen Server wird ein Reverse-Proxy oder Gateway betrieben, der Authentifizierung, Logs, Wiederholungen und Drosselung bündelt. Die Kontrolle ist hoch, aber Server, Zertifikate, Upgrades und Rufbereitschaft tragen Sie selbst. Wer nur „einfach“ sein will, unterschätzt die Betriebskosten häufig.

Inländisches KI-Gateway: Ein Dienstleister bietet einen OpenAI-kompatiblen Einstieg mit Abrechnung in RMB, meist mit Kundenportal, Nutzungsstatistik und Rechnungen. Der Anschlussaufwand ist niedrig und mehrere Modelle lassen sich bündeln. Zu prüfen sind Rechtssubjekt, Datenbedingungen, Limitregeln und Störungsreaktion.

Kriterium	Offizielle Direktverbindung	Eigener Proxy	Inländisches KI-Gateway
Netzwerk und Zugang	Abhängig von der Auslandsstrecke, eigene Optimierung nötig	Route wählbar, Betrieb selbst	Inländischer Einstieg, meist sofort nutzbar
Zahlung und Rechnung	USD-Abrechnung, längerer Spesenweg	Abhängig von Konto und Server-Rechtssubjekt	RMB-Abrechnung, Rechnung möglich
Batch-Durchsatz	An Kontolimits gebunden	Warteschlange möglich, Upstream-Limit bleibt	Abhängig von Gateway-Limits und Scheduling
Datengrenze	Ausfuhr und Bedingungen selbst bewerten	Datenstandort selbst verantworten	Bedingungen und Qualifikation des Anbieters prüfen
Betriebsaufwand	Mittel, vor allem Netz und Konto	Hoch: Server, Zertifikate, Monitoring	Niedrig, zentrale Verwaltung im Portal
Modellabdeckung	Meist ein Anbieter	Selbst erweiterbar	Häufig mehrere Anbieter

Kein Weg passt für jedes Team. Wer nur ein Modell nutzt und Netz sowie Zahlung stabil laufen, fährt mit der Direktverbindung am einfachsten. Wer festen Ausgang und Audit braucht, wählt den eigenen Proxy. Wer keine Betriebskapazität hat und mehrere Modelle mit einer Rechnung bündeln will, prüft ein inländisches Gateway.

2. Netzwerktest: Bei Embeddings zählt Durchsatz, nicht nur Latenz

Bei Chat-APIs interessiert die Time-to-First-Token; bei Embeddings zählen Batch-Durchsatz und Stabilität. Eine Anfrage kann Dutzende bis Hunderte Texte enthalten, die Antwort besteht aus Hunderten oder Tausenden Gleitkommazahlen. Netzprobleme äußern sich als Timeout, abgeschnittene Antworten und 5xx.

Senden Sie im Test nicht nur ein „Hallo“. Verwenden Sie Dokumentblöcke realistischer Länge und Produktions-Batchgrößen und beobachten Sie mindestens vier Werte: Dauer pro Batch, P50/P95-Latenz, Fehlerrate und Verhalten in der Abendspitze. Prüfen Sie außerdem Größenlimits des Request-Bodys, Verbindungswiederverwendung und Timeout-Einstellungen von Proxy oder Gateway; wird eine große Anfrage in einer Zwischenschicht abgeschnitten, ist die Fehlermeldung oft wenig aussagekräftig.

Lange Aufgaben müssen ab einem Prüfpunkt fortgesetzt werden können. Eingaben nach Inhalts-Hash nummerieren, jeden erfolgreichen Batch speichern und nur fehlende Teile erneut senden, statt den gesamten Bestand neu zu starten.

3. Zahlung, Vertrag und Rechnung

Ein häufiger Engpass für Teams in China ist das Zahlungssubjekt. Aufladung per Privatkarte, Zahlung durch Dritte und uneinheitliche Belege lassen sich in der Buchhaltung oft nicht verbuchen. Klären Sie vor der Wahl: Mit wem wird der Vertrag geschlossen, in welcher Währung wird abgerechnet, welche Rechnungsart ist möglich, hat das Guthaben ein Verfallsdatum und wie lauten die Erstattungsregeln?

Bei nutzungsbasierter Abrechnung zusätzlich die Logik prüfen: nach Input-Token oder pro Anfrage, werden fehlgeschlagene Anfragen gezählt, werden Wiederholungen doppelt berechnet, lässt sich die Nutzung nach Projekt oder Key aufteilen? Halten Sie dies in der Vergleichstabelle fest und testen Sie mit denselben Daten, um die tatsächlichen Kosten zu ermitteln. Konkrete Kosten richten sich nach der Preisübersicht und dem Vertrag.

4. Zuverlässigkeitsdesign für Batch-Aufgaben

Vektorisierung ist meist Offline-Batch-Verarbeitung. Am problematischsten ist ein Abbruch bei 80 Prozent ohne Fortsetzungsmöglichkeit. Empfohlener Ablauf:

1. Für jeden Text einen Inhalts-Hash als Idempotenzschlüssel erzeugen; wiederholtes Senden überschreibt, statt doppelt einzuspielen.
2. Zuerst nach Token schätzen und dann unter drei Limits aufteilen: Elemente pro Anfrage, Länge pro Text und Gesamt-Token.
3. Parallelität schrittweise von niedrig nach hoch erhöhen und den 429-Anteil beobachten; nicht sofort voll aufdrehen.
4. Bei 429 und 5xx exponentielles Backoff mit zufälligem Jitter und eine maximale Wiederholungszahl verwenden.
5. Nach jedem Batch Erfolgszahl, Token-Verbrauch und Laufzeit protokollieren; fehlgeschlagene Stichproben separat speichern.
6. Vor dem Einspielen Dimension, leere Vektoren und NaN prüfen; Anomalien isolieren statt stillschweigend schreiben.
7. Nach Abschluss stichprobenartig vergleichen und bestätigen, dass Anzahl, Dimension und Indexstatistik übereinstimmen.

Der Ablauf ist nicht komplex, verhindert aber das Muster „sieht fertig aus, tatsächlich fehlt ein Batch“.

5. Drosselung, Wiederholungen und Ausfallswechsel

Embedding-Schnittstellen drosseln üblicherweise nach Anfragezahl und Token. Bei Überschreitung kommt 429; bei Gateway-Überlast sind 5xx oder Timeouts möglich. Die Wiederholungsstrategie muss Fehlertypen unterscheiden: 429 und kurzfristige 5xx dürfen mit Backoff wiederholt werden; bei 401, 403 und Parameterfehlern ist Wiederholen sinnlos, zuerst die Konfiguration korrigieren.

import os
import time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["ZSQH_API_KEY"],
    base_url=os.environ["ZSQH_BASE_URL"],
    timeout=60.0,
    max_retries=0,
)

def embed_batch(texts, model, attempts=4):
    for i in range(attempts):
        try:
            resp = client.embeddings.create(model=model, input=texts)
            vectors = [item.embedding for item in resp.data]
            dims = {len(v) for v in vectors}
            if len(dims) != 1 or len(vectors) != len(texts):
                raise ValueError("Dimension oder Anzahl inkonsistent")
            return vectors, resp.usage
        except Exception as exc:
            if i == attempts - 1:
                raise
            wait = min(2 ** i, 30) + 0.5 * (i + 1)
            print(type(exc).__name__, "retry in", wait)
            time.sleep(wait)

vectors, usage = embed_batch(
    ["Erster Textabschnitt", "Zweiter Textabschnitt"],
    os.environ["EMBEDDING_MODEL"],
)
print(len(vectors), len(vectors[0]), usage)

Beim Ausfallswechsel gibt es eine leicht übersehene Grenze: Vektoren unterschiedlicher Embedding-Modelle lassen sich nicht mischen. Selbst bei gleicher Dimension ist der Vektorraum nicht identisch; schreibt man Vektoren zweier Modelle in denselben Index, verschlechtert sich das Retrieval deutlich. Beim Wechsel des Upstream daher zuerst prüfen, ob Modell und Version identisch sind. Ist ein Modellwechsel nötig, neuen Index anlegen, vollständig neu berechnen, Ergebnisse vergleichen und erst dann umschalten – nicht während einer Störung spontan den Modellnamen ändern.

6. Checkliste vor dem Livegang

• Dimension: stimmt mit der Indexkonfiguration überein, und die Anzahl zurückgegebener Vektoren entspricht der Eingabe.
• Baseline: Mit einem festen Testset die Kosinus-Ähnlichkeit gegen die Direktverbindung vergleichen; sie sollte sehr nahe liegen.
• Nutzung: Lässt sich usage aus der Antwort mit der Rechnung abgleichen? Batch-Anfragen einzeln prüfen.
• Drosselung: Sind Parallelitätsobergrenze, 429-Anteil und Erfolgsquote nach Wiederholungen akzeptabel?
• Timeout: Schafft der größte Batch in der Abendspitze die Antwort innerhalb des Timeouts?
• Daten: Enthält die Eingabe personenbezogene Daten, und sind Aufbewahrung, Logs und Löschstrategie des Anbieters nachvollziehbar?
• Ausstieg: Lässt sich der Key rotieren, Guthaben erstatten und bleiben alter Index sowie Rückfallweg erhalten?

Ist ein Punkt unklar, zunächst mit kleinem Traffic testen und den Produktionsindex nicht direkt umziehen.

7. Auswahl nach Rahmenbedingungen

Prüfen Sie zuerst, ob Netz und Zahlung langfristig stabil sind, dann, ob fester Ausgang und Audit nötig sind, und schließlich Modellabdeckung und Rechnungsfähigkeit. Wer einheitlichen Einstieg, RMB-Abrechnung und Modellvergleiche braucht, kann im ZSQH AI Gateway einen Test-Key anlegen, zunächst mit kleinen Datenmengen testen und dann schrittweise ausbauen. Verfügbare Modelle und Abrechnungsarten stehen in der Preisübersicht.

Weiterlesen:

• Embedding API Relay: Batch, Abrechnung und Migration
• Embedding API Fehler beheben: 401, 413, 429 und Dimensionsfehler
• OpenAI API in China: Direktverbindung, Proxy oder Gateway

Häufige Fragen

Wie unterscheidet sich der Zugang zu Embedding- und Chat-APIs?

Bei Chat-APIs stehen Time-to-First-Token und Streaming-Stabilität im Vordergrund. Embeddings sind Batch-Aufgaben mit kurzen Antworten und hohem Gesamtvolumen; wichtiger sind Durchsatz, Obergrenzen pro Anfrage und Fortsetzen nach Fehlern. Batch-Lasttest und Wiederaufnahme gehören in die Planung.

Ist die Direktverbindung zur Embedding API aus China stabil?

Das hängt vom lokalen Ausgang, der Tageszeit und den Kontolimits ab und lässt sich nicht pauschal beantworten. Beobachten Sie echte Batchgrößen und Parallelität über einen längeren Zeitraum, protokollieren Sie Fehlerrate und P95-Latenz und vergleichen Sie mit der Gateway-Lösung. Ziehen Sie keine Schlüsse aus einer einzelnen erfolgreichen Anfrage.

Was tun, wenn die Batch-Vektorisierung unterbrochen wird?

Inhalts-Hashes als Idempotenzschlüssel verwenden, batchweise speichern und nur fehlende Teile ergänzen. Vor dem erneuten Lauf Anzahl und Dimension der bereits eingespielten Daten prüfen, um doppelte Einträge oder halbe Batches als vollständige Ergebnisse zu vermeiden.

Lassen sich alte Vektoren nach einem Gateway-Wechsel weiterverwenden?

Bei identischem Modell und identischer Version in der Regel ja; bei einem Modellwechsel ist ein Neuaufbau erforderlich. Vergleichen Sie vor der Migration mit einem festen Testset die Kosinus-Ähnlichkeit alter und neuer Vektoren und behalten Sie den alten Index als Rückfallweg.

Lassen sich Rechnung und Nutzung nach Projekt aufteilen?

Das hängt vom Anbieter ab. Klären Sie vor Vertragsschluss, ob sich die Nutzung nach Projekt, Key oder Modell exportieren lässt, ob die Abrechnung fehlgeschlagene und wiederholte Anfragen enthält und ob der Rechnungsinhalt den Beschaffungsanforderungen entspricht.