GPT Transcribe 与 GPT Live Transcribe 教程：文件和实时语音转写

OpenAI 于 2026 年 7 月 28 日正式发布两款语音转写模型：gpt-transcribe 和 gpt-live-transcribe。两者都是 Audio API 与 Realtime 转写体系的一部分，但解决的问题不同。

• gpt-transcribe：处理完成的音频文件，或转写 Realtime 中已经提交的完整语音片段。
• gpt-live-transcribe：持续接收现场音频，并尽快返回增量文字。

它们都支持自由格式上下文、关键词提示和多个预期输入语言，适合会议记录、客服通话、直播字幕、语音检索和多语言录音整理。

先按音频到达方式选模型

最容易混淆的是“流式”一词。已经录好的文件也能在处理过程中流式返回部分文本，但音频本身已经完整存在，不需要建立 Realtime 会话。只有音频仍在从麦克风、电话或媒体流不断到达时，才需要 gpt-live-transcribe 和持久实时连接。

两个模型的能力差异

如果业务必须拿到单词时间戳、SRT 或 VTT，官方转写指南仍建议使用 whisper-1。需要说话人标签时，应使用文件转写模型 gpt-4o-transcribe-diarize，而不是要求这两个模型猜测发言人。

准备 SDK 与 API Key

安装或更新 Python SDK：

1

pip install -U openai

设置 API Key：

1

$env:OPENAI_API_KEY = "你的_API_Key"

不要把 API Key 写进脚本、前端代码或 Git 仓库。浏览器通过 WebRTC 使用 Realtime API 时，应由后端创建短期客户端凭据，而不是把长期服务端密钥发给浏览器。

用 GPT Transcribe 转写音频文件

文件转写调用 /v1/audio/transcriptions。下面是官方 Python SDK 的基本写法：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

from openai import OpenAI

client = OpenAI()

with open("meeting.wav", "rb") as audio_file:
    transcription = client.audio.transcriptions.create(
        model="gpt-transcribe",
        file=audio_file,
    )

print(transcription.text)

对应的 cURL 请求如下：

1
2
3
4
5

curl https://api.openai.com/v1/audio/transcriptions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: multipart/form-data" \
  -F model="gpt-transcribe" \
  -F file="@/path/to/file/meeting.wav"

文件转写指南列出的常用格式包括：

• mp3
• mp4
• mpeg
• mpga
• m4a
• wav
• webm

单个文件上限为 25 MB。更大的录音要先压缩或切分，每段保持在 25 MB 以内。切分时尽量选择停顿或句子边界，不要在一个人名、编号或完整句子中间截断，否则相邻片段会丢失语义上下文。

用上下文提高专业词识别率

两个新模型都接受三类转写上下文：

• prompt：描述录音主题、场景或背景。
• keywords：可能在音频中出现的产品名、缩写和专有词。
• languages：预期出现的一个或多个输入语言。

文件转写示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

from openai import OpenAI

client = OpenAI()

with open("support-call.wav", "rb") as audio_file:
    transcription = client.audio.transcriptions.create(
        model="gpt-transcribe",
        file=audio_file,
        prompt="一段关于高级套餐和账户 AC-42 的客户支持通话。",
        extra_body={
            "keywords": ["高级套餐", "AC-42", "账单"],
            "languages": ["zh-cn", "en"],
        },
    )

print(transcription.text)

prompt 应提供与录音相关的信息，不需要重复“请把音频转成文字”这类任务说明。keywords 只是提示，不是模型必须输出的词表。如果音频里没有某个关键词，转写结果也不应该凭空加入它。关键词过多或与内容无关，可能诱发未说出口的词出现在结果里。上线前应比较有无关键词时的真实错误率。

languages 与旧 language 参数不同

gpt-transcribe 和 gpt-live-transcribe使用复数参数 languages，不要同时发送旧的单数 language。官方支持的语言代码形式包括：

• ISO 639-1，例如 en、es、fr。
• 部分 ISO 639-3，例如 eng、spa、yue、cmn。
• 中文区域代码，例如 zh-cn、zh-tw、zh-hk。

不受支持或格式错误的语言代码会被 API 拒绝。多语言通话可以提供多个候选语言，但不要把完全不相关的语言全部塞进请求。关键词必须保持一行一个值，不能包含 <、>、回车或换行字符。遇到这些字符时，文件请求或 Realtime 会话更新会被整体拒绝。

创建 GPT Live Transcribe 会话

实时转写会话的类型是 transcription。服务端音频管道通常使用 WebSocket，浏览器麦克风场景通常使用 WebRTC。下面的 session.update 使用 24 kHz PCM 音频，并关闭自动语音轮次检测：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

{
  "type": "session.update",
  "session": {
    "type": "transcription",
    "audio": {
      "input": {
        "format": {
          "type": "audio/pcm",
          "rate": 24000
        },
        "transcription": {
          "model": "gpt-live-transcribe",
          "prompt": "一场包含中英文产品名称的技术支持通话。",
          "keywords": ["OpenAI", "Realtime API", "AC-42"],
          "languages": ["zh-cn", "en"],
          "delay": "low"
        },
        "turn_detection": null
      }
    }
  }
}

关闭自动轮次检测后，应用需要自己决定什么时候结束一个语音片段。音频数据用 Base64 编码后追加：

1
2
3
4
5
6

ws.send(
  JSON.stringify({
    type: "input_audio_buffer.append",
    audio: base64Pcm16,
  })
);

片段结束时显式提交：

1
2
3
4
5

ws.send(
  JSON.stringify({
    type: "input_audio_buffer.commit",
  })
);

也可以配置服务端 VAD，让系统检测说话开始与结束并自动提交轮次。

处理增量文本和最终结果

gpt-live-transcribe 会先发送增量事件，再发送该语音轮次的完整结果。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

ws.on("message", (data) => {
  const event = JSON.parse(data);

  if (event.type === "conversation.item.input_audio_transcription.delta") {
    process.stdout.write(event.delta);
  }

  if (event.type === "conversation.item.input_audio_transcription.completed") {
    console.log("\nFinal transcript:", event.transcript);
  }
});

界面不能把每个 delta 都当成永久文本。后续增量或最终结果可能修正先前内容，应设计可更新的字幕缓冲区。

不同语音轮次的完成事件不保证按提交顺序到达。必须使用 item_id 将 delta、最终文本和原始音频片段关联，不能只依赖 WebSocket 消息到达时间排序。

调整实时转写延迟

gpt-live-transcribe 允许用 delay 调整延迟与准确率：

档位不对应固定毫秒数。实际延迟会随模型配置、音频和网络变化，不能把某个测试结果写死成服务承诺。

更低延迟会更早展示部分文本，更高延迟让模型在输出前听到更多上下文，通常有利于降低词错误率。

提交后再转写的 Realtime 模式

如果应用已经使用 Realtime WebSocket，但不需要边说边显示文字，可以在会话中选择 gpt-transcribe。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

{
  "type": "session.update",
  "session": {
    "type": "transcription",
    "audio": {
      "input": {
        "format": {
          "type": "audio/pcm",
          "rate": 24000
        },
        "transcription": {
          "model": "gpt-transcribe"
        },
        "turn_detection": null
      }
    }
  }
}

应用先追加音频，再发送 input_audio_buffer.commit。模型可在最终完成事件前发出文本增量，完成事件还会包含检测到的语言。

如果无法可靠判断语言，languages 会是空数组。gpt-live-transcribe 不提供这项检测语言结果。

在专用转写会话或 Realtime 输入转写中，gpt-transcribe 会自动把之前已经转写的轮次作为上下文，有利于保持连续对话中的术语一致性。

生产环境怎么测试

不要只拿安静房间里的标准普通话样本验收。测试集应覆盖真实使用条件：

• 目标语言、口音和中途切换语言的情况。
• 电话窄带音频、不同麦克风和背景噪声。
• 人名、日期、金额、邮箱、订单号与字母数字串。
• 产品名、药品名、缩写和行业术语。
• 极短回答、长录音、抢话和中断。
• 网络抖动、连接重建与重复提交。

除了整体词错误率，还要统计对业务真正重要的错误。客服系统应单独评估订单号和账户号，医疗场景应单独评估药品名和剂量。

实时界面还应记录：

• 首个 delta 到达延迟。
• 最终结果完成延迟。
• 空转写、截断和长时间无结果。
• delta 被最终文本修正的比例。
• 不同 delay 档位下的准确率差异。

常见问题

文件转写的 stream 等于 Realtime 吗？

不等于。文件可以在处理期间流式返回文字，但输入音频已经完整上传；Realtime 用于仍在持续到达的现场音频。

两个模型能生成字幕时间轴吗？

它们不提供单词级时间戳。需要单词或分段时间戳、SRT、VTT 时，应根据官方指南选择 whisper-1。

GPT Live Transcribe 能区分说话人吗？

不能返回说话人标签。需要说话人分离时，应使用兼容的文件转写模型或应用级后处理方案。

keywords 越多越好吗？

不是。关键词只是识别提示，无关词过多可能增加未说词语被写入结果的风险。

多语言录音应该使用 language 还是 languages？

这两个新模型使用 languages。不要同时发送 language 和 languages。

总结

gpt-transcribe 适合已经完成的文件、有限音频请求，以及 Realtime 中提交后再处理的完整语音轮次。

gpt-live-transcribe 适合麦克风、电话和直播音频，能持续返回低延迟文本增量，并通过 delay 调节速度与准确率。

无论选择哪一个，都应把 prompt、keywords 和 languages当成需要通过真实音频评测的提示，而不是保证特定文字一定出现的硬约束。

官方资料

• OpenAI API 发布日志
• GPT Transcribe 模型文档
• GPT Live Transcribe 模型文档
• 转写工作流总览
• 文件转写指南
• Realtime 转写指南