OpenAI 将语音转文字拆分为四个模型 ID：每条音频流水线都需要做的路由决策

OpenAI 于 7 月 28 日发布了两个新的语音转文字模型——gpt-transcribe 和 gpt-live-transcribe——并立即将其设为所有新转录任务的推荐默认。这看起来像是模型升级，实则是一次路由架构变更：OpenAI 将语音转录拆分为四个模型 ID 的矩阵，每个 ID 覆盖不同能力集，其中两项能力在新默认模型中已不再存在。

如果你的音频流水线是围绕 gpt-4o-transcribe 构建的，代码今天仍然可以运行——但你所依赖的路由表已经被替换。

发生了什么变化，各模型 ID 现在覆盖什么

7 月 28 日之前，gpt-4o-transcribe 是所有转录任务的推荐模型——文件上传、流式处理和实时音频都走它，接受 /v1/audio/transcriptions endpoint，从单一模型名称覆盖大多数场景。

新的模型矩阵：

路由后果：在选择模型之前，你现在必须明确自己需要哪种能力。旧的 gpt-4o-transcribe 允许你在请求中声明功能，endpoint 会处理它们。新架构将每种能力放入不同的模型 ID。

Endpoint 拆分才是破坏性变更

gpt-live-transcribe 不支持 v1/audio/transcriptions。它只通过 v1/realtime/transcription_sessions——OpenAI 的 WebSocket 实时 API——工作。如果你的流水线上传文件并期待同步返回转录文本，gpt-live-transcribe 无法处理该请求。

反过来，gpt-transcribe 不支持 Realtime endpoint 的流式场景。它是请求-响应模型：发送文件，返回文本。它确实可以在 Realtime endpoint 的一个特定子场景中工作——转录 committed turns（语音会话中用户已说完的内容）——但获取说话中的实时转录片段需要 gpt-live-transcribe。

对于构建语音 agent 的 operator 而言，这一点尤为重要。如果你运行的是 WebSocket 语音会话，并且需要用户说话过程中的局部转录，则需要在 Realtime endpoint 上使用 gpt-live-transcribe。如果你只需要在每次对话结束后读取用户说了什么，那么使用 Realtime transcription endpoint 上的 gpt-transcribe 更便宜、足够用。

定价差距：文件与实时相差 3.8 倍

gpt-transcribe 每分钟音频收费 $0.0045。gpt-live-transcribe 每分钟 $0.017——对于相同的语音内容，大约贵 3.8 倍。

溢价来自低延迟：gpt-live-transcribe 在音频到达时实时流出局部转录，并跨音频会话维持连接状态。如果你的场景不需要说话者说完之前的局部转录——只需要说完后准确的转录结果——gpt-transcribe 是正确的路由决策，可显著降低成本。

对于运行呼叫中心分析、会议录音或播客转录流水线的 operator：这些任务几乎从不需要流式局部转录，工作发生在音频录制完成之后。这些流水线应当路由到 gpt-transcribe，而非 gpt-live-transcribe。

whisper-1 仍然独占的能力

两个新模型都不支持逐词时间戳、SRT 输出、VTT 字幕或将音频翻译为英文。这些能力仍然专属于 whisper-1。如果你在构建字幕流水线、配字幕工作流，或任何需要逐词时间戳的输出，新模型不是迁移目标。

这是现有集成中最常见的错误：使用带 timestamp_granularities: ["word"] 或 response_format: "srt" 的 gpt-4o-transcribe 的团队，需要为这些调用保留 whisper-1，而非升级到 gpt-transcribe。

新增上下文参数提升准确率

gpt-transcribe 和 gpt-live-transcribe 新增了 gpt-4o-transcribe 所没有的两个参数：

• keywords：一个术语数组，在音频模糊时模型应优先识别——模型名称、产品 SKU、专有名词、技术术语
• languages：语言代码列表，提示预期输入语言；模型能处理单段音频中的语言混用

prompt 字段继续作为非结构化上下文字符串使用。新的 keywords 参数是结构化的，对特定术语的权重更高。对于领域专属音频——提到产品 ID 的客服电话、使用 API 名称的工程会议——即使在其他迁移工作之前，也值得为现有集成添加 keywords 数组。

从 gpt-4o-transcribe 的迁移路径

对于大多数文件转录任务：

# 之前
transcription = client.audio.transcriptions.create(
    model="gpt-4o-transcribe",
    file=audio_file
)

# 之后
transcription = client.audio.transcriptions.create(
    model="gpt-transcribe",
    file=audio_file,
    keywords=["你的领域术语"]  # 新增，提升准确率
)

对于实时音频流，endpoint 本身也会变化：

# gpt-live-transcribe 需要 v1/realtime/transcription_sessions
# 而非 v1/audio/transcriptions——这是两种不同的 WebSocket 会话

硬编码 endpoint URL（而非仅指定模型名称）的团队需要验证 endpoint 与模型匹配。将 gpt-live-transcribe 发送至 /v1/audio/transcriptions 会失败；将 gpt-transcribe 发送至 /v1/realtime 进行流式转录只会返回 committed-turn 结果，不会返回实时局部片段。

路由团队需要关注的点

GPT Transcribe 的发布表明 OpenAI 正在将音频作为能力集群而非单一模型来处理。预计这个矩阵还会扩展——说话人分离已经在单独的模型（gpt-4o-transcribe-diarize）中，翻译仍在 whisper-1 中。今天规划语音流水线意味着要跨多个模型 ID 制定路由策略，而非依赖单一别名。

对于通过 AI gateway 路由至 OpenAI 的团队，模型到 endpoint 的映射需要验证。接受任意模型名称并转发至固定 /v1/audio/transcriptions endpoint 的代理，会静默地错误路由 gpt-live-transcribe 请求。音频 endpoint 的 operator 级路由规则现在与文本补全路由是独立的。