语音转文字 API 怎么选？2026 年七大服务价格与功能对比

选择语音转文字 API，可以先从用途入手：语音智能体优先看 Deepgram，需要区分说话人的多语言录音优先看 ElevenLabs Scribe，部署控制权是关键条件时则看 Speechmatics。Mistral 的 Voxtral 3 以每音频小时 $0.21 的文件转写价格进入候选名单，但其实时模型在说话人分离功能上有所取舍，应用架构需要提前考虑。

价格与文档已于 2026 年 10 月 21 日对照厂商资料核实。 本文依据公开功能进行比较，并换算每小时费用，不是上手实测的准确率基准测试。

转写 API 把音频转换成文字，供应用内部使用。首先要确定，应用是等录音完成后再处理，还是必须在人说话时实时响应。其次要确定，需要的是文字本身、谁说了什么的记录，还是提醒智能体何时回答的信号。这些需求不同，即使选择同一家厂商，适合的模型也可能不同。

如果需要的是开箱即用的会议或编辑软件，而非 API，可以阅读另一篇 AI 转写工具对比，其中介绍了 Otter、Descript 等产品。

语音转文字 API 对比：先看模式，再看价格

先选处理模式，再比较每小时单价。 便宜的文件转写模型不一定能替代实时识别模型；支持实时识别，也不代表自带说话人标签或对话轮次检测。

下表均为基础转写费用，币种为美元。按分钟收费的模型，统一按每分钟价格 × 60换算。AssemblyAI、ElevenLabs 和 Speechmatics 公布的相关价格已按小时计费，因此直接沿用。费用不包含可选功能、税费、存储、应用使用的语言模型和语音生成。比较以处理单个音频声道、未签订议价企业协议为前提。

“流式”指音频一边到达、一边接收。对已上传的文件分批返回文字，是另一种能力。“说话人分离”指把不同人的发言分开标注，不一定能识别他们的姓名。

用于换算的每分钟价格分别为：Mistral 的 $0.0035/$0.004/$0.008；Deepgram 上述方案的 $0.0043/$0.0048/$0.0065；OpenAI 的估算价 $0.0045/$0.017；以及 Google 的 $0.016/$0.003。Deepgram 的实时说话人分离附加费为 $0.0020/分钟。Google Standard 采用月用量首档价格，未使用大用量折扣。

语言和功能信息来自厂商的模型文档：Mistral 语言支持矩阵、Deepgram 模型列表、OpenAI 转写指南、Google Chirp 3 文档、ElevenLabs 功能指南及 Speechmatics 模型指南。AssemblyAI 的价格页直接列出了各模型的语言数量和附加功能。

Speechmatics 的价格页可能突出展示 Melia 折后约 $0.12/小时的价格，但其计算器给出的文件处理未折扣价格是 $0.24/小时。表格采用这一基础价，不计入同意将数据用于模型训练的折扣，也不计入批量额度折扣。同样，正式确定预算前，也应重新核对 Deepgram 标注的实时促销价。

七款 API：文件转写与实时语音识别各有侧重

下文先介绍适用面较广的实时智能体首选，再介绍在特定需求下更有优势的方案。顺序不代表转写准确率排名。适合整理录音档案的模型，未必适合处理产生这些录音的实时通话。

1. Deepgram：做语音智能体，先看 Flux

Deepgram 是我为语音智能体列出的首选候选，因为 Flux 在返回转写文字的同时，还会提供对话轮次信号。 这种信号会告诉应用，来电者似乎已经说完了。对需要回答问题的智能体来说，这往往比多收到一个识别正确的词更有用。Nova-3 则是独立的通用转写方案，适合录音文件、字幕，以及无需模型原生轮次检测的任务。

设想预约助手听到：“我想约周五……不，还是周一。”中间转写结果有助于提前准备回复，却不足以据此约定周五。应用必须区分用户仍在说话、看似结束一轮发言，以及重新接着说的情况。Flux 快速入门为此介绍了 EndOfTurn、可选的 EagerEndOfTurn 和 TurnResumed 事件。

这带来的接入优势很具体：智能体何时响应，可以由明确的策略控制。只有在来电者继续说话时能够取消准备工作，才适合提前生成回复。确认预约等会改变业务状态的操作，仍应经过应用自身的判断和确认逻辑。提前推测只有在不会把用户的更正变成错误操作时，才有价值。

适合： 实时语音智能体，以及希望分别采用通用转写模型与对话模型的团队。
亮点： Flux 原生轮次事件；Nova-3 负责文件转写和字幕。
价格： Nova-3 单语言文件转写 $0.0043/分钟起，即 $0.258/音频小时；实时模型与附加费见上表。
免费试用： Deepgram 价格页提供 $200 额度，无需信用卡。

关键限制在于不同模型的功能和语言支持并不一致。Flux English 是英语模型。Flux Multilingual 列出的语言为英语、西班牙语、法语、德语、印地语、俄语、葡萄牙语、日语、意大利语和荷兰语。Nova 的语言列表更广，并不代表 Flux 能覆盖产品需要的每一种语言。同样，Nova 能做通用转写，也不代表它具有 Flux 的轮次处理能力。

说话人标签需求也会影响接入方式和费用。当前的说话人分离文档建议使用带版本的 diarize_model 参数。批处理与流式处理使用的说话人分离模型不同；在流式请求中指定仅支持批处理的版本，会返回参数校验错误。做会议产品时，要检查最终会存入数据库的响应中的说话人标签，不能验证了批处理示例，就默认实时接口行为相同。

小规模原型还可能掩盖并发上限。Deepgram 的 PAYG 价格页列出的语音转文字并发上限为 150 个 WebSocket 连接和 50 个 REST 请求。并发指同时进行的任务，而非每月累计音频时长。如果应用会在工作日开始时集中接入客户通话，即使平均用量很低，也必须为峰值做准备。

结论：选择 Flux，核心理由是它的对话处理能力。 如果产品只需要在通话结束后提供可搜索的录音文字，可以先看 Nova-3 或其他专注文件转写的方案。更完整的费率结构见 Deepgram 价格详解。

第一次接入 Flux，可以这样做

1. 1

   先选对话模型

   英语使用 flux-general-en；多语言场景先核对文档中的语言列表，再考虑 flux-general-multi。从厂商当前的 Flux 快速入门开始，使用 /v2/listen WebSocket 路径。

2. 2

   让参数匹配实际音频

   发送原始 linear16 音频时，填写真实采样率；Deepgram 在快速入门中建议使用 16000。对于支持的封装格式音频，应按文档使用自动检测流程，避免附上与实际格式冲突的原始音频参数。

3. 3

   分别处理文字与轮次事件

   先展示或缓存转写更新，再单独处理 EndOfTurn 事件。开始时使用文档中 eot_threshold 的默认值 0.7。等到能够处理 TurnResumed 并取消尚未完成的回复后，再加入提前生成。

4. 4

   模拟用户真实的打断与停顿

   试着让来电者更正日期、停下来找账号，或在智能体说话时插话。检查应用能否等待、恢复聆听并保留更正内容。这些是建议采用的验收项，并非本文已执行的测试。

2. Mistral Voxtral 3：文件转写值得评估，预览版限制要看清

Mistral 的 Voxtral 3 已值得纳入文件转写评估，尤其适合同时需要欧盟托管 API 或自行部署方案的团队。 这一转写系列于 2026 年 10 月 20 日进入公开预览，包含用于录音的 Voxtral Mini Transcribe 3、Voxtral Small Transcribe 3，以及用于实时音频的 Voxtral Mini Transcribe Realtime 3。它们是不同的模型选择，不能理解为同一个模型加了流式开关。

对业务的影响很直接。导入客户访谈的应用可以评估 Mini，无需支付实时会话费用，也不必开发对话管理。电话智能体则需要 Realtime 模型，并单独设计何时回答。Mistral 的文件模型支持 50 种语言，Realtime 列出 45 种语言及方言。产品需求文档应采用所选模型的具体数字。

Mistral 将 Small 定位为质量更高的文件模型。这是 Mistral 自身的产品定位，不是本文实测得出的准确率结论。真正该判断的是，Small 能否减少你关心的录音错误，例如客户姓名、产品代码、带口音的发言或多人重叠说话。如果 Mini 已通过验收样本测试，更大的模型未必是更好的产品选择。

适合： 需要欧盟托管选项的文件转写，以及评估新一代 Voxtral 的团队。
亮点： Mini、Small、Realtime 各自独立，处理模式有明确文档。
价格： Mini 文件转写 $0.0035/分钟起，即 $0.21/音频小时；自行部署的商业条款需询价。
免费试用： 引用的模型页面未给出明确的免费转写额度；计划免费用量前，应先查看账户。

最重要的限制写在详细的语音转文字概览中：实时说话人分离和轮次检测不能在同一会话中同时运行。宣传中说整个系列具备这两种能力，不代表一次请求能同时使用。

假设你开发的智能体既要立即回答来电者，又要为主管提供带说话人标签的记录。Mistral 的说话人分离指南建议实时运行轮次检测、保留音频，再对录音进行说话人分离。这种架构可行，但会增加一道处理流程。如果应用必须同时获得实时标签和轮次信号，就应评估其他模型方案，不能指望改个配置便消除限制。

字幕和编辑产品还会遇到另一项限制。当前文件文档提供的是片段级时间戳，而非词级时间戳。前者标记一段语音，后者则让编辑器能够高亮或跳转到单个词。两者对应不同的产品能力。转写文字即使读起来很好，也可能缺少界面需要的时间精度。

对音频理解能力的表述也要谨慎。系列发布公告涉及更广的语音技术栈，但当前语音转文字指南中，音频问答和翻译在发布时仍通过使用 Voxtral 2 的音频聊天流程完成。不能把这些相关能力当作已验证的 Voxtral 3 转写功能来宣传。公开预览意味着需要固定所用模型并确认具体流程，而不是直接忽略这个系列。

结论：文件转写可将 Voxtral Mini 列入候选；Realtime 则要逐项核对实际对话需求。 假设每月处理 1,000 小时文件，Mini 的基础转写费用为 $210，Small 为 $240。差额不大，选哪款更应取决于后续纠错工作量。其他模型费用见单独的 Mistral 价格指南。

3. AssemblyAI：从转写结果的用途倒推模型

AssemblyAI 适合需要结构化转写结果，并希望清楚选择附加处理功能的产品。 Universal-2 是语言覆盖较广的文件方案；Universal-3.5 Pro 是另一款文件模型，语言范围更小，但增加了提示选项。实时产品则可看 Universal-Streaming 和 Universal-3.6 Pro Realtime，两者有各自的价格与能力。只选定品牌，还不足以确定最终上线的 API 请求。

通话复核应用就是一个典型场景。客户上传录音，应用生成带时间戳的发言，审核人员据此查看是谁作出了承诺。之后再决定是否需要摘要、实体检测或敏感内容遮蔽。这些附加功能各有用途；全部开启，很容易只增加支出，却没有改善用户真正关注的界面。

当前价格页将词级时间戳和格式整理列入文件转写功能，说话人分离则单独收费。页面另列出 Speaker Identification，可将通用标签替换为姓名或角色。这个区别很重要：有些回放界面显示“说话人 A”就够了，培训或质检流程则可能必须区分“客户”和“客服”。

适合： 通话录音产品，以及需要对转写结果进行结构化处理的应用。
亮点： 文件、实时和可选语音理解功能分别提供。
价格： Universal-2 文件转写或 Universal-Streaming 均为 $0.15/音频小时起；说话人标签另收费。
免费试用： 注册无需信用卡；厂商列出的额度最高可覆盖 185 小时录音或 333 小时流式音频，具体取决于模型和额度安排。

主要限制是不同模型、不同价位的语言覆盖差异明显。Universal-2 列出 99 种语言，Universal-3.5 Pro 为 18 种，Universal-3.6 Pro Realtime 为 32 种。较便宜的 Universal-Streaming Multilingual 列出英语、西班牙语、德语、法语、葡萄牙语和意大利语。如果应用用厂商最大的语言数量宣传全部能力，就可能承诺所选实时模型根本无法提供的功能。

产品负责人应建立一份按语言和功能交叉核对的验收清单。如果客户使用德语和日语，就要分别核查所选文件或实时模型是否支持，再测试这些语言中的难处理素材。支持语言的数量只能说明厂商提供该语言，不能证明它能处理你的专用词汇、麦克风环境或语言切换方式。

说话人标签也会改变费用对比。Universal-3.5 Pro 加文件说话人分离，总价为 $0.23/小时；Universal-3.6 Pro Realtime 加说话人分离，总价为 $0.57/小时。假设每月处理 1,000 小时，两种配置分别为 $230 和 $570。它们服务于不同工作流，价差不能理解为“同一件事做得更快”的费用。

还要分清同步 API。它在一次请求中返回完整转写结果；异步文件流程则先创建任务，之后才拿到结果。两者都不等同于持续保持实时音频连接。应按使用体验选择：简短语音备忘可以接受短暂的上传和等待，等着回答的来电者则需要实时方案。

结论：当转写结果要成为结构化产品数据时，AssemblyAI 值得考虑。 选模型之前，先画出需要的审核界面或下游记录。如果界面必须展示带说话人归属的发言，就应从一开始按这一配置核算费用。如果只需可搜索文字，就不必购买用户根本用不到的处理功能。

4. ElevenLabs Scribe：适合多语言录音与媒体内容

多语言录音如果同时需要说话人标签、词级时间信息和非语音声音标签，ElevenLabs Scribe 很值得列入候选。 Scribe v2 文档列出 90+ 种语言，并可区分最多 32 位说话人，适合访谈档案、媒体库和通话复核应用。Scribe v2 Realtime 是独立的实时选项，功能范围也需单独确认。

设想一款媒体应用，用户上传多种语言的访谈。需要的输出不只是一个段落：界面还要支持点击词语定位、显示说话人切换，并保留笑声或掌声等声音信息。ElevenLabs 功能指南明确介绍了文件模型的这些能力。这些实际功能，才是评估 Scribe 的理由，而不只是因为它与某款语音生成产品来自同一家厂商。

当转写文字本身就是编辑或导航界面时，词级时间信息尤其有用。审核人员可以直接跳到录音中的准确位置，不必在较长片段中来回寻找。音频事件标签还能保留普通文字会遗漏的上下文。它们属于需要主动展示或过滤的元数据，不应被当作某人说过的话，直接混入搜索索引。

适合： 多语言访谈、媒体和通话录音应用。
亮点： 文件方案同时提供说话人标签、词级时间戳和音频事件标签。
价格： Scribe v2 文件转写 $0.22/音频小时起；Scribe v2 Realtime 为 $0.39/小时。
免费试用： Free/PAYG 价格表列出内含的 Scribe 用量；先核对套餐共享额度，不要默认每个模型都有独立免费额度。

最需要避免的误区是默认实时模型也有文件模型的说话人分离功能。本次比较查阅的实时功能列表与 WebSocket 参考文档，没有记载说话人标签。这意味着选型时还需确认，并非断言厂商永远不会提供。如果实时说话人归属是硬性要求，选择 Scribe Realtime 前，应要求有文档明确支持的配置。

实时 API 明确提供中间转写结果与已提交的结果。浏览器接入方面，客户端指南使用由服务器创建的一次性令牌，避免将永久 API 密钥发给浏览器。这为网页应用中的麦克风功能提供了可落地的接入起点。界面可以显示暂定文字，同时单独保存已提交的片段。

对于录音内容，文档列出的标准上传上限为 3 GB 和 10 小时。多声道模式可根据声道编号分配说话人 ID，适合原始录音已经分开记录参与者的情况。上游录音设备如果保留了这种区分，就应继续保留。先混成一条音轨，再让模型推断身份，可能会丢掉原本已经掌握的信息。

词汇相关功能要单独计价。API 价格页列出的批处理关键词提示附加费为 $0.05/小时。因此，假设处理 1,000 小时文件，基础费用为 $220，启用这一附加功能后为 $270。提供相关产品词表可能值得这笔差价，但词表应包含录音中可能出现的术语，而不是把整个产品目录的所有词都塞进去。

结论：评估 Scribe，应围绕实际会用到的录音内容功能。 它凭借多语言文件处理和实用的转写元数据进入本文候选。针对这类任务，可以从 ElevenLabs Scribe 开始，再通过上方直接链接的文档核实接入细节。

5. OpenAI：选用当前模型，同时规划说话人标签的迁移

已经使用 OpenAI API 的团队可以考虑其转写服务，前提是应用所需能力与当前模型相符。 厂商目前建议：完整录音使用 gpt-transcribe，实时传入的音频使用 gpt-live-transcribe。新接入应从这里开始。照搬旧版 Whisper 或 GPT-4o 教程，可能会把产品建在已经排定停用日期的模型上。

官方转写指南区分了文件流式输出与实时音频输入。文件请求处理的是一段完整录音，可以分批返回文字；实时会话接收的音频则还在持续到达。这个区别会影响传输方式、重试策略，以及应用何时认定转写已经完成。

如果应用只是把语音备忘转换成可搜索文字，文件方案是自然的起点。如果是实时跟随来电者发言的客服智能体，就应使用专门的实时流程。不能只因为应用中现有的某段示例代码用了某个接口，就据此选型。

适合： 已有 OpenAI 应用，需要当前的文件或实时转写，且不会默认新旧模型功能完全一致的团队。
亮点： 文件与实时分别有推荐模型，并共用提示、关键词和预期语言等上下文输入方式。
价格： 推荐文件模型估算为 $0.0045/分钟起，即 $0.27/音频小时；实时转写估算为 $1.02/小时。
免费试用： 引用的价格页未明确提供免费转写额度。

OpenAI 语音转文字怎么收费？

OpenAI 将每分钟价格标为估算费用，因此换算到小时后也必须保留这一限定。当前价格页还列出了旧款 gpt-4o-mini-transcribe 的估算价 $0.003/分钟，以及 gpt-4o-transcribe 的 $0.006/分钟，分别相当于 $0.18 和 $0.36/音频小时。这些价格有助于现有客户评估迁移，但更便宜的旧款模型不是新产品的推荐起点。

弃用公告计划于 2027 年 2 月 26 日停用 whisper-1、gpt-4o-transcribe、gpt-4o-mini-transcribe 和 gpt-4o-transcribe-diarize。当前文件指南仍在已弃用的说话人分离模型下介绍带说话人标签的输出，并提醒，更换模型 ID 并不能保留全部输出格式或元数据能力。

这会直接影响会议应用。原先带有说话人字段和时间信息的转写结果，不能在不改变产品的情况下换成普通文字。先列出数据库和界面实际使用的字段，再与替代模型的响应逐项比较。如果说话人标签不可缺少，而当前推荐方案没有文档支持，就应评估明确支持该能力的替代方案，不能把迁移当作一次字符串替换。

文件指南还规定上传上限为 25 MB。一小时录音是否需要压缩或切分，取决于编码方式。设计这一环节时，应避免分块边界悄然丢词、重复文字，或打断下游流程所依赖的上下文。只要客户能上传任意录音，文件大小限制就是产品设计需要处理的问题。

对于专用词汇，推荐模型可接收提示、明确列出的关键词和预期语言。用这些上下文说明录音背景与可能出现的术语即可；它们是提示，不是要求模型把没说过的词硬写进结果。同时，不要把 Whisper 公布的语言数量套用到新模型上：当前指南介绍了语言输入方式，但未给出统一的语言总数。

结论：选择 OpenAI，应以当前文档支持的工作流为依据，不能只因为旧转写代码还能运行。 已有接入应先盘点必需字段，再迁移流量。新产品如果高度依赖说话人信息，这份盘点可能直接指向另一家服务商。

6. Google Cloud Speech-to-Text API：适合已有云端工作流的团队

如果转写本就属于现有 Google Cloud 工作流，或者产品可以接受延后批处理，Google Cloud Speech-to-Text 就值得考虑。 Speech-to-Text V2 Standard 与 Dynamic Batch 的价格差异明显。使用 Chirp 3 还需多做一层选择：模型、API 调用方法、语言和区域，都必须与所需功能匹配。

夜间录音归档任务和实时通话助手，不能按 Google 的同一个计费项目做预算。归档可以等待音频以较低优先级处理；助手却必须立即拿到回答所需的文字。Google 价格页将 Dynamic Batch 定义为享受折扣的延后处理方案，而非低价实时接口。

适合： Google Cloud 应用、可排队处理的录音档案，以及能管理不同模型配置的团队。
亮点： V2 Standard 与 Dynamic Batch 提供不同处理方式。
价格： V2 Dynamic Batch 为 $0.003/分钟起，即 $0.18/音频小时；Standard 识别首档价格为 $0.016/分钟，即 $0.96/小时。
免费试用： 不要把价格页上的 V1 免费分钟数计入 V2 预算；账户实际可用额度应另行核对。

结果什么时候要，会直接改变 Google 的账单

假设每月处理 1,000 音频小时，按公布价格，Standard 转写费用为 $960，Dynamic Batch 为 $180。$780 的差额来自接受延后处理。对只需在后续复核周期前拿到结果的档案任务，这很有价值；但不能用批处理价格为实时客户对话做预算。存储及其他 Google Cloud 资源仍需额外付费。

说话人标签也要同样严谨地核对。Chirp 3 文档支持通过 StreamingRecognize 实时转写，但将说话人分离列为非流式功能，支持的语言范围也更窄。需要带说话人标签的档案，应遵循文档中的批处理配置。模型支持实时转写，并不意味着可以承诺同一模型支持实时说话人分离。

Google 产品页标注 Chirp 3 支持 85+ 种语言及变体。“及变体”不能忽略：厂商的计数可能包括地区语言变体，与其他厂商的语言列表口径不同。更关键的是，可用性矩阵会区分上线状态与功能支持。产品如果既需要某种地区语言，又需要说话人标签，就必须同时满足这两个条件。

主要难点在于配置组合的适用范围。需求一旦涉及多种语言、区域和处理模式，选型就不只是填入 chirp_3。应在应用配置中记录选定组合，并让不受支持的组合明确报错。否则，英语批处理演示中正常的功能，可能在客户上传另一种语言或切换到实时模式时突然缺失，且原因不明。

逐声道计费也值得注意。Google 对每个被处理的音频声道计费。将客服与来电者分开录制有助于保留角色信息，但账单也会按各声道处理时长计算。拿双声道通话档案与其他服务商的单声道示例比较之前，应先计入这一区别。

结论：周边工作流能体现价值时，再选 Google。 现有 Google Cloud 录音档案可能很适合延后处理。新建语音智能体项目则应拿标准实时配置与专业方案比较，不能只看 Dynamic Batch 的醒目低价。

7. Speechmatics：优先满足部署与实时说话人归属需求

如果需要企业本地部署，或需要实时返回带说话人归属的对话片段，Speechmatics 应进入靠前的候选位置。 本地部署意味着在自行控制的基础设施中处理数据。Speechmatics 的企业方案列出了容器、虚拟设备与混合部署。这些商业条款需询价；公有云价格并不代表私有部署报价。

选模型与选部署方式同样重要。Melia 1 是支持多语言文件与实时处理的系列，Linden 1 则用于 Agent STT 方案。模型文档说明，Linden 返回带说话人归属的片段和轮次消息。如果应用需要以对话结构同时保存文字和说话人归属，它就值得评估。

多人共用免提电话与单人听写是不同的问题。可能有人中途加入通话，也可能有背景人声与目标来电者重叠。选模型前，先确定智能体是要跟随一个人的声音、区分参与者，还是只需保留可追溯到说话人的记录。输出结构应围绕这个决定设计，而不是事后补上。

适合： 对部署环境有约束的产品，以及评估实时通话说话人归属能力的团队。
亮点： 企业私有部署选项，以及独立的 Agent STT 模型方案。
价格： Melia 1 文件处理未折扣 PAYG 价为 $0.24/音频小时起；Linden Agent STT 为 $0.30/小时；私有部署需询价。
免费试用： 价格页提供 $100 额度，无需信用卡。

价格的前提条件很容易被忽略。公开价格页可能展示已叠加模型训练与批量额度折扣的较低 Melia 价格，而计算器列出的基础 PAYG 文件价格为 $0.24/小时。选择训练折扣，就意味着允许记录、保留音频，并将其用于改进服务。这是需要单独作出的数据处理决定，不能视为同一合同条件下白得的降价。

实时功能还有两处限制。首先，Melia 实时目前不支持说话人分离，虽然支持按声道区分。声道区分利用已经分开的输入声道；说话人分离则从音频中推断不同声音。模型指南还要求客户端自行检测发言结束，并为 Melia 实时流程发送 ForceEndOfUtterance。

其次，Linden 当前的 Agent STT 页面说明，其轮次信号依赖静音检测，服务端语义轮次检测仍待推出。静音检测等待声音停顿；语义检测还会判断说话人是否已表达完整意思。两者都有用，但当来电者念编号时在中途停顿，表现会不同。

语言支持也要仔细区分。Melia 列出 56 种语言，并支持混合语言转写。Linden 页面列出 55+ 种语言，同时仍将完整多语言支持描述为即将推出。分别支持每一种语言，并不能证明同一通话内可以自由切换。多语言呼叫中心应专门验证这一场景，不能因为它与 Melia 同属一家厂商就默认行为一致。

结论：先明确必须满足的需求，再选择真正符合需求的 Speechmatics 模型。 如果实时说话人归属或部署地点排除了更简单的方案，它尤其值得评估。企业方案应明确写出模型与功能组合；笼统的“本地语音转文字”不足以判断产品是否适用。

不同任务，语音转文字 API 该怎么选？

输出要求或运行模式一变，最合适的选择就会改变。 先找出一旦不满足就会让产品失败的条件，再用自己的录音和预期费用比较剩余候选。

如果要做能自然回答的语音智能体，先看 Deepgram Flux，理由是它的轮次处理能力。如果实时说话人归属是核心需求，就把 Speechmatics Linden 放进首轮比较，并验证其基于静音的轮次行为。部署选项很重要时，可以评估 Mistral Realtime，但必须接受文档中实时轮次检测与说话人分离不能同时使用的限制。

如果处理的是多种语言的访谈录音或媒体内容，先看 ElevenLabs Scribe。它的文件说话人标签、词级时间信息和音频事件标签，能直接支撑实用的审核界面。如果 AssemblyAI Universal-2 的语言列表覆盖输入，也值得评估。只要片段级时间信息足够，并能完成对预览模型的验收，Voxtral Mini 也是合理的文件候选。

如果做的是结构化通话分析，先列出应用需要的字段。工作流需要带说话人归属的发言和可选处理时，AssemblyAI 很自然地进入候选。Deepgram Nova-3 是另一种同时提供文件与流式处理的方案。如果客服与客户已经分开录音，先保留各声道，再判断是否还需要模型推断说话人标签。

如果是 Google Cloud 上可排队处理的录音档案，就按交付时限评估 V2 Dynamic Batch。只有应用能接受延后结果，折扣才有意义。如果用户会停留在页面上等待完成，就应单独测量这种体验，不能默认把任务放入更低优先级队列后用户毫无察觉。

如果是已有的 OpenAI 应用，从当前推荐、符合处理模式的模型开始。若旧版说话人标签、字幕或其他元数据不可缺少，而替代方案未在文档中支持，就不能只图接入方便。既然已经需要迁移，正好借此检查依赖，而不是自动沿用原厂商。

如果需要本地部署处理，可将 Speechmatics、Deepgram 文档中的企业部署方案，以及 Mistral 的自行部署方案列入候选。未公开的商业条款均需询价。比较许可证之外，还要比较硬件、部署支持、可用模型和更新责任。公有云的每音频小时单价，无法直接决定这类采购。

已知谁在哪个声道，就别先混音再让模型猜

如果音频来源已将客服与来电者分开记录，请保留独立声道。 已知声道可以直接保留角色信息；混成一条音轨后，说话人分离模型只能重新推断。这是发生在选择转写服务商之前的架构决策。

设想一段通话，客服占一个声道，来电者占另一个声道。应用本来就知道各声道对应谁。如果转写前把它们合并成单条音轨，这层信息就消失了。说话人分离模型也许能把声音拆成匿名说话人，但你仍需将这些说话人重新映射到角色。

ElevenLabs 的文档说明，多声道文件模式可从声道生成说话人 ID。Deepgram、AssemblyAI 和 Google 则明确说明按声道计费。因此，产品要作出的取舍很实际：保留声道可以简化归属判断，同时也可能增加账单中的音频处理时长。比较单声道估价与生产环境的多声道处理流程时，必须计入这一区别。

会议麦克风是另一种情况。多人的声音已经混在同一条音轨，声道标签无法还原每个人。这时需要说话人分离，也需要在多人重叠发言或音色相近时复核错误。说话人归属与真实身份应保持区分：匿名标签不能仅仅因为出现在结构化 JSON 中，就被当作已经核实的客户姓名。

下游摘要也应遵循同样原则。生成摘要时，同时保留原始转写、说话人标签和音源引用。如果客户对“谁承诺了退款”提出异议，应用需要能回到相关音频，而不只是拿出一段流畅的总结。

这些推荐是怎么选出来的？

本文是基于注明日期的文档核查给出的接入建议，并非独立准确率排行榜。 价格和具体能力已于 2026 年 10 月 21 日对照厂商自己的价格页或文档核实。本文没有发起付费转写请求，也没有开展跨厂商音频基准测试。

选型围绕五个问题展开：

• 所需模型接受完整文件、实时音频，还是两者都支持？
• 所选模式是否返回产品需要的说话人标签、时间戳和轮次信号？
• 实际支持的语言及语言切换行为是否有文档说明？
• 服务能否运行在要求的部署环境中？
• 计入必需附加功能和声道数量后，所选配置需要多少钱？

本文的独立分析在于统一换算每小时费用，并逐一核对模型与处理模式的兼容性。这能揭示厂商整体功能列表容易掩盖的差异：Voxtral 的实时功能互斥、OpenAI 已弃用的元数据流程、Chirp 仅限非流式处理的说话人标签，以及 Melia 对声道区分与说话人分离的不同支持。

真正比较准确率，需要让各厂商处理相同的代表性录音，并采用相同的参考转写与评分规则。本文没有提供这样的测试。“最准确”或基准测试胜出之类表述仍是厂商自己的主张，不能据此对本文产品排出名次。

自己评估时，应从产品目标定义什么叫成功。可搜索的访谈档案也许容得下标点差异，却不能漏掉姓名。预约智能体可能每个词都识别正确，却在错误的时机打断来电者。通话复核产品可能更需要可靠的说话人归属，而不是漂亮的排版。应判断哪些行为真正改变用户结果，并在复核时将这些类别分开记录。

本文范围是这七家面向开发者的 API 服务商。面向消费者的会议和编辑产品另有文章介绍。针对某种语言或基础设施约束，其他厂商也可能值得评估；没有入选本文，不代表它们未通过准确率测试。

哪些选型组合应该避开？

即使厂商整体合适，也要避开不符合任务的具体模型。 以下是明确的采购与接入错配：

• 用 OpenAI 已弃用的 GPT-4o 转写或 Whisper API 模型，开发需要长期运行的新接入。 文档已明确停用计划，意味着迁移工作已不可避免。应采用当前模型，或评估其他服务商。
• 在同一会话必须同时使用说话人分离和轮次检测时，选择 Voxtral Mini Transcribe Realtime 3。 详细指南明确不支持这一配置。
• 用 Google Dynamic Batch 做实时交互。 较低价格对应的是延后处理，无法服务正在等待回答的来电者。
• 实时说话人标签是硬性要求，却未经确认就选择 Scribe Realtime。 必须先获得文档支持，才能把文件模型的说话人分离能力视为实时功能。
• 需要模型推断不同说话人时，选择 Speechmatics Melia 实时方案。 按声道区分是另一种能力，应评估真正适合的模型方案。

也不要只凭准确率宣传语选型。即使模型在厂商自己的评测中胜出，也可能因为缺少所需语言、时间元数据或部署模式而不适用。这些足以排除候选的条件，在试用前就能核对。

开发者常见问题

有没有免费的语音转文字 API？

可以用免费额度验证准备购买的具体配置。Deepgram 提供 $200 额度，Speechmatics 提供 $100，AssemblyAI 则公布按模型区分的免费用量。免费用量不等于无限生产容量。批量导入录音档案前，先确认账户额度覆盖哪些模型、模式和附加功能。

Python 怎么接入语音转文字 API？

先选处理模式和模型，再找 Python 示例。当前 OpenAI 文件转写的官方指南从 gpt-transcribe 开始；Mistral 的音频快速入门使用其当前 Voxtral Mini 模型。实时智能体应从厂商当前的流式快速入门入手，实现连接与轮次事件处理。不要未经核对当前文档，就沿用旧教程里的模型 ID。

接入 Google Speech-to-Text API 要注意什么？

新建 V2 接入时，先明确模型和识别方法，再检查语言与功能矩阵。Standard 识别和 Dynamic Batch 的费率与处理优先级不同。Chirp 3 支持实时转写，但文档中的说话人标签流程仅用于非流式处理。

语音转文字 API 应该怎样入门测试？

先按厂商当前的快速入门，处理一段有代表性的录音或建立一次实时会话。检查产品需要的响应字段，再加入难识别的语音、多人重叠发言和所需语言。之后再测试峰值并发，并按已确定的配置计算月度费用。

下一步：拿真正符合要求的配置做对比

下周，选出两套都能满足最难需求的配置进行比较。 实时助手可以比较 Flux 与带说话人归属功能的 Linden；多语言访谈应用可以比较 Scribe 与符合要求的 AssemblyAI 或 Voxtral 文件模型。运行录音测试之前，先写清必须返回的字段和失败场景。

保留一小组验收样本，既包含普通语音，也包含容易出问题的情况：更正日期、生僻姓名、多人重叠发言，以及客户确实会使用的语言切换。将转写错误、说话人标签错误和轮次处理失误分别记录，再按实际评估的模式、声道和必需附加功能估算费用。

选择 API 之前，先用 AI Business Workflow Audit Checklist梳理音频来源、所需输出和各环节交接。获取清单。