文档 · 语音识别

不用先把音频传到哪儿

转写只有一个别名 auto/asr，走 OpenAI 形状的 POST /v1/audio/transcriptions。它收 multipart 上传、公开链接、以及 base64 data URL——最后一种值得单独说：意味着音频在发出去之前不需要先放到任何地方。

怎么调

curl https://tokenexchage.com/v1/audio/transcriptions \
  -H "Authorization: Bearer sk-你的key" \
  -F "model=auto/asr" \
  -F "file=@会议录音.mp3"

{ "text": "……完整转写……" }

JSON 或者链接也能代替上传：

import base64, requests

audio = base64.b64encode(open("会议录音.mp3", "rb").read()).decode()
data_url = "data:audio/mpeg;base64," + audio

r = requests.post(
    "https://tokenexchage.com/v1/audio/transcriptions",
    headers={"Authorization": "Bearer sk-你的key"},
    json={"model": "auto/asr", "audio_url": data_url},
)
print(r.json()["text"])

base64 那条路能走，是因为上游模型本身就收 data URL——实测过，不是想当然。多数网关要求你先找个地方把文件托管起来。那一步多出来的是一个存储桶、一套凭据、一条生命周期规则和一份清理任务。

只有一个模型，所以没什么能漂移

auto/asr 指向唯一一个模型，背后没有候选链。这跟这里所有非对话别名的做法一致：换转写模型会静默改变输出——标点不同、人名和数字的处理不同、断句不同。你不会收到报错，你会得到一份读着有点不对、但出自你已经信任的流水线的文本。

模型不可用时，请求直接失败并说明原因。

支持的输入

model 必填，写 auto/asr。

请求体上限 25 MB，超了在任何上游调用之前返 413。base64 会把体积撑大约三分之一，文件本身就接近上限的话，优先走 multipart。

其他能力

同一套命名，一个能力一个别名，都在 /v1/models 里：