Salesforce 的 SOV-Transcribe-1 在开源权重批量转写中领先，但它不能流式输出，嘈杂音频仍经常出错

2026 年 11 月 12 日，Salesforce 的 Sovereign Intelligence 团队发布了 Apache 2.0 许可的语音模型 SOV-Transcribe-1，并在 Hugging Face 上同时放了博客和模型卡。标题数字是：截至当天，它在 Artificial Analysis 的非流式语音转写评测中排开源权重第一、总榜第七，该机构的字错误率指数为 2.28%。非流式，也叫批量转写，指的是模型针对的是已经录完的音频，而不是在人还没说完时就往外吐字。

这个区别比名次更要紧。博客宣传的是"真实场景语音"，以及一个看起来很好看的 40 亿活跃参数规模。模型卡写得更精确：总参数 266 亿，其中活跃 46 亿，把音频编码器也算在内。在混合专家模型里，每一次输入只会点燃网络的一部分，但要跑起来，你仍然得把全部 266 亿参数装进机器。Salesforce 自己的部署说明里，推荐的带草稿模型的 vLLM 配置，是按 96 GB 这一档的 GPU 来写的。

这是一个带语音能力的语言模型，而不是单独的语音编码器。模型卡的结构是：Whisper large-v3 音频编码器、一个音频投影层，再加上 Google 的 Gemma 4 26B A4B 混合专家语言模型。音频按 16 kHz 输入，也可以附带文本指令和一段短上下文。支持的语言是英语、法语、德语、西班牙语、意大利语、葡萄牙语和荷兰语。Salesforce 说测过的最长音频是 30 分钟。默认的 vLLM 转写接口除非改配置，单次请求只接受 600 秒，也就是 10 分钟，不是 30 分钟。

vLLM 和 Hugging Face Transformers 的原生支持仍在向上游合入。在此之前，仓库提供面向 vLLM 0.32.0 的插件，以及给 Transformers 用的建模代码。Salesforce 建议用贪心解码。它也警告：模型偶尔会把一个字符或短语重复到触及长度上限，需要用从 Qwen3-ASR 工具集改来的后处理步骤把这些循环去掉。

服务速度是厂商在一块 96 GB 显存的 NVIDIA RTX PRO 6000 Blackwell GPU 上测的。配合一次提议 15 个词元、供主模型核对的 DFlash 草稿模型，Salesforce 给出的平均耗时是：不超过 10 秒的片段 0.09 秒，10 到 30 秒 0.15 秒，30 到 60 秒 0.31 秒，1 到 5 分钟的录音 1.26 秒，且都是一次只处理一条请求。另一条更晚的说明，测自 2026 年 11 月带原生支持的 vLLM 开发版：同样一块 GPU，在 BF16 并开启草稿时，每秒最多能转写 1039 秒音频，30 秒录音的转写结果 0.22 秒返回。这些都是离线吞吐数字，不是实时字幕的延迟故事。模型卡还写明，vLLM 默认的 1024 路并发在启用草稿时会显存不足；把并发上限设为 64，启动时的显存分析才能落在 96 GB 的卡上。

准确率方面，博客把 SOV-Transcribe-1 放在 Artificial Analysis 字错误率指数的 2.28%，高于活跃参数数量相近的 NVIDIA Nemotron 3.5 Transcribe 的 2.81%，也高于博客对照里活跃参数为 240 亿的 Mistral Voxtral Small 的 2.77%。博客还说，相近规模的其他开源权重模型大约在 4%。我没有独立重跑 Artificial Analysis 的指数。这个名次应读作 Salesforce 在转述一个第三方榜单，时间截至 2026 年 11 月 12 日。

更有辨识度的，不是干净语音上的平均字错误率，而是实体、指令和上下文。

VoiceCodeBench 被博客标明为 BeSimple 的私有榜。一条录音只有在其中每个目标实体都正确时才算成功，同时再统计这些实体被找回的比例。Salesforce 给出的数字是任务成功率 76.3%、实体回收率 93.4%，在开源权重里第一，在全部 23 套系统里两项都是第二。因为榜单是私有的，这些数字无法像公开的 Artificial Analysis 页面那样被核对。

在 AppTek 呼叫中心对话这套覆盖 14 种英语口音的长音频上，博客给出的平均字错误率是 8.21%，并在其中 8 种口音上最低：澳大利亚、英国、苏格兰、威尔士、爱尔兰、印度、墨西哥和新加坡英语。

HALAS 是一套人工标注的真实财报电话音频，专门挑模型容易凭空造词的片段。SOV-Transcribe-1 的字错误率被报为 25.69%，只略优于阿里巴巴 Qwen3-ASR 1.7B 的 26.01%，对 Voxtral Small 24B 的 27.35%、Nemotron 3.5 Transcribe 的 31.59%，以及 IBM Granite Speech 5.0 2B 的 34.51% 领先更明显。但 25.69% 的字错误率，仍然意味着大约每四个词里有一个是错的。如果所谓"真实场景"指的是嘈杂的财报电话，这个数字支撑不起很强的稳健性宣传。

风格控制靠指令。模型默认逐字转写，也可以用普通语言要求它把数字写成阿拉伯数字，或去掉口头禅。Preference-ASR 衡量转写是否遵循指定格式。带指令时，Salesforce 给出的偏好感知字错误率是 5.05%，次于 Granite Speech 5.0 2B 的 4.70%。在 Contextual Earnings-22 上，把一段 15 秒片段里实际说到的关键词交给模型，关键词 F1 从 71.9 升到 96.8；即便把长达一小时的电话里全部关键词都给它，其中大多数是干扰项，分数仍是 94.0，为博客表格里开源权重模型中最高。

因此，和"开源权重第一"这行字一起走的，应是这些具体限定。

这个模型不能做流式转写。若语音代理必须在对方还在说话时就显示文字，仍然需要另一套系统，或尚未发布的流式版本。46 亿活跃参数的那张图，只有在你已经准备好 266 亿参数混合专家模型的显存和磁盘占用时，才是一个关于每个词元算力的故事。这个模型建立在 Gemma 4 和 Whisper large-v3 之上。Salesforce 自己的 vLLM 说明，把推荐的草稿配置指向 96 GB 这一档的卡。这是数据中心或高端工作站的成本，不是笔记本电脑的成本。

包括 VoiceCodeBench、AppTek、HALAS、Preference-ASR 和 Contextual Earnings-22 在内，不少最常被拿来宣传的分数，都是 Salesforce 自己报告的，而不是我从独立页面复现的。VoiceCodeBench 被明确写成私有榜。即便采用 Salesforce 的数字，HALAS 也说明，嘈杂的金融音频对比较里的每个开源模型都很难，它与 Qwen3-ASR 1.7B 只差 0.32 个百分点。模型卡还记录了一种需要在解码后额外清理的故障：重复循环。

公平的反驳是：干净语音上的平均字错误率，本来就不是判断企业转写好坏的好办法。Salesforce 在测量的，是真正会把下游软件弄坏的东西：一个邮箱地址、一个电话号码、一个药品名、一种被要求的数字写法。如果 Artificial Analysis 的名次站得住，SOV-Transcribe-1 就是离线、英语为主的批量转写里，开源权重模型要追赶的对象，而且许可是 Apache 2.0，公司可以把它跑在自己控制的机器上。对不能把通话音频送到一家美国接口的医院、银行和公共机构，这才是产品。用指令控制格式、再用关键词提示难词，也是对"整段大致对、但账号写错了"这种常见麻烦的务实回应。

同样公平的是：在 Salesforce 所用的硬件上，一个 266 亿参数的模型能在约 1 秒内完成 5 分钟录音，对许多离线队列已经够快。它的限制在于被设计来做的那类工作，而不是没达到一个它从未声称过的速度目标。

接下来六个月，要看的是 Artificial Analysis 的公开非流式指数里，SOV-Transcribe-1 是否仍领先 Nemotron 3.5 Transcribe 和 Voxtral Small，以及是否有人发布一套可独立核验、而不是私有榜的实体测试。也要看 Salesforce 或竞争对手会不会推出实体和指令控制能力相近的开源权重流式模型，以及 Salesforce 之外的团队，能否在同一档 GPU 上、不依赖尚未合入上游的 vLLM 路径，跑出接近所报速度的 266 亿参数堆栈。如果 HALAS 这类音频的字错误率仍靠近 26%，诚实的用途就是有人把关的听写和通话录音，而不是对嘈杂财经语音放手不管的自动稿。