文档 · 语音识别
不用先把音频传到哪儿
转写只有一个别名 auto/asr，走 OpenAI 形状的 POST /v1/audio/transcriptions。它收 multipart 上传、公开链接、以及 base64 data URL——最后一种值得单独说：意味着音频在发出去之前不需要先放到任何地方。
一句话定义
auto/asr 是一种 tokenexchage 提供的语音识别能力别名：把音频转成文字，不需要先把文件存到某个地方。它收 3 种输入（multipart 上传、公开链接、base64 data URL），背后只有 1 个模型、没有候选链。换转写模型会静默改变输出——标点不同、人名和数字的处理不同、断句不同，你不会收到任何报错。接口一次返回 1 条转写结果，不返回候选或置信度。
关键数字
| 接口 | POST /v1/audio/transcriptions |
| 支持的输入 | multipart 上传、公开链接、base64 data URL |
| 别名背后的候选模型数 | 1 |
三步接入
- 在控制台创建 API 密钥。
- 向 https://tokenexchage.com/v1/audio/transcriptions 发 POST，音频用 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 指向唯一一个模型，背后没有候选链。这跟这里所有非对话别名的做法一致：换转写模型会静默改变输出——标点不同、人名和数字的处理不同、断句不同。你不会收到报错，你会得到一份读着有点不对、但出自你已经信任的流水线的文本。
模型不可用时，请求直接失败并说明原因。
支持的输入
| 怎么发 | 字段 |
|---|---|
| multipart 上传 | file |
| 一个可访问的音频链接 | audio_url |
| 内联 base64 data URL | audio_url，值以 data:audio/…;base64, 开头 |
model 必填，写 auto/asr。
请求体上限 25 MB，超了在任何上游调用之前返 413。base64 会把体积撑大约三分之一，文件本身就接近上限的话，优先走 multipart。
什么时候用语音识别
会议录音整理、客服通话转写、视频字幕、语音输入，是四类最常见的用法。它们对精度的要求差别很大：字幕错一两个字观众能自己纠正，合同录音错一个数字就是事故。先想清楚你的场景能容忍多少错误，再决定要不要加人工校对环节。
环境噪声比口音更影响结果。安静环境下的方言，往往比嘈杂环境下的标准普通话识别得更好——先解决录音质量，比换模型更有效。
三种输入方式怎么选
已经有文件在本地，走 multipart 上传。音频已经在某个可公开访问的位置（对象存储、CDN），直接给链接，省一次上传。音频还在内存里、不想落盘，用 base64 data URL——这种方式不需要先把文件存到任何地方，适合一次性的、隐私敏感的音频。
长音频建议先按静音切段再逐段提交。整段提交的问题不在精度，在于失败的成本：一小时的文件传到 90% 断了，只能从头再来；切成几十段之后，某一段失败只需要重传那一段。
转写结果怎么用
转写文本通常还要过一遍处理才适合展示：去掉口语里的重复词、把数字和专有名词统一成固定写法、按语义重新断句。这些事在拿到文本之后做，比指望识别模型一次到位更实际。
如果后续要做检索或摘要，把时间戳一起留着。只有纯文本的话，用户想定位到「那句话是什么时候说的」就无从下手。
隐私与存储
音频里往往有比文本更多的信息：背景里提到的人名、电话、现场环境。转写完成后，原始音频要不要留、留多久，应该由业务需求决定，而不是默认一直存着。只走 base64 不落盘的那条路，适合那些「转完就不想再让它存在」的场景。
转写文本本身也可能包含敏感内容。 如果后续要拿去做检索或训练，先想清楚谁会用到它、用到什么程度。
转写结果的时间戳、说话人标记这类附加信息，能留就留着。它们不会让文本变好看，但在排查「这句话到底是谁在什么时候说的」时，往往是唯一的线索。
延伸阅读
- OpenAI API Reference —— 本页接口沿用的请求形状
- schema.org —— 本页结构化数据所用的类型定义
- Sitemap 协议 —— 站点页面的收录约定
常见问题
音频必须先上传吗？
不用。收 multipart 上传、公开可访问的音频链接、base64 data URL 三种输入；base64 那种方式意味着音频在发出去之前不需要先存到任何地方。
为什么会静默改变输出？
换转写模型会改变标点、人名和数字的处理、断句方式。你不会收到报错，会得到一份读着有点不对、但出自你已经信任的流水线的文本。
候选有几个？
背后没有候选链，只有一个模型。
其他能力
同一套命名，一个能力一个别名，都在 /v1/models 里：