Embedding API Relay und Proxy: Batch, Abrechnung, Migration (2026)

Ein Embedding-API-Relay wird oft als reine Frage des Endpunkts und des Preises behandelt: andere URL, etwas günstiger, fertig. Vektorisierung ist jedoch eine Batch-Aufgabe. Eine Migration kann Hunderttausende Textblöcke umfassen. Wenn der Relay drosselt, Eingaben abschneidet oder stillschweigend das Modell wechselt, ist nicht eine Anfrage verloren, sondern die Verlässlichkeit des gesamten Index.

Dieser Artikel behandelt vier Fragen: welche Formen von Relay es gibt, wie Batch-Anfragen aufgebaut werden, wie Sie die Abrechnung prüfen und wie Migration und Verifikation ablaufen. Maßgeblich für Modelle und Preise ist die Preisübersicht.

Hinweis: OpenAI und andere Modell- und Dienstnamen sind Marken der jeweiligen Rechteinhaber. Dieser Artikel steht in keiner Verbindung zu den genannten Anbietern. Der Relay-Markt verändert sich schnell; der Beitrag ist keine Empfehlung für einzelne Anbieter.

1. Relay, Proxy und Gateway sind nicht dasselbe

Netzwerk-Proxy: löst nur die Erreichbarkeit, leitet HTTP- oder HTTPS-Anfragen weiter, der Key bleibt in eigener Verwaltung.
Kommerzieller Relay: ein Dienstleister leitet an den Upstream weiter, gegebenenfalls mit Abrechnung, Limits, Logs und Rechnungen. Auf dem Markt gibt es auch geteilte oder weiterverkaufte Keys; die Stabilität hängt vom Betreiber ab.
Einheitliches KI-Gateway: bietet einen OpenAI-kompatiblen Einstieg, bündelt mehrere Modelle, vergibt eigene Keys und liefert Konsole sowie Nutzungsstatistik.
Selbst betriebener Proxy: Sie deployen einen Reverse-Proxy oder ein Gateway selbst. Das bietet die größte Kontrolle, aber Betrieb und Upstream-Konto liegen bei Ihnen.

Klären Sie vor der Buchung, welche Schicht der Anbieter abdeckt, wem der Key gehört und wo die Daten durchlaufen. Ohne diese Klarheit verliert jeder weitere Vergleich seinen Bezugspunkt.

Kriterium	Offizielle Direktverbindung	Eigener Proxy	Kommerzieller Relay	Einheitliches KI-Gateway
Abrechnung	Anbieterrechnung, klare Regeln	Upstream-Rechnung plus eigene Kosten	Vom Betreiber abhängig, Abgleich nötig	Einheitliche Rechnung im Portal
Batch-Durchsatz	An Kontolimits gebunden	Warteschlange möglich, Upstream-Limit bleibt	Möglicher gemeinsam genutzter Pool	Abhängig von Gateway-Limits und Scheduling
Key-Zugehörigkeit	Eigener Key	Eigener Key	Möglicherweise geteilt oder weiterverkauft	Meist eigener Key
Datengrenze	Selbst bewerten	Selbst verantworten	Bedingungen und Aufbewahrung prüfen	Bedingungen und Qualifikation prüfen
Rechnung und Vertrag	Vom Rechtssubjekt abhängig	Kein Drittvertrag	Von den Fähigkeiten des Anbieters abhängig	Meist Rechnung möglich
Betriebsaufwand	Mittel	Hoch	Niedrig bis mittel	Niedrig

2. Batch-Anfragen: erst Lasttest, dann Preis

Der Durchsatz von Embeddings hängt von drei Variablen ab: Anzahl der Texte pro Anfrage, Länge des einzelnen Textes und Parallelität. Anbieter setzen unterschiedliche Obergrenzen für Elemente pro Anfrage, Gesamt-Token und Request-Größe. Wird eine überschritten, kann eine Parametermeldung zurückkommen oder eine Zwischenschicht schneidet die Anfrage still ab.

Testen Sie mit Produktionsdaten. Nehmen Sie echte Dokumentblöcke und stellen Sie Anfragen in kleinen, mittleren und großen Batches zusammen. Beobachten Sie Dauer pro Batch, P95-Latenz, 429-Anteil und Fehlertypen. Größer ist nicht automatisch besser: Bei sehr großen Batches kostet ein Fehlschlag viel Wiederholungsarbeit, und Timeouts lassen sich schlechter kontrollieren.

Empfohlener Ablauf für die Stückelung:

Zuerst die Längenverteilung der Texte erfassen und nach Token schätzen, nicht nach Anzahl hart schneiden.
Ein Limit pro Batch setzen und Reserve für lange Texte lassen.
Parallelität niedrig beginnen und pro Runde erhöhen; Durchsatz und Fehlerrate protokollieren.
Beim Ziel-Durchsatz aufhören zu erhöhen, damit die Reserve nicht vollständig verbraucht wird.
Für jeden Batch Eingabe-Hash, Token-Verbrauch und Ergebnis speichern, um Abgleich und Fortsetzen zu erleichtern.

3. Wiederholungen und Teilfehler

Embedding-Anfragen sind Leseoperationen. Eine Wiederholung erzeugt keine doppelten Schreibvorgänge, kann aber Fehlschläge in Rechnungskosten verwandeln. Bei 429 und kurzzeitigem 5xx sind exponentielles Backoff und zufälliges Jitter sinnvoll. Bei 401, 403, 404 und Parameterfehlern sofort stoppen und zuerst Key, Adresse oder Request-Body korrigieren.

Teilfehler brauchen eine eigene Behandlung. Wenn in einem Batch von 200 Texten drei wegen Überlänge abgelehnt werden, nicht den gesamten Batch endlos wiederholen. Die problematischen Texte herauslösen, korrigieren oder kürzen und separat senden; die übrigen Ergebnisse normal übernehmen. Für das Einspielen einen Inhalts-Hash als Upsert-Schlüssel verwenden, damit ein erneuter Lauf keine doppelten Datensätze erzeugt.

import hashlib
import os
import time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["RELAY_API_KEY"],
    base_url=os.environ["RELAY_BASE_URL"],
    timeout=60.0,
    max_retries=0,
)
MODEL = os.environ["EMBEDDING_MODEL"]

def key_of(text):
    return hashlib.sha256(text.encode("utf-8")).hexdigest()

def embed_with_retry(batch, attempts=4):
    for i in range(attempts):
        try:
            resp = client.embeddings.create(model=MODEL, input=batch)
            store = {
                key_of(batch[d.index]): d.embedding
                for d in resp.data
            }
            return store, resp.usage
        except Exception as exc:
            if i == attempts - 1:
                raise
            time.sleep(min(2 ** i, 30))

texts = ["Dokumentblock eins", "Dokumentblock zwei", "Dokumentblock drei"]
store, usage = embed_with_retry(texts)
print(len(store), len(next(iter(store.values()))), usage)

4. Transparenz der Abrechnung

Embeddings werden üblicherweise nach Input-Token abgerechnet, ohne Output-Token. Das unterscheidet sie von Chat-Modellen. Für den Abgleich sollten Sie klären:

Wie Token berechnet werden und ob der Tokenizer des Anbieters verwendet wird.
Ob fehlgeschlagene und wiederholte Anfragen abgerechnet werden.
Ob es Batch-Rabatte, Caching oder Staffelpreise gibt.
Ob sich die Nutzung nach Projekt, Key und Modell exportieren lässt.
Ob Guthaben ein Verfallsdatum hat und ob Restbeträge erstattet werden.
Wie Rechnungsinhalt, Währung und Wechselkurs festgelegt werden.

Ein niedriger Multiplikator bedeutet nicht automatisch niedrigere Gesamtkosten. Wenn ein Relay auch fehlgeschlagene Wiederholungen berechnet oder die Nutzungsstatistik nicht zum usage-Feld der Antwort passt, fressen versteckte Verluste den Preisvorteil auf. Maßgeblich sind die Preisübersicht und die tatsächliche Rechnung des Anbieters, nicht mündliche Zusagen.

5. Key-Risiken und Datengrenzen

Am häufigsten übersehen wird beim Relay die Frage, wem der Key gehört. Geteilte Keys, weiterverkaufte Kontingente oder Guthaben unklarer Herkunft bringen vier Probleme: Bei einer Sperre des Upstream-Kontos fällt der Betrieb mit aus; mehrere Kunden teilen sich Limits und beeinflussen sich gegenseitig; Anfrageinhalte laufen über Dritte, Logs und Aufbewahrung bleiben undurchsichtig; und wenn die Nutzungsbedingungen den Weiterverkauf untersagen, fehlt bei Streitigkeiten die Grundlage.

Klären Sie bei der Auswahl mindestens Firmensitz und Rechtssubjekt, Nutzungsbedingungen, Datenschutzerklärung, Speicherort der Daten, Rechnungsfähigkeit und einen Kontakt für Störungen. Texte mit personenbezogenen Daten, Vertragstexten oder Schlüsseln sollten nicht an einen Relay gehen, der den Datenfluss nicht erklären kann. In stark regulierten Umgebungen sind Direktverbindung, private Bereitstellung oder Anbieter mit unterzeichenbarem Datenverarbeitungsvertrag vorzuziehen.

6. Migrationscheckliste

Für den Wechsel von der Direktverbindung zu einem Relay oder Gateway empfehlen wir diese Reihenfolge:

Bestehende Modelle, Dimensionen, Batch-Parameter und Indexstruktur erfassen; Baseline für Erfolgsquote und P95-Latenz festhalten.
Mit einem festen Testset einmal gegen die Direktverbindung laufen und Vektoren, usage und Laufzeit speichern.
Einen neuen Test-Key mit Budget und Warnschwellen anlegen, nicht den Produktions-Key wiederverwenden.
Nur base_url und api_key ändern und in einer Vorabumgebung eine minimale Anfrage zum Laufen bringen.
Dasselbe Testset über den Relay senden und Dimension, Anzahl, usage und Kosinus-Ähnlichkeit vergleichen.
5 bis 10 Prozent der Batch-Aufgaben schrittweise umstellen, drei bis sieben Tage beobachten und die Direktverbindung als Rückfallweg behalten.
Nach der vollständigen Migration eine Woche lang abgleichen: Rechnung, Anzahl eingespielter Datensätze und fehlgeschlagene Wiederholungen müssen zusammenpassen.
Mindestens eine Version des alten Index aufbewahren und erst nach stabiler Retrieval-Qualität aufräumen.

Wenn der Relay ein anderes Modell verwendet, dürfen alte Vektoren nicht einfach weiterverwendet werden. Bauen Sie einen parallelen Index, berechnen Sie alles neu und vergleichen Sie die Retrieval-Ergebnisse, bevor Sie umschalten.

7. Woran man einen verlässlichen Relay erkennt

Vektorkonsistenz: Dieselbe Eingabe einmal direkt und einmal über den Relay senden, Dimension und Kosinus-Ähnlichkeit vergleichen. Bei deutlicher Abweichung zuerst prüfen, ob das Modell gewechselt oder die Eingabe gekürzt wurde.
Konsistenz der Nutzung: usage in der Antwort Batch für Batch mit der Abrechnung abgleichen; besonders prüfen, ob Fehler und Wiederholungen doppelt berechnet werden.
Latenz und Fehlerrate: Mit echten Batches zur Hauptverkehrszeit testen und P50/P95, 429- und 5xx-Anteil erfassen.
Batch-Obergrenzen: Limits für Elemente pro Anfrage, Gesamt-Token und Request-Größe bestätigen, damit Produktionsbatches nicht abgeschnitten werden.
Key-Isolation: Prüfen, ob der Key exklusiv ist, rotiert werden kann und ob Kontingent und Drosselung mit anderen Kunden geteilt werden.
Vertrag und Support: Rechtssubjekt, Bedingungen, Rechnung und Reaktionszeit prüfen. Nur eine private Kontaktadresse und keine Nutzungsdetails sind Warnsignale.

Das model-Feld in der Antwort ist allein kein Beweis, denn es kann überschrieben werden. Eine Kombination mehrerer Prüfungen ist verlässlicher als eine Einzelmessung.

8. Wann ein Relay nicht sinnvoll ist

Wenn Daten sensibel sind und die Aufbewahrungsregeln nicht geprüft werden können, wenn direkter Support des Herstellers nötig ist, wenn das Aufrufvolumen sehr klein ist oder dem Team die Kapazität für den Rechnungsabgleich fehlt, ist ein Relay nicht zwangsläufig wirtschaftlich. Ein Relay umgeht auch keine Upstream-Limits und keine Nutzungsbedingungen. Für gelegentliche kleine Vektorisierungen ist die Direktverbindung mit einem einfachen Skript oft unkomplizierter.

Wer einen einheitlichen Einstieg und Modellvergleiche braucht, kann im ZSQH AI Gateway einen Test-Key anlegen, mit einem festen Testset die Vektorkonsistenz prüfen und danach die Batch-Aufgaben migrieren. Verfügbare Modelle und Abrechnungsarten stehen in der Preisübersicht.

Weiterlesen:

Häufige Fragen

Wie unterscheidet sich ein Embedding-Relay von einem Chat-Relay?

Beim Chat-Relay stehen Streaming und Time-to-First-Token im Vordergrund. Beim Embedding-Relay zählen Batch-Durchsatz, Obergrenzen pro Anfrage, Fortsetzen nach Fehlern und Vektorkonsistenz. Beim Abgleich ist außerdem zu beachten, dass Embeddings üblicherweise nur Input-Token berechnen.

Lassen sich Vektoren aus Relay und Direktverbindung mischen?

Nur bei identischem Modell und identischer Version. Unterschiedliche Modelle haben unterschiedliche Vektorräume; selbst bei gleicher Dimension dürfen sie nicht in denselben Index. Vergleichen Sie vor der Migration mit einem festen Testset die Kosinus-Ähnlichkeit.

Was tun, wenn die Hälfte eines Batches fehlschlägt?

Zuerst den Fehlertyp bestimmen: Bei Drosselung und kurzeitigem 5xx ist Backoff sinnvoll; überlange Texte oder Parameterfehler müssen herausgelöst und separat behandelt werden. Ein Inhalts-Hash als Idempotenzschlüssel sorgt dafür, dass beim erneuten Lauf nur fehlende Teile ergänzt werden.

Wie wird beim Relay abgerechnet?

Meist nach Input-Token. Token-Definition, Behandlung von Fehlern und Wiederholungen sowie mögliche Batch-Rabatte unterscheiden sich jedoch je Anbieter. Maßgeblich sind Rechnung und Nutzungsdetails; halten Sie diese Punkte vor der Buchung in Ihrer Vergleichstabelle fest.

Muss nach der Migration neu vektorisiert werden?

Bei gleichem Modell und gleicher Version normalerweise nicht; bei einem Modellwechsel ist ein Neuaufbau des Index erforderlich. Auch ohne Neuberechnung sollten Sie den alten Index und einen Rückfallweg behalten und die Konsistenz mit einem festen Testset prüfen.