实时语音 API 怎么选模型：转写、翻译与语音 Agent 的路由和成本设计

做语音应用时，一个常见误区是先问“哪个语音模型最强”，再把录音转写、实时字幕、同声翻译和客服 Agent 全部接到这个模型上。

但这四类任务看起来都在处理音频，工程目标却完全不同：录音转写追求最终文本准确率；实时字幕要尽快返回可读的增量结果；翻译既要连续理解，又要连续输出另一种语言；语音 Agent 还要管理对话状态、打断、工具调用和回复声音。选错接口，不仅会多花钱，还可能把延迟、重试和故障恢复都做复杂。

OpenAI 近期更新了语音 API 的模型和文档。截至 2026 年 7 月 31 日，官方已经把文件转写、实时转写、实时翻译与双向语音对话拆成不同的模型和计费方式。这次变化真正值得开发团队关注的，不是又多了几个模型名，而是语音请求需要按任务形态路由，不能继续把“音频”当成一个统一类别。

先按结果分类，不要先按模型分类

可以先用一个问题判断请求应该走哪条链路：用户最终需要的是文本、翻译后的声音，还是一个能继续行动的助手？

任务	更合适的能力	当前计费参考	关键取舍
已完成录音转文字	`gpt-transcribe`	0.0045 美元/分钟	最终文本质量优先，不需要保持实时会话
直播、会议或通话字幕	`gpt-live-transcribe`	0.017 美元/分钟	用更高成本换取低延迟增量文本
连续语音翻译	`gpt-realtime-translate`	0.034 美元/分钟	连续接收源音频并输出翻译音频与文本增量
可对话、可调用工具的语音 Agent	`gpt-realtime-2.1` 或同类实时模型	按文本、音频等 token 计费	需要管理会话历史、打断、推理与工具调用

上表价格来自 OpenAI 官方定价页，是截至本文发布日期的快照。模型和价格可能继续调整，生产路由应从配置中心读取，而不是写死在业务代码里。

录音已经结束：优先走文件转写

如果音频已经完整存在，例如播客、访谈录音、工单留言或会议录像，通常没有必要维持实时连接。官方转写指南建议从 gpt-transcribe 开始，它支持完整文件、文件处理过程中的文本流式返回，以及用于行业术语和多语言场景的上下文、关键词与语言提示。

这里要区分两种“流式”：文件转写可以在处理完整录音时逐步返回文本，但它并不等于麦克风还在持续输入的实时会话。用户不要求边说边看时，文件接口通常更简单，也更便宜。

音频仍在产生：再使用实时转写

直播字幕、电话质检和会议记录面对的是尚未结束的音频流。gpt-live-transcribe 会在语音到达时返回 transcript delta，并在一个语音轮次提交后给出最终文本。

实时转写的核心变量不是单一的“快”或“准”。官方文档明确指出，较低的延迟设置可以更早输出局部文本，较高的延迟设置能让模型获得更多语音上下文，通常更有利于词错率。实际选择必须用真实麦克风、电话音质、口音、噪声、夹杂外语和行业词汇测试，不能只用干净的合成音频做结论。

用户需要翻译：不要在转写后临时拼一条链

一种常见实现是“语音转文字 -> 文本翻译 -> 文字转语音”。它便于分别替换组件，但每一段都会增加缓冲、排队和错误传播。对连续同声翻译，专用的实时翻译会话可以持续接收音频，并返回翻译后的音频与文本增量。

这不意味着专用翻译模型永远更好。如果业务需要保存逐字稿、人工修订术语、对每一段翻译做审计，拆开的流水线反而更容易控制。路由规则应根据是否要求端到端低延迟、是否需要中间文本和是否允许人工修订来决定，而不是只看单价。

用户需要助手回答和行动：才进入语音 Agent 会话

语音 Agent 不只是“会说话的转写模型”。实时对话模型会同时处理输入音频、会话上下文、输出文本或音频，还可能调用搜索、工单、日历等工具。TechCrunch 对 GPT-Live 系列的报道也强调了全双工能力：模型可以同时听和说，让自然打断和实时翻译成为可能。

这种能力的成本结构与按分钟转写不同。以当前 gpt-realtime-2.1 为例，文本、音频和图像输入分别计费，输出也有不同价格；对话越长，前面的消息越可能继续成为后续请求的输入。把它直接与“每分钟 0.0045 美元”的文件转写比较，会得到错误结论。

算成本时，先把四本账拆开

语音应用的月度成本可以先按下面的结构估算：

总成本 = 文件转写分钟数 x 文件转写单价
       + 实时转写分钟数 x 实时转写单价
       + 实时翻译分钟数 x 实时翻译单价
       + 语音 Agent 的文本/音频输入输出 token 成本
       + 重试、并行调用和兜底模型成本

例如，同样处理 1,000 分钟音频，按当前标价，文件转写约为 4.50 美元，实时转写约为 17 美元，实时翻译约为 34 美元。这只是帮助理解计费差异的算术示例，不包含存储、媒体转码、应用服务器、日志和下游模型调用，也不代表真实业务账单。

语音 Agent 还要特别注意三个容易漏算的部分：

长会话会累积上下文。 Realtime API 在每次创建 Response 时会带上整个对话，后面的轮次通常比前面的轮次更贵。
缓存依赖历史稳定。 中途修改早期指令或工具定义会破坏之后的缓存命中，频繁动态改写 system prompt 可能让预估成本失真。
空音频也要正确处理。 启用语音活动检测可以过滤没有说话的片段；如果客户端手动把空白音频加入会话，它仍可能进入计量链路。

因此，成本看板至少要按“业务场景、模型、会话、输入类型、输出类型”拆分，不能只统计一个 API Key 的总金额。

把路由决策放在会话开始前

文本请求失败后，网关往往可以把同一段 prompt 重发给备用模型。实时语音连接不同：浏览器可能使用 WebRTC，服务端可能使用 WebSocket，电话系统还可能通过 SIP 接入。连接建立后，会话状态、音频缓冲和已输出内容都在持续变化，不能假设换个模型名就能无缝续传。

更稳妥的做法，是在创建会话前完成一次明确分类：

{
  "workload": "live_transcription",
  "latencyTarget": "balanced",
  "languages": ["zh", "en"],
  "needsToolUse": false,
  "needsAudioResponse": false,
  "dataRegion": "configured-region",
  "budgetPolicy": "team-default"
}

网关根据这些字段选择提供方、模型、区域和凭据，再建立对应连接。这样做有三个直接好处：业务代码不需要记住不断变化的模型名；预算、地区和合规规则可以统一应用；模型升级时可以做小流量验证，而不是一次改动所有客户端。

降级也要按任务设计

不同语音任务需要不同的降级策略：

文件转写失败，可以排队重试，或切换到另一个支持相同文件格式和语言提示的模型。
实时字幕断线，应保留最后确认的音频偏移和最终 transcript，重连后从安全边界继续，避免重复字幕。
实时翻译断线，要向用户明确提示翻译中断，不能把缺失片段伪装成连续结果。
语音 Agent 断线，需要保存结构化会话摘要和已完成的工具调用；涉及付款、发信或修改数据的动作，恢复后不能自动重复执行。

这也是语音路由和普通负载均衡最大的区别：fallback 的目标不是简单“请求成功”，而是恢复到用户能理解、业务能校验的状态。

观测指标要覆盖质量、延迟和账单

只记录 HTTP 状态码，无法判断语音链路是否真的可用。建议至少记录以下字段：

维度	建议指标
路由	业务场景、提供方、模型、区域、路由规则版本
会话	session id、连接方式、时长、断线原因、重连次数
延迟	首个 transcript delta、最终 transcript、首个音频回复、工具调用耗时
用量	音频分钟数、文本 token、音频 token、缓存输入、重试与并行调用
质量	抽样词错率、术语修订率、翻译人工修订率、用户打断成功率
安全	凭据来源、工具授权、敏感动作确认、审计关联 id

这些数据要能回到同一个业务任务。否则团队只能看到“某模型本月花了多少钱”，却无法回答“实时字幕为什么变贵”“某种电话音质为什么频繁重试”或“新模型是否真的降低了人工修订量”。

上线前用这份清单做一次复核

录音转写、实时字幕、翻译和语音 Agent 是否已经拆成不同 workload？
路由依据是任务目标与 SLA，还是客户端写死的模型名？
是否分别统计按分钟费用与文本、音频 token 费用？
是否用真实口音、噪声、电话音质和领域词汇做过测试？
实时连接中断后，字幕偏移、会话摘要和工具调用状态如何恢复？
模型切换时，是否验证事件格式、VAD、提示字段和连接方式兼容性？
浏览器和移动端是否只拿短时凭据，而不是长期 API Key？
是否为成本、延迟、错误率和异常重试设置了告警？

语音模型正在从一个通用能力拆成多条专业链路。对开发团队来说，真正可持续的做法不是追着每次发布改模型名，而是先定义任务、计费和恢复边界，再让统一路由层根据这些边界选择模型。这样，新模型上线时只是多一个可验证的候选项，而不会变成一次高风险迁移。