语音合成与转写 API：音频能力的新入口

本文基于 OpenRouter 公告翻译整理，保留关键接口信息并用中文重新组织。

OpenRouter 新增了两个专用音频端点：文本转语音的 /api/v1/audio/speech，以及音频转文本的 /api/v1/audio/transcriptions。它们面向更明确的音频任务，相比通用音频模型通常更快、成本更低，也更容易被产品界面解释。

三类音频能力的差异

音频相关模型可以拆成三类：

• 音频理解模型：接收文本或音频，输出文本或音频，适合语音 Agent、音频问答和多模态对话。
• 语音合成模型：接收文本，输出语音，适合朗读、播报、配音和流式语音输出。
• 转写模型：接收音频，输出文本，适合会议纪要、字幕、客服录音整理和语音输入预处理。

这种拆分让用户在选模型时更容易理解“我到底需要推理能力，还是只需要一个专用音频转换能力”。

接入方式

语音合成端点接收文本、模型、声音和输出格式，返回音频字节流。转写端点接收 base64 编码的音频文件和格式，返回转写文本。

对于调用方来说，这类端点的价值是复用同一套：

• API Key 管理。
• 路由与 Provider 选择。
• 账单与用量统计。
• 日志与错误格式。

也就是说，音频能力不应该成为单独的孤岛，而应进入统一的模型治理体系。

对 GlobalRouter 的启发

GlobalRouter 已经将非标准多模态能力纳入异步 Task API。音频端点的设计提醒我们：对高频、明确的能力，可以提供更直接的专用入口；对长耗时或复杂多模态任务，则继续使用 Task API。

更清晰的产品分层可以是：

• Chat Completions：适合文本、多模态对话和工具调用。
• Dedicated APIs：适合语音合成、转写、Embedding 等专用能力。
• Task API：适合图片、视频、3D 等异步生成任务。

这样既能保持 OpenAI 兼容，又能给用户足够明确的能力边界。