Ein Rerank-API-Relay wirkt zunächst wie eine reine Weiterleitung. Doch das Reranking sitzt an einer kritischen Stelle der Suchkette: Wird es um 100 Millisekunden langsamer, bemerken das Nutzer; ist die Abrechnungseinheit intransparent, entstehen am Monatsende Abgleichprobleme; ändert sich die Modellversion unbemerkt, driftet die Sortierqualität.

Dieser Beitrag behandelt typische Formen von Relay und Proxy, die Auswirkungen auf die Latenz, die Prüfung der Abrechnung und die Migrationsschritte. Er hilft Teams bei der Abwägung zwischen schnellem Start und langfristiger Wartbarkeit. Konkrete Modelle und Preise entnehmen Sie den Dokumentationen der Anbieter und unseren Modellpreisen.

Hinweis: Cohere, Jina AI und weitere genannte Namen sind Marken ihrer jeweiligen Inhaber. Dieser Beitrag steht in keiner Verbindung zu den betreffenden Anbietern. Der Relay-Markt verändert sich schnell; beschrieben wird die übliche Lage im Jahr 2026, ohne Empfehlung für einen bestimmten Anbieter.

1. Rerank-Relay und Chat-Relay sind nicht dasselbe

Bei Chat-API-Relays stehen Streaming, Kontextlänge und Parallelität im Vordergrund; bei Rerank-Relays sind es synchrone Latenz, Dokumentanzahl und Abrechnungslogik. Rerank-Anfragen sind meist kurz, reagieren aber sehr empfindlich im P95. Eine Anfrage kann Dutzende Dokumente enthalten, und die Kosten wachsen mit „Anzahl × Länge“. Zurück kommen nur Indizes und Scores; bei Problemen lässt sich aus der Antwort oft nicht erkennen, welcher Upstream beteiligt war.

Hinzu kommt ein häufig übersehener Punkt: Für Reranking gibt es keinen einheitlichen OpenAI-kompatiblen Standard. Cohere verwendet /v2/rerank, Jina /v1/rerank; Feldnamen und Score-Bereiche können abweichen. Wenn ein Relay eine Protokollübersetzung vornimmt, muss bestätigt sein, dass sich das Ergebnis wie beim Upstream verhält – insbesondere bei Kürzungsstrategien und der Bedeutung von top_n.

2. Vier verbreitete Relay-Formen

Form Kontrolle Latenzquelle Abrechnungstransparenz Key-Inhaberschaft Einsatzszenario
Kommerzieller Relay-Dienst gering, abhängig vom Anbieter Relay-Routing + grenzüberschreitende Strecke hängt von bereitgestellten Aufrufdetails ab Anbieter hält Upstream-Key schnelle Validierung, wenig Traffic
Eigener Reverse-Proxy hoch, eigener Betrieb Serverregion + Upstream-Strecke Upstream-Rechnung direkt sichtbar eigener Key Teams mit Betriebskompetenz
Cloud-Regional-Gateway mittel, an Cloud-Produkt gebunden Aufrufe in derselben Region meist kürzer Cloud-Rechnung aufteilbar eigener Key oder Cloud-Konto bereits in derselben Cloud
Einheitliches AI-Gateway mittel bis hoch, mehrere Upstreams konfigurierbar Gateway-Region + Upstream-Routing einheitliche Rechnung, Multiplikatoren prüfen Gateway-Betreiber oder eigener Key mehrere Modelle und Projekte

Ein eigener Proxy ist nicht automatisch risikofrei: Server, Zertifikate, Retries und Rate-Limits müssen selbst betrieben werden, und die Compliance-Verantwortung für das Upstream-Konto bleibt beim Team. Ein kommerzielles Relay erspart Betriebsaufwand, nicht die Verantwortung für die Auswahl.

3. Wie sich Latenz auf die Suche auswirkt

Zuerst ein End-to-End-Budget aufstellen: Retrieval, Reranking, Generierung und Netzwerk. Der Zusatzaufwand für das Reranking sollte im Bereich einiger hundert Millisekunden bleiben, sonst wirkt die Suche für Nutzer verzögert. Jina nennt als Referenz für 100 Dokumente mit etwa 256 Token und eine Query mit 64 Token rund 150 Millisekunden; bei 4096 Token pro Dokument steigt der Wert auf mehrere Sekunden. Cohere empfiehlt, pro Anfrage nicht mehr als 1000 Dokumente zu senden. Ein Relay fügt eine weitere Station hinzu: RTT, Warteschlange und mögliche Protokollübersetzung.

Maßnahmen zur Latenzreduktion, nach Kosten-Nutzen sortiert: weniger Kandidaten, kürzere Einzeldokumente, kleineres top_n, Relay-Knoten nahe der eigenen Region und Verbindungswiederverwendung. Liegt der Relay-Knoten in einer anderen Region als der Upstream, kann die grenzüberschreitende RTT größer sein als die eigentliche Modellinferenz. Bei Suche mit sofortiger Anzeige lässt sich das Reranking in eine zweite Anfrage verlagern oder nur auf die ersten 20–50 Kandidaten anwenden.

Bei der Messung ist zwischen „Antwortzeit des Relays“ und „End-to-End-Suchzeit“ zu unterscheiden. Eine gute erste Zahl bedeutet keine gute zweite, weil Retries, DNS, TLS-Handshake und Warteschlangen im Durchschnitt verborgen bleiben.

4. Abrechnungstransparenz: drei Modelle müssen zusammenpassen

Für Reranking gibt es drei verbreitete Abrechnungsmodelle: pro Anfrage, pro Dokument oder Search Unit sowie pro Eingabe-Token. Bei gleichem Geschäftsvolumen können die Rechnungen deutlich auseinanderliegen. Zu klären ist: ob top_n die Abrechnung beeinflusst, wie gekürzte Dokumente zählen, ob fehlgeschlagene Anfragen berechnet werden, ob Cache-Treffer vergünstigt sind, ob es Mindestumsätze gibt und ob Multiplikatoren im Stückpreis enthalten sind.

Am wirksamsten ist ein Abgleichversuch: eine feste Anfragemenge sowohl direkt als auch über das Relay senden und Aufrufzahl, Dokumentanzahl, Token und tatsächliche Belastung erfassen. Liefert das Relay nur einen Gesamtsaldo und keine Aufrufdetails, lässt sich später schwer klären, warum die Rechnung gestiegen ist. Für den Unternehmenseinkauf sollten zudem Rechnungssteller, Rechnungszeitpunkt und Erstattungsregeln geklärt werden, damit vorausbezahltes Guthaben nicht zum versunkenen Aufwand wird.

5. Key- und Datenrisiken

Kommerzielle Relays nutzen häufig gemeinsame Upstream-Keys. Das ist schnell verfügbar, aber Rate-Limits, Modellversionen und Sperrrisiken des Upstream-Kontos liegen außerhalb der eigenen Kontrolle; ändert der Upstream seine Politik, betrifft das alle Mandanten. Ein eigener Proxy verlagert Key-Leaks, Missbrauch und unkontrollierte Rechnungen in die eigene Verantwortung.

Rerank-Anfragen enthalten Query und Dokumentausschnitte, möglicherweise Kundeninformationen, Vertragsklauseln oder Inhalte interner Wissensdatenbanken. Vor Vertragsabschluss ist zu klären: ob Anfragen protokolliert werden, wie lange Logs aufbewahrt werden, ob sie für Training genutzt werden, in welcher Region die Daten liegen und wie die Löschung funktioniert. Für sensible Geschäftsbereiche ist ein Anbieter mit Datenverarbeitungsvertrag oder ein im eigenen Umfeld betriebenes Rerank-Modell vorzuziehen.

Vorsicht auch bei vagen Formulierungen wie „Zusammenarbeit mit dem Hersteller“. Ob eine Autorisierung oder ein Enterprise-Vertrag besteht, sollte anhand von Vertrag und prüfbaren Nachweisen beurteilt werden, nicht anhand der Marketingseite.

6. Migrationscheckliste

  1. Bestehende Aufrufe erfassen: Endpunktpfad, Modell, Kandidatenzahl, Timeout- und Retry-Einstellungen.
  2. Baseline sichern: mit echten Queries Sortierergebnisse, P95-Latenz und Fehlerrate aufzeichnen.
  3. Client abstrahieren: URL, Key und Modellname in die Konfiguration auslagern, nicht im Geschäftscode verstreuen.
  4. Parallel betreiben: dieselben Anfragen über den bisherigen Dienst und das neue Relay senden, Sortierung und Qualitätskennzahlen vergleichen.
  5. Scores kalibrieren: Score-Verteilungen unterscheiden sich je Modell; alte Schwellenwerte nicht unverändert übernehmen.
  6. Schrittweise umstellen: zunächst 5–10 % des Traffics, Suchkennzahlen und Rechnung beobachten.
  7. Fallback testen: sicherstellen, dass bei Timeout, 429 und 5xx ein Rückfall auf den alten Dienst oder die ursprüngliche Sortierung möglich ist.
  8. Rollback-Fenster einhalten: alte Konfiguration und alten Key mindestens einen vollständigen Abrechnungszyklus behalten.

Am fehleranfälligsten ist Schritt 5. Rerank-Scores geben nur die relative Reihenfolge innerhalb derselben Kandidatenmenge an und sind modellübergreifend nicht direkt vergleichbar; Modellversion, Kürzungslänge und strukturierte Dokumenteingabe verändern das Ergebnis.

7. Wie ein Relay geprüft wird

Zuerst statisch prüfen: Endpunktpfad, Authentifizierungsart, ob der Modellname fixiert werden kann, ob die Antwort index und relevance_score enthält und ob der Score-Bereich zur Dokumentation passt. Dann dynamisch testen: identische Payloads direkt und über das Relay senden, P50/P95, Fehlerrate und 429-Vorkommen erfassen. Schließlich die Rechnung abgleichen und bestätigen, dass die Aufrufdetails zusammenpassen.

Das folgende minimale Latenzskript verwendet Dokumente in realistischer Länge statt gleich langer Platzhalter:

import statistics, time, requests

URL = "https://<relay-host>/v1/rerank"
HEADERS = {"Authorization": "Bearer <key>"}
PAYLOAD = {
    "model": "<model>",
    "query": "Wie lautet die Rückgaberichtlinie?",
    "documents": ["Realistisch langer Dokumentabschnitt " + str(i) for i in range(50)],
    "top_n": 5,
}

latencies = []
for _ in range(30):
    start = time.perf_counter()
    resp = requests.post(URL, json=PAYLOAD, headers=HEADERS, timeout=3)
    resp.raise_for_status()
    latencies.append((time.perf_counter() - start) * 1000)

latencies.sort()
print("p50", statistics.median(latencies))
print("p95", latencies[int(len(latencies) * 0.95) - 1])

Kann der Relay-Anbieter keine stabile Modellversion oder Aufruflogs bereitstellen, sollte er nur für unkritische Aufgaben genutzt werden. Produktionsumgebungen brauchen einen umschaltbaren Ersatzpfad und regelmäßige Nachmessungen. Teams, die mehrere Anbieter einheitlich anbinden wollen, können sich über das Registrierungsportal über die aktuellen Schnittstellen informieren und anschließend mit den Modellpreisen das Budget schätzen.

8. Häufige Fragen

Wie viel langsamer ist ein Relay als eine Direktverbindung?

Das hängt von Knotenposition und Routing ab. Ein Relay in derselben Region kann nur wenige Millisekunden hinzufügen; eine zusätzliche grenzüberschreitende Station kann einige Dutzend bis mehrere hundert Millisekunden kosten. Entscheidend ist eine P95-Messung mit echten Anfragen, nicht der Durchschnittswert des Anbieters.

Warum stimmt die Relay-Rechnung nicht mit der Upstream-Rechnung überein?

Häufig wegen unterschiedlicher Abrechnungsmodelle: pro Anfrage, pro Dokument, pro Token oder mit Multiplikatoren, Mindestumsatz und berechneten Fehlanfragen. Vor Vertragsabschluss sollten Abrechnungsformel und ein Beispiel für Aufrufdetails verlangt werden.

Ist es normal, dass sich die Sortierung nach dem Wechsel ändert?

Ja. Modellversion, Kürzungslänge, Behandlung strukturierter Dokumente und Score-Normalisierung können abweichen. Mit derselben Query-Menge vergleichen und die fachlichen Schwellenwerte neu kalibrieren.

Was tun, wenn der Relay-Dienst eingestellt wird?

Zwei Dinge frühzeitig vorbereiten: den Client als umschaltbare Konfiguration abstrahieren und einen direkten oder alternativen Pfad behalten; das Budget nicht vollständig bei einem einzigen Relay einzahlen.

Ist ein eigener Reverse-Proxy auch ein Relay?

Technisch ja. Er gibt Kontrolle über Keys und Logs, verlangt aber eigenen Betrieb für Server, Zertifikate, Rate-Limits, Compliance und das Upstream-Konto.

Weiterführende Informationen