GPT-Transcribe 與 GPT-Live-Transcribe：定價、API 差異與遷移

重點摘要

對已完成錄音使用 gpt-transcribe，費率為每音訊分鐘 $0.0045；對麥克風、通話或直播媒體串流使用 gpt-live-transcribe，費率為每分鐘 $0.017。OpenAI 在已發布的基準上報告，新的即時模型相較於 GPT-Realtime-Whisper 的轉寫錯誤更低，但選擇取決於文字需要出現的時間點、所需輸出欄位，以及兩種模型在你的生產音訊上的實測表現。

GPT-Transcribe 與 GPT-Live-Transcribe 一覽

若你只需要在音訊錄製完成後取得轉寫，請使用 gpt-transcribe。若你的應用需要在音訊仍持續輸入時即出現文字，請使用 gpt-live-transcribe。最大的差別不只是價格，還包括轉寫開始的時機與你的應用需要支援的 API 工作流程類型。

雖然 gpt-transcribe 能在處理已完成檔案或已提交的音訊輪次時回傳部分轉寫更新，但它並非持續的即時串流路徑。對於即時字幕、通話或麥克風輸入，gpt-live-transcribe 是更好的選擇。

若想更廣泛比較不同供應商，請參見 CometAPI 的《2026 年 6 款最佳語音轉文字 API》。

什麼是 GPT-Transcribe 與 GPT-Live-Transcribe？

OpenAI 在 2026 年 7 月 29 日推出 gpt-transcribe 與 gpt-live-transcribe。gpt-transcribe 處理已完成錄音、串流的檔案轉寫與已提交的 Realtime 輪次；gpt-live-transcribe 則在音訊從麥克風、通話或直播媒體串流到達時，回傳低延遲的轉寫更新。

這兩種模型提供一般檔案與即時轉寫的新預設路徑，但對於時間戳、翻譯、字幕與說話人分離等專門需求，仍需要使用 Whisper 與 GPT-4o 的特化轉寫工作流程。

何時值得為 GPT-Live-Transcribe 支付較高價格？

OpenAI 的 API 定價頁列出 gpt-transcribe 每分鐘 $0.0045，gpt-live-transcribe 每分鐘 $0.017。因此即時路徑每音訊分鐘約貴 3.8 倍。

上述轉寫成本僅採用 OpenAI 公開的基礎費率：音訊小時 × 60 × 每分鐘價格。不包含儲存、網路傳輸、重試、應用託管、後處理、人工作業修正與備援供應商成本。

當產品需求包含即時字幕、智能助理、審核或即時互動時，選擇 gpt-live-transcribe。當只在會議、通話、訪談或媒體上傳完成後才需要轉寫時，選擇 gpt-transcribe。雙路徑架構可用即時轉寫優化使用者體驗，再用檔案轉寫處理通話後流程或回填。

OpenAI 目前將 GPT-Realtime-Whisper 與 gpt-live-transcribe 列為相同的每分鐘 $0.017 基礎費率。評估在這兩種即時路徑間遷移時，應著重於可接受轉寫的品質、延遲、事件處理與營運相容性，而非僅憑標示價格。

GPT-Transcribe 與 GPT-Live-Transcribe 的 API 有何不同？

主要差異在於音訊進入系統的方式與轉寫事件開始的時間點。gpt-transcribe 接受已完成檔案或已提交的音訊輪次；gpt-live-transcribe 維持 Realtime 連線，並在音訊仍持續到達時發出轉寫更新。

已完成音訊使用 GPT-Transcribe

對已完成錄音，將檔案送至 /v1/audio/transcriptions。OpenAI 的檔案轉寫指南接受大小上限 25 MB，格式為 mp3、mp4、mpeg、mpga、m4a、wav 或 webm。

from openai import OpenAI

client = OpenAI()
with open("support-call.wav", "rb") as audio_file:
    transcript = client.audio.transcriptions.create(
        model="gpt-transcribe",
        file=audio_file,
        prompt="A support call about a premium plan and account AC-42.",
        extra_body={
            "keywords": ["premium plan", "AC-42", "billing"],
            "languages": ["en"],
        },
    )
print(transcript.text)

設定 stream=True 以在 OpenAI 處理已上傳錄音時接收轉寫差量事件。這能縮短看到文字的等待時間，但不會將檔案端點變成即時接收麥克風音訊的路徑。

到達中的音訊使用 GPT-Live-Transcribe

建立一個 type: "transcription" 的 Realtime 工作階段，並選擇 gpt-live-transcribe。伺服器端媒體管線使用 WebSocket，瀏覽器音訊使用 WebRTC。

{
  "type": "session.update",
  "session": {
    "type": "transcription",
    "audio": {
      "input": {
        "format": {
          "type": "audio/pcm",
          "rate": 24000
        },
        "transcription": {
          "model": "gpt-live-transcribe",
          "prompt": "A support call about a premium plan and account AC-42.",
          "keywords": ["premium plan", "AC-42", "billing"],
          "languages": ["en"],
          "delay": "low"
        },
        "turn_detection": null
      }
    }
  }
}

使用 input_audio_buffer.append 附加音訊區塊。應用程式可透過 input_audio_buffer.commit 提交輪次，或設定伺服器端語音活動偵測。

Realtime 轉寫指南會透過 conversation.item.input_audio_transcription.delta 回傳增量文字，並在提交的項目完成後以 conversation.item.input_audio_transcription.completed 結束。不同輪次的完成事件不保證按照到達順序，因此請以 item_id 而非到達順序進行對齊。

當不需要立即顯示文字時，使用已提交輪次路徑

gpt-transcribe 也可在 WebSocket 的 Realtime 轉寫工作階段中運行。轉寫會在提交一個音訊輪次之後開始，模型可使用較早輪次的轉寫作為上下文，且完成事件可包含偵測到的語言。

當基於輪次的串流或語言偵測比說話期間即時顯示文字更重要時，這種已提交輪次的路徑會很有用。它不應與 gpt-live-transcribe 的持續、較低延遲行為混淆。

Prompts、Keywords、Languages 與 Delay 如何影響轉寫？

兩種模型皆可接受能改善人名、數字、縮寫、產品術語、口音、多語音訊與語碼轉換識別的上下文。

對於新模型，languages 取代舊的單一 language 欄位。請勿同時傳送兩者。每個 keyword 必須是一行文字，且不能包含 <、>、CR 或 LF；無效值會導致請求或工作階段更新被拒絕。

gpt-live-transcribe 支援 minimal、low、medium、high、xhigh 的 delay 設定。較低的設定偏好更早的部分文字，較高的設定會提供更多音訊上下文並可能提升轉寫品質。OpenAI 並未保證每個等級對應固定延遲，因此請在代表性的麥克風、編解碼器、網路、語言與工作階段長度上量測首個增量與最終轉寫的時間。

OpenAI 的準確度基準顯示了什麼？

OpenAI 的發佈公告指出，gpt-live-transcribe 在兩項多語轉寫測試中優於 GPT-Realtime-Whisper-1。亦指出在 Context Aware ASR 評估中，自由形式的上下文可提升語意準確度。

審慎的結論是：新的即時模型在 OpenAI 報告的測試中表現較佳，且上下文提高了所報告的語意準確度。這些供應商回報的結果並不保證對所有語言、電信編解碼器、麥克風、delay 設定、領域詞彙或校正策略均有相同提升。

何時應改用 Whisper 或 GPT-4o Transcribe？

這兩個新模型並非取代所有語音轉文字工作流程。

對於分離說話人，OpenAI 需要使用檔案 Transcriptions API；Realtime 轉寫工作階段不支援說話人標籤。對於長於 30 秒的錄音，請將 chunking_strategy 設為 "auto" 或使用語音活動偵測設定。

若需時間戳、字幕、翻譯或沿用現有 Whisper 工作流程，請參考 CometAPI 的 Whisper API 指南與 Whisper-1 模型頁面。評估另一個 OpenAI 檔案轉寫路徑的團隊也可參考 GPT-4o Transcribe 模型頁。

應如何從 Whisper 遷移？

更換模型 ID 只是第一步。在切換生產流量前，請驗證整個工作流程。

針對 GPT-Realtime-Whisper 的遷移，請保持音訊格式、輪次偵測策略、測試集與延遲目標不變。由於公布的即時價格未變，請優先關注可接受轉寫率、延遲分佈、輸出穩定性與與其餘管線的相容性。

遷移指南（從 Whisper／既有模型）

OpenAI 提供官方範例手冊：從 Whisper 遷移至 GPT-Transcribe 與 GPT-Live-Transcribe。

高階規則：

1. 已錄製／批次音訊 → 在現有的 /v1/audio/transcriptions 端點切換至 gpt-transcribe。
2. 持續即時音訊 → 在 Realtime 轉寫工作階段切換至 gpt-live-transcribe。
3. 在已提交輪次後追求更高準確度 → 在 Realtime 工作階段內使用 gpt-transcribe。

最小檔案遷移範例（Python）：

Python

# Before (Whisper)with open("meeting.wav", "rb") as audio:    result = client.audio.transcriptions.create(        model="whisper-1",        file=audio,        language="en",        prompt="Support call about AC-42"    )# After (GPT-Transcribe)with open("meeting.wav", "rb") as audio:    result = client.audio.transcriptions.create(        model="gpt-transcribe",        file=audio,        prompt="A customer support call about billing",        extra_body={            "keywords": ["AC-42", "Premium Plus"],            "languages": ["en", "fr"]        },        response_format="json"  # or stream=True for deltas    )

即時遷移注意事項：

• 保持相同的 Realtime 工作階段／WebSocket 架構。
• 更換模型 ID，並以 languages 陣列取代單一 language。
• 可選擇加入 prompt、keywords 與 delay（例如 "low"）。
• 持續處理相同的差量／完成事件。
• 勿同時傳送 language 與 languages。

遷移重要注意事項：

• GPT-Transcribe／GPT-Live-Transcribe 不以與 whisper-1 相同的方式支援字詞級時間戳、SRT／VTT 或英譯。對於這些特定需求請保留 Whisper。
• 回應格式不同——勿假設 text、verbose_json、srt 或 vtt 的行為完全一致。
• keywords 必須是單行常值（不可含 <、>、CR 或 LF），否則請求會被拒絕。
• 請在具代表性的生產音訊上測試（口音、雜訊、領域術語、短語句），而非僅依賴公布的 WER。

快速建議

• 新專案預設：檔案／批次用 GPT-Transcribe，即時串流用 GPT-Live-Transcribe。
• 現有的 Whisper 或 GPT-4o-Transcribe 整合仍可運作，但不再是起步首選。
• 成本敏感的批次作業改用 GPT-Transcribe 收益最大（$0.0045 對 $0.006）。

最新詳情請查閱官方模型頁與 OpenAI 開發者網站上的轉寫總覽指南。

應如何在生產音訊上評估兩種模型？

請使用具授權且能代表產品實況的音訊，而非僅使用乾淨的示範片段。

1. 至少選取 50 段涵蓋主要用例、語言、裝置與音訊條件的錄音。
2. 納入口音、打斷、背景噪音、語碼轉換、數字、日期、貨幣、電子郵件與領域詞彙。
3. 以 gpt-transcribe 對已完成錄音進行測試（含上下文與不含上下文）。
4. 以三種 delay 設定在 gpt-live-transcribe 上重播相同的即時樣本。
5. 在不同輪次間保持格式、輪次邊界、prompts 與評分規則一致。
6. 量測轉寫錯誤、領域術語召回、部分文字修訂、p50 與 p95 延遲、失敗、重試與人工作業修正時間。
7. 計算每份可接受轉寫的成本，並在全面遷移前對選定路由策略進行金絲雀測試。

最終設計可只用其中一種模型，或兩者並用。決策指標應是可接受的生產轉寫的成本與可靠度，而非孤立的每分鐘標示價格。

常見問題

我應該使用哪個模型：GPT-Transcribe 或 GPT-Live-Transcribe？

對已完成錄音與非同步任務使用 gpt-transcribe。當文字必須在音訊仍在串流時到達，請使用 gpt-live-transcribe。

GPT-Transcribe 與 GPT-Live-Transcribe 的費用是多少？

OpenAI 列出 gpt-transcribe 每音訊分鐘 $0.0045（每小時 $0.27），gpt-live-transcribe 每分鐘 $0.017（每小時 $1.02）。

GPT-Live-Transcribe 是否比 GPT-Realtime-Whisper 更準確？

在 OpenAI 的九語 Real-World Audio Recording 基準上，回報的轉寫錯誤率由 11.65% 下降至 9.60%。請在你的音訊上驗證此基準特定的結果。

GPT-Live-Transcribe 是否支援分離說話人或字詞時間戳？

否。不回傳說話人標籤、字詞級時間戳或信心分數。當需要這些欄位時，請使用相容的檔案模型或備援步驟。

從 GPT-Realtime-Whisper 遷移是否只需更換模型 ID？

否。在移轉生產流量前，請驗證工作階段設定、語言欄位、上下文輸入、delay 設定、事件排序、功能相依、延遲與輸出品質。

使用 CometAPI 測試轉寫路徑

在實作前，請於 CometAPI 定價頁確認最新的模型可用性與路徑價格，並使用 CometAPI 文件參考相容 OpenAI 的請求樣式。在測試中鎖定精確的模型 ID，並記錄音訊時長、delay 等級、首個增量延遲、最終轉寫延遲、重試次數與可接受轉寫率，讓路由決策反映完整工作流程成本。