一句话看懂：OpenRouter 推出了统一的音频转写 API 端点，开发者可以用现有的 API key 直接转写音频，无需单独部署 Whisper 服务或接入第二家 SDK。平台同时支持按时长计费的 Whisper 模型和按 token 计费的新一代语音转文本模型。
事件核心：发生了什么
7月22日，OpenRouter 宣布在 POST /api/v1/audio/transcriptions 端点上线音频转写功能。开发者只需将音频文件编码为 base64 放入 JSON 请求体，就能获得 JSON 格式的转写文本和用量信息。该接口使用与 Chat Completions 相同的 Bearer 令牌认证。支持的模型包括 Whisper 类（slug 为 openai/whisper-1）以及按 token 计费的 STT 模型。需要注意的是，这些 STT 模型不会出现在默认的模型目录中，需通过 ?output_modalities=transcription 参数筛选才能发现。目前该端点不支持音频 URL 上传，文件需以 base64 或 OpenAI 风格的 multipart 形式提交（最大 25 MB），上游超时限制为 60 秒，且暂不支持 SRT/VTT 字幕输出。对于 OpenAI 兼容的提供商，可设置 response_format: "verbose_json" 获取单词和片段时间戳。定价按模型不同分别为按时长或按 token 计费，OpenRouter 不收取额外加价，usage.cost 字段会返回每次请求的实际费用。
为什么重要
对于调用 LLM 的开发者而言，语音转写一直是独立于主流程的“附加基础设施”。以往要么自建 Whisper 服务器，要么集成第二家服务商的 SDK。OpenRouter 将这一能力收归到已有 API 体系内，意味着语音输入不再需要单独管理凭证、配置路由或进行成本核算。当一个转写模型被多个提供商托管时，OpenRouter 会跨提供商自动负载均衡，无需开发者手动指定。这种“一个平台、一个 SDK、统一计费”的整合路径，降低了多模态应用的前期集成成本。目前公开信息显示，该端点的路由控制选项（如 order、allow_fallbacks、data_collection、sort）暂不适用，用户自带密钥的请求仅将流量路由至个人密钥并收取平台费。
对用户/开发者/创作者的影响
对于开发者，带来最直接的便捷是省去一套独立代码的维护工作。无论是处理 40 分钟的销售通话录音、整理语音备忘录文件夹，还是构建按下话筒按钮即转写的用户界面，一套 API 一个 key 就能完成。对于创作者和内容团队，转写功能的接入门槛大幅降低，只需通过 curl 或 SDK 就能将会议录音、播客音频批量转为文字。同时也意味着 AI 应用可以更自然地接收语音输入——语音→文本→大模型处理→文本回复的链路在 OpenRouter 平台上可以统一完成。按 token 计费的新模型则给人更精细的预算控制选项，尤其适合对成本敏感的大规模转写场景。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
1. 多模态融合方向：OpenRouter 将语音转写与 Chat Completions 对齐后，下一步是否会将音频输入直接作为原生模态支持，值得观察。目前转写端点尚未支持音频输入与对话的历史上下文结合。2. 路由控制的补齐：当前转写端点不支持 fallback、排序等路由控制，若后续加入这些能力，将进一步提升容错和成本优化空间。3. 竞品跟进：其他聚合网关服务商是否也会推出统一的音频转写端点，或提供类似的多模态整合方案，这将影响开发者选择端侧基础设施的长期倾向。
