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

在 OpenAI 的 Realtime API 上進行一場語音對話，使用者說話時每分鐘要 $0.0192，模型回話時每分鐘要 $0.0768。說話剛好是聆聽的四倍，光是這個比例就能解釋一場語音工作階段大部分的帳單。開始講數字前先釐清一個命名：「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。
• 在 server VAD 下靜音 60 秒，計費的 input token 為零。
• 到第 30 輪時，自動快取涵蓋了 93% 的 input；刪掉一筆歷史紀錄，會讓那一輪的全價 input 變成三倍。
• 一段長回答說到第 2 秒時取消，計費為 4 秒的音訊。
• gpt-realtime-2.1-mini 的計費機制完全相同，但音訊價格低 3.2 倍。

這裡的每個數字都來自 2026-07-19 針對兩個模型跑的 WebSocket 工作階段實測，並記錄了每一個 server 事件。兩個模型都跑在 Synthorai 閘道的 /v1/realtime 端點上，這些工作階段就是在那裡執行的；協定和計費跟直接連 OpenAI 完全一樣。測試工具是單一一個只用 stdlib 的 Python 檔案，下面每個數字都能回溯到原始的 response.done usage 紀錄。

如何連上 Realtime API？

跟文字 API 不同，Realtime 不是 HTTP 上的 request/response。每個工作階段開一條 WebSocket，透過它來回交換 JSON 事件：用戶端把麥克風音訊串流進去，伺服器把語音音訊串流回來，整場對話都在同一條連線上。

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.update 設定 instructions、語音、工具和輪次偵測（這會成為可快取的前綴）；input_audio_buffer.append / commit 加入使用者音訊；response.create 觸發一次回覆；每個 response.done 都帶著那次回應完整的 usage 明細。順帶提一個方言差異：GA 版 API 用的是 output_modalities 和巢狀的 audio.input/audio.output 設定；beta 時期的 response.modalities 欄位會被拒絕並回傳 unknown_parameter。

GPT Realtime 每分鐘要花多少錢？

官方換算率精準到每一個 token：一段 30.0 秒的音訊會計入 300 個輸入音訊 token（每 100 ms 算 1 個），一段 4.5 秒的語音回覆會計入 90 個輸出音訊 token（每 50 ms 算 1 個）。把每 token 的價目表換算成每分鐘，結果如下：

有兩筆費用藏在表格之外。第一，語音回覆也會計入文字輸出：轉錄稿加上 reasoning token（gpt-realtime-2.1 確實會推理，每次執行 output_token_details.reasoning_tokens 回傳的值都不是零）。在我們那段簡短的測試回覆裡，這部分在音訊 token 之上又多加了約 24%，以 $24/M 的文字費率計費。

第二，轉錄附加功能自成一條計費項目。它的用量紀錄寫的是 {"type": "duration", "seconds": 30}：按時長以每分鐘 $0.017 計費，與 token 無關，而且轉錄稿不會進入模型的輸入。打開這一個開關，會讓 2.1 的輸入端成本大約翻倍，mini 則接近四倍，所以只有在合規或產品需求真的需要文字時才開啟。

靜音、打斷、工具呼叫要花錢嗎？

靜音不花錢。我們在啟用 server VAD 的 session 裡串流了 60 秒的靜音，接著提問：用量與一個從未送出音訊的對照 session 一模一樣。VAD 只會提交它偵測為語音的音訊，所以等候音樂、客戶讀表單、或一條閒置未掛斷的線路，輸入 token 都是零。要注意的是，真實的背景雜訊可能觸發 VAD；純靜音是下限，但在吵雜的通話裡並不保證如此。

打斷是計費到生成的前緣，而非使用者耳朵聽到的位置，且不會為尚未生成的剩餘部分計費。我們請模型慢慢用語音數到四十，聽到 2.0 秒後取消：帳單是 81 個音訊 token，也就是 4.0 秒。那 2 秒的超出量，是在 response.cancel 送達之前，生成領先播放的距離。在 mini 上做同樣的實驗，計費是 6.3 秒，因為較小的模型生成得比即時進度更超前。實務規則是：一偵測到用戶插話（barge-in），就立刻送出 response.cancel，因為計費會一直跑到取消送達為止。

工具呼叫在計費上是中性的。一個帶有單一 function 定義的 session 發出了呼叫、取回注入的結果，緊接著的下一個回應顯示，它 99% 的輸入都以快取費率計費。Function-call 項目與其輸出會像其他附加的歷史紀錄一樣被快取，而工具定義本身位於靜態前綴中，從第 2 輪起就會被快取。

快取如何讓長對話維持在可負擔的成本？

Realtime API 每產生一次回應，都會把整段對話重新讀進來當作輸入，所以每一輪的輸入量會隨著對話長度線性成長。真正把成本壓下來的是自動 prefix caching：快取音訊以 $0.40/M 重播，而不是 $32/M，只有全價的 1/80。在我們 30 輪的對話裡，快取占比穩定攀升，到第 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 為一個區塊往前推進，而且靜態 prefix 可以在同一把 key 的不同 session 間重複使用。最後這點對 60 分鐘的 session 上限很關鍵：新 session 的第一輪，instructions 就已經按快取價計費，所以輪替只需為重新讀取對話歷史付全價，system prompt 不用。

唯一會讓折扣失效的做法就是編輯歷史，我們也量出了確切的代價。在對話中途刪掉一個早期項目，會讓快取占比崩掉整整一輪，之後快取又會重建：

還有一項實測到的好處：模型自己講出來的回答，會以文字而非音訊的形式重新進入後續輸入。在一段 8 輪的語音對話中，輸入音訊每輪的成長量剛好等於使用者的語音片段大小，而 assistant 那一側則以逐字稿 token 的形式重新出現，計價 $4/M。複利成長裡真正貴的部分，只有使用者的音訊。

由此得出的做法很簡單：歷史只做 append，整個 session（以及跨 session）保持 instructions 和 tool 定義逐位元組相同，把任何動態內容放進最新的使用者訊息而不是 prefix，需要刪減時就少刪、大步刪，別每一輪都動。想了解各家供應商的通用機制，可參考我們的 prompt caching 指南，以及 實測快取最低門檻 的研究。

gpt-realtime-2.1 還是 mini：該選哪個？

兩個模型的計費機制完全相同：一樣的換算率、一樣的 64-token 快取量化、一樣的曲線形狀。差別在價格和行為：

有兩點值得留意。在快取重播這條路徑上，兩者價差幾乎抹平（$0.40 對 $0.30），所以一個高度快取的長會談會稍微縮小 mini 的優勢，不過總量還是由新產生的 token 主導。另外 mini 的速度在打斷時反而是劣勢：它產生的內容比播放進度超前更多，所以每次打斷丟棄的已產生音訊大約是兩倍。換算成金額，我們測過的每個場景 mini 仍然勝出；3.2 倍的價差吸收了這兩個影響。

短指令助理、IVR、高併發客服，預設選 mini。當會談需要複雜的工具編排或多步推理時，選 2.1；OpenAI 把它定位成指令遵循的旗艦，而我們的成本測試框架刻意不評判這一點。

常見語音場景實際要花多少錢？

打斷頻繁的場景，把打斷溢出量加進每次互動的計算裡：每次打斷的成本 = 使用者聽到的音訊，再加上幾秒的生成超前量。

常見問題

GPT Live 和 GPT Realtime API 是同一個東西嗎？

不是。GPT Live 是 ChatGPT app 裡的語音功能，本身沒有 API，也沒有獨立的定價頁面。開發者若想用程式方式取得同樣的體驗，會用 Realtime API 的模型 gpt-realtime-2.1 和 gpt-realtime-2.1-mini，本文量測的就是這兩者的價格。

一個 Realtime session 最長能持續多久？

上限硬性規定為 60 分鐘，session 一旦關閉就無法恢復。文字歷史可以重新注入到新的 session（以全額計價一次，靜態 prompt 仍維持快取），但助理的音訊無法重播，所以長時間運行的語音產品必須在第 60 分鐘之前準備好輪替方案。

回合之間有 idle timeout 嗎？

文件沒有記載任何 idle timeout，而在我們的量測中，server VAD 下的靜默不計任何 token，所以在互動之間保持連線開著，除了連線本身之外沒有額外成本。對於使用頻率稀疏的產品，維持一個長 session 比每次互動都重連更便宜也更快，因為建立連線量測到約 2.5 秒。

API 預期的音訊格式是什麼？

輸入與輸出的預設都是 24 kHz 單聲道的 PCM16，透過 session.update 中的 audio.input.format 和 audio.output.format 設定。計價與格式無關：音訊 token 只跟時長有關，輸入每 100 ms 算 1 個 token，輸出每 50 ms 算 1 個 token。

如何應對這道 60 分鐘的牆（輪替、歷史交接、重連後有哪些東西會保留），本身就是另一個獨立的主題，而本文的數字正是那些計算的輸入值。至於文字 API 中計費 token 如何依家族拆解，可參考姊妹文章 token 用量剖析。

← 返回部落格