Wenn Teams die Whisper API aufrufen, liegt das Problem selten im Modell, sondern in der Verbindung: schwankende grenzüberschreitende Netze, langsame Uploads, Timeouts bei langen Audiodateien, begrenzte Dateigrößen und ein gemeinsamer Key für viele Projekte, der sich kaum abrechnen lässt. Relays und Proxys bündeln diese Schwierigkeiten in einer Zugriffsschicht.
Ein Relay ist jedoch nicht einfach „eine andere Adresse“. Audio ist sensibel, und Transkription ist eine lang laufende Anfrage. Bei der Auswahl zählen Upload-Grenzen, Timeouts, Wiederholungen, Abrechnung und Key-Verwaltung. Dieser Artikel geht diese Punkte der Reihe nach durch und liefert eine praktikable Prüf- und Migrationscheckliste.
Hinweis: OpenAI und Whisper sind Marken der jeweiligen Rechteinhaber. Dieser Artikel dient ausschließlich der technischen Erläuterung; es besteht keine Zugehörigkeit und kein Vertretungsverhältnis zu den genannten Unternehmen. Schnittstellengrenzen, Fehlercodes und Abrechnungsregeln können sich ändern; maßgeblich sind die offizielle Dokumentation und die Dokumentation der eingesetzten Plattform.
1. Was ein Relay tatsächlich weiterleitet
Ein Sprach-Relay übernimmt üblicherweise vier Aufgaben: Anfragen an den Upstream weiterreichen, Upstream-Keys ersetzen oder verwahren, Nutzung und Logs erfassen sowie bei Fehlern erneut versuchen oder den Kanal wechseln. Für die Anwendung bleibt es bei einem Multipart-Request an /v1/audio/transcriptions; nur Basis-URL und Key ändern sich.
Drei Formen sind verbreitet:
- Selbst betriebener Reverse Proxy: löst nur Netzwerk und Ausgang, Key und Daten bleiben unter eigener Kontrolle, die Stabilität hängt aber an der eigenen Infrastruktur.
- Aggregations-Gateway: bündelt mehrere Upstreams und bietet Kontingente, Logs, Rate-Limits und Ausweichkanäle; sinnvoll für Teams mit mehreren Projekten.
- Wiederverkauf oder stellvertretende Aufladung: Anfragen laufen über ein Drittanbieterkonto; Preise und Bedingungen unterscheiden sich stark, Daten- und Compliance-Fragen sind besonders wichtig.
Die Verantwortungsgrenzen unterscheiden sich. Beim eigenen Proxy diagnostiziert man selbst. Beim Gateway zählen SLA und Störungsmeldungen des Anbieters. Beim Wiederverkauf muss geklärt sein, ob die Upstream-Bedingungen diese Nutzung überhaupt erlauben.
2. Upload-Grenzen: drei Ebenen prüfen
Die Whisper-Schnittstelle begrenzt die Größe einzelner Dateien; die offizielle Dokumentation nennt derzeit 25 MB und keine einheitliche Obergrenze für die Dauer. Wie viel Audio tatsächlich passt, hängt von der Kodierung ab:
- 16 kHz mono, 16 Bit WAV benötigt etwa 1,9 MB pro Minute; 25 MB reichen für ungefähr eine Viertelstunde.
- 32 kbps mono MP3 benötigt etwa 240 KB pro Minute; 25 MB reichen für über eine Stunde.
- Relays, Reverse Proxys und Serverless-Plattformen können kleinere Request-Body-Grenzen setzen.
Bei einem 413 oder einem fehlgeschlagenen Upload müssen daher Upstream-Grenze, Gateway-Grenze und Client-Grenze gemeinsam geprüft werden. Audio zu komprimieren ist meist einfacher als sofort zu schneiden: Für Sprache genügen 16 kHz mono, und MP3 oder Opus reduzieren die Dateigröße deutlich.
3. Segmentieren, transkribieren, zusammenführen
Audio oberhalb der Grenze muss geteilt werden. Am besten an Stillepunkten, damit kein Satz mitten durchtrennt wird. Ist das nicht möglich, funktioniert auch eine feste Segmentlänge, allerdings sollte ein kleiner Überlapp bleiben.
ffmpeg -i input.wav -ar 16000 -ac 1 -c:a libmp3lame -b:a 32k \
-f segment -segment_time 600 -reset_timestamps 1 chunk_%03d.mp3
Der Ablauf lässt sich standardisieren:
- Alles einheitlich in 16 kHz mono umwandeln, um Größe und Formatunterschiede zu reduzieren.
- In Abschnitte von 5 bis 10 Minuten teilen, bevorzugt an Stillepunkten.
- Jedes Segment einzeln transkribieren und dabei Sprachhinweis und kurzen Kontext mitgeben.
- Texte zusammenführen und die Zeitstempel um den Startversatz des Segments korrigieren.
- Übergänge auf doppelte oder fehlende Sätze prüfen und bei Bedarf über die Überlappung abgleichen.
Zeitstempel brauchen besondere Aufmerksamkeit: Jeder Segment-Zeitstempel muss um „Segmentnummer × Segmentdauer“ verschoben werden, sonst beginnt nach dem Zusammenführen alles wieder bei null. Bei Wort-Zeitstempeln muss zusätzlich behandelt werden, dass Wörter an Schnittstellen zerteilt werden können.
4. Timeouts und Wiederholungen
Die Transkription langer Audiodateien ist keine kurze Anfrage. Lese-Timeout im Client, Idle-Timeout im Reverse Proxy und Upstream-Timeout im Gateway: Jede zu kurz gesetzte Ebene führt zum Abbruch. Timeouts sollten zunächst für den schlechtesten Fall dimensioniert und die Parallelität anschließend über eine Queue begrenzt werden.
| Störung | Typisches Symptom | Vorgehen |
|---|---|---|
| 429 Rate-Limit | Häufungen zu Spitzenzeiten | Exponentielles Backoff mit Jitter, Parallelität senken |
| 5xx oder Gateway-Fehler | Zeitweise Fehler | Begrenzt wiederholen, Ausweichkanal nutzen |
| Lese-Timeout | Lange Datei bricht mittendrin ab | Timeout erhöhen, segmentweise senden |
| 413 Anfrage zu groß | Upload scheitert sofort | Komprimieren oder teilen, Proxy-Grenze prüfen |
| 401/403 | Key ungültig oder ohne Recht | Nicht wiederholen, Key und Kontingent prüfen |
| 400 Parameterfehler | Format, Sprache oder Feld nicht unterstützt | Anfrage korrigieren, nicht blind wiederholen |
Wiederholungen sind nur bei Rate-Limits, Timeouts und 5xx sinnvoll. Bei 4xx-Parametern kostet jeder Versuch nur Kontingent. Jeder Versuch sollte eine Request-ID protokollieren, damit dieselbe Audiodatei nicht doppelt berechnet wird. Batch-Aufgaben gehören in eine Queue; fehlgeschlagene Segmente in eine Dead-Letter-Queue zur manuellen Prüfung.
5. Transparente Abrechnung
Sprachtranskription wird häufig nach Audiodauer abgerechnet, teils auch nach Tokens. Beim Rechnungsvergleich zählen: Aufrundung pro Minute, Mindestabrechnungsdauer, Berechnung fehlgeschlagener Anfragen, doppelte Berechnung bei Wiederholungen und Mindestumsatz.
Die Prüfung ist einfach: lokal die insgesamt übermittelten Audiominuten zählen und mit den Rechnungsminuten vergleichen; einen Tag aus den Logs ziehen und Anfrage für Anfrage abgleichen; für Fehler und Wiederholungen eigene Kennzeichen setzen. Weicht die Differenz dauerhaft um mehr als wenige Prozentpunkte ab, sollte der Anbieter eine Aufschlüsselung liefern. Konkrete Preise und Staffelungen stehen auf der Seite Modellpreise; Preise ändern sich, alte Screenshots taugen nicht als Budgetgrundlage.
6. Keys und Datenrisiken
Ein Relay kann Audio und Transkript sehen. Vor der Auswahl muss geklärt werden: Werden Anfrage und Antwort gespeichert, wie lange, werden sie zum Training verwendet, welche Unterauftragnehmer gibt es, in welcher Region liegen die Daten und wie funktioniert die Löschung?
Technisch sollten mindestens folgende Punkte umgesetzt sein: eigene Keys pro Projekt, Obergrenzen für Kontingente, regelmäßige Rotation, keine Keys im Frontend und keine vollständigen Transkripte in Logs. Bei Kundenaufnahmen, medizinischen oder finanziellen Inhalten sollten Dienste mit Datenverarbeitungsvertrag oder eine selbst gehostete Transkription gewählt werden.
7. Ein Relay prüfen
- Eine Audiodatei mit bekanntem Text transkribieren und Ergebnis sowie Zeichenfehlerrate vergleichen.
- Rückgabefelder prüfen: Modellname, Sprache, Dauer und Segmentinformationen müssen plausibel sein.
- Eine Datei nahe der Obergrenze hochladen und sicherstellen, dass nicht stillschweigend abgeschnitten wird.
- Langes Audio simulieren und beobachten, ob Timeouts und Fehlermeldungen verständlich sind.
- Einmal ein Rate-Limit oder einen falschen Parameter auslösen und prüfen, ob Fehlercodes transparent sind und korrekt abgerechnet wird.
- Über mehrere Tage Nutzung und Rechnung vergleichen, um eine einheitliche Zählweise zu bestätigen.
Dabei nicht nur kurze Videos testen. Lange Meetings, Telefonaufnahmen und laute Umgebungen aus dem echten Betrieb zeigen die Probleme.
8. Migrationscheckliste
- Bestehende Schnittstellen, Modelle, Audioformate, durchschnittliche Dauer und Spitzenparallelität erfassen.
- Eine Testdatei plus manuell korrigiertes Transkript als Vergleichsbasis vor und nach dem Wechsel festlegen.
- Upload-Obergrenze, Timeouts, Parallelität und Retry-Verhalten des Relays klären.
- Basis-URL, Key und Timeouts als Konfiguration ablegen statt fest zu codieren.
- Segmentierung, Zusammenführung, Zeitstempelversatz und Fehlerqueue ergänzen.
- Rechnungsabgleich und Nutzungswarnungen einrichten, Budgetobergrenzen setzen.
- Zuerst zehn Prozent des Traffics umstellen, Fehlerrate und P95 beobachten, dann schrittweise erhöhen.
- Alten Kanal und Rollback-Schalter behalten und erst nach bestätigter Stabilität abschalten.
Teams mit bereits OpenAI-kompatiblem Code müssen meist nur die Konfiguration ändern. Der Einstieg ist über die Registrierung möglich; zunächst mit kleinem Traffic validieren.
9. Häufige Fragen
Worin unterscheiden sich Whisper-Relay, VPN und Reverse Proxy?
Ein VPN ändert nur den Netzwerkpfad. Ein Reverse Proxy leitet Anfragen weiter. Ein Aggregations-Gateway übernimmt zusätzlich Keys, Abrechnung, Rate-Limits und Wiederholungen. Je nach Problem ist eine andere Schicht sinnvoll.
Ist das 25-MB-Limit vom Relay gesetzt?
Nicht unbedingt. Bereits die Upstream-Schnittstelle begrenzt einzelne Dateien; Relay und Proxy können niedrigere Grenzen setzen. Jede Ebene einzeln prüfen, statt nur die Client-Fehlermeldung zu betrachten.
Wie lang sollten Segmente bei langem Audio sein?
Üblich sind 5 bis 10 Minuten pro Segment, geteilt an Stillepunkten. Zu kleine Segmente erhöhen Anfragezahl und Kosten, zu große laufen eher in Timeouts. Letztlich entscheidet der eigene Test.
Entstehen durch Wiederholungen doppelte Kosten?
Das hängt von der Abrechnungsregel des Anbieters ab. Wiederholung nach erfolgreicher Antwort oder ein Timeout, obwohl der Upstream bereits verarbeitet hat, kann doppelt berechnen. Request-IDs zur Deduplizierung nutzen und die Rechnung prüfen.
Wie erkennt man, ob ein Relay das Modell gewechselt hat?
Rückgabefeld für das Modell, Sprache und Segmentstruktur prüfen und mit einem festen Testsatz vergleichen. Ändert sich der Stil plötzlich oder fehlen Felder, sollte der Anbieter das erklären.
Weiterlesen:
