导读MOSS-Transcribe-Diarize 0.9B 把文字识别、匿名说话人标签和时间戳放进一次生成；在作者评测中，CER 与 cpCER 的差距也较小。但它能否替代传统 ASR 流水线，不能只看参数量和普通识别错误率，还要核对说话人指标、长音频条件、部署后端与流式边界。
多人转写最麻烦的，不只是错别字
一段会议录音转成文字后，真正让人头疼的经常不是某个词识别错了，而是整段话被归到了错误的说话人标签下。
普通自动语音识别（Automatic Speech Recognition，ASR）主要回答“说了什么”。多人会议还要回答两个问题：这句话属于哪位说话人，以及它从什么时候开始、什么时候结束。前一个问题对应说话人日志（Speaker Diarization）：它给时间轴上的语音片段分配匿名标签，如 S01、S02；这与把混合声音拆成多条独立音轨的说话人分离（Speaker Separation）不是同一任务，也不等于直接识别真实姓名。
传统系统往往把任务拆成几步：ASR 生成文字，说话人模块判断每段属于谁，再由对齐模块补上时间边界。模块化的好处是每一步都能单独替换、调试和人工修订，但交接处也会传播错误。
比如两个人同时说话时，说话人边界先偏了半秒，后面的文字就可能被分给错误的人；长录音被切成多个片段后，同一个人在前半段叫 S01，后半段又可能变成 S03。最终文本看起来很完整，会议结论的责任人却错了。
所以，判断一个多人转写模型是否可用，至少要算三本账：
文字账：内容本身识别得准不准；
归属账：文字有没有还给正确的说话人；
工程账：长音频、显存、延迟和修订流程能不能满足真实使用条件。
只看模型有多少参数，三本账一本也算不清。
MOSS 0.9B 改变的是任务接口
2026 年 7 月 9 日，OpenMOSS 开源了 MOSS-Transcribe-Diarize 0.9B。它面向 Speaker-Attributed, Time-Stamped Transcription（SATS），也就是“带说话人归属和时间戳的转写”。
与显式串联多个系统不同，它接收音频后，在一次自回归生成中直接输出这样的序列：
这里，时间戳、说话人编号和文字不是三个独立文件，而是同一个输出序列里的 token。模型使用音频编码器提取语音特征，再把这些特征映射到文本大模型的特征空间，由自回归 SpeechLLM 联合生成结果。
图片说明：音频经过编码后进入自回归 SpeechLLM，输出序列同时包含起止时间、匿名说话人标签和转写文本。 图片来源：MOSS Transcribe Diarize 技术报告 Figure 2
这套设计真正减少的是模块之间的显式交接。模型可以在同一上下文里联合利用文字、声学特征和前后说话轮次，不必等 ASR 完成后再猜“这句话属于谁”。
但“一个模型一次输出”不等于错误消失了。过去，错误可能发生在 ASR、说话人日志或对齐模块；现在，它们更多地耦合在同一次生成里。优点是能够联合优化，代价是出了问题后不一定还能准确定位该改哪一个模块。
这也是端到端路线和传统流水线之间最重要的取舍：前者压缩了系统边界，后者保留了可拆解、可替换的工程边界。
CER 很低，仍可能把话分给错误的人
普通 ASR 常用字符错误率（Character Error Rate，CER）衡量转写文本与标准答案之间需要多少次插入、删除和替换。它不关心说话人身份。
多人转写还要看 cpCER，即 concatenated minimum-permutation CER。它先寻找预测说话人标签与真实说话人的最佳对应关系，再比较每个说话人的拼接文本。这样，“模型把真实的张三叫作 S02”不会被当成错误，但张三的话被分给李四仍会体现在指标里。
技术报告还给出 Δcp：
它用于观察加入说话人归属后，指标相对普通文本识别发生了多大变化。
在作者的 AISHELL-4 会议数据评测中，MOSS 0.9B 的 CER 为 14.84%，cpCER 为 15.83%，Δcp 为 0.99%；在 Podcast 数据上，三项分别为 5.97%、7.37% 和 1.40%。在作者设定的比较协议中，这说明额外加入说话人归属后，编辑距离增加得较少。
图片说明：图中 Ours 指 MOSS-Transcribe-Diarize 0.9B，三项指标均为越低越好；GPT-4o 因音频输入长度限制未参与该组评测，空缺不能解释为模型得分。 图片来源：MOSS Transcribe Diarize 技术报告 Table 2（AISHELL-4 局部）
不过，Δcp 不能被机械理解为一个独立、必然为正的“说话人错误率”。报告的 Alimeeting 结果甚至出现了 -2.69。原因在于 CER 与 cpCER 使用的文本拼接和最优匹配方式不同，它更适合作为诊断信号，而不是对说话人能力的完整体检。
如果要决定系统能否上线，我还会补看三类结果：
说话人数量是否估对：把两个人合成一个，或者把一个人拆成多个标签，都会影响可用性；
边界与重叠语音是否可靠：抢话、插话和短促回应最容易让责任归属错位；
长距离身份是否稳定：某位说话人沉默二十分钟后再次出现，标签能否保持一致。
换句话说，CER 回答的是“字对不对”，cpCER 更接近“这些字有没有分对人”。真实会议系统两项都不能省。
128K 和 90 分钟，解决的不是实时问题
MOSS 0.9B 的另一个醒目指标是 128K 上下文，官方资料称单次可处理最长约 90 分钟音频。它的工程意义很明确：在覆盖范围内，模型可以看到整段录音，为减少切片后的说话人标签漂移和上下文断裂提供条件。
但这里有三个边界。
第一，支持最长约 90 分钟不是对任意 90 分钟录音的稳定性承诺。说话人数、语速、重叠比例、背景噪声和输出长度都会改变推理负担。上线前仍要用自己的会议分布测试，而不是只上传一段干净样例。
第二，长上下文不等于低显存。官方仓库建议优先使用高效注意力后端，并明确提醒 eager attention 的内存使用会随长序列快速增长，长录音可能直接显存不足。长音频还需要相应调高 max_new_tokens，否则模型可能不是“没听懂”，而是输出额度用完后被截断。
第三，整段长音频离线处理不等于实时流式字幕。技术报告把 streaming SATS 列为后续工作。官方仓库虽然提供 OpenAI 兼容的转写接口，但接口形式与模型是否能持续接收音频、低延迟更新字幕、稳定修订之前的说话人标签，并不是一回事。
如果场景是会后生成纪要，整段上下文可能非常有价值；如果要在会议进行时出字幕，就要单独验证首 token 延迟、增量输出、标签回改和断线恢复。
本地能跑，不等于传统流水线可以直接删除
官方当前推荐 SGLang Omni 作为服务后端，并提供 vLLM 路线。仓库给出了单张 H100 上的吞吐与延迟数据，但这不能直接回答一张消费级显卡能否处理你的 60 分钟会议。设备、精度、并发、音频长度和输出 token 上限必须处于同一条件，数字才可比较。
论文评测也要读清范围。AISHELL-4 是公开会议数据集，但 Podcast 和 Movies 是团队内部整理的测试集；报告写明计划公开。部分商业模型又因为输入长度或无法稳定遵循说话人输出格式，没有出现在所有长音频测试中。这些结果足以说明 MOSS 0.9B 值得测试，却还不足以推出“所有传统方案都已落后”。
实际迁移时，可以按下面的顺序做小规模验收：
1. 先固定任务。明确是会后纪要、播客字幕、客服质检，还是实时会议字幕；它们对延迟和说话人边界的要求完全不同。
2. 再准备自己的样本。至少覆盖安静会议、远场录音、多人抢话、长时间沉默后再次发言和领域术语，不要只测官方样例。
3. 同时记录三本账。文本看 CER 或人工修订量，归属看说话人混淆和边界错误，工程侧记录峰值显存、实时率、截断与失败重试。
4. 最后决定替换范围。如果端到端模型在目标音频上稳定，可以先替换主转写链路；如果还需要已知人员识别、人工拖动边界、实时低延迟或单模块定制，传统流水线仍可能更好维护。
一个更稳妥的判断不是“端到端还是流水线谁更先进”，而是：哪条路线能在你的音频分布里，以可接受的资源，把正确的话稳定地还给正确的人。
MOSS 0.9B 已经把多人转写的入口压缩到一个模型里，这是很实在的进步。但决定它能否替代现有系统的，不是 0.9B 这个数字，而是文字、归属和工程三本账能否同时对上。
参考资料
MOSS Transcribe Diarize 技术报告： https://arxiv.org/abs/2601.01554
MOSS-Transcribe-Diarize 官方仓库： https://github.com/OpenMOSS/MOSS-Transcribe-Diarize
MOSS-Transcribe-Diarize 官方模型卡： https://huggingface.co/OpenMOSS-Team/MOSS-Transcribe-Diarize
— THE END —
文章仅做学术分享，如有侵权请联系删除，非常感谢！