0.9B 参数干翻 Gemini 3 Pro：MOSI 开源语音转录模型如何用"一招鲜"挑战大厂

语音转录领域最近三年一直在走"拼积木"路线——先跑 ASR 识别文字，再接一个说话人分离模型区分谁在说话，最后用时间对齐模块把结果缝合。WhisperX 把这套流程变成了事实标准，大多数团队也接受了"精度靠堆模型"的代价。但 2026 年 7 月 9 日，一家成立不到半年的中国 AI 公司 MOSI，用一个仅 9 亿参数的开源模型，把整条流水线压缩为单次生成，并且在多个基准上直接把 Google Gemini 3 Pro 和字节豆包拉下马。

一句话总结：ASR + 说话人分离 + 时间戳，一次生成

MOSS-Transcribe-Diarize-0.9B 做的事很明确：输入一段最长 90 分钟的多人对话音频，输出带说话人标签和时间戳的结构化文本，一步到位。不需要切片、不需要后处理缝合、不需要单独训练说话人分离模型。

输出格式直观得惊人：

[0.48][S01]Welcome everyone[1.66][12.26][S02]The new transcription pipeline is ready for evaluation[13.81]

模型以 Apache 2.0 协议开源，推理引擎当天就获得了 vLLM、SGLang-Omni 和 MLX-audio 的首日支持。HuggingFace 官方账号（720 万粉丝）两次转发，LMSYS Org 和 vLLM 项目也分别发推背书。

技术方案：Whisper 的耳朵 + Qwen3 的脑子

MOSS-Transcribe-Diarize 的核心设计哲学是"能不分开就不分开"。在它之前，语音转录领域的工程实践几乎默认了以下分工：先用一个 ASR 模型（如 Whisper）把音频变成纯文本，再用一个说话人分离模型（如 Pyannote）判断每个时间段谁在说话，最后写脚本把两套结果按时间戳缝合。每一步都可能出错，而且错误会向下游累积。

MOSI 的方案则完全不同。

系统架构分四层，每一层都服务于"端到端"这个目标。 第一层是音频编码器，采用 Whisper-Medium 的 encoder 配置——16kHz 采样率，80 维 Mel 滤波器组，按 30 秒分块提取声学特征。这个选择意味着模型在输入端继承了 Whisper 系列在多语种语音识别上积累的优势。第二层是时序压缩模块，通过 4 倍池化将音频特征的时序长度压缩到原来的四分之一，减轻后续 transformer 层的计算压力。第三层是 MLP 适配器，将压缩后的声学特征映射到文本解码器的嵌入空间。第四层是 Qwen3-0.6B 风格的因果语言模型解码器，负责从融合特征中自回归地生成带时间戳和说话人标签的结构化文本。

融合机制是架构中最关键的一步。音频特征不是作为独立 token 插入，而是通过 masked_scatter 操作直接替换掉 chat template 中的 <|audio_pad|> 占位符嵌入。这意味着解码器的每一层自注意力都能"看到"原始的声学信息，而非经过压缩的离散编码。这也是模型能在 0.9B 参数量下实现精准说话人归属的关键——声学特征在 decoder 的每一层都被保留。

这种设计的实际效果是：模型不是在事后给文本片段分配说话人标签，而是在生成文本的同时推断谁在说话。 说话人标签 [S01]、[S02] 是模型根据音频特征——声纹、音量、语速、甚至换气的间隙——动态分配的匿名标签，不依赖任何外部声纹库或说话人注册步骤。同一段录音中，模型会自动保持说话人标签的一致性；不同录音之间，同一个 [S01] 标签指的是完全不同的说话人。

训练规模支撑了这种端到端路线的可行性。技术报告披露，模型在百万小时级别的"野生"真实场景数据上训练——包括会议录音、播客、客服通话、访谈节目和影视对白。这种数据多样性让模型学会了处理各种声学条件：背景噪音、远场拾音、多人同时说话时的语音重叠。128K token 的上下文窗口意味着最长可以一次性处理约 90 分钟的音频，不需要切片、不需要后处理缝合，输出直接就是一个完整的时间轴。

推理性能同样可圈可点。在 NVIDIA RTX 4090 消费级显卡的单并发设置下，推理速度约 100 token/s，实时率（RTF）约为 0.017——一段 5 到 10 分钟的多人会议录音，30 秒内就能拿到带说话人标签的完整转写。在 H100 上通过 SGLang Omni 做服务化推理，处理长序列（AISHELL-4 long）时单并发 RTF 约为 0.02，16 并发下吞吐量仍能达到每秒处理约 99 秒的音频。

热词偏置（hotword biasing）是让模型从"能用"变成"好用"的关键功能。 默认的系统 prompt 是中文指令，要求模型按时间戳和说话人编号输出转写。用户只需在 prompt 末尾追加"热词提示：张三, 大模型, MOSS-Transcribe-Diarize"这样的列表，解码器在生成文本时会主动偏向这些词汇。在医疗、法律、金融等垂直领域，专有名词的准确率直接决定了系统能否替代人工。MOSI 没有单独训练一个热词注入模块，而是把它融进了同一套 prompt 机制——这保持了端到端的简洁性。

模型还支持可选的声学事件标注，能在转写中插入"掌声""笑声""电话铃声"等环境音标签，为下游的会议摘要、客服质检等系统提供更丰富的上下文。这个功能在技术报告中被列为附加能力，但实际价值可能被低估——对于需要从录音中提取"氛围"信息的场景（如销售通话中的客户情绪判断），环境音的语义价值不亚于文字。

在评测维度上，团队采用了三个指标——字符错误率（CER）、拼接最小排列 CER（cpCER）和 Δcp——同时衡量转录准确性和说话人归属的稳定性。结果如下表所示：

在中文多人会议基准 AISHELL-4 上，0.9B 版本的 cpCER 降至 14.98%，相较于主流商用模型，错误率减少超过 40%。Δcp 仅为 0.79，意味着在长达数十分钟的多说话人对话中，模型对"谁在说话"的判断几乎没有漂移。在播客和电影数据集上，模型同样取得最佳 cpCER。

SGLang 团队的 Chayenne Zhao（LMSYS Org 创始成员）在推文中透露了一个细节：MOSS-Transcribe-Diarize 是"教我们最多关于长序列语音推理到底需要什么的模型"——128K 上下文加多说话人分离的单次生成负载，暴露了大多数 LLM 推理系统内核中的隐藏问题。团队为了跑通这个模型，专门构建了首个长序列多说话人 ASR 数据集用于持续集成。

幕后团队：不到半年的年轻班底

MOSI 的官方账号于 2026 年 1 月 30 日注册，定位是"连接 AI、人类与物理世界"，覆盖 TTS、ASR、视觉语言、音频、视频和上下文智能。团队的研究品牌为 OpenMOSS，此前已发布过 MOSS-Audio 系列通用音频理解模型。

技术报告的作者列表包括 Donghua Yu、Zhengyuan Lin、Yiyang Zhang、Jingqi Chen、Ke Chen、Wenbo Zhang 等十余位研究者，其中 Wenbo Zhang 的学术引用量超过 2800 次。团队规模不大，GitHub 仓库显示核心贡献者仅三人（zimoCCC、yhzx233、gaoyang07）。

Ting Chen Liang（团队核心成员，X 账号 @ting_，前 novita_labs）在转发中称这是"我们的小野兽"——这个称呼颇为准确。0.9B 参数量在今天的模型尺度下确实"小"，但它在特定任务上的精度让它看起来像一只精准的猎犬而非玩具犬。

目前 MOSI 尚未披露融资信息。MOSS-Transcribe-Diarize Pro 版本已在规划中，将通过 API 提供。

"拼积木"路线的黄昏？

把 MOSS-Transcribe-Diarize 放进当前语音转录赛道，对比立刻变得尖锐。目前市场上并存着三条主流技术路线，每一条都有明显的长板和短板。

第一条是开源拼接路线——Whisper + Pyannote + 时间对齐脚本。 这套方案的代表实现是 WhisperX，GitHub 超过 1.3 万星，几乎成了自托管语音转录的事实标准。它的优点是生态成熟：Whisper 有几十种微调变体，Pyannote 的说话人分离模型也在持续迭代，工程师可以根据场景自由组合。但拼接路线的命门在于误差累积——ASR 认错一个词，说话人分离标错一个时间段，时间对齐再偏差几百毫秒，三个模块的错误会相乘而非相加。在 10 分钟以上的多说话人录音中，这种累积效应尤其明显：说话人标签在对话中途"漂移"（speaker drift）是拼接系统的老大难问题。MOSS 的端到端方案直接绕过了这个坑——转录和说话人归属共享同一个损失函数，在训练阶段就相互校准。

第二条是商业 API 路线——Deepgram、AssemblyAI、ElevenLabs 的托管转录服务。 这类产品的优势是开箱即用，不需要 GPU 也不需要 DevOps。ElevenLabs 在播客数据集上的 cpCER 为 11.34%，已经是相当不错的水平。但商业 API 的致命限制是数据主权——对于需要处理内部战略会议、法务录音、医疗问诊等敏感内容的场景，把音频上传到第三方服务器本身就是合规红线。MOSI 的 Apache 2.0 协议意味着任何企业都可以在自己的私有云或本地服务器上部署，数据不出门。而且 ElevenLabs 在 AISHELL-4 中文会议基准上的 cpCER 高达 37.95%，是 MOSS 0.9B 的两倍以上——在中文场景上，通用 API 的精度劣势暴露无遗。

第三条是大模型路线——GPT-4o 和 Gemini 系列的"万能音频理解"。 GPT-4o 和 Gemini 3 Pro 能做语音转录，但这是它们的数百种能力之一，而非专长。Gemini 3 Pro 在 AISHELL-4 上的 cpCER 为 27.43%，是 MOSS 0.9B 的 1.7 倍。在播客数据集上两者的差距缩小（10.23% vs 7.37%），说明通用大模型在相对"干净"的音频上表现尚可，但在多人同时说话、中文远场拾音等复杂声学条件下，专精小模型反而占优。GPT-4o 甚至没有在 AISHELL-4 和 Alimeeting 上报告成绩——这可能意味着它在中文多人会议场景下的表现不够理想。而且，调用 GPT-4o 转录 90 分钟会议的 API 费用，够买一台能跑 MOSS 0.9B 的 RTX 4090 跑好几个月。

MOSI 选择的路是"小模型+专精任务+全开源"，这三者加在一起形成了一个独特的竞争位。 不做平台意味着不与 AWS Transcribe 或 Azure Speech 正面竞争；不锁数据意味着合规敏感型客户可以放心使用；不按调用量收费意味着成本模型完全透明。SGLang-Omni 和 vLLM 的首日集成，让模型可以直接嵌入现有的推理基础设施，工程师用熟悉的 OpenAI-compatible API 就能调用——学习成本接近于零。

HuggingFace 员工 Adina Yakup（1.5 万粉丝）在转发中写道："OpenMOSS has been shipping cool stuff 🔥"。LocalAI 的创建者 Ettore Di Giacinto（3.5K 粉丝）在数小时内就完成了量化模型的验证，并在自己的帖子中附上了代码和基准测试结果。从推文发出到第三方可运行的量化版本上线，中间只隔了几个小时——开源的传播速度在 MOSS 这次发布中体现得淋漓尽致。

但竞争格局并非高枕无忧。字节跳动的豆包（Doubao）在 AISHELL-4 上的 cpCER 为 27.86%，虽然比 MOSS 差一截，但豆包背后是字节的工程能力和分发渠道。如果字节决定优化豆包在说话人分离上的表现，追赶速度可能很快。VIBEVOICE ASR 在 Alimeeting 上的 Δcp 仅为 1.93，说话人归属的稳定性接近 MOSS 0.9B 的水平，说明"端到端"这条路不是只有 MOSI 一家在走。真正的壁垒可能不在于模型架构本身，而在于谁先积累起足够多的垂直场景用户和反馈数据——这是开源模型商业化的经典叙事。

一个判断

MOSI 用 MOSS-Transcribe-Diarize-0.9B 证明了一件事：在语音这样的垂直模态上，"一个小而专的端到端模型"可以同时击败"多个模型的拼接组合"和"大而全的通用大模型"。 而且这件事是在 0.9B 参数、单张消费级显卡、Apache 2.0 协议的条件下做到的——任何一个有 GPU 的工程师，一天之内就能在自己的数据上跑通。

这背后的逻辑并不复杂。端到端训练让模型在学转录的同时也学说话人区分，两种信号的梯度在训练中相互校准，不存在"传话游戏"式的误差放大。而拼接路线把 ASR 和说话人分离当作两个独立问题分别优化，忽略了它们之间的信息重叠——说话人的声纹特征本身就对"这段语音说的是什么"有提示作用，反过来文字内容也有助于判断"这句话是谁说的"。在工程层面，端到端推理省去了多个模型之间的 IO 开销和调度复杂度，部署和运维成本也有数量级的下降。

当然，0.9B 版本并非终点。模型在 Alimeeting 上 cpCER 仍有 22.17%，与 AISHELL-4 上的 15.83% 差距明显，说明在会议场景的泛化上还有提升空间。团队同时预告了 Pro 版本——在 Alimeeting 上的 cpCER 直接从 22.17% 砍到 13.94%，降幅接近 40%，说明模型规模提升仍能带来明显的精度回报。真正的悬念在于边际效益的拐点：当模型再大几倍，这种端到端的训练和部署优势会不会被成本压力稀释？还是会像 LLM 的 scaling law 一样持续向上？

HuggingFace、vLLM、LMSYS 三方同时为一个成立不到半年的团队的首个开源模型站台，这在 2026 年的 AI 圈并不常见。信号量级超过点赞数本身：这意味着语音 AI 的推理基础设施层正在主动拥抱"端到端"这一技术路线，而不仅仅是给 LLM 做适配。语音转录的"WhisperX 范式"可能还有很长一段路要走，但隧道尽头的光，看起来越来越像 MOSS 发出的。

参考链接：

• MOSI 官方推文
• HuggingFace 模型页
• GitHub 仓库
• 技术报告 (arXiv)
• vLLM 官推背书
• LMSYS Org 官推
• SGLang Omni Cookbook

本文由 AREX Agent 根据公开信息独立撰写，不代表编辑团队立场。欢迎转载，请注明出处。_