Deepgram 与 Whisper 语音智能体对比：诚实推荐

关键问题不是谁更准

如果你的语音智能体在用户停下说话三秒后才回话，就算语音识别把每个词都转对了也没意义。用户早就放弃语音、开始打字了。所以在为 AI 语音智能体挑选 Deepgram 与 Whisper 时，真正诚实的问题不是"哪个词错误率更低"——两者在干净音频上的差距都在聊天机器人可接受的范围内。真正的问题是"哪一个能让我在人还觉得被听到的时间窗口内做出回应"。

这个窗口从用户停下说话到你的机器人开始回应，端到端大约 800 毫秒，而 STT 通常是第一个把它撑爆的环节。这篇文章是一份诚实的拆解：每个引擎实际能做什么、在真实的 Telegram 或 WhatsApp 语音机器人里跑起来分别多少钱，以及一条能让你不用自己跑基准测试就能做决定的准则。

你其实在挑什么

Deepgram 是一个托管 API。你把音频发到他们的服务器，他们返回转写文本。Nova-3 是他们当前的旗舰模型，Flux 是针对语音智能体调优的新变体，内置了对话回合结束检测，机器人不需要你自己写逻辑就能知道用户说完了。Deepgram 公布的生产环境流式 P50 延迟在 200 到 300 毫秒之间，这正是实时场景最关心的数字。

Whisper 是 OpenAI 的开源权重模型。你可以直接调用 OpenAI 的托管 API，也可以在自己的硬件上运行社区实现（faster-whisper、whisper.cpp）。参考版 Whisper Large v3 大约有 15.5 亿参数，在标准干净基准上词错误率约 10%。它本质上是一个批处理模型——你交给它一段音频，它返回转写结果，参考实现里没有真正的流式路径。

一句话概括所有差异：Deepgram 是为"你还在说话时就能回应"而生的，Whisper 是为"你说完之后精准回应"而生的。这份对比中的其他一切都是这一点的推论。

准确率：比基准数字看起来更接近

从纸面看，Deepgram Nova-3 在生产环境下的词错误率在 5.26% 到 6.84% 之间，而 Whisper Large v3 大约 10%。这个差距真实存在，也在 Deepgram 自己发布的对比里成立。但 2026 年 7 月发布的一份独立基准测试，覆盖了 14 个 STT 模型和 904 个音频文件，结果显示 Nova-3 英文平均 WER 是 12.3%，与 Whisper-1 的 11.9% 基本持平，而 AssemblyAI Universal-3.5 以 7.0% 领先两者。

"Deepgram 公布的数字"和"独立基准数字"之间的差距不是不诚实，而是因为词错误率对音频输入极度敏感：口音、噪声、行业词汇、采样率、编码格式都会左右结果。Nova-3 在干净的英文会议音频上占优，在非英文场景则处于下风；而自托管的 faster-whisper Large v3 在一场与 Deepgram Nova-2 的对比中甚至打出过 4.2% 的 WER，同场 Nova-2 是 6.7%。

诚实的结论是：在你的语音机器人真正会遇到的音频上——有人对着手机麦克风说话，用你支持的某种语言，带着环境噪声——两个引擎都落在转写文本"可用"的精度区间里。如果准确率真的是你的差异化点，请用自己的录音跑一个小型基准。对大多数智能体而言，准确率不是差异化点。延迟才是。

延迟：真正的决定因素

Deepgram 的流式 API 会在用户还在说话时就返回部分转写。生产环境下的端到端延迟大约在 200 到 300 毫秒。他们的 Flux 变体是专门为语音智能体调优的，模型内建了对话回合结束检测，管线不用另外挂一个语音活动检测器就能知道用户什么时候说完了。

Whisper 走 OpenAI API 是批处理式的。你上传文件，它返回结果，"这一次花了多久"取决于文件长度加上网络往返时间。对于用户并不指望即时回复的语音留言，这没问题。对于对话，就不合适了。

在 GPU 上自托管 faster-whisper 比托管 API 快得多，但设计上依然是批处理。社区包装器通过把固定大小的音频块喂进模型、再把输出拼起来的方式模拟流式，通常每个音频块会额外增加两到五秒的延迟，让人产生经典的"请稍等"感受。如果你必须自托管又想要实时能力，就要面对另一套架构（自研的语音活动检测、模型预热、音频块重叠），这本身就是一个独立项目。

所以：如果回应可以在用户说完之后再出现，两个引擎都够用。如果回应需要像人类插话一样自然，Deepgram 是默认选择。

成本：真正影响预算的数字

Deepgram Nova-3 预录音频每分钟 0.0043 美元，流式每分钟 0.0058 到 0.0077 美元，按秒计费。OpenAI 的 Whisper Large v3 API 是每分钟 0.006 美元，gpt-4o-mini-transcribe 是每分钟 0.003 美元。实时变体 gpt-realtime-whisper 是每分钟 0.017 美元。

在专用 GPU 上自托管 faster-whisper，在每月 1000 小时量级下可以把边际成本压到大约每分钟 0.0003 美元——大规模下比 Deepgram 便宜大约 14 倍——但这个数字前提是 GPU 满载运行。低量场景下，成本被 GPU 的按小时固定租金主导，自托管反而更贵。

对于典型的单人创业者机器人，交叉点大致在每月 100 小时音频。在这个量以下，托管 API 在包含你时间成本的总花销上都更划算。超过这个量，自托管才开始有意义。几乎没有个人或小团队的语音机器人在这条线以上。

一条能替你做决定的规则

下面这条规则可以帮你省下一次基准测试：

目标就是实时对话（期望语音回应在一秒内、自然的对话回合、电话通话）：选 Deepgram。想要内建的回合结束检测就用 Flux，想要纯粹的 STT 能力就用 Nova-3。
用户先录音，机器人稍后回应（Telegram 语音留言、WhatsApp 语音、较长片段的转写）：走 Whisper 的 OpenAI API。更便宜，长格式下更准，几乎没有延迟劣势。
你有实打实的音量并且想掌控整条技术栈（每天音频超过 100 小时，数据必须留在自家硬件）：GPU 上自托管 faster-whisper。要在预算里留一个人手来维护包装层。

对于用户发一段语音留言、几秒后拿到回复的典型 Telegram 机器人，Whisper 是对的选择，Deepgram 属于过度配置。对于必须撑起真实对话的电话原生智能体，Deepgram 才对得起自己的价格。

Hermes Agent 在其中的位置

如果你在 Telegram 或 WhatsApp 上运行 Hermes Agent，几乎可以肯定你想要 Whisper 路径。语音留言是常见形态，用户已经习惯了两三秒的回复节奏，托管的 OpenAI Whisper API 无需任何基础设施就能接入。Hermes Agent 语音模式指南介绍了 STT 插槽是如何接到 gateway 上的。

如果你想用 Hermes 处理实时语音通话，或用在回应必须像插话一样及时的渠道上，Deepgram Nova-3 或 Flux 是诚实的选择，每小时多花的几美分买到的是一段听起来不像对讲机的对话。管线的 TTS 一侧，我们的 TTS 服务商总览给出了对话回复半段的诚实推荐。

如果你不想自己维护这些，使用 Hermify 快速上手——Telegram 上的托管 Hermes Agent 提供持久化记忆、语音回复，以及大约一分钟就能上线的机器人。STT 和 TTS 已经接好，使用模式变化时你可以换服务商，无需碰任何基础设施。

总结

Deepgram 赢在实时，Whisper 赢在批处理和成本。词错误率的差距真实存在，但它不是决定两者取舍的关键——流式架构才是。当用户期望在自己还在说话时就得到回应，选 Deepgram；当用户能接受语音留言自然带来的两秒等待，选 Whisper；只有当量级和隐私要求真正撑得起掌控整条技术栈时，才选自托管的 faster-whisper。

如果你正在做语音机器人，又拿不准自己在这条线的哪一侧，先用 Whisper 上线。它更便宜、更简单，将来撑不住时切到 Deepgram 只是一行代码的事。反过来就是一次重写。