Für Teams in China ist die Whisper API technisch unspektakulär: ein Multipart-Request, eine Audiodatei, ein Text als Antwort. Entscheidend ist der Netzwerkpfad. Grenzüberschreitende Verbindungen am Tag, Paketverlust im Abendverkehr und Dateien von mehreren Dutzend Megabyte, die mitten im Upload abbrechen, machen aus einer einfachen Schnittstelle ein Betriebsproblem.

Dieser Artikel vergleicht Direktverbindung, Proxy und Gateway. Im Mittelpunkt stehen große Uploads, Timeouts, Wiederholungen, Segmentierung sowie eine Prüfliste vor dem Produktivstart.

Hinweis: OpenAI und Whisper sind Marken der jeweiligen Rechteinhaber. Dieser Artikel dient ausschließlich der technischen Integrationshilfe; es besteht keine Zugehörigkeit, Vertretung oder Kooperation mit OpenAI. Schnittstellengrenzen, verfügbare Modelle und Abrechnungsregeln richten sich nach der offiziellen Dokumentation und der Plattformdokumentation.

1. Drei Wege, drei Verantwortungsgrenzen

  • Direkt: Der Code ruft api.openai.com ohne Zwischenschicht auf.
  • Proxy: ein selbst betriebener Reverse Proxy auf einem VPS oder eine Weiterleitungsadresse eines Drittanbieters.
  • Gateway: ein OpenAI-kompatibler Zugang wie ZSQH AI Gateway mit einheitlichem Key, Guthaben, Abrechnung und Rechnung.
Dimension Direkt Eigener Proxy Gateway
Kontrolle über den Pfad Abhängig vom Netzbetreiber Höher Beim Anbieter
Stabilität Schwankt stärker Abhängig von Rechenzentrum und Leitung Meist mehrere Routen
Betriebsaufwand Niedrig Hoch, Bereitschaft nötig Niedrig
Abrechnung und Rechnung US-Dollar, selbst abwickeln Upstream-Rechnung, weiterhin selbst Landeswährung, Rechnung über Plattform
Geeignet für Seltene Aufrufe mit Wiederholbarkeit Teams mit Betriebskompetenz Teams in China und Produktivbetrieb

Der Kernunterschied ist nicht „ob es verbindet“, sondern wer bei Problemen analysiert und einspringt. Diese Frage ist bei der Auswahl wichtiger als der Vergleich von Latenzzahlen.

2. Direktverbindung: erreichbar heißt nicht stabil

Die Direktverbindung spart die Zwischenschicht, aber die Qualität der grenzüberschreitenden Leitung liegt nicht in eigener Hand. Typische Beobachtungen:

  • tagsüber normal, im Abendverkehr steigende Timeout-Quote;
  • gelegentlich langsame DNS-Auflösung und längere TLS-Handshakes;
  • Verbindungsabbruch bei großen Uploads, der Transfer beginnt von vorn;
  • derselbe Code läuft im Büro, aber nicht auf dem Cloud-Server.

Tests sollten nicht aus dem Heimnetz bestehen. Auf dem Produktionsserver eine Gruppe echter Anfragen senden und Erfolgsquote, p50- und p95-Latenz sowie Upload-Dauer über mehrere Tage beobachten. Für asynchrone Aufgaben ist Direktzugang akzeptabel, solange ein späterer Neuversuch erlaubt ist. Bei Live-Untertiteln oder Echtzeit-Meetings werden Leitungsschwankungen dagegen direkt als sichtbares Stocken erlebt.

3. Proxy: der Server ist günstig, der Betrieb nicht

Ein eigener Proxy besteht meist aus nginx auf einem VPS als Reverse Proxy, ergänzt um Domain und Zertifikat. Er fixiert den Anfragepfad, bringt aber neue Fehlerquellen:

  • Ausgangsbandbreite reicht nicht; mehrere parallele Uploads beginnen zu warten.
  • Die Request-Body-Grenze wurde nicht geöffnet; eine Datei von mehreren Dutzend Megabyte erhält sofort 413.
  • Der Proxy-Timeout ist kürzer als die Transkriptionsdauer; der Backend arbeitet noch, die Verbindung ist bereits getrennt.
  • Abgelaufene Zertifikate, IP-Drosselung und Änderungen der Upstream-Schnittstelle brauchen manuelle Pflege.

Bei der Konfiguration mindestens client_max_body_size, proxy_read_timeout und Puffer prüfen. Eine geteilte Proxy-Adresse birgt zusätzliche Risiken: Man weiß nicht, wer denselben Ausgang nutzt, und Rate-Limits oder Sperren können alle betreffen. Wird der Key in der Proxy-Schicht weitergegeben, darf das Auth-Header nicht im Klartext in Logs landen.

4. Gateway: Netzprobleme werden zu Dienstleistung

Ein Gateway stellt eine OpenAI-kompatible Basis-URL bereit; im Code werden meist nur base_url und Key ersetzt. Der praktische Nutzen für Teams in China: Der Pfad wird vom Anbieter betrieben, Text, Audio und Embeddings teilen ein Guthaben, und Zahlung sowie Rechnung laufen in Landeswährung.

Bei der Auswahl nicht bei „unterstützt Whisper“ stehen bleiben, sondern prüfen:

  • ob die Audioschnittstelle vollständig unterstützt wird, einschließlich response_format und Zeitstempeln;
  • Dateigröße, Parallelität und Timeout-Grenzen;
  • Abrechnung fehlgeschlagener Anfragen und Bereitstellung einer Request-ID;
  • Log-Aufbewahrung und Löschverfahren;
  • ob die Preisseite die Abrechnungsregeln klar nennt.

Ein Gateway löst Leitung und Abrechnung, nicht alle Engineering-Probleme. Audio über der Größengrenze muss weiterhin geteilt, Netzwerkflattern weiterhin wiederholt werden. Es ist eine Infrastrukturschicht mit Servicezusage, kein universeller Beschleuniger.

5. Große Uploads: warum auch unter 25 MB scheitern kann

Die Whisper-Schnittstelle begrenzt Dateien üblicherweise auf 25 MB; maßgeblich ist die offizielle Dokumentation. Viele nehmen an, unterhalb der Grenze sei alles in Ordnung. In der Praxis scheitert der Transfer.

Bei 1 Mbps Upload benötigt eine 25-MB-Datei allein etwa 200 Sekunden. Dazu kommen TLS-Handshake, serverseitige Warteschlange und Transkriptionszeit; schnell wird ein Proxy- oder Client-Timeout erreicht. Mobilfunk, grenzüberschreitende Leitungen und geteilte Bandbreite verlängern das weiter.

Die Reihenfolge zur Senkung der Fehlerquote lautet: zuerst komprimieren, dann teilen, erst zuletzt über Wiederholungen nachdenken.

  • Einheitlich auf 16 kHz mono umwandeln; Sprachtranskription braucht keine hohe Samplerate.
  • MP3 mit 64 kbps fasst in 25 MB etwas über 50 Minuten Sprache.
  • Audio über 10 Minuten in 5- bis 10-Minuten-Abschnitte teilen, mit 0,5 bis 1 Sekunde Überlapp.
  • Schnittpunkte möglichst in Stille legen, um zertrennte Wörter zu vermeiden.

Diese Werte sind Erfahrungswerte, keine Zusage der Schnittstelle; maßgeblich sind Tests in der eigenen Umgebung.

6. Timeout, Wiederholung und Segmentierung

Das Teilen erledigt ffmpeg:

ffmpeg -i input.mp3 -f segment -segment_time 600 \
  -ac 1 -ar 16000 -b:a 64k part_%03d.mp3

Die Retry-Strategie folgt dieser Reihenfolge:

  1. Nur Netzwerkfehler, 408, 429 und 5xx wiederholen; 400, 401 und 413 bringen keine Besserung.
  2. Exponentielles Backoff mit Jitter, etwa 1, 2, 4, 8 Sekunden, höchstens drei bis fünf Versuche.
  3. Bei jeder Anfrage Dateiname, Segmentnummer und Request-ID protokollieren, um später abgleichen zu können.
  4. Beim Zusammenführen Texte in Segmentreihenfolge verbinden und den Startversatz zu den Zeitstempeln addieren.
  5. Überlappungen deduplizieren und bevorzugt den vollständigeren Satz behalten.
  6. Bei Batch-Aufgaben die Parallelität begrenzen, damit 429 sich erholen kann.

Die Audioschnittstelle hat üblicherweise keinen Idempotenzschlüssel. Nach einem Timeout kann der Server bereits transkribiert und abgerechnet haben. Vor einer Wiederholung das Nutzungsprotokoll prüfen und entscheiden, ob eine geringe doppelte Abrechnung akzeptabel ist. Kostenempfindliche Teams können fehlgeschlagene Segmente separat ablegen und nach manueller Prüfung erneut senden.

7. Zahlung, Rechnung und Compliance

Üblich ist die Kombination: Aufladung über ein Gateway in Landeswährung, Rechnung von der Plattform, Überweisung über das Firmenkonto im Beschaffungsprozess. Vor der Zahlung klären, ob Vertragspartei und Empfängerkonto übereinstimmen, ob sich der Rechnungsbetrag auf die Zahlung oder das eingegangene Guthaben bezieht und wo Rückerstattung sowie Nachausstellung geregelt sind. Details stehen in der Aufladedokumentation der Plattform.

Compliance: drei Punkte beachten.

  • Audio kann Namen, Telefonnummern, Diagnosen und Transaktionsdaten enthalten; vor dem Upload informieren und einwilligen lassen.
  • Sensible Inhalte vorab anonymisieren oder eine privat betreibbare Lösung wählen.
  • Prüfen, ob Daten grenzüberschreitend übertragen werden und wie Aufbewahrung sowie Löschung geregelt sind.

Die Rechte am Transkript hängen vom Inhalt und den Plattformbedingungen ab. Bei Meetingaufnahmen, Kursen und Kundenanrufen vor der kommerziellen Nutzung die Einwilligung klären.

8. Prüfliste vor dem Start

  • Mit zehn Sekunden Audio eine 200-Antwort erreichen.
  • Mit fünf Minuten Audio deutsche Erkennung und Zeichensetzung prüfen.
  • Eine Datei nahe 25 MB hochladen und Upload-Dauer sowie Timeout testen.
  • 429 und 5xx simulieren und prüfen, ob Backoff greift.
  • Netzausfall simulieren und sicherstellen, dass Wiederholungen nicht endlos laufen.
  • Zeitstempelversatz nach dem Zusammenführen prüfen.
  • Parallelitätsgrenze und Queue-Länge kontrollieren.
  • Guthabenwarnung, Rechnung und Abgleichprozess bestätigen.
  • Sicherstellen, dass Keys nur serverseitig liegen und Rotation sowie Widerruf möglich sind.

Die Liste ist kurz, aber jeder Punkt entspricht einem realen Störfall. Zuerst eine Woche mit kleinem Traffic testen und dann die Parallelität erhöhen; das ist stabiler als sofort volle Last.

Häufige Fragen

Ist die Direktverbindung zur Whisper API aus China stabil?

Das lässt sich nicht pauschal beantworten; es hängt von Netzbetreiber, Tageszeit und Serverstandort ab. Im Produktivbetrieb mehrere Tage messen und Erfolgsquote sowie p95-Latenz betrachten, nicht eine einzelne Anfrage.

Worin unterscheiden sich Gateway und Proxy?

Ein Proxy leitet meist nur Traffic weiter; Abrechnung und Betrieb bleiben beim Upstream. Ein Gateway bietet zusätzlich Konto, Guthaben, Key-Verwaltung, Zahlung in Landeswährung und Rechnungen; die Verantwortungsgrenze ist umfassender.

Was tun bei Audio über 25 MB?

Zuerst auf 16 kHz mono MP3 komprimieren, dann in 5- bis 10-Minuten-Abschnitte teilen. Schnittpunkte in Stille legen und beim Zusammenführen den Zeitversatz ergänzen.

Entstehen bei Wiederholung nach Timeout doppelte Kosten?

Möglich. Der Server kann die Transkription bereits abgeschlossen haben. Vor der Wiederholung das Nutzungsprotokoll prüfen und die Anzahl der Versuche begrenzen.

Welche Compliance-Punkte sind beim Zugang aus China wichtig?

Vor allem personenbezogene Daten im Audio, grenzüberschreitende Übertragung, Aufbewahrungsregeln des Anbieters und die Einwilligung zum Inhalt. Bei sensiblen Daten zuerst anonymisieren oder privat hosten.

Nächste Schritte

Zuerst mit kurzem Audio den Pfad testen, dann mit einer echten langen Aufnahme Segmentierung und Zusammenführung prüfen und erst danach Batch-Aufgaben anbinden. Teams, die Aufladung in Landeswährung, eine einheitliche Rechnung und Belege benötigen, können sich bei ZSQH AI Gateway registrieren; Audiomodelle und Abrechnungsregeln stehen unter Modellpreise.

Weiterlesen: