Übersicht
GoModel stellt die OpenAI-kompatiblen Audio-Endpunkte für Text-to-Speech (TTS) und Speech-to-Text (STT) bereit. Clients und SDKs, die bereits die/v1/audio/*-Routen von OpenAI aufrufen, können unverändert auf GoModel zeigen.
Requests werden nach Modell über dieselbe Registry geroutet, die auch für
Chat und Embeddings verwendet wird. Daher gelten die Auswahl über model,
provider-Hinweise, virtuelle Modelle, Modell-Zugriffsregeln pro Key
(User Paths) und Budgets gleichermaßen. Audio wird von
OpenAI und den OpenAI-kompatiblen Providern (OpenRouter, Azure OpenAI, vLLM,
Oracle, Z.ai) bereitgestellt, außerdem von Providern, deren native Audio-APIs
GoModel hinter denselben Endpunkten übersetzt: Xiaomi MiMo
(TTS und ASR über Chat Completions), Cohere (Transkription)
und MiniMax (TTS über die native t2a_v2-API). Ein
Provider ohne Audio-Unterstützung gibt einen eindeutigen Fehler zurück, statt den
Request falsch zu routen.
Unterstützte Endpunkte
JSON-Bodys von Transkriptionen und Übersetzungen werden in die OpenAI-Form
normalisiert: Das herstellerspezifische Feld
x_groq von Groq wird aus
json- und verbose_json-Responses entfernt, sodass ein für OpenAI
geschriebener Client überall dieselben Felder sieht.
Text-to-Speech
model, input und voice sind erforderlich. Optionale Felder – instructions,
response_format (Standardwert mp3, außerdem opus, aac, flac, wav, pcm)
und speed – werden an den Provider weitergeleitet. Der Content-Type der
Response ist derjenige, den der Upstream zurückgibt; ersatzweise wird der Typ
verwendet, der sich aus response_format ergibt (zum Beispiel wav → audio/wav).
Synthetisiertes Audio wird so weitergereicht, wie der Provider es erzeugt –
siehe Streaming.
Speech-to-Text
file und model sind erforderlich. Optionale Formularfelder – language,
prompt, response_format, temperature und timestamp_granularities[] –
werden weitergeleitet. response_format bestimmt die Form der Response: json
und verbose_json geben ein JSON-Objekt zurück; text, srt und vtt geben
einen text/plain-Body zurück.
Fügen Sie stream=true hinzu, um das Transkript bereits während der Erzeugung zu
erhalten – siehe Streaming.
Self-hosted Speech-to-Text-Server
Viele self-hosted STT-Server stellen/v1/audio/transcriptions bereit, aber kein
/v1/models. Registrieren Sie einen solchen Server als openai-Provider und
geben Sie das Modell an, das er bereitstellt:
/models mit 404 oder 405 antwortet, stellt GoModel die konfigurierten
Modelle bereit und meldet den Provider als gesund. Andere Fehler von /models
markieren ihn weiterhin als beeinträchtigt (degraded).
Streaming
GoModel leitet einen Audio-Body so an den Client weiter, wie der Provider ihn erzeugt. Die Zeit bis zum ersten Byte richtet sich daher nach dem Provider und nicht nach der gesamten Generierung:Inkrementelles Transkript
transcript.text.done-Event meldet, gestreamte Sprachausgabe anhand der Dauer
des durchgeleiteten Audios. Beides wird gemessen, während die Response gestreamt
wird, und nicht anhand einer gepufferten Kopie. Eine Response beliebiger Länge
wird daher vollständig abgerechnet.
Eine gestreamte Response kann nicht wiederholt werden, sobald ihre ersten Bytes
beim Client angekommen sind. Daher führt GoModel – wie bei gestreamten Chat
Completions – für einen fehlgeschlagenen Upstream-Versuch bei
/v1/audio/speech
oder bei einer Transkription mit stream: true keinen Retry durch. Ein normaler
Transkriptions-Request behält die üblichen Retries.Streaming gilt für die OpenAI-kompatiblen Upstreams. Provider, deren native
Audio-API GoModel übersetzt (Xiaomi MiMo, Cohere, MiniMax, ElevenLabs), geben
einen vollständigen Body zurück, den GoModel als eine Response weiterleitet.
Weiterleitung von Parametern
Jeder Parameter, den GoModel oben nicht nennt, wird unverändert an den Provider weitergeleitet. So funktionieren neuere OpenAI-Optionen und providerspezifische Zusatzoptionen, ohne auf ein Gateway-Release warten zu müssen (ADR-0011, Regel 1):/v1/audio/speech– unbekannte JSON-Felder (zum Beispielstream_format) werden wieder in den Upstream-Body eingefügt./v1/audio/transcriptionsund/v1/audio/translations– unbekannte Formularwerte (zum Beispielinclude[]=logprobs,chunking_strategy,stream) werden in den Multipart-Body für den Upstream geschrieben, einschließlich wiederholter Werte.
model, file und der Routing-Hinweis provider, außerdem die
Transkriptionsoptionen, die es neu ausgibt – language, prompt,
response_format, temperature sowie timestamp_granularities[] und sein
Alias ohne Klammern timestamp_granularities), und zusätzliche Datei-Teile
in einem Transkriptions-Upload; nur das Audio in file wird gesendet.
Weitergeleitete Werte werden nicht im Audit-Log
gespeichert: Da es sich um beliebige Client-Eingaben handelt, die
Provider-Zugangsdaten enthalten können, erfasst der Eintrag unter
forwarded_fields nur die Namen der Felder.
Die Weiterleitung gilt für die OpenAI-kompatiblen Upstreams. Provider, deren
native Audio-API GoModel übersetzt (Xiaomi MiMo, Cohere, MiniMax, ElevenLabs),
erstellen ihre eigene Request-Form und ignorieren zusätzliche Parameter.
Kostenerfassung
Jeder/v1/audio/*-Aufruf wird in der Nutzungserfassung
unter seinem eigenen Endpunktpfad erfasst. Audiomodelle werden nach der Einheit
bepreist, die der Provider abrechnet, nicht nach Token:
- Sprachausgabe (
/v1/audio/speech) erfasst die Anzahl der Eingabezeichen (input_characters, bepreist mitper_character_input, wietts-1abgerechnet wird) und die Dauer des synthetisierten Audios (audio_output_seconds, bepreist mitper_second_output, wiegpt-4o-mini-ttsabgerechnet wird). Die Dauer wird anhand des zurückgegebenenwav,pcmodermp3gemessen; andere Codecs (opus,aac,flac) lassen sich ohne Dekodierung nicht messen, und die Zeile enthält einen entsprechenden Kostenhinweis. - Transkriptionen und Übersetzungen werden nach der Dauer des hochgeladenen
Audios bepreist (
audio_seconds, bepreist mitper_second_input). GoModel übernimmt die Dauer, die der Provider inusage.secondsoder indurationvonverbose_jsonmeldet, und misst andernfalls den Upload selbst. Die Kosten hängen daher nicht vomresponse_formatab, das der Client angefordert hat, und auch Provider, die überhaupt keine Nutzung melden (Groq, ElevenLabs), werden erfasst. - Nach Token abgerechnete Transkriptionsmodelle (
gpt-4o-transcribeund ähnliche) melden Token-usageund werden stattdessen mitinput_per_mtok/output_per_mtokbepreist. Ein Modell, das sowohl einen Token-Preis als auch einen Preis pro Sekunde veröffentlicht, wird nach der Einheit abgerechnet, die der Provider gemeldet hat, nie nach beiden.
m4a, ogg, flac, webm) –, wird die Nutzungszeile mit einem
Hinweis zur Kostenberechnung markiert, statt Kosten von $0 auszuweisen.
Einschränkungen
Die Audio-Endpunkte sind eine schlanke, nach Modell geroutete Weiterleitung an den Provider und durchlaufen nicht den vollständigen Inferenz-Orchestrator. Im Vergleich zu/v1/chat/completions gilt:
- Kein Failover, keine Guardrails, kein Response-Cache – diese Stufen werden
übersprungen. Requests werden trotzdem autorisiert, gegen das Budget geprüft,
erfasst (siehe Kostenerfassung) und unter ihrem
/v1/audio/*-Pfad in das Audit-Log geschrieben. - OpenAI-Request-Form rein, Provider-Dialekt raus – Clients senden immer das Audioformat von OpenAI. OpenAI-kompatible Upstreams erhalten es unverändert; Requests an Xiaomi MiMo, Cohere und MiniMax werden in den nativen Audio-Vertrag des jeweiligen Providers übersetzt. Weitere Provider werden hinter diesem Endpunkt nicht angepasst.
- Keine Retries für eine gestreamte Response – siehe Streaming.
- Realtime Voice-to-Voice (die WebSocket-basierte Realtime-API) wird nicht unterstützt.
/p/{provider}/v1/audio/...), um Bytes unverändert an diesen Upstream
weiterzuleiten.
Audit-Logging
Audio-Requests erscheinen im Audit-Log wie jede andere Modellinteraktion. Da Audio-Payloads binär und groß sind, werden ihre Bodys über eine eigene Einstellung gesteuert,LOGGING_LOG_AUDIO_BODIES
(Standardwert false), die LOGGING_LOG_BODIES verfeinert – sie hat keine
Wirkung, solange das Body-Logging nicht aktiviert ist:
- Body-Logging aus (
LOGGING_LOG_BODIES=false) – unabhängig von dieser Einstellung wird kein Audio-Body gespeichert. - Body-Logging an, Audio aus (Standard) – die Audio-Response wird als
schlanker Platzhalter
{__audio__, content_type, bytes, stored: false}erfasst; es werden keine Audio-Bytes gespeichert. - Body-Logging an, Audio an –
/v1/audio/speechspeichert seine Texteingabe und das erzeugte Audio, sodass das Dashboard einen eingebetteten Player anzeigt, und/v1/audio/transcriptionsspeichert das hochgeladene Audio (ebenfalls im Dashboard abspielbar) zusammen mit den Upload-Metadaten (Dateiname, Modell, Parameter).
media_id, und das
Dashboard ruft die Datei über GET /admin/media/{id} ab. Es gibt keine
Größenbegrenzung, und eine gestreamte Response wird gespeichert, während sie
weitergereicht wird. Dateien werden so lange aufbewahrt wie die Audit-Einträge,
die auf sie verweisen (LOGGING_RETENTION_DAYS).