Auf den ersten Blick scheint die Rechnung für Sprachtranskription nur davon abzuhängen, „wie lang das Audio ist“. Die tatsächlichen Gesamtkosten entstehen jedoch aus mehreren Faktoren: unnötige Stille, Dateien mit hoher Bitrate, fehlgeschlagene Wiederholungen, Überlappungen beim Segmentieren, doppelte Übermittlungen, vorgehaltene Speicherung und die manuelle Nachkorrektur des Transkripts.

Dieser Artikel nennt keine festen Stückpreise, weil Preise angepasst werden und Modelle sowie Gateways unterschiedliche Abrechnungsregeln haben. Wichtiger ist das Verständnis der Abrechnungsstruktur und der Kostentreiber. Konkrete Preise stehen auf der Seite Modellpreise.

Hinweis: OpenAI und Whisper sind Marken der jeweiligen Rechteinhaber. Dieser Artikel dient ausschließlich der technischen Erläuterung; es besteht keine Zugehörigkeit zu OpenAI. Abrechnungseinheiten, verfügbare Regionen und Limits der einzelnen Modelle können sich ändern; maßgeblich sind die offizielle Dokumentation und die Preisseite der Plattform. Dieser Artikel enthält keine konkreten Preisangaben.

1. Abrechnungsbasis ist die Audiodauer

Das klassische whisper-1 wird nach den übermittelten Audiominuten abgerechnet. Neuere Modelle der gpt-4o-transcribe-Reihe rechnen Audio-Input- und Output-Tokens ab; die Preisseite nennt häufig zusätzlich eine äquivalente Schätzung pro Minute. Auch die Abrechnung neuerer Transkriptionsmodelle entwickelt sich weiter.

Ob nach Minuten oder Tokens: Grundlage ist die übermittelte Audiolänge, nicht die darin tatsächlich gesprochene Zeit. Vorspann, Abspann, lange Stille und Pausen während einer Besprechung können in die Abrechnung eingehen. Die erste Kostenregel lautet daher: vor dem Upload alles Unnötige abschneiden.

2. Wie Dateigröße und Format die Rechnung beeinflussen

Die offizielle Schnittstelle begrenzt einzelne Dateien auf 25 MB und unterstützt unter anderem mp3, mp4, mpeg, mpga, m4a, wav und webm. Die Größenbegrenzung wirkt indirekt auf die Kosten:

  • WAV mit hoher Bitrate ist groß; lange Aufnahmen überschreiten das Limit schneller und müssen häufiger geteilt werden.
  • Je größer die Datei, desto langsamer der Upload und desto wahrscheinlicher Timeout und Wiederholung.
  • Ein inkompatibles Format scheitert sofort und verbraucht Anfragen sowie Diagnosezeit.
  • Die Transkodierung selbst steht meist nicht auf der API-Rechnung, kostet aber Server- und Speicherressourcen.

Eine einheitliche Umwandlung in 16-kHz-Mono-MP3 oder -WAV reduziert die Dateigröße bei akzeptabler Qualität deutlich. Vor dem Komprimieren muss klar sein, ob der Qualitätsverlust für den Anwendungsfall vertretbar ist; bei Dialekten und Eigennamen lieber eine höhere Bitrate behalten.

3. Welche Vorgänge die Kosten unbemerkt erhöhen

Kostenfaktor In der API-Rechnung Gegenmaßnahme
Audiodauer Ja Stille entfernen, Vor- und Abspann kürzen, nur relevante Abschnitte senden
Fehlgeschlagene Wiederholungen Möglicherweise doppelt Anzahl begrenzen, Ergebnisse protokollieren
Überlappung beim Teilen Ja, Überlappung wird erneut transkribiert Überlappung auf 0,5–1 Sekunde begrenzen, beim Zusammenführen deduplizieren
Transkodierung und Speicher Meist nicht in der API-Rechnung Lifecycle-Regeln setzen, zeitnah aufräumen
Egress-Traffic Je nach Anbieter und Architektur In derselben Region verarbeiten, wiederholte Downloads vermeiden
Manuelle Korrektur Nicht in der API-Rechnung Stichproben, Wörterbuchersetzung, gestufte Prüfung

Die häufigste Verschwendung ist nicht der Stückpreis, sondern doppelte Arbeit: Dieselbe Audiodatei wird wegen eines Timeouts dreimal übermittelt, oder das gesamte Audio wird erneut transkribiert, nur um Zeitstempel zu erhalten.

4. Wiederholungen, Timeouts und doppelte Abrechnung

Ein Netzwerk-Timeout bedeutet nicht, dass der Server nichts verarbeitet hat. Wurde die Anfrage bereits abgerechnet und der Client erhielt keine Antwort, entstehen bei einer Wiederholung zweite Kosten. Technisch sind drei Dinge nötig:

  1. Eine Idempotenzkennung aus Dateihash oder Vorgangsnummer bilden und erfolgreiche Ergebnisse in der Datenbank wiederverwenden.
  2. Die maximale Anzahl an Wiederholungen begrenzen, zum Beispiel auf drei, und exponentielles Backoff verwenden.
  3. Nur bei 429, 5xx und Timeouts wiederholen; bei 400, 401 und 413 ist eine Wiederholung sinnlos.

Batch-Aufgaben benötigen außerdem sinnvolle Verbindungs- und Lese-Timeouts. Ein zu kurzer Timeout erklärt normale lange Audiodateien für gescheitert, ein zu langer blockiert die Queue.

5. Segmentierung langer Audiodateien und Parallelität

Audio über 25 MB muss geteilt werden. Je feiner die Teilung, desto mehr Anfragen; je gröber, desto teurer wird ein fehlgeschlagener Versuch. Sinnvolle Reihenfolge:

  1. Mit ffprobe Dauer und Bitrate jeder Datei ermitteln und die Gesamtminuten schätzen.
  2. Einheitlich auf 16 kHz mono transkodieren, um die Segmentgröße zu kontrollieren.
  3. Bevorzugt an Stillepunkten teilen, sonst in festen 10-Minuten-Abschnitten.
  4. Den Versatz jedes Segments speichern und beim Zusammenführen die Zeitachse korrigieren.
  5. Parallelität innerhalb des Kontingents halten und die 429-Quote beobachten.
  6. Nach dem Zusammenführen deduplizieren und Schnittstellen stichprobenartig prüfen.
  7. Tatsächlich übermittelte Minuten mit der Rechnung abgleichen und Abweichungen erklären.

Parallelität ändert den Stückpreis nicht, wohl aber Retry-Quote und Gesamtdauer. Volle Parallelität erzeugt viele 429; mit Backoff wird das oft teurer als ein ruhigerer Betrieb.

6. Speicher und Egress werden leicht übersehen

Audiodateien, Transkripte, Logs und Backups verursachen Speicherkosten, wobei Audio das größte Volumen hat. Eine sinnvolle Gliederung:

  • Originalaudio: nach der Transkription für einen definierten Zeitraum aufbewahren, danach löschen oder in Cold Storage verschieben.
  • Transkripte: projektbezogen speichern, sensible Inhalte verschlüsseln und Zugriffe beschränken.
  • Request-Logs: keine vollständigen Audio-URLs und Keys protokollieren, aber notwendige Request-IDs behalten.
  • Backups: nur Ergebnisse sichern, Originalaudio nicht doppelt archivieren.

Liegen Audio und Transkriptionsdienst in unterschiedlichen Regionen, entstehen durch Upload und Download Egress-Kosten. Eine Verarbeitung nahe am Speicher reduziert diesen Anteil.

7. Budget richtig schätzen

Nicht einfach einen geschätzten Stückpreis mit der Gesamtdauer multiplizieren. Robuster ist:

Monatskosten ≈ effektive Audiominuten × Stückpreis × Retry-Faktor + Speicher und Traffic + manuelle Korrektur

Den Retry-Faktor schätzt man aus realen Monitoring-Daten; bei 97 Prozent Erfolgsquote bleibt für Fehlversuche ein Aufschlag. Das folgende Skript liest nur Dauer und Stückpreis und schreibt keinen Preis fest:

import os, subprocess, json

UNIT_PRICE = float(os.environ["AUDIO_UNIT_PRICE"])  # von der Preisseite, pro Minute
files = ["meeting-01.mp3", "meeting-02.mp3"]
total_minutes = 0.0

for path in files:
    out = subprocess.check_output([
        "ffprobe", "-v", "error", "-show_entries", "format=duration",
        "-of", "json", path,
    ])
    total_minutes += float(json.loads(out)["format"]["duration"]) / 60

estimate = total_minutes * UNIT_PRICE * 1.1  # Puffer für Retries und Überlappung
print(f"Audio {total_minutes:.1f} Minuten, geschätzt {estimate:.2f}")

Zum Budget gehören außerdem Speicher, Transkodierungsserver, manuelle Korrektur sowie Entwicklung und Wartung. Wer nur API-Stückpreise vergleicht, unterschätzt die Gesamtbetriebskosten.

8. Abgleich und Preisbeobachtung nach dem Start

  1. Nutzung nach Projekt oder Key trennen, damit nicht alle Geschäftsbereiche in einer Rechnung landen.
  2. Wöchentlich die Nutzung exportieren und mit den intern übermittelten Audiominuten vergleichen.
  3. Projekte mit Abweichung über dem Schwellenwert prüfen: doppelte Übermittlung, ungewöhnliche Wiederholungen, falsche Segmentparameter.
  4. Budgetwarnungen einrichten und bei Annäherung an die Obergrenze früh reagieren.
  5. Modell- und Preisänderungen verfolgen; vor einem Wechsel mit echten Samples Qualität und Kosten vergleichen.

Preise und Modelle ändern sich. Den Stückpreis konfigurierbar halten und nicht im Code fest schreiben; bei einer Preisänderung genügt dann ein Konfigurationsupdate und eine neue Schätzung.

Häufige Fragen

Wird Whisper API nach Minuten oder Tokens abgerechnet?

whisper-1 wird nach Audiominuten abgerechnet. Neuere Modelle der gpt-4o-transcribe-Reihe rechnen Audio-Input- und Output-Tokens ab; die Preisseite nennt eine äquivalente Minutenschätzung. Maßgeblich sind Modellpreise und die offizielle Dokumentation.

Wird Stille ebenfalls berechnet?

In der Regel wird die übermittelte Audiolänge abgerechnet, Stille kann also enthalten sein. Stille vor dem Upload zu entfernen ist die direkteste Kostenkontrolle.

Werden fehlgeschlagene Wiederholungen doppelt berechnet?

Hat der Server die Anfrage bereits verarbeitet und nur der Client lief in einen Timeout, kann ein neuer Versuch zweite Kosten erzeugen. Erfolgreiche Ergebnisse über einen Idempotenzschlüssel wiederverwenden und Wiederholungen begrenzen.

Spart mehr Parallelität Geld?

Der Stückpreis bleibt gleich, und die Gesamtkosten sinken nicht zwangsläufig. Zu hohe Parallelität löst 429 aus; Wiederholungen und Warteschlange kosten zusätzlich Zeit und Geld.

Warum nennt der Artikel keine konkreten Preise?

Preise für Audiomodelle werden häufig angepasst, und Gateways rechnen unterschiedlich ab. Feste Zahlen veralten schnell; eine Schätzung anhand der aktuellen Preisseite ist verlässlicher.

Nächste Schritte

Zunächst bei ZSQH AI Gateway registrieren, mit kurzem Audio die Transkription testen und echte Minuten zählen, bevor das Budget festgelegt wird. Modelle und aktuelle Preise stehen unter Modellpreise.

Weiterlesen: