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 秒，输入 token 计费为零。
• 到第 30 轮时，自动缓存覆盖了 93% 的输入；删掉一条历史记录，会让某一轮的全价输入翻三倍。
• 在一段较长的语音回答开始 2 秒时取消，实际按 4 秒音频计费。
• gpt-realtime-2.1-mini 的计费机制完全一致，音频价格低 3.2 倍。

这里的每个数字都来自 2026-07-19 针对这两个模型跑的带监测的 WebSocket 会话，每个服务端事件都有日志记录。两个模型都跑在 Synthorai 网关的 /v1/realtime 端点上，这些会话就是在那里跑的；协议和计费与直连 OpenAI 完全一样。测试脚手架是一个只用标准库的 Python 文件，下面每个数字都能追溯到一条原始的 response.done 用量记录。

怎么连接到 Realtime API？

和文本 API 不同，Realtime 不是走 HTTP 的请求/响应模式。每个会话开一条 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、voice、tools 和轮次检测（这部分会成为可缓存的前缀）；input_audio_buffer.append / commit 添加用户音频；response.create 触发一次回复；每个 response.done 都携带该次回复的完整用量明细。有个方言上的细节：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 的价目表换算成按分钟计价，结果如下：

有两项成本藏在表格之外。第一，语音回答还会计费 text output：转写文本加上 reasoning token（gpt-realtime-2.1 确实会推理，output_token_details.reasoning_tokens 每次跑下来都是非零值）。在我们那段简短的测试回答里，这部分在 audio token 之上多算了大约 24%，按 $24/M 的 text 费率计费。

第二，转录附加项是独立的一条计费项。它的用量记录是 {"type": "duration", "seconds": 30}：按时长计费，每分钟 $0.017，与 token 无关，而且转写文本从不进入模型的输入。打开这个开关，2.1 上的输入侧成本大约翻倍，mini 上则接近翻四倍，所以只在合规或产品需求确实需要文本时才开启它。

静默、打断和工具调用会产生费用吗？

静默不花钱。我们在开启 server VAD 的会话里推流了 60 秒静默，然后提了个问题：用量和一个从不发送音频的对照会话逐字节完全一致。VAD 只提交它检测为语音的音频，所以背景音乐、客户念表格、或者一条空闲挂着的线路，输入 token 都计 0。需要注意的是，真实的背景噪声可能触发 VAD；纯静默是下限，在嘈杂的通话里并不能保证如此。

打断计费到生成的前沿，而不是到用户听到的位置，也绝不会为尚未生成的剩余部分计费。我们请求模型缓慢数到四十，在听到 2.0 秒后取消：计费为 81 个 audio token，也就是 4.0 秒。那多出来的 2 秒是 response.cancel 到达之前，生成领先播放的距离。同样的实验在 mini 上计费 6.3 秒，因为更小的模型比实时进度领先得更多。实用规则是：客户端一检测到 barge-in 就立即发送 response.cancel，因为计费一直跑到 cancel 到达为止。

工具调用不影响计费。一个带有单个函数定义的会话发出了调用，接收注入的结果，紧接着的下一个 response 显示其 99% 的输入按缓存费率计费。函数调用项及其输出会像其他追加的历史一样被缓存，而工具定义本身位于静态前缀里，从第 2 轮起就开始缓存。

缓存如何让长会话保持低成本？

Realtime API 每次生成回复都会把整段对话重新读作输入，所以每一轮的输入会随会话长度线性增长。让这件事仍然负担得起的是自动前缀缓存：命中缓存的音频按 $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 }
  }
}

有三个官方文档没有写明、但我们都实测过的细节：缓存大约在前缀达到 128 个 token 时开始生效（文本 API 文档写的最小值是 1,024），它以 64 个 token 为一块推进，而且静态前缀可以在同一个 key 的多个会话间复用。最后这一点对 60 分钟的会话上限很重要：新会话的第一轮，instructions 就已经按缓存价计费了，所以轮换会话只需为重新读取对话历史付全价，system prompt 不用。

编辑历史是唯一会丢掉折扣的做法，我们把具体代价也测了出来。在会话中途删掉一条早期条目，缓存占比正好塌陷一轮，随后缓存重建：

还有一处实测发现能省钱：模型自己说出的回答再次进入后续输入时是以文本形式，而不是音频。在一段 8 轮的语音对话里，每一轮输入音频只增长了用户音频片段本身的大小，而 assistant 一侧则以 transcript token 的形式重新出现，按 $4/M 计费。累积项里真正贵的部分只有用户音频。

由此得出的操作要点很简单：历史只追加、不改动；整个会话（以及多个会话之间）的 instructions 和工具定义保持逐字节一致；把任何动态内容放进最新的用户消息里，而不是放进前缀；确实需要裁剪时，少裁、每次裁一大段，而不是每轮都裁。想了解各家提供商通用的机制，参见我们的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 应用里的语音功能，没有独立的 API，也没有单独的定价页。想在程序里实现同样体验的开发者，用的是 Realtime API 的模型 gpt-realtime-2.1 和 gpt-realtime-2.1-mini，本文测的就是这两个的价格。

一个 Realtime 会话最长能持续多久？

硬上限是 60 分钟，会话一旦关闭就无法恢复。文本历史可以重新注入到一个新会话里（按全价计费一次，静态 prompt 仍然走缓存），但 assistant 的音频无法重放。所以做长时间运行的语音产品，得在第 60 分钟之前准备好轮换方案。

两轮对话之间有空闲超时吗？

没有文档记录的空闲超时。在我们的测量中，server VAD 下静默期间计费为零 token，所以两次交互之间保持连接除了连接本身之外没有额外成本。对于使用频率低的产品，这意味着开一个长会话比每次交互都重连更便宜、更快，因为建立连接实测约需 2.5 秒。

API 需要什么音频格式？

输入和输出默认都是 24 kHz 单声道的 PCM16，在 session.update 里通过 audio.input.format 和 audio.output.format 配置。计费和格式无关：audio token 只取决于时长，输入每 100 ms 计 1 个 token，输出每 50 ms 计 1 个 token。

如何应对 60 分钟的这堵墙（轮换、历史交接、重连后哪些内容能保留），本身是另一个话题，本文的这些数字是做这道计算题的输入。至于文本 API 中计费 token 如何按类别拆分，可以看配套文章 token 用量剖析。

← 返回博客