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 轉寫指南