语音模型

2.3% 的错词率，只激活 4.6B 参数：Salesforce 开源了最好的语音转写模型，但它不会中文

2026年11月13日1 次阅读
2.3% 的错词率，只激活 4.6B 参数：Salesforce 开源了最好的语音转写模型，但它不会中文

音频模型动态 · 2026-11-12

语音模型开源SalesforceASR

3分钟看懂

先讲结论：Salesforce 在 11 月 12 日放出了一个叫 SOV-Transcribe-1 的语音转写模型，权重挂在 Hugging Face 上，许可证是 Apache 2.0，可以商用。它在 Artificial Analysis 的语音识别榜上拿到 2.3% 的词错率，是开源模型里的第一名，把 Mistral 的 Voxtral Small 和英伟达的 Nemotron 3.5 Transcribe（都是 2.8%）压在后面；放到全部 44 个模型里（包括不给权重的闭源模型），它排第 7。

第二句：它不是「更大的 Whisper」，而是一个语音增强的语言模型——用 Whisper large-v3 当耳朵，用 Gemma 4 的 26B MoE 当脑子，所以你能用一句人话指挥它怎么转写：要逐字稿就说「逐字稿」，要清洗稿就说「去掉口头语、数字写成阿拉伯数字」。

第三句：它只支持 7 种语言（英、法、德、西、意、葡、荷），没有中文，而且是非流式的——一整段录音进去，一整段文字出来，做不了实时字幕和电话打断。这不是一个能立刻替掉你现有中文转写方案的东西。

它到底做了什么

按官方模型卡的口径，SOV-Transcribe-1 的结构是三段：

  • 耳朵：Whisper large-v3 的音频编码器，输入 16 kHz 单声道音频。
  • 接口：一个音频投影层，把音频特征每 4 帧压成一个 token，塞进语言模型的输入序列。
  • 脑子：Gemma 4 26B A4B 的 MoE 解码器，总参数 26.6B、每次只激活 4.6B（含音频编码器），BF16 精度，MoE 路由层保持 FP32。

它对外承诺四个能力：关键词纠偏（给一串人名、药名、专有名词，让它往这些词上靠）、风格控制（逐字/清洗、标点、大小写、数字格式）、抗口音抗噪声、以及对邮箱、电话、单号这类「实体」的准确率。

这几个能力里，最后一个是它真正的卖点。官方在博客里讲得很直白：一段看起来 95% 正确的转写，只要漏掉邮箱里的一个下划线、或者把账号里的两个数字调换，下游的工具调用就会失败、数据库字段就会写错。所以他们专门用了 BeSimple 的 VoiceCodeBench 来测「关键实体有没有全对」——SOV-Transcribe-1 的整段通过率是 76.3%，实体召回 93.4%，在开源模型里第一、23 个系统里第二。

为什么一家 CRM 公司能拿第一

Salesforce 不是模型公司，它的语音团队挂在 Missionforce Sovereign AI 这条线下——2025 年 9 月成立，主打政府和国家安全客户，核心卖点是「数据不出你自己的机房」。开源权重对这条线是顺理成章的一步：客户下载回去，在自己的 GPU 上跑，音频不用上传给任何云服务。

这也解释了它为什么强调「非流式」。政企和客服场景里最常见的需求不是实时字幕，而是事后把一通电话、一场会议、一段取证录音完整、准确地落成文字。这个场景对延迟不敏感，对实体准确率极度敏感。

需要说清楚的是，榜单数字来自 Artificial Analysis 的独立测评，本文的评测口径与分项数据基于该机构的公开结果以及多家媒体转述整理，Salesforce 官方博客引用的是同一组数字；官方技术报告在发布时仍标注为「即将发布」。

数字怎么看

总榜：AA-WER 2.3%，开源第一，44 个模型中第 7。这个 2.3% 是三项英文测试按 50% / 25% / 25% 加权出来的（语音 Agent 对话 AA-AgentTalk、欧洲议会语音 VoxPopuli、上市公司财报电话 Earnings22），不是「所有语言、所有录音条件下每 100 个词错 2.3 个」。

分项：

  • Earnings22（财报电话，专业术语密集）：4.1%，Voxtral Small 是 4.8%。
  • VoxPopuli（议会发言）：1.5%，Voxtral Small 是 1.8%。
  • AA-AgentTalk（语音 Agent 对话）：1.8%，和 Nemotron 3.5 Transcribe 打平。
  • AppTek 客服对话（14 种英语口音）：平均 8.21% 错词率，在其中 8 种口音上最低（澳、英、苏格兰、威尔士、爱尔兰、印度、墨西哥、新加坡）。
  • HALAS（真实财报电话里最容易出现「幻觉词」的那部分）：25.69%，比 Qwen3-ASR 1.7B（26.01%）、Voxtral Small 24B（27.35%）、Nemotron 3.5（31.59%）、Granite Speech 5.0 2B（34.51%）都低。
  • 风格控制（Preference-ASR）：带指令时 5.05% 的偏好感知错词率，仅次于 IBM Granite Speech 5.0 2B 的 4.70%，好于 Qwen3-ASR 的 5.96% 和 Nemotron 的 6.16%。

关键词纠偏：在 Contextual Earnings-22 上，只给这段音频里真正出现的关键词，关键词 F1 从 71.9 拉到 96.8；把整场一小时会议的全部关键词（大部分是干扰项）都塞进去，仍有 94.0，是开源模型里最高的。这条比总榜分数更有实用价值——它说明「把客户名单丢给模型」这个动作是真的有用，而不是心理安慰。

还有一处官方自己没对齐：博客正文写「4 billion active parameters（26 billion total）」，模型卡的表格写「26.6B total（4.6B active）」。以模型卡和 HF 仓库的元数据为准。

怎么用

权重是公开的，不需要申请。两种跑法：

  1. vLLM（官方推荐）。仓库里带了一个 vllm_plugin/，装上后 vLLM 0.32.0 可以原生加载，也可以直接起一个 OpenAI 兼容的转写服务：
vllm serve salesforce-sovereign-intelligence/SOV-Transcribe-1 --max-model-len 32768
curl http://localhost:8000/v1/audio/transcriptions -F model=salesforce-sovereign-intelligence/SOV-Transcribe-1 -F [email protected] -F temperature=0
  1. Transformers。需要 transformers>=5.19,<5.23，用 AutoModelForMultimodalLM + AutoProcessor，trust_remote_code=True，一次可以批量喂多条录音。

想要更快，再挂一个 DFlash 草稿模型（SOV-Transcribe-1-DFlash，单独一个仓库），投机解码一次猜 15 个 token 让主模型校验，单请求能快 2–3 倍；10 秒以内的短音频收益不明显。

给提示词是最容易被忽略的一步。官方给的四个模板，直接抄：

  • 逐字稿：Transcribe the audio verbatim, outputting only spoken words in sequence.
  • 带关键词：This audio may contain the following words or phrases: {keywords}. Transcribe the audio into text.
  • 自动判语言：Transcribe the audio verbatim in the language's standard writing system, using punctuation and capitalization. Output only the transcript.
  • 指定语言：Transcribe the {language} audio into text, ensuring all punctuation marks are included.

采样参数用贪心：temperature=0、top_p=1.0、top_k=0、repetition_penalty=1.0。音频必须 16 kHz 单声道，单条最长 30 分钟（官方测试过的上限）。

适用场景

  • 会议与访谈的长录音转写：一次 30 分钟，带标点和大小写，输出可直接进文档。
  • 客服与销售通话质检：14 种英语口音的平均错词率 8.21%，且能把客户名、订单号这类实体单独盯住。
  • 语音 Agent 的「事后审计」：Agent 说了什么、用户说了什么，落成一份可核对的文本。
  • 数据不能出内网的机构：医院、律所、政府项目，权重下载到自有 GPU，全程离线。
  • 需要多种输出格式的团队：同一段音频，一份逐字稿给法务，一份清洗稿给产品文档，不用跑两个模型。

不适用场景

  • 中文、日文、韩文：官方只列了 7 种拉丁/日耳曼/罗曼语系语言，中文完全不在列表里。做中文转写现在就不用考虑它。
  • 实时字幕、实时会议：非流式，必须等整段音频结束。要边说边出字，得看流式方案。
  • 电话机器人打断：同上，它没有增量输出，做不了「用户一插话就停」。
  • 超长音频一次性灌入：30 分钟是测试过的上限，更长的要按语音边界切开再拼。
  • 想按分钟付费、不想碰 GPU 的团队：官方没给 API 价目，这是自托管模型，成本就是你的显卡。

避坑

  • 先设 --max-num-seqs 64。官方明确写了：挂上 DFlash 草稿模型后，vLLM 默认的 1024 并发会让 96GB 显卡在启动显存分析阶段就 OOM。
  • 权重占多少显存心里要有数：26.6B 参数 BF16，光权重就约 53GB，加上 KV cache 和 30 分钟音频的激活，96GB 卡才跑得舒服。24GB 消费卡不用试。
  • 它会「卡带」。官方 Best Practices 里承认：极少数情况下模型会一直重复某个字或短语直到 token 上限。官方自己是用一段后处理（改编自 Qwen3-ASR 的工具包）清掉的，你也要准备这一步。
  • 长录音要留足输出 token（示例里是 8192），并检查结尾有没有被截断。
  • vLLM 的转写端点默认只吃 600 秒音频，要跑满 30 分钟得把 VLLM_MAX_AUDIO_DECODE_DURATION_S 调到 1800。
  • 别把「Speed Factor 60×」读成「比别的模型快 60 倍」。它是「音频时长 ÷ 处理时长」的倍数，约等于 1 秒转完 1 分钟音频；韩媒 TokenPost 专门澄清过这一点。
  • 许可证是 Apache 2.0，但底座不是：它的底座是 Gemma 4 26B A4B 和 Whisper large-v3，商用前建议自己把两边的条款过一遍，别只看仓库首页那个 Apache 2.0 标签。

成本和时间

  • 软件成本：0。权重、代码、vLLM 插件全公开，Apache 2.0。
  • 硬件成本：官方所有性能数字都测在一张 NVIDIA RTX PRO 6000 Blackwell（96GB） 上。单请求、BF16、贪心解码：10 秒音频 0.16 秒（带草稿 0.09 秒），30 秒 0.44 秒（0.15 秒），60 秒 0.88 秒（0.31 秒），1–5 分钟 2.78 秒（1.26 秒）。
  • 吞吐：起成服务后，单卡每秒可处理 1039 秒音频（带 DFlash），一条 30 秒录音 0.22 秒返回。换算下来一张卡一天理论上是几万小时的音频，实际会被并发和长音频拉低。
  • 上手时间：装 vLLM 插件 + 下权重（约 53GB），网络好的话一小时内能跑通第一条；要接进业务系统，留一天做切分、后处理和实体校验。
  • 没有 API 定价：官方没公布托管端点价格，所以也没法跟 ElevenLabs、Deepgram 这类按分钟计费的服务直接比价。真要算，就按你本地 GPU 的小时成本除以吞吐。

行动建议

第一步，别先看总榜，先测你自己的实体。挑 20 条真实录音（会议、客服、访谈都行），把里面的人名、公司名、订单号、邮箱列成关键词表，跑两遍：一遍不给关键词，一遍喂关键词，然后只统计「实体全对」的比例。这个数字才决定它能不能进你的生产流程——总榜 2.3% 和你业务里的关键字段准确率，经常是两件事。

第二步再决定要不要挂 DFlash、要不要把 30 分钟切短、要不要为长音频加一层重复检测。

如果你做的是中文业务，这一步可以跳过：等它支持中文再说。

参考来源

以下为本文核验所用的一手与第三方来源，按发布时间在近 72 小时窗口内。

评论

0 条已公开
登录或注册后可以参与评论。

正在加载评论...