语音接口（TTS / STT）在中转站上的支持盘点与自测要点

为什么语音是「最后才发现」的能力

文本类能力你一定会测（因为它是主用途）。而语音往往是项目后期才加的功能 —— 到那时你已经在某家站上跑了几周，才发现它不支持，或者支持得很难用。

所以：如果你的产品规划里有语音，把它放进第一轮选型评估。

三类接口形态

一、STT（语音转文字）

OpenAI 的标准形态：

POST /v1/audio/transcriptions
Content-Type: multipart/form-data
file=@audio.mp3&model=whisper-1

要点：

• 是 multipart/form-data，不是 JSON。这一点会让很多只会转发 JSON 的网关直接失败；
• 音频文件通常有大小上限（官方为 25MB），中转站可能更小；
• 支持格式取决于上游（mp3 / mp4 / m4a / wav / webm 常见）。

二、TTS（文字转语音）

OpenAI 的标准形态：

POST /v1/audio/speech
{"model":"tts-1","input":"要合成的文字","voice":"alloy"}

返回的是音频二进制流，不是 JSON。

要点：

• 返回 Content-Type: audio/mpeg，如果你按 JSON 解析会直接失败；
• 中转站的计费口径可能按字符数而不是 token，需要在后台确认；
• 有些站的 TTS 走的是完全不同的上游（如国内厂商），音色列表与官方不一致。

三、Realtime（实时语音）

WebSocket 长连接。这一类的支持率在中转站上最低，因为：

• WebSocket 的转发比 HTTP 复杂（需要保持长连接与双向流）；
• 计费口径与 HTTP 请求不同；
• 多数基于 One API 系的实现不支持或支持不完整。

如果你的产品需要实时语音对话，务必在上线前单独验证，不要假设它可用。

四个必测点

1. 接口形态是否能通

先用 curl 直接打 multipart/form-data 的 STT：

curl -s https://<域名>/v1/audio/transcriptions \
  -H "Authorization: Bearer $KEY" \
  -F file=@test.mp3 -F model=whisper-1

判据：返回 {"text": "..."} 结构，且转写内容与音频相符。

失败时看错误类型：

• 415 / 400 且提示 Content-Type → 网关不支持 multipart，这是最常见的失败原因；
• 404 → 端点不存在；
• 200 但 text 为空 → 转写被跳过（同样是静默失败，值得警惕）。

2. 文件大小与时长上限

从小文件开始，逐级测试到 5MB、10MB。记录失败点。

为什么重要：语音产品的典型输入是几分钟的录音，很容易超过某些站的限制。而这类限制在文档里常常不写。

3. 音频格式覆盖

同一段音频转成 mp3 / wav / m4a / webm 各测一次。

为什么重要：浏览器的 MediaRecorder 默认输出 webm/opus，如果你的前端用的是这个，而站方只支持 mp3，就会在真实使用中失败 —— 而 curl 测试时你用 mp3，所以测不出来。

这是一个非常典型的「测试通过、上线失败」场景。

4. TTS 的音色与质量

• 音色列表：官方有固定的一组，站方可能与官方不同；
• 实测音质：有些站用低价上游，合成出来的音频采样率或响度异常；
• 长文本：TTS 通常有单次字符上限，超了要么报错要么被截断（后者更糟）。

计费口径要单独确认

语音的计费与文本完全不同：

必须在站方后台确认口径，因为「倍率」这个词在语音上可能指完全不同的基准。有些站根本不在页面上写语音的计费方式，这时直接问站长比猜要快。

一个务实建议

语音能力单独用一个 Key（如果站方支持多 Key）。

理由：语音的失败模式（大文件、长时间、multipart）与文本不同，混在一个 Key 上会让用量曲线很难解读；分开之后，一旦语音出问题，你能立刻从用量上区分出来。

结论

语音接口在中转站上的成熟度明显低于文本接口。如果你的项目用到语音：

1. 选型阶段就测，不要等开发到一半；
2. 重点测 multipart 支持、文件大小、webm 格式、返回类型四项；
3. 如果站方不支持，不要指望「以后会支持」 —— 语音端点的转发实现与文本差异较大，很多站根本不打算做。

本站的收录数据以文本类探测为主（/v1/models 与首页可达性），不包含语音能力的实测。这一项必须自己验证。