OpenAI 把语音转录拆成两条路：实时贵 3.8 倍，差在哪？

两条独立产品线：文件转录与实时转录分离

OpenAI 刚刚发布 GPT-Transcribe 和 GPT-Live-Transcribe 两套语音转文字模型。两者分别面向已完成的录音文件和持续输入的实时音频，均支持上下文、关键词和多语言提示。

这次更新的重点不只是增加了两个模型，而是将文件转录和实时转录拆成了两条独立产品线。过去，开发者经常需要在同一套语音识别方案中兼顾准确率、延迟和成本，现在可以根据音频是否正在发生，选择不同的模型和调用方式。

GPT-Live-Transcribe：处理实时音频

gpt-live-transcribe 面向麦克风、电话、会议或直播等持续产生的音频。

模型通过 Realtime transcription session 接收音频流，并随着语音输入持续返回文字增量。在一段语音被提交后，系统还会返回该片段的最终转录文本。

服务端可以通过 WebSocket 接入，浏览器和移动端也可以通过 WebRTC 接入。模型支持调整转录延迟：较低的延迟设置可以更早返回部分文字，较高的延迟设置则可能提高转录质量。

其适用场景包括直播字幕、会议实时记录、电话转录、语音助手和通话辅助。

GPT-Live-Transcribe 按音频时长计费，价格为每分钟 0.017 美元。按照公开单价计算，一小时音频的模型费用约为 1.02 美元。

实时模型价格更高，主要对应的是持续音频接入、增量文字输出和更低响应延迟。对于直播字幕和语音交互产品，转录结果能否及时出现，通常与最终准确率同样重要。

GPT-Transcribe：处理录音文件

gpt-transcribe 主要处理已经录制完成的音频文件，也可以为 Realtime 会话中已经提交的语音片段生成最终转录文本。

文件转录继续使用：/v1/audio/transcriptions

开发者可以一次性获取完整结果，也可以让接口分段返回已经生成的文字。这里的流式返回，是指完整音频文件的转录结果逐步输出，并不是持续接收正在发生的现场音频。

GPT-Transcribe 的价格为每分钟 0.0045 美元，一小时音频的模型费用约为 0.27 美元。GPT-Live-Transcribe 的每分钟价格约为 GPT-Transcribe 的 3.8 倍。

因此，已经录制完成的会议、播客、采访和客服录音，可以使用 GPT-Transcribe 处理。没有实时显示需求时，文件转录的成本明显更低。

两套模型的价格差异，也反映出语音转录正在从“一个模型覆盖所有任务”，转向按照延迟要求和处理方式分层计费。

两套模型都支持上下文提示

GPT-Transcribe 和 GPT-Live-Transcribe 均支持三类转录上下文：

• prompt：录音主题、场景和背景信息；
• keywords：产品名、人名、药品名、缩写和编号等可能出现的词；
• languages：音频中预期出现的语言列表。

这些参数可以帮助模型处理专业术语、多语言切换、产品编号和特定名称。

关键词只是识别提示，并不代表模型必须输出对应词语。开发者仍需要检查模型是否误插入音频中没有出现的关键词。

上下文参数的结构化，是这次更新中较重要的变化。语音识别不再只依赖音频信号，调用方还可以将业务场景、术语库和语言信息传入模型。

对于医疗、金融、客服、教育和企业会议等垂直场景，模型本身的通用准确率之外，专业词汇能否稳定识别，往往直接影响转录结果是否可用。

批量任务不等于 Batch API

GPT-Transcribe 可以用于批量工作负载，例如由应用程序将多份录音加入任务队列，分别调用文件转录接口。

但 OpenAI 当前的 Batch API 不包括：/v1/audio/transcriptions

因此，音频转录的批量处理仍需要由应用侧自行组织，不能直接通过 /v1/batch 提交，也不适用 Batch API 的折扣和独立额度。

在实际系统中，开发者还需要自行处理任务队列、并发限制、失败重试、文件上传和结果回写。

对语音产品意味着什么

OpenAI 将实时转录和文件转录分开，说明语音识别产品的竞争重点正在发生变化。

第一，实时转录开始成为独立能力。直播字幕、电话客服和语音助手关注的不只是最终文本是否准确，还包括首段文字出现时间、增量结果稳定性和最终文本完成速度。

第二，上下文正在成为转录系统的一部分。产品可以根据用户、行业和对话场景，动态传入术语和语言信息，而不是只依赖一个固定模型处理所有音频。

第三，基础转录能力的接入门槛继续下降。开发者可以更快获得实时或文件转录能力，但产品之间的差异会更多转向音频处理、上下文管理、交互设计和业务流程整合。

两套模型都不能只依靠官方描述完成选型。实际效果仍与音频类型、口音、背景噪声、电话音质、专业术语和多语言环境有关，需要使用真实业务音频进行测试。

JOTO 企业落地观察

• 企业部署语音转录能力时，需明确区分「实时性」是否为业务刚需——若仅需事后分析会议纪要或客服录音，GPT-Transcribe 的成本优势显著，且上下文提示已足够支撑垂直领域术语识别。
• 实时转录系统对端到端延迟、流式稳定性及错误恢复机制提出更高工程要求，单纯替换模型无法达成可用效果，需配套设计音频缓冲、断连续传与增量校验逻辑。
• 上下文参数（prompt/keywords/languages）的结构化暴露，使 RAG 知识工程可前置介入：企业能将内部术语库、业务流程图谱、多语种命名规范等作为标准输入注入转录链路，而非依赖后处理清洗。
• 当前 Batch API 缺失音频接口，意味着企业级批量转录需自建任务调度与容错体系；这对 FDE 驻场共创中定义标准化音频预处理、元数据绑定与结果归档协议提出了明确需求。