GPT-Live-1 与 Grok Voice Think Fast 2.0：两款语音 API 的定价走向截然相反

关于这场对比，最有用的信息是一个方向，而不是一个数字。当 x​AI 于 2026 年 7 月下旬发布 Gr​ok Voice Think Fast 2.0 时，它把每分钟音频费率提高了 60%，从 Think Fast 1.0 所收取的 $0.05 涨到 $0.08。六周后，也就是 2026 年 9 月 10 日，Ope​nAI 将 GPT-Live-1 放入开发者 API，定价恰好是 x​AI 刚刚放弃的那个价格。这就带来了一种罕见局面：两个领先的全双工语音 API 可以直接按价格进行比较，而且较新的入局者反而是更便宜的那个——而更老、更贵的那个模型，才是背后有第三方基准测试分数支撑的模型。

账本，在任何基准测试之前

这两种都是为电话形态的工作负载而打造的语音到语音模型：与客户的实时对话、一次打断、一次工具调用，以及按分钟计费的账单。除此之外，它们很快就会分道扬镳。

• 每分钟音频价格 — GPT-Live-1 $0.05，对比 Gr​ok Voice Think Fast 2.0 $0.08

• 计费单位 — GPT-Live-1 按秒计费，不向上取整到下一整分钟；Grok Voice Think Fast 2.0 按音频分钟计价，折算下来约为每小时 4.80 美元

• 发布 — GPT-Live-1 于2026年7月8日在 ChatGPT 内上线，并于2026年9月10日登陆 API；Gr​ok Voice Think Fast 2.0 于2026年7月29日至30日前后发布，大约在 Think Fast 1.0 发布三个月后

• 端点 — GPT-Live-1 仅支持 Live Sessions，位于 v1/live/sessions，基于 WebRTC；Gr​ok Voice Think Fast 2.0 运行在 x​AI 的 Speech-to-Speech API 上，同时支持 WebSocket 和 WebRTC

• 工具面 — GPT-Live-1 通过 Responses API 委托给后端推理模型；Grok Voice Think Fast 2.0 在会话内可使用网页搜索、X 搜索、文件搜索、MCP 服务器和客户端函数

• 语音可移植性——GPT-Live-1 使用 OpenAI 重新录制的十二种语音合集；Grok Voice Think Fast 2.0 支持内置语音和自定义语音

WebSocket 这条线看着不大，重要性却超出了它的体量。相当大一部分电话基础设施——大多数 CPaaS 产品内部的媒体流管道——说的是 WebSocket，而不是 WebRTC。Gr​ok Voice Think Fast 2.0 就着这套基础设施的现状与之对接；GPT-Live-1 则不能，而要从一条只支持 WebSocket 的通话路径走到 WebRTC，是一项实打实的工程活儿，而非一个配置开关。

基准不对称才是真正的问题所在

正是在这里，对比不再是不分伯仲的平局；也正是在这里，大多数分析文章都搞反了——它们把两组数字当成了同一类证据。

Grok Voice Think Fast 2.0 的主要分数来自 Artificial Analysis 的语音到语音质量指数，这是一项第三方测量，使该模型达到 82.9%，高于 1.0 版本的 75.7%，领先于 GPT-Realtime-2.1 的 79.1% 和 Gemini 3.1 Flash 的 69.5%。xAI 还报告称，在 τ-voice Bench 的智能体行为方面以 56.5% 排名第一，领先于 GPT-Realtime-2.1 的 45.7%。这些都是对 xAI 模型进行的外部测量结果。

GPT-Live-1 的亮眼成绩都是 OpenAI 自己给出的。该公司报告称，其全双工交互率为 80.1%，而 GPT-Realtime-2.1 为 45.4%；轮流对话延迟从 1.4 秒降至 0.8 秒；工具调用准确率从 60% 提升至 87%。这些数字全部来自厂商自报，尚未被独立实验室复现，而且是将 OpenAI 的新模型与其自家上一代模型相比，而非与竞争对手相比。

这不是否定这些数字的理由——发展趋势与早期部署者报告的情况一致——但这确实意味着，目前唯一可用的跨厂商比较在独立运行的测试中偏向 xAI 的模型，而关于 OpenAI 延迟优势的唯一可用数字来自 OpenAI 自己。不要把 0.8 秒和 0.70 秒当作一场真正的较量；这两个数字中只有一个是由与结果无利害关系的人测得的。

别名陷阱，以及为什么涨价让人措手不及

如果 x​AI 没有同时通过别名推送它，60% 的涨幅在大多数发布说明中本只会是一个舍入误差。指向 grok-voice-latest 别名的应用，除非显式固定到 grok-voice-think-fast-1.0，否则在 2026 年 8 月 5 日自动继承了新模型和更高的费率。这是一个值得理解而非抱怨的设计决策：浮动别名为你带来免费升级，也会不声不响地改变你的单位经济效益。

显而易见的补救措施比它看起来更弱。Grok Voice Think Fast 1.0——每分钟 0.05 美元的模型，于 2026 年 4 月 23 日发布——现已在 xAI 自己的模型列表中被标记为弃用。将其固定可以让你免受自动升级影响，但它争取的是时间，而非一条永久更便宜的路径，因为弃用模型前方某处有一个退役日期。按你自己的时间表规划迁移，而不是按别名的。

定价页面本身值得在确定数字之前仔细阅读。xAI 的模型页面明确列出了各个版本的费率——grok-voice-think-fast-2.0 为每分钟音频 $0.08，每小时 $4.80，外加每次文本输入 $0.004——而同一页面上单独的 Voice API 卡片宣传的智能体价格为“每分钟 $0.05 起”，这是入门价，而不是 2.0 模型实际计费的费率。如果你的容量规划是基于营销数字做出的，那它大约低了 60%。

OpenAI 的模型不会以同样的形式遇到这个问题，因为没有任何可供浮动指向的对象。GPT-Live-1 只有一个模型 ID，即 gpt-live-1，而这个 ID 同时也是它自己的默认快照——没有带日期的变体可供锁定，因此也没有别名能悄悄更改模型或价格。代价是，你同样无法冻结一个已知良好的行为，并在新事物逐步稳定期间继续沿用。

两种模型都把推理层与语音层分开计费，而正是在这里，那个醒目的标价不再是全部成本。GPT-Live-1 委托的 Responses 调用按所配置后端模型的正常每 token 费率计费。x​AI 则会在语音会话中按每段文本输入加收 $0.004，再加上工具调用费用、在需要时提供的预置电话号码约每分钟 $0.01 的费用，以及电话和存储费用——这些都叠加在每分钟音频费率之上。一个主要倾听、偶尔查点东西的语音代理，其费用会接近它的标价；而一个每轮都调用工具的则不会，并且两者不会朝同一方向偏离，因为委托后端的设计与会话内工具的设计在不同地方消耗 token。

在我们这边，每分钟费率变化之所以值得密切关注，是因为 OrcaRouter 以零加价的方式直接传导提供商的目录价。当供应商调整已公布的价格时，我们这边的数字会在同一天随之变动，而不是等到下一个合同周期。

委托拆分在工程上让你付出的代价

如果你是基于架构而非价格在这两者之间做选择，那么决定性的问题就在于接缝落在哪里。

xAI 的模型将工具保留在会话内部。这样更容易理解——一个连接、一次对话、一个函数调用发生的地方——也意味着模型可以在说到一半时决定自己需要搜索，并在等待的同时继续说话。

Ope​nAI 的模型把这项工作向外推。语音层让对话保持活跃，并通过 Responses API 把任务交给一个独立的推理模型；这意味着你的工具定义、检索逻辑和业务逻辑位于普通的文本模型集成中，而不是在一个会话事件流内部。这涉及更多活动部件，同时也更具可移植性：被委托出去的那一半是一次普通的 API 调用，你可以独立于语音层对它进行替换、定价和故障转移。

这一点之所以重要，原因只有一个。GPT-Live-1 和 Grok Voice Think Fast 2.0 都只能由各自的厂商提供——两者都是单一来源，而路由器在音频这一半帮不上忙。路由器能做的是整合你真正能选择的那一半。GPT-5.6 Terra 是 OpenAI 自己的委托示例中使用的后端，可通过 OrcaRouter 以每百万输入 token 2.00 美元、每百万输出 token 12.00 美元的价格获取，同时开放 /v1/chat/completions 和 /v1/responses 两个接口，并与约 190 个其他模型共用一把密钥。如果你的语音代理每一轮都要调用推理模型，那么这一项正是其中具有路由优化空间的支出条目。

结论，按工作负载细分

• 如果约束是每分钟的价格，如果你的呼叫路径已经使用 WebRTC，或者如果你希望语音背后的推理大脑是一个可替换的文本模型，而不是会话中固定的一部分，那就选择 GPT-Live-1。

• 如果你需要在做出承诺之前，先看到经过独立验证的质量摆在桌面上，如果你的电话技术栈是 WebSocket 原生的，或者如果会话内工具——尤其是 X 搜索——是产品的核心而非附带功能，那就选择 Grok Voice Think Fast 2.0。

• 如果你已经在使用 xAI，请留意别名。固定一个有版本号的模型 ID，是你与下一次自动速率变更之间的唯一屏障，而在任何出现浮动别名的地方，这套做法都值得沿用。

令人不安的总结是：更便宜的那个模型恰恰是背后没有第三方验证的那个，而文档更完善的那个模型则刚刚涨价了60%。如果你还处在构建的早期阶段，两个集成方案都尚未锁定，那么风险最低的做法是同时针对两者做原型验证——无论选哪条路，音频处理路径都只有几百行代码——然后让你自己的转写质量来做决定，因为目前的公开证据还不足以定论。