Grok 语音转文字升级 2.0：价格不变，默认模型已切换

Grok 语音转文字 2.0 到底变了什么

xAI 于 2026 年 9 月 18 日发布 Grok Voice Transcribe 2.0。它接替 Grok Voice Transcribe 1.0，成为当前的语音转文字模型：把录音或实时语音转成文本，交给其他产品或工作流继续处理。

两种模式分工明确。批处理适合录音完成后，把文件或音频 URL 发给 REST 端点；流式处理则在人还没说完时，通过 WebSocket 持续发送音频，让字幕、智能体回复或实时辅助能在通话结束前作出反应。

发布页 表示，现有集成无需修改代码就会改用 2.0 模型。听起来很省事，却正是运维团队需要留意的地方：如果请求里没有指定模型，输出何时改变就由服务商决定。

价格表没有变化。批处理仍为每音频小时 $0.10，流式处理仍为每音频小时 $0.20。说话人分离、词级时间戳和关键术语偏置都包含在这个价格里；说话人分离会把词语归到对应的说话人名下。

API 账单没变，工作流总成本未必

只看 API 层，账很好算：

流式处理的价格是批处理的两倍。按 1,000 音频小时计算，要多付 $100。只有等待完整录音会破坏产品体验时，这笔溢价才值得，例如实时字幕、通话实时辅助，或需要当场决定下一句话的语音智能体。

如果音频已经存放在存储系统里，改用流式处理本身并不会让转写结果更有用。媒体资料库、播客积压内容、已录制采访或夜间通话质检任务，通常都该继续使用批处理，保留更低的费率。

API 费用只是预算的一部分。更实用的运营公式是：

转写总成本 = 音频 API 支出 + 人工校正成本 + 下游返工成本

第一项可以直接从价格表得出。第二项取决于审核人员花费的时间及其综合小时成本。第三项则会在词语、说话人标签、时间戳或数字格式发生变化，进而影响字幕文件、质量评分、CRM 备注、搜索索引或自动化操作时出现。

这才是此次发布对业务的真正影响。音频费用可以完全不变，但得到可用转写文本的总成本可能上升，也可能下降。在用代表性音频验证之前，校正时间变短只是一种可能，不能直接写进成本预测。

谁适合使用，升级后要关注什么

手握历史通话的客服运营负责人

客服团队可以按每音频小时 $0.10 的价格批量处理已录通话，启用说话人分离，并把产品名称设为关键术语。API 直接成本依旧可预测。迁移时真正要问的是：使用 2.0 后，审核人员修正姓名、账户信息和说话人归属所花的时间，是变少了还是变多了。

收益不在一个抽象的准确率分数，而在于校正队列缩短，同时不增加下游错误。更换生产环境锁定的模型之前，两项都要测。

运营实时语音智能体的产品团队

对语音智能体来说，等通话结束再处理就失去了产品意义。流式处理按每音频小时 $0.20 收费，价格更高却合理，因为转写文本本身就是实时控制回路的一部分。团队应对比两款模型处理停顿、数字、打断和关键术语的表现，再检查这些文本触发了哪些操作。

转写文本在人眼看来可能更干净，却仍会破坏工作流：一个数值的格式变化可能让查询失败，一处轮次边界变化也可能让智能体过早回复。验收测试不能只看文本，还要覆盖下游操作。

负责交付字幕的媒体运营团队

处理采访或客户视频的机构应使用批处理，在对比中保留时间戳输出，并让两个锁定模型处理同一批难读姓名和多人重叠语音。衡量收益要看校正时间和字幕交付质量，而不是厂商给出的总体基准分数。

API 是组件，不是编辑工作台。如果团队需要浏览器编辑器、会议机器人、字幕工作流或人工升级通道，请改看转写工具完整对比。

多语言 SaaS 客服团队

xAI 称，在其评测中，2.0 的准确率是 1.0 的两倍。它还表示，在自有多语言短语数据集上，词错误率从 20.6% 降至 6.8%。这些都是厂商自行完成的对比，并非本文的独立测试。

多语言客服团队应抽样自己的实际语言组合、口音、电话线路、姓名和语码转换场景。总体指标提升，并不能说明工单量最大的语言是否同步改善，也无法证明校正时间的变化足以影响人员配置。

先锁定模型，再验证输出

最简批处理调用并不复杂。下面的 cURL 示例来自 xAI 文档，并显式指定了 2.0 模型：

curl -X POST https://api.x.ai/v1/stt \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -F model=grok-voice-transcribe-2.0 \
  -F file=@audio.mp3

关键是模型字段。显式锁定 grok-voice-transcribe-2.0，模型选择权就在自己手里。当前文档仍允许暂时用 grok-voice-transcribe-1.0 作为基线。在 multipart 请求中，应把文件字段放在最后，因为 xAI 提醒，排在它后面的选项字段可能会被忽略。

迁移验证的两组请求必须使用完全相同的设置。如果同时改动模型、说话人分离、格式化、填充词处理和关键术语，最后就无法判断究竟是哪一项造成了输出差异。

把不确定性说清楚

价格已经核实，能节省多少人工尚无定论。

xAI 的准确率说法值得拿来设计测试，却不能直接当作人员配置模型。不同的音频组合会带来不同结果，词错误率降低也不必然意味着审核时间更短或自动化更安全。

默认模型的实际变化也跑在公告措辞前面。9 月 18 日的发布页说切换即将发生，而当前文档已经把 2.0 列为省略模型时的默认值。这处不一致再次说明，生产环境应该显式指定模型，而不是依赖不断变化的默认别名。

最后，$0.10 和 $0.20 只覆盖音频处理，不包含审核队列、集成工作、存储、重试，也不包含下游操作出错的代价。把这些成本分开核算，才不会让便宜的 API 掩盖昂贵的工作流。

现在应该怎么做

本周就行动：只要有任何 xAI 语音转文字请求省略模型，或生产环境仍锁定在 1.0，就应盘点所有调用，运行代表性样本集，并明确锁定生产模型。

只在实时到达会改变产品结果时使用流式处理。能等待的录音用批处理，因为同样包含说话人分离、时间戳和关键术语功能，而音频层费用只有一半。

可以暂缓：如果还在筛选服务商，没有任何 xAI 转写结果流入线上工作流，可以先把 2.0 放进候选清单；迁移前，仍要用自己的音频对比人工校正总成本和下游成本。

不受影响：系统没有使用 xAI 语音转文字，或已经锁定 2.0 并验证过输出。锁定 1.0 的集成目前仍然稳定，但这不是推迟迁移测试的理由，因为 xAI 已经宣布将弃用它。

下周一要做的事很简单：拿一组代表性音频，用相同设置分别运行 1.0 和 2.0，衡量校正时间与下游差异，然后锁定通过测试的模型。价格表不变，让 API 预算很容易计算；检查转写结果，则能保护围绕它运行的整个工作流。

如果只想在 AI 价格或工作流真正发生变化时收到一份实用拆解，欢迎订阅邮件通讯。