GPT Realtime API 定價：說話成本是聆聽的 4 倍（實測）

透過 OpenAI Realtime API 進行語音對話時，使用者說話的成本是每分鐘 $0.0192，模型回話則是每分鐘 $0.0768。說話成本正好是聆聽的四倍，光是這個比例，就能解釋語音 session 帳單中的大部分費用。先釐清名稱：「GPT Live」是 ChatGPT 面向一般使用者的功能，並沒有 API。背後的 API 產品是 gpt-realtime-2.1 與 gpt-realtime-2.1-mini，也是本文實測的對象。

TL;DR

• gpt-realtime-2.1 對使用者語音的計費正好是每 100 ms 1 個 audio token，模型語音則是每 50 ms 1 個：聆聽每分鐘 $0.0192，說話每分鐘 $0.0768。
• 啟用伺服器端 VAD 時，60 秒靜音的 input token 計費為零。
• 到第 30 輪時，自動快取已涵蓋 93% 的輸入；刪除一筆歷史項目後，該輪按原價計費的輸入增加至三倍。
• 一段很長的語音回答，在開始 2 秒後取消，仍會計費 4 秒的音訊。
• gpt-realtime-2.1-mini 的計費機制完全相同，音訊價格低 3.2 倍。

本文所有數據都來自 2026-07-19 對兩個模型執行的 WebSocket 儀表化 session，並記錄了伺服器送出的每個事件。兩個模型都已上線至 Synthorai 閘道的 /v1/realtime endpoint，這些測試也都在該處執行；通訊協定與計費方式和直接呼叫 OpenAI 相同。測試工具是單一 Python 檔案，只使用標準函式庫。下文每一項數據都可追溯至原始的 response.done usage 記錄。

如何連線至 Realtime API？

Realtime 和文字 API 不同，不是透過 HTTP 進行 request/response。每個 session 都要開啟一條 WebSocket 連線，並透過它交換 JSON 事件：client 將麥克風音訊以串流送入，伺服器再以串流回傳模型語音，整段對話都走同一條連線。

import websocket, json

ws = websocket.create_connection(
    "wss://synthorai.io/v1/realtime?model=gpt-realtime-2.1",
    header=["Authorization: Bearer sk-..."])

ws.send(json.dumps({"type": "session.update", "session": {
    "type": "realtime", "output_modalities": ["audio"],
    "audio": {"input": {"format": {"type": "audio/pcm", "rate": 24000}}}}}))

# stream mic audio as base64 chunks: {"type": "input_audio_buffer.append", ...}
# then either let server VAD end the turn, or commit and ask for an answer:
ws.send(json.dumps({"type": "response.create"}))
# read events until "response.done": billing usage rides on that event

與計費相關的 session 生命週期如下：session.update 設定 instructions、voice、tools 與 turn detection，並形成可快取的 prefix；input_audio_buffer.append／commit 加入使用者音訊；response.create 觸發回覆；每個 response.done 則包含該次回覆的完整 usage 明細。另需注意 API 版本差異：GA API 使用 output_modalities，以及巢狀的 audio.input／audio.output 設定；beta 時期的 response.modalities 欄位會被拒絕，並回傳 unknown_parameter。

GPT Realtime 每分鐘要多少錢？

官方換算比例精確到單一 token：一段 30.0 秒的音訊會計入 300 個 input audio token，也就是每 100 ms 1 個；一段 4.5 秒的模型語音會計入 90 個 output audio token，也就是每 50 ms 1 個。依照每 token 價格換算後，每分鐘成本如下：

表格之外還有兩項成本。第一，語音回答同時也會計入文字輸出，包括逐字稿與 reasoning token（gpt-realtime-2.1 確實會進行推理；每次測試的 output_token_details.reasoning_tokens 都不是零）。在我們的短回答測試中，這部分以 $24/M 的文字費率計價，額外增加約 24% 的音訊 token 成本。

第二，文字轉錄附加功能有獨立的計費類別。其 usage 記錄是 {"type": "duration", "seconds": 30}：按時長以每分鐘 $0.017 計費，與 token 無關，而且逐字稿不會進入模型輸入。只要開啟這個選項，2.1 的輸入端成本大約會翻倍，mini 則接近四倍。因此，只有在法遵或產品需求確實需要文字時才應啟用。

靜音、中斷或工具呼叫會產生成本嗎？

靜音不收費。我們在啟用伺服器端 VAD 的 session 中串流傳送 60 秒靜音，之後再提出問題；usage 與完全未傳送音訊的對照 session 逐 byte 相同。VAD 只會提交判定為語音的音訊，因此保留音樂、客戶閱讀表單的時間，或閒置但未掛斷的通話，都不會產生 input token。限制是實際環境中的背景噪音可能誤觸 VAD；純靜音是成本下限，不代表嘈雜通話也一定免費。

中斷會按模型已生成的位置計費，而不是按使用者實際聽到的位置，也不會收取尚未生成部分的費用。我們要求模型緩慢數到四十，使用者聽到 2.0 秒後便取消；帳單計入 81 個 audio token，也就是 4.0 秒。多出的 2 秒，是 response.cancel 抵達前，生成進度超前播放的位置。mini 在同一項實驗中計入 6.3 秒，因為較小的模型生成速度更快，會更大幅度超前即時播放。實務原則很簡單：client 一偵測到使用者插話，就立刻送出 response.cancel，因為計費會持續到取消事件抵達為止。

工具呼叫本身不影響計費。一個定義了單一 function 的 session 發出呼叫並接收注入結果後，下一個 response 有 99% 的輸入按快取費率計價。Function-call item 與其輸出和其他新增的歷史內容一樣可以快取；tool definition 本身則位於靜態 prefix，從第 2 輪起即可命中快取。

快取如何降低長時間 session 的成本？

Realtime API 每次產生 response 時，都會重新讀取整段對話作為輸入，因此每輪輸入會隨 session 長度呈線性成長。控制成本的關鍵是自動 prefix caching：快取音訊的重播價格是 $0.40/M，而不是 $32/M，只有原價的 1/80。在我們的 30 輪 session 中，快取占比持續上升，到第 30 輪時已達輸入的 93%：

每個 response.done 都會回報快取拆分明細：

"usage": {
  "input_tokens": 891,
  "input_token_details": {
    "text_tokens": 891, "audio_tokens": 0,
    "cached_tokens": 832,
    "cached_tokens_details": { "text_tokens": 832, "audio_tokens": 0 }
  }
}

官方文件沒有說明但我們實測出的規格有三項：prefix 約達 128 個 token 時就會啟用快取（文字 API 文件列出的最低值是 1,024）、快取以 64 個 token 為單位向前推進，而且同一把 key 下的不同 session 可以共用靜態 prefix。最後一點對 60 分鐘 session 上限尤其重要：新 session 的第一輪，instructions 就已按快取費率計價。因此，輪替 session 時只有重新讀取對話歷史需要支付一次原價，system prompt 不需要。

編輯歷史是唯一會失去折扣的方式，我們也實測了具體代價。在 session 中途刪除一筆較早的 item，快取占比只在一輪內驟降，下一輪就重新建立：

另一項有利的實測結果是：模型自己的語音回答在後續輸入中會以文字重新進入，而不是音訊。在一段 8 輪語音對話中，input audio 每輪增加的量正好等於使用者音訊片段的大小；assistant 端則以逐字稿 token 重新進入，費率為 $4/M。隨對話累積而增加的昂貴部分，只有使用者音訊。

實務做法可以濃縮成幾點：歷史內容只新增、不修改；整個 session 期間以及跨 session 都維持 instructions 與 tool definition 的 byte 完全一致；動態內容放進最新的 user message，不要放在 prefix；必須裁切時，降低頻率並一次裁掉較大區段，不要每輪都裁。若要了解跨供應商的通用機制，可參考我們的 prompt 快取指南與實測快取最低門檻研究。

gpt-realtime-2.1 與 mini：該選哪一個？

兩個模型的計費機制完全相同：換算比例相同、快取都以 64 個 token 量化，曲線形狀也一致。差異在於價格與行為：

有兩點需要留意。在快取重播這一類別中，價格差距幾乎消失（$0.40 對 $0.30）。因此，快取命中率很高的長 session 會略微縮小 mini 的優勢，但新 token 仍占總成本的大部分。mini 的速度也會在中斷時形成反效果：它的生成進度更大幅度超前播放，所以每次使用者插話，都會浪費約兩倍的已生成音訊。即使如此，在所有實測情境中，mini 的美元成本仍然較低；3.2 倍的價格差足以吸收這兩項影響。

短指令助理、IVR 與高併發客服預設選 mini。若 session 需要複雜的工具編排或多步推理，則選擇 2.1；OpenAI 將其定位為 instruction following 的旗艦模型，而我們的成本測試工具刻意不評估這項能力。

常見語音情境實際要花多少錢？

對於經常發生中斷的情境，每次互動的成本計算還要加上插話超前量：每次中斷都會計入使用者已聽到的音訊，以及額外幾秒的生成超前部分。

常見問題

GPT Live 和 GPT Realtime API 是同一個產品嗎？

不是。GPT Live 是 ChatGPT 應用程式內的語音功能，沒有自己的 API 或定價頁面。開發者若要透過程式提供類似體驗，需使用 Realtime API 模型 gpt-realtime-2.1 與 gpt-realtime-2.1-mini，本文實測的也是這兩個模型的價格。

Realtime session 最長可以維持多久？

硬性上限是 60 分鐘，而且 session 關閉後無法恢復。文字歷史可以重新注入新的 session，並按原價計費一次，靜態 prompt 則維持快取；但 assistant 音訊無法重播。因此，長時間運作的語音產品必須在第 60 分鐘前規劃好輪替機制。

輪次之間有閒置逾時嗎？

文件沒有列出閒置逾時，而且根據我們的實測，啟用伺服器端 VAD 時，靜音的 token 計費為零。因此，在互動之間維持連線，除了連線本身外不會產生成本。對使用頻率較低的產品而言，維持一個長 session 會比每次互動都重新連線更便宜也更快，因為 session 建立時間實測約為 2.5 秒。

API 預期使用什麼音訊格式？

輸入與輸出的預設格式都是 24 kHz 單聲道 PCM16，可在 session.update 內透過 audio.input.format 與 audio.output.format 設定。計費不受格式影響：audio token 只取決於時長，輸入每 100 ms 1 個 token，輸出每 50 ms 1 個。

如何處理 60 分鐘的硬性上限，包括 session 輪替、歷史交接，以及重新連線後哪些內容仍可保留，是另一個獨立主題。本文數據則是計算這些方案成本時的輸入。若要了解文字 API 中不同模型家族的計費 token 如何拆分，可參考延伸文章：token usage 結構解析。

← 返回部落格