GPT-Live-1 与 NVIDIA Nemotron VoiceChat 11B：按分钟计费，还是 80 GB GPU

在 GPT-Live-1 与 NVIDIA Nemotron VoiceChat 11B 之间做选择，并不是在两个语音模型之间做选择。它是在两种商业模式之间做选择，只不过两者都披着语音模型的外衣。GPT-Live-1 是一个托管式 API，OpenAI 于 2026 年 9 月 10 日将其开放给开发者使用，按音频每分钟 0.05 美元计费，且无需你投入任何硬件。NVIDIA Nemotron VoiceChat 11B——以 NVIDIA-NemotronLabs-VoiceChat-11B 之名发布，配有日期为 2026 年 7 月 21 日的 NGC 容器以及与之并列的 Hugging Face 检查点——是一个 110 亿参数的开源权重全双工语音模型，任何低于 80 GB 的 GPU 都跑不动它。这两者之中，一个按每通话分钟向你收费；另一个则无论有没有人来电，都在让你花钱。

盈亏平衡比供应商演示文稿里说的要简单

先从双方都认可的那个数字说起。{{1}}GPT-Live-1{{/1}}每分钟 {{2}}$0.05{{/2}}，持续保持接通一小时就是 {{3}}$3.00{{/3}}。这就是一次始终在线的语音对话的价格。

现在给替代方案算笔账。Nemotron VoiceChat 11B 需要一块至少有 80 GB VRAM 的 GPU——A100、H100、H200、B100、B200 或 RTX 6000 级显卡，且要在 Linux 上运行。在公开市场上租用其中一块，每小时大约只要低个位数美元，而自购一块，在计入利用率后，摊销下来也差不多是同样的数字。所以，一条始终在线的语音线路大致只是打平：租用 GPU 的成本和 API 的成本差不多，而这还没算上你为了让任何东西在上面跑起来所付的费用。

那是错误的比较，也是大多数关于自建还是购买的文章止步于此的比较。正确的比较是按每块 GPU，而不是按行，并且取决于 NVIDIA 尚未公布的一个数字。

• 在 Tier 1 账户上使用 GPT-Live-1 —— 25 个并发会话，当全部 25 条线路都处于在线状态时，每分钟 1.25 美元，即每小时 75 美元

• Nemotron VoiceChat 11B 在单块 80 GB GPU 上运行——一个 11B 混合 Mamba/Transformer 模型在 80 GB 内能容纳多少并发会话，就支持多少，成本大致相当于该卡的租用费用

在 80 GB 加速器上跑一个 11B 模型有很大余量，而 80 GB 这一要求在实践中能换来大量批处理容量。如果一张卡即使承载六个并发对话，那么在满载情况下，自托管也比 API 便宜得多。如果它只能承载一个半，那就不是。在有人基于真实流量对并发进行基准测试之前，诚实的立场是：盈亏平衡点很可能在规模化时偏向自托管，而两家供应商都没有给你能证明这一点的数字。

在开源模型确实更好、而不仅仅是更便宜的地方

延迟方面的比较比价格方面的比较更值得审慎对待，因为在这个维度上，开放模型掌握着更有力的证据。

• 轮次切换延迟 — Nemotron VoiceChat 11B 在 Full-Duplex-Bench 1.0 上报告流畅轮次交接的延迟为 448 毫秒，打断并让出延迟为 480 毫秒，用户打断接管率为 1.00。OpenAI 报告的 GPT-Live-1 数据为 0.8 秒，较 1.4 秒有所下降。

把这两个数字并排放在一起看，再附上各自的来源，结论就反了过来。英伟达的数字来自一套已公开发布、公开定义基准的测试套件。OpenAI 的数字来自 OpenAI 自己，是拿它的新模型与自家上一代做对比，且从未被独立复现。就现有证据而言，在让语音智能体显得像真人的那件事上，开放权重模型的速度优势是可测量的；而托管模型更快，只是它自家宣传材料里的说法。

NVIDIA 还宣称了一项首创：Nemotron VoiceChat 11B 被称为首个开放的全双工模型，支持在对话过程中实时调用工具，它使用单独的输出通道和预设的等待话术，让智能体在等待外部 API 时仍能继续说话。模型卡附带了三个音频样本，邀请你专门去听这几点——被描述为约 450 毫秒响应的自然轮替、模型会立即让出的打断（barge-in），以及对话中途实时调用的工具。这些样本来自厂商，它们佐证了 448 毫秒这一数字，而非对其进行独立测试，但它们至少是附在可下载检查点上的可听证据，而不是发布帖里的一个数字。这与 GPT-Live-1 通过委派解决的同一个架构问题，给出了不同的答案——开放模型自己撑住线路；托管模型把任务交给一个单独的推理模型，让语音层维持对话不中断。

相似之处与差异之处同样具有启发性。两者都支持全双工，也就是说，它们在说话的同时也在聆听，而不是轮流进行。两者都支持打断与插话。两者的语音训练规模，都让早期那种 ASR→LLM→TTS 级联流水线看起来像三个彼此独立、被硬拼到一起的产品——NVIDIA 的检查点就接触了约 55 万小时的语音数据。

你放弃的，不只是金钱

用开放模型时，你最先放弃的是声音。已发布的检查点使用一个固定的声音，名为 Aria，并且不支持声音克隆或声音库。GPT-Live-1 提供十二种声音，涵盖不同口音、方言和语言，而 Ope​nAI 专门为这个模型重新制作了它们。如果你产品的声音是其身份的一部分，或者你需要从一个部署中为多个市场提供听起来不同的智能体，那么仅凭这一点就几乎足以让它出局——而这是规格对比中最不显眼的限制，因为它看起来像是功能数量，而不是产品决策。

你放弃的第二样东西是上下文的上限。该模型带有约 142 秒的训练时话语长度限制，并且在实际中难以容纳超过大约两分钟的音频上下文。一通持续二十分钟的电话，对于这个检查点来说并不是一个连续的上下文；它是一系列片段，必须由外围系统来管理。托管模型通常会替你承担这些簿记工作。

第三点是你获准用它做什么。Hugging Face 模型卡附带的是 openmdw-1.1 许可证，而一些关于该发布的报道将其描述为仅限研究用途，NGC 容器页面则将这些组件表述为可供商业或非商业使用。三个来源，三种不同的解读，而只有许可证文本具有约束力。这种不一致，正是那种会在发布前三周的法律审查中冒出来的问题。要在构建之前解决它，而不是之后。

第四项是运维。一块 80 GB 的 GPU 不是你在一个安静的周日就能关掉的一项开支：即使流量为零，你也在为这张卡付费，而且扩缩容曲线、驱动升级、容量规划，以及实时音频链路的待命轮值，全都得由你负责——在这条链路上，连接一断，客户就没了。在你做到这一点之前，也没有托管的后备方案可以依靠——Hugging Face 模型卡上的推理提供商一栏明确写着，该模型没有由任何推理提供商部署，所以没有这个检查点的按分钟付费版本可供你做原型验证。你要么自行托管，要么就别用。这些工作在按分钟计费的对比中看不见，但在招聘计划上却非常显眼。

大多数团队真正应该考虑的混合模式

让这个决策变得可处理的思路是，这两个模型不必是二选一。语音智能体通常有一个语音层和一个推理层，而灵活性正是在推理层。

GPT-Live-1 就是这样设计的。它的语音层让对话保持连贯，而思考部分则通过 Responses API 委托给一个普通的文本模型——Ope​nAI 自己发布的 WebRTC 示例就是将该后端接入 GPT-5.6 Terra。你技术栈的这一半是普通的 API 调用，按 token 计费，并且可以真正自由选择供应商。GPT-5.6 Terra 通过 OrcaRouter 提供服务，价格为每百万输入 token 2.00 美元、每百万输出 token 12.00 美元，上下文长度达 100 万 token，并同时开放 /v1/chat/completions 和 /v1/responses，与约 190 个其他模型并列，只需一个密钥即可访问。

这对自托管项目尤其重要，因为它改变了风险状况。如果你部署了 Nemotron VoiceChat 11B，而它在你的流量下撑不住，那么语音那一半就是沉没的 GPU 成本——但推理那一半可以迁移、故障转移，或者拆分为：常规轮次用便宜模型，升级场景用强模型，而完全不用触碰音频路径。当单一来源依赖宕机时，跨上游提供商的自动故障转移就是糟糕的一个下午和糟糕的一个季度之间的区别。

明确地说明什么在哪里可用、什么不可用：OrcaRouter 既不提供 GPT-Live-1，也不提供 Nemotron VoiceChat 11B。两者都来自各自的来源——一个是 OpenAI 的 Live Sessions 端点，另一个是你自己的 GPU。路由层面的影响力完全处于音频的下游。

应该基于哪一个来构建

• 如果您想在本季度发布，如果您需要多个语音，如果您的对话通常持续超过两分钟的连续上下文，或者如果用量还不够高，不足以证明使用闲置时计费的 GPU 是合理的，请选择 GPT-Live-1。

• 如果你已经在运行 80 GB GPU，如果你需要低于 500 毫秒的轮流对话，并且要有证据而非仅凭断言，如果你出于数据驻留原因需要让音频留在自己的基础设施内，或者如果你的通话量已大到 API 的按分钟计费成为账单上最大的一项支出，请选择 NVIDIA Nemotron VoiceChat 11B。

• 在 API 上做原型，并对检查点做基准测试。这个决策取决于一个尚未公开的数字——每张 80 GB 显卡上的并发会话数——而获得它的唯一途径，就是按照你自己的流量形态去实测。那是一周的工作量，而它决定的，是一个站得住脚的基础设施决策，还是一个被包装成决策的猜测。