GPT Realtime API 定价实测：说话成本是听取的 4 倍

使用 OpenAI Realtime API 进行语音对话时，用户说话期间的费用为每分钟 $0.0192，模型回应期间为每分钟 $0.0768。生成语音的成本正好是听取语音的 4 倍，这个比例足以解释语音会话中的大部分费用。先澄清名称：“GPT Live”是 ChatGPT 面向消费者的功能，并没有 API。它背后的 API 产品是 gpt-realtime-2.1 和 gpt-realtime-2.1-mini，本文测量的就是这两个模型。

TL;DR

• gpt-realtime-2.1 对用户语音严格按每 100 ms 计 1 个音频 token，对模型语音按每 50 ms 计 1 个音频 token：听取语音每分钟 $0.0192，生成语音每分钟 $0.0768。
• 启用服务端 VAD 后，60 秒静音产生的输入 token 为零。
• 到第 30 轮时，自动缓存覆盖了 93% 的输入；删除一条历史记录后，下一轮按全价计费的输入增加到原来的 3 倍。
• 一段较长的语音回答在播放 2 秒后取消，最终按 4 秒音频计费。
• gpt-realtime-2.1-mini 的计费机制完全相同，音频价格低 3.2 倍。

本文所有数字均来自 2026-07-19 针对两个模型运行的 WebSocket 插桩测试，每个服务端事件都完整记录。两个模型都已上线 Synthorai gateway 的 /v1/realtime endpoint，测试会话也在这里运行；其协议和计费方式与直接调用 OpenAI 相同。测试工具是一个只依赖 Python 标准库的单文件程序，下面的每项数据都能追溯到原始 response.done usage 记录。

如何连接 Realtime API？

Realtime 与文本 API 不同，并非基于 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、voice、tools 和 turn detection，这些内容会成为可缓存前缀；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 的文本费率计费。

第二，语音转文字附加项有独立的计费通道。其 usage 记录为 {"type": "duration", "seconds": 30}：按时长以每分钟 $0.017 计费，与 token 无关，而且转录文本不会进入模型输入。仅启用这一项，就会让 2.1 的输入侧成本接近翻倍，并让 mini 的输入侧成本接近 4 倍。因此，只应在合规要求或产品功能确实需要文本时开启。

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

静音不产生费用。我们在启用服务端 VAD 的会话中持续发送了 60 秒静音，随后提出问题；得到的 usage 与完全未发送音频的对照会话逐字节一致。VAD 只会提交检测为语音的音频，因此等待音乐、客户阅读表单或保持空闲的通话线路都不会产生输入 token。实际环境中的背景噪声可能会触发 VAD；纯静音只是理论下限，不能代表嘈杂通话也一定免费。

打断按模型已经生成到的位置计费，而不是按用户实际听到的位置计费；尚未生成的部分不会收费。我们要求模型缓慢地从一数到四十，并在听到 2.0 秒后取消：最终计费 81 个音频 token，相当于 4.0 秒。多出的 2 秒是 response.cancel 到达前，生成进度领先播放进度的部分。mini 在相同测试中计费 6.3 秒，因为较小的模型生成速度更快，领先实时播放更远。实际使用中，客户端一旦检测到用户插话，就应立即发送 response.cancel，因为取消请求到达之前计费不会停止。

工具调用本身不影响计费。我们在会话中定义了一个函数，模型发出调用并接收注入的结果后，紧接着的响应有 99% 输入按缓存费率计费。函数调用 item 及其输出与其他追加到 history 的内容一样可以缓存，工具定义则位于静态前缀中，从第 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，因此轮换会话时，只有重新读取 conversation history 需要支付一次全价，system prompt 不需要。

编辑 history 会导致缓存优惠失效，我们也测量了具体代价。在会话中途删除一条较早的 item 后，缓存占比仅在下一轮大幅下降，随后便重新建立：

实测还有一个有利因素：模型自己的语音回答在后续输入中会以文本形式重新进入上下文，而非音频。在一段 8 轮语音对话中，输入音频每轮增加量与用户音频片段大小完全一致；assistant 的内容则以转录 token 形式重新出现，费率为 $4/M。累积成本中价格较高的部分仅来自用户音频。

对应的实践很简单：history 只追加，不修改；整个会话以及不同会话之间，都应保持 instructions 和工具定义逐字节一致；动态内容放在最新的用户消息中，不要写入前缀；必须裁剪时，应减少裁剪频率并一次裁剪较多内容，而不是每轮都裁剪。有关不同 provider 的通用机制，可参考我们的 prompt 缓存指南和缓存最低门槛实测。

gpt-realtime-2.1 与 mini：该选哪个？

两个模型的计费机制完全相同：换算规则相同，缓存都以 64 个 token 为单位量化，成本曲线形状也一致。区别在于价格和行为：

这里有两个细节。缓存重放时，两者的价格差距会大幅缩小（$0.40 对 $0.30），因此在缓存占比很高的长会话中，mini 的优势会略微减小，不过新增 token 仍是总成本的主要部分。mini 的速度在被打断时反而不利：它的生成进度领先播放更远，因此每次插话都会丢弃约两倍的已生成音频。即便如此，在我们测量的所有场景中，mini 的总费用仍然更低；3.2 倍的价格差足以抵消这两项影响。

短指令 assistant、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 分钟，关闭后的会话无法恢复。可以将文本 history 重新注入新会话，这部分会按全价计费一次，而静态 prompt 仍可命中缓存；但 assistant 音频无法重放。因此，长时间运行的语音产品必须在第 60 分钟前完成会话轮换。

轮次之间有空闲超时吗？

文档没有说明空闲超时。我们的实测显示，在服务端 VAD 下，静音产生的 token 为零，因此两次交互之间保持连接不会产生费用，连接本身除外。对于使用频率较低的产品，维持一个长会话比每次交互都重连更便宜、更快，因为实测建立会话约需 2.5 秒。

API 要求什么音频格式？

输入和输出默认都使用 24 kHz 单声道 PCM16，通过 session.update 中的 audio.input.format 和 audio.output.format 配置。计费不受格式影响：音频 token 只取决于时长，输入每 100 ms 计 1 个 token，输出每 50 ms 计 1 个 token。

如何在 60 分钟上限下设计工程方案，包括会话轮换、history 交接以及重连后哪些内容能够保留，需要单独讨论。本文的实测数字可以直接用于这些方案的成本计算。若要了解文本 API 中不同模型系列的计费 token 如何拆分，可阅读配套文章 token usage 构成详解。

← 返回博客