时间：2026年7月22日
地点：美国旧金山（OpenRouter线上平台）
人物：OpenRouter团队；OpenAI Whisper模型团队及平台接入的多家语音模型提供方
事件详情：OpenRouter近日上线音频转写接口，开发者可以通过统一的POST /api/v1/audio/transcriptions端点，将音频直接转换为文本。该接口沿用OpenRouter现有的Bearer密钥和鉴权方式，不需要另行部署Whisper服务或接入第二套供应商SDK。平台目前支持OpenAI Whisper-1等Whisper类模型，也提供按Token计价的新一代语音转文本模型；当同一模型由多家供应商托管时，平台会在供应商之间自动负载均衡。请求可以使用Base64编码音频，也支持最大25MB的OpenAI风格multipart文件；返回结果包含转写文本、音频时长、Token用量及实际成本等信息。
背景：语音输入正在从聊天机器人的附加能力，变成会议纪要、客服质检、语音备忘录、播客处理和实时应用的基础设施。过去，开发团队通常需要自行维护Whisper推理服务，或分别适配不同云厂商的语音API，导致模型切换、故障转移、用量统计和成本核算都较为分散。OpenRouter此前主要以统一的大语言模型调用接口和模型路由能力受到关注，此次将音频转写纳入同一入口，反映出AI API聚合平台正从文本模型扩展到多模态和语音工作流。
影响：
- 降低集成门槛——开发者可复用已有的OpenRouter账号、鉴权和调用习惯，把语音转写接入现有AI应用。
- 提升供应商切换弹性——多供应商托管和统一返回格式，有助于减少单一语音服务商故障或限流对业务的影响。
- 让成本更容易量化——响应中的用量与成本字段便于按请求、用户或业务线进行计量，支持更精细的语音应用运营。
- 仍需关注工程边界——当前接口存在约60秒上游超时限制，不支持直接提交音频URL或输出SRT/VTT，长音频和字幕生产仍需自行拆分与后处理。
总结：OpenRouter此次推出的音频转写API，核心价值不只是增加一个语音模型入口，而是把语音识别纳入统一的模型路由、鉴权和成本管理体系。对需要快速验证会议转写、语音搜索或音频内容分析的团队而言，这能减少基础设施和多供应商适配工作；对已有生产系统而言，自动负载均衡和成本回传也提供了更清晰的运维抓手。不过，60秒超时、25MB文件上限以及缺少SRT/VTT原生输出，意味着它更适合短音频和在线处理场景，复杂长音频流水线仍需要配合队列、切片和字幕封装服务。
参考来源：
- https://openrouter.ai/blog/tutorials/transcription-on-openrouter
- https://openrouter.ai/docs/api_reference/overview
- https://openrouter.ai/openai
- https://openrouter.ai/docs/quickstart
- https://openrouter.ai/pricing
- https://github.com/OpenRouterTeam