GPT Transcribe 是 OpenAI 推荐的语音转文字模型，用来把已经录完的材料写成其原始语言的文本。它面向上传的音频文件、完整文件的流式转写结果，以及 Realtime WebSocket 会话里已确认的音频回合。这个范围适合会议、访谈、播客、客服通话、调研录音，以及任何需要把说话内容变成可检索文本的产品。对短视频字幕、课件逐字稿和客服质检来说，先得到一份能检索、能人工改的原文，往往比立刻摘要或配音更重要。
关键细节是准确的模型名：gpt-transcribe。它不是 gpt-4o-transcribe 的简称，也不是突然能接收 MP3 的通用 ChatGPT 模型。OpenAI 把它写成专用的高精度转写模型：输入可以是音频和文本，输出是文本，并支持上下文提示、多语言引导、语言检测和流式。本指南说明这些能力在实务里意味着什么，以及什么时候另一个模型仍是更合适的选择。
来源和产品细节复核于 2026 年 7 月 30 日。把生产流量切过去之前，请再核对模型是否可用、价格、上限和数据控制。指南页、端点参考和定价表更新节奏并不相同，集成文档里写死一份格式清单，最容易在上线后才发现容器或留存策略已经变了。
要点
- 一段已经录完、需要留在原始语言的录音，从
gpt-transcribe开始。 - 把文件发到
POST /v1/audio/transcriptions；响应里包含转写文本，以及模型能够可靠检出的语言。 - 把
prompt、keywords和languages当作相关上下文，而不是让模型编造内容的指令。 - 把一份已经完整的文件的转写做成流式，并不等于对着直播麦克风不停转写。
- 说话人标签、逐词时间戳、字幕文件和译成英语，继续走专用路径。
- 上线前，用你自己的音频评估专有名词、数字、漏句、语码转换、延迟和凭空插入。评估集要覆盖会进生产的那种噪声和术语，而不是只拿干净旁白报喜。
GPT Transcribe 是什么？
GPT Transcribe 是自动语音识别模型。它的核心工作比对话模型更窄：接收说话音频，加上可选的文本上下文，返回书面转写。它不会在同一次调用里替你做纪要、待办或配音草稿；那些是转写之后的派生步骤。GPT Transcribe 官方模型卡 把音频和文本列为输入模态，文本列为输出模态，并同时支持转写和 Realtime 转写端点。
「GPT」这个名字有意义，因为接口可以利用那些传统声学流水线通常会单独处理的语言上下文。一次请求可以描述这段录音、列出很可能出现的字面术语，并标明多种预期语言。不过 OpenAI 没有在模型卡上公布详细架构或训练配方。断言内部参数量、数据集规模、解码器设计或普适准确率，都属于推测。
更有用的是实务定义：
GPT Transcribe 是带上下文的语音转文字模型，用来高精度转写文件和已确认的音频回合，输出以 JSON 为主，并带有检测到的语言元数据。
这个定义也能挡住常见的命名错误。gpt-transcribe、gpt-4o-transcribe、gpt-4o-mini-transcribe、gpt-4o-transcribe-diarize、gpt-live-transcribe 和 whisper-1 是不同的模型选择。它们有重叠，但最佳流程和所支持的输出并不相同。
它在 OpenAI 语音转文字栈里排在哪
OpenAI 现行文档建议：从匹配音频生命周期和所需输出的模型开始。决策不是简单的「新模型对旧模型」。先问音频是不是已经录完、要不要说话人、要不要时间戳或字幕文件、要不要译成英语；这四件事会直接把你送进不同的端点和响应格式。
| 需求 | 建议的起点 | 原因 |
|---|---|---|
| 原始语言的已完成录音 | gpt-transcribe | 通用文件转写、上下文提示、检出语言，以及流式文本输出 |
| 持续到达的麦克风、通话或媒体音频 | gpt-live-transcribe | 音频到达时的低延迟转写 |
| 已完成录音里的说话人标签 | gpt-4o-transcribe-diarize | 在 diarized_json 里返回带说话人的片段 |
| 逐词或逐段时间戳 | whisper-1 | 配合 verbose_json 支持时间戳粒度 |
| 原生 SRT 或 VTT 字幕输出 | whisper-1 | 直接支持字幕响应格式 |
| 把录下的说话内容译成英语 | whisper-1 走 /v1/audio/translations | 专用的音频到英语翻译路径 |
这个区别容易被漏掉，因为「流式」其实在说两件不同的事。文件可以已经躺在磁盘上，同时 API 把部分转写事件流回应用。直播转写是另一回事：麦克风或通话音频还在进来，系统必须管理一场进行中的 Realtime 会话。产品界面上的「边转边出字」，并不自动等于麦克风开着还在进音。OpenAI 的 Whisper 到 GPT 迁移指南 明确建议：把直播音频和流式输出当成两件分开的决策。
若需要一份面向浏览器、把模型及其实务边界讲清楚的短说明，GPT Transcribe 模型概览 适合当作 API 文档的搭档。
/v1/audio/transcriptions 如何工作
对一份已完成的文件，接入故意保持简单。应用打开音频文件，按 multipart 表单发出，选定 gpt-transcribe，然后接收 JSON。
curl --request POST \
--url https://api.openai.com/v1/audio/transcriptions \
--header "Authorization: Bearer $OPENAI_API_KEY" \
--header "Content-Type: multipart/form-data" \
--form file=@/path/to/meeting.mp3 \
--form model=gpt-transcribe一次成功响应可以同时包含文本和检出语言：
{
"text": "Bonjour, can everyone see the AC-42 billing record?",
"languages": [{ "code": "fr" }, { "code": "en" }]
}语言检测是概率性元数据，不是调用方所给提示的强制回声。当模型做不出可靠预测时，空的 languages 数组是合法的；单凭这一点，并不表示音频是静音，也不表示请求失败。
OpenAI 的 语音转文字指南 目前把 Transcriptions API 的上传上限写成 25 MB，并概括支持 MP3、MP4、MPEG、MPGA、M4A、WAV 和 WebM。现行端点参考还列出了 FLAC 和 OGG。指南摘要和端点 schema 可能不同步演进，所以做校验时请查 Create transcription API 参考，不要把一份静态格式清单写成永久产品承诺。
上下文是这个模型最重要的控制面
真实录音里充满容易听错、但一旦错了代价很高的词：客户编号、药品名、型号、人名、组织名、缩写，以及夹杂多种语言的句子。客服账单、临床随访和产品评审尤其如此：听错一个型号，后面的质检和检索都会跟着错。GPT Transcribe 把上下文分成三种。
prompt：描述这段录音
prompt 是关于场景或主题的自由上下文。一条有用的 prompt 可以这样写：
A customer support call about enterprise billing and an account migration.
Preserve filler words because the transcript will be used for conversation research.这是在告诉模型，它正处在哪一个语言邻域。它也可以写明格式偏好，或把长录音前一段的上下文带过来。它不应塞进一段编造的转写，也不该让模型做摘要；转写和后处理是两件任务。需要纪要、章节或待办时，先保住逐字稿，再另开一层处理，并留下审计轨迹。
keywords：提供字面术语
keywords 是录音里真正可能出现的词或短语：
["AC-42", "Premium Plus", "ZyntriQix", "SOC 2"]它们是提示，不是必出内容。这个区别有运营意义。术语表可以提高召回，但一份不相关或过长的清单，会把识别偏向一个根本没人说过的词。OpenAI 建议专门评估关键词幻觉：只有音频撑得住时，转写里才应出现该 keyword。
languages：标明预期语言
languages 数组可以描述多语言音频和语码转换。现行文档接受 ISO 639-1 代码，例如 en、es 和 fr，部分 ISO 639-3 代码，以及中文地区代码如 zh-cn、zh-tw 和 zh-hk。
这既是功能，也是迁移细节。gpt-transcribe 使用复数字段 languages。更老的模型可能使用单数字段 language。不要两个都发、再指望服务器挑一个；现行说明是：API 会拒绝不兼容或格式错误的值。
把一份已完成的文件做成流式，不是直播转写
当音频文件已经完整、但界面应随着处理进度显示文字时，设置 stream=true。GPT Transcribe 会发出 transcript.text.delta 事件，并以 transcript.text.done 结束。
对一场很长的访谈，这能改善体感响应。用户在完整结果出来前就能看到前几段，而应用仍有一个明确的最终事件，用来保存、建索引或打开后续动作。界面可以先渲染 deltas，但不要在最终事件到达前就把部分文本当成已核准稿去分发。
它并不会把 /v1/audio/transcriptions 变成一只开着的麦克风。整份文件是随请求一起提交的。对仍在进行的音源，OpenAI 让开发者走 Realtime 转写，并建议用 gpt-live-transcribe 做持续低延迟工作。
还有一条进阶的中间路径：应用手动确认一个音频回合后，gpt-transcribe 可以跑在 Realtime WebSocket 转写会话里。当「一段有界话语之后的准确率」比连续字幕更重要时，这条路有用。应用追加音频、确认缓冲区，然后收到 deltas，再收到该回合的完成转写事件。
这给产品团队三种不同的交互方式：
- 阻塞式文件转写： 上传一段已完成的录音，等待最终 JSON。
- 流式文件结果： 上传一段已完成的录音，并渲染转写 deltas。
- Realtime 转写： 在持续连接上发送音频，可以跟直播模型连续走，也可以按手动确认的回合走。
把这些方式命名清楚，后面才不容易在架构上踩坑。
生产环境里的准确率到底指什么
语音转文字没有一个诚实的、放之四海皆准的准确率数字。词错误率会随语言、口音、麦克风距离、编码、噪声、重叠、词汇、说话人习惯，以及用来规范化标点和大小写的计分规则而变。干净英语旁白上的基准，预测不了一通经 8 kHz 电话信道录下的双语客服电话。
因此，GPT Transcribe 应被当成某个具体流程里的组件来评估，而不是排行榜标签。建一个小而有权限的评估集，代表用户真正会提交的音频：有噪声的、会换语言的、术语很密的，比干净旁白更能暴露问题。保留经人工核准的参考转写，并至少比较三种配置：
- 当前生产基线；
- 只把模型换成
gpt-transcribe； - 带上相关 prompt、keyword 和语言提示的
gpt-transcribe。
测量的不只是汇总词错误率：
| 评估维度 | 要核对什么 |
|---|---|
| 完整性 | 漏掉的句子、被截断的结尾，以及被跳过的低音量说话 |
| 关键实体 | 姓名、数字、邮箱、药品、SKU 和账户 ID 是否精确匹配 |
| 语言行为 | 文字系统是否正确、语码转换是否保留、输出是原文还是译文，以及检出的语言是否正确 |
| 稳健性 | 口音、背景音乐、混响、重叠说话人和电话音频 |
| 提示纪律 | 提供的 keywords 是否只在真正被说出时才出现 |
| 流式行为 | 到第一条 delta 的时间、到最终文本的时间、部分修订和事件顺序 |
| 运营韧性 | 空音频、损坏文件、重试、断线，以及重复提交怎么处理 |
不要在打分前，先用通用文本模型把评估转写「润色」一遍。后处理可能让文档更好读，同时悄悄改掉说话人的原话。先保留逐字层，再派生出带审计轨迹的清洁版或摘要层。对外给客户看的纪要，必须能回溯到那一层未经改写的转写，否则质检无法判断错误出在识别还是摘要。
GPT Transcribe 替代不了什么
最新默认值，并不自动就是每一种输出上都功能最全的模型。把「更准的文件转写」理解成「字幕、说话人和翻译也一并解决了」，后续剪辑和合规审查会反复返工。
说话人分离
如果产品必须回答「谁说了什么」，使用 gpt-4o-transcribe-diarize。它的 diarized_json 响应包含带说话人、起止元数据的片段。对长于 30 秒的录音，OpenAI 要求自动或已配置的切片策略。该模型也可以为有限数量的已知说话人接受短参考样本，但说话人标注在 Realtime 转写会话里不受支持。会议纪要如果要把发言记到人头上，应在文件转写路径上显式选择这条专用模型，而不是事后用通用聊天模型去猜。
逐词时间戳和字幕
GPT Transcribe 以 JSON 为主的输出，并不能直接替换 Whisper 的每一种响应格式。如果剪辑依赖词级时间戳、片段时间戳、SRT、VTT 或 verbose_json，请继续用 whisper-1，或另外搭建并验证一层对齐和字幕。不要把词均匀摊到文件时长上，去伪造时间码。
翻译
转写保留原始说话语言。翻译会换语言。OpenAI 把已完成录音译成英语的路径，仍然是 /v1/audio/translations 配 whisper-1。其他翻译流程里，把识别和翻译拆开，让每一段都能被审。先得到原始语言逐字稿，本地化或英语纪要才有可核对的底稿，也避免把误识别的术语再译错一层。
没有上限的输入长度
25 MB 上传上限不是时长承诺。一段压缩的单声道录音，能装进的分钟数远多于未压缩立体声 WAV。更大的输入请适当压缩，或按语义边界切开。从句子中间切断会丢掉声学和语言上下文；重叠切片若没有对齐策略，又可能把词复制一遍。
成本和吞吐
OpenAI 定价页 在本文复核时把 gpt-transcribe 标为 $0.0045 每分钟。这大约是一小时源音频 $0.27，尚未计入存储、网络、编排、重试、后处理和人工复核。
每分钟价格只是生产成本的一块。真正拉开账单的，往往是重试、切片、存储和人审，而不是模型那一行的标价。还要计入：
- 失败或重复的上传；
- 媒体规范化和切片；
- 源文件和已核准转写的存储；
- 术语管理；
- 高影响内容的质量复核；
- 下游摘要、检索或脱敏；
- 适用时的数据驻留或企业控制。
更便宜的模型如果把改正时间拉长，反而可能更贵。更准的模型如果流程要求原生字幕或连续直播字幕，仍可能是错的选择。拿流程总成本去对输出合同，而不只是看模型那一行。合同里写清交付物是逐字稿、可检索 JSON、对齐字幕还是说话人记录，报价和验收才不会各说各话。
隐私和负责任的处理
录音往往比普通文本更敏感：声音、身份线索、背景对话、地址、健康细节和机密会议。先取得有效的录制与处理权利，尽量少采集，保护源文件，并定下删除时间表。会议室里没发言的人、电话里报出的住址、以及背景里另一场谈话，都可能一起被写进转写。
OpenAI 现行 API 数据控制文档 写明：除非客户明确选择加入，API 数据不会用于训练模型。其端点表把 /v1/audio/transcriptions 列为不保留应用状态、不为滥用监测保留数据，并具备零数据留存（Zero Data Retention）资格。这些是平台层声明，不是完整的隐私方案。你的上传器、对象存储、日志、分析、支持工具和下游处理方，各有各的政策和留存行为。
对受监管或高风险工作，请与负责的法务和安全团队确认现行合同、地区、安全和人工复核要求。绝不要把自动转写当成唯一记录，去支撑一项会实质影响某人的决定。人事、医疗和信贷场景尤其要把人审写成强制步骤，而不是上线后再补。
一套能进生产的转写架构
可靠实现会把接入、转写、复核和派生内容分开：
- 授权并接入。 校验用户、录制权利、媒体类型、文件大小和恶意软件控制。
- 规范化媒体。 转换不支持的容器，必要时保留源副本，避免不必要的有损重编码。
- 附上有范围的上下文。 只选与本次任务相关的语言、keywords 和录音描述。
- 幂等转写。 给每个源一个稳定的任务 ID，避免重试制造重复计费或互相冲突的转写。
- 保存原始结果。 保留模型的精确响应、模型 ID、上下文字段、源校验和，以及处理日期。
- 复核关键字段。 把低置信或高影响的姓名、数字、承诺，以及医学或法律用语交给人看。
- 生成派生内容。 从已核准转写生成摘要、章节、字幕、检索索引、脱敏版本或待办事项。
- 执行留存。 按已文档化的政策删除或归档源音频和派生内容。
转写也可以是双向音频流程的前半段。转写改正之后，团队可以再改一版，并用 文字转语音 做成无障碍旁白、本地化草稿或已核准配音。把识别到的源和生成的输出明确标开：一个是「当时说了什么」的证据，另一个是新合成的媒体。课件和有声书最容易把这两层混在一个文件名里，后面一旦要撤回克隆声线或改正原话，就会找不到该改哪一份。
API 接入，还是浏览器工具
当转写是产品、自动化、数据流水线或可重复的内部流程的一部分时，用 API。它能控制鉴权、上下文、任务跟踪、下游存储和错误处理。需要幂等任务、术语表和审计字段时，浏览器试听替代不了这条接入。
不是每一次评估都要先做接入。浏览器流程适合先测几段有代表性的录音、搞清预期输出，或服务偶尔需要导出格式、而不是 SDK 代码的用户。GPT Transcribe 在线语音转文字工作区 提供一条能先上传再审的实务路径，团队再决定要不要自建界面。先用真实难例看召回和幻觉，再把同样的上下文策略写进 API 请求。
两条路径的评估标准应当一样：只用你有权处理的音频，对照人工参考，检查关键实体，并搞清是哪一个应用——而不只是哪一个底层模型——在生成时间戳、说话人标签、导出或存储。模型卡不会替你的产品承担字幕对齐或说话人档案的责任。
什么时候该选 GPT Transcribe？
在这些情况下选择 gpt-transcribe：
- 输入是已完成的录音，或一段有界、已确认的回合；
- 想要的输出是原始语言里的准确文本；
- 录音可能在预期语言之间切换；
- 领域词汇能从有范围的 keywords 里受益；
- 检出语言的元数据有用；
- 部分转写事件能改善文件处理界面。
在这些情况下选择专用替代：
- 音频持续到达，而且低延迟至关重要；
- 必须给说话人打标签；
- 词级时间戳或原生字幕文件是硬性要求；
- 输出必须是英语译文；
- 现有接入依赖一种
gpt-transcribe并不提供的响应格式。
正确选择取决于所需交付物。「一份转写」可能是纯文本、可检索的 JSON 对象、和视频对齐的字幕、法庭风格的说话人记录，或直播字幕。即便都以语音识别开头，它们也是不同产品。先把交付物写进需求，再选模型和端点，比先追最新模型名要省返工。
常见问题
GPT Transcribe 和 GPT-4o Transcribe 是一回事吗？
不是。gpt-transcribe 是当前另一个模型 ID，也是 OpenAI 为普通文件转写推荐的起点。现有的 gpt-4o-transcribe 接入可能仍能工作，但不要假设它们的请求字段、价格和输出行为一致。迁移时单独核对复数字段、流式事件和定价行，而不是只改模型名。
GPT Transcribe 能转写 MP3 或视频文件吗？
能。文件转写端点接受常见音频和媒体容器。请在 API 参考里核对现行输入清单和 25 MB 请求上限，尤其是在校验 FLAC、OGG 或视频容器时。视频文件往往先抽出音轨再传，既容易落在上限内，也避免把用不到的画面数据一并计费。
GPT Transcribe 能区分不同说话人吗？
它自己不能。需要带说话人标签的片段时，使用 gpt-4o-transcribe-diarize 并请求 diarized_json。
它能生成 SRT 或 VTT 字幕吗？
不能作为开箱即用的 GPT Transcribe 原生输出。OpenAI 目前把时间戳和原生 SRT/VTT 流程指向 whisper-1，你也可以另建一层经过单独测试的对齐。
GPT Transcribe 能处理直播麦克风音频吗？
对持续到达的音频，走 Realtime 转写流程，并从 gpt-live-transcribe 开始。GPT Transcribe 可用于 WebSocket 上手动确认的回合，这和连续不停的直播字幕不是一回事。
怎样提高姓名和技术术语的转写质量？
用 prompt 描述录音，用 keywords 提供预期的字面术语，并给出预期的 languages。测试这些提示是否提高了召回，同时没有插入从未被说出的术语。术语表只放这一场录音里真的可能出现的型号、药名和客户编号，宁可短，也不要一次倒进全公司词库。
GPT Transcribe 免费吗？
OpenAI API 按用量计费。复核当日，官方定价把 gpt-transcribe 标为每音频分钟 $0.0045。第三方界面可能自带试用、积分、上限或订阅。免费试用不等于 API 本身免费，上线前把计费账户和留存策略分开核对。
好用的默认值，不是万能答案
GPT Transcribe 给新的 OpenAI 语音转文字项目一个扎实默认值：一个模型覆盖高精度录音转写、多语言上下文、语言检测，以及文件结果的流式。它真正的优势，不是把所有旧路径都作废。它给开发者一条更清楚的通用路，把专用工作留给专用模型。会议纪要、播客检索和客服质检往往先需要这一条通用路；字幕时间轴、说话人档案和英语译文，再按交付物接专用模型。
先定义所需输出。然后用用户会提交的、最吵、最多语言、术语最密的录音去测 gpt-transcribe。一份能扛住这些案例的转写——带着可追溯的上下文、人工复核和诚实的边界——才配成为产品的一部分，而不只是一次好看的演示。默认值选对了，并不等于评估可以省略：把你的难例跑通，产品才能把语音转文字写成稳定能力，而不是一次发布会演示。