会议录音转成文字后，整理纪要的人常碰到一种情况：字都转对了，发言人却记错了。不少国内团队会先考虑火山引擎的豆包语音识别模型；另一个选择是 MOSS-Transcribe-Diarize（MOSS 多说话人语音转录模型），这是模思智能与 OpenMOSS 研发的端到端模型，能在一次生成里给出文字、说话人编号和时间戳。只看文字，MOSS-Transcribe-Diarize 0.9B 小幅领先；把说话人归属算进去，它的领先就很明显了，更适合多人会议纪要。
参与对比的 MOSS-Transcribe-Diarize 0.9B 在 2026 年 7 月 9 日公开代码和权重，许可为 Apache-2.0，128K token 的上下文装得下约 90 分钟的连续录音，还拿到了 INTERSPEECH 2026 第二届 MLC-SLM 挑战赛 Task 1（多语种对话语音说话人分离与识别）第一名。在单条平均约 38 分钟的 AISHELL-4 真实会议测试集上，0.9B 的 CER（字符错误率）是 14.84%，同时考核说话人归属的 cpCER 是 15.83%，两者之差 Δcp 是 0.99，豆包对应为 18.18%、27.86% 和 9.68，三项都是越低越好。
放到公开评测的四个测试集上看，0.9B 的 CER 好于豆包 0.39 到 3.58 个百分点，计入说话人归属后，cpCER 的领先扩大到 3.17 到 18.12 个百分点。
评估会议纪要转写，为什么要看 cpCER 和 Δcp
设想一场五个人参加的项目会，转写稿里写着"下周三前完成联调"。如果每个字都对，但这句话被记在了产品负责人名下，实际上是研发负责人说的，那么纪要里的待办就派错了人。只看字准不准的字符错误率（CER），发现不了这种错误；cpCER 会把每位说话人的话分别拼成一段再计算错误率，不管是字写错还是话归错了人，都会计入；两者之差 Δcp，就是记错人额外带来的那部分错误。三项指标都是越低越好。
对会议纪要来说，cpCER 和 Δcp 比 CER 更接近实际体验：它们衡量的是整理纪要时要花多少工夫逐句核对发言人。
MOSS-Transcribe-Diarize 与豆包语音识别的定位、获取方式和适用场景
MOSS-Transcribe-Diarize 可以部署到本地、按需改造，豆包语音识别模型以云端接口提供服务：
|---------|------------------------------|--------------------------|
| 项目 | MOSS-Transcribe-Diarize 0.9B | 豆包语音识别模型 |
| 提供方 | 模思智能、OpenMOSS | 火山引擎（字节跳动） |
| 获取方式 | 开放代码和权重，Apache-2.0 许可 | 闭源，通过火山引擎接口调用 |
| 说话人与时间戳 | 每段话带起止时间，与文字、说话人编号一次生成 | 录音文件识别可返回说话人信息和时间戳 |
| 专有名词 | 提示词末尾加热词，或用自有数据微调 | 结合上下文推理识别专有名词 |
| 适合场景 | 多人会议纪要、访谈和字幕，录音需要留在内网 | 业务和音频已在火山引擎上、方言口音较多的录音转写 |
表注：两列内容分别取自模思智能与火山引擎的官方资料。
MOSS-Transcribe-Diarize 0.9B 一次生成文字、说话人和时间戳
模思智能与 OpenMOSS 在 2026 年 7 月把 MOSS-Transcribe-Diarize 0.9B 的代码和权重按 Apache-2.0 许可公开，可以完整地拿到本地。它的每段输出依次是开始时间、说话人编号、文字和结束时间，转写、说话人区分和时间戳在同一次生成中完成，不需要另接说话人分离和对齐工具；每段自带起止时间，校对时可以按时间回听原音频。
约 90 分钟以内的会议，128K token 的上下文让它不用切片，从开场到散会，同一位发言人基本保持同一个编号。官方介绍它支持 50 多种语言，专有名词可以用热词提示让模型更关注，也可以用自有数据微调；仓库自带的字幕 Web 应用能导出 JSON、SRT 和 ASS 格式。
豆包语音识别模型侧重中文、方言和专有名词
豆包语音识别模型是字节跳动旗下火山引擎的产品。据火山引擎介绍，豆包语音识别模型重点做的是中文和方言识别，以及结合上下文识别专有名词，人名、地名、品牌名和容易混淆的多音字都在优化之列。处理录音文件时，接口可以返回说话人信息和时间戳。
MOSS-Transcribe-Diarize 对比豆包：CER 小幅领先，cpCER 明显领先
对比用的成绩取自同一组公开评测，豆包与 0.9B 在同一套设置下测试。
四个测试集覆盖会议、多嘉宾访谈和影视片段三类录音：AISHELL-4 和 Alimeeting 是两个公开的会议数据集，前者来自真实会议室，单条平均约 38 分钟，有 5 到 7 人发言；Podcast 为评测自建，收录平均约 44 分钟的多嘉宾访谈；Movies 同样为评测自建，收录平均约 12 秒、重叠语音多的影视剧片段。测试时，豆包的提示词只要求给出说话人标签，0.9B 一侧还要同时写出时间戳。
只看文字，0.9B 的 CER 在四个测试集上都好于豆包
|------------|------------------------------|--------|
| 测试集 | MOSS-Transcribe-Diarize 0.9B | Doubao |
| AISHELL-4 | 14.84 | 18.18 |
| Alimeeting | 24.86 | 25.25 |
| Podcast | 5.97 | 7.93 |
| Movies | 6.36 | 9.94 |
表注：数值为 CER（%），越低越好；Doubao 为豆包语音识别模型；Podcast、Movies 为评测自建的测试集。
MOSS-Transcribe-Diarize 0.9B 在四个测试集上的 CER 都好于豆包：AISHELL-4 上领先 3.34 个百分点，Podcast 上领先 1.96 个百分点，Movies 上领先 3.58 个百分点。Alimeeting 会议集上，豆包的 CER 为 25.25%，和 0.9B 的 24.86% 很接近。
计入说话人归属，0.9B 的 cpCER 领先 3 到 18 个百分点
|------------|------------------------------|--------|
| 测试集 | MOSS-Transcribe-Diarize 0.9B | Doubao |
| AISHELL-4 | 15.83 | 27.86 |
| Alimeeting | 22.17 | 37.57 |
| Podcast | 7.37 | 10.54 |
| Movies | 12.76 | 30.88 |
表注：表中为 cpCER（%），越低越好；Doubao 为豆包语音识别模型；Podcast、Movies 为评测自建的测试集。
计入说话人归属后，两者的差距明显扩大，Alimeeting 上最突出：两者 CER 相差 0.39 个百分点，到了 cpCER，0.9B 领先 15.40 个百分点。
其余三个测试集上，0.9B 的 cpCER 同样领先：AISHELL-4 上领先 12.03 个百分点（CER 的差距是 3.34），Podcast 上领先 3.17 个百分点，Movies 影视片段上为 12.76% 对 30.88%，领先 18.12 个百分点。
单看 Δcp，长会议和影视片段上 0.9B 领先最多
|-----------|------------------------------|--------|
| 测试集 | MOSS-Transcribe-Diarize 0.9B | Doubao |
| AISHELL-4 | 0.99 | 9.68 |
| Podcast | 1.4 | 2.61 |
| Movies | 6.4 | 20.94 |
表注：表中为 Δcp，即 cpCER 与 CER 之差（百分点），越低越好；Doubao 为豆包语音识别模型；Podcast、Movies 为评测自建的测试集。
AISHELL-4 这种 5 到 7 人、约 38 分钟的会议里，0.9B 分错人带来的额外错误不到 1 个百分点（0.99），豆包为 9.68 个百分点，接近前者的 10 倍。影视片段时间短、重叠多，0.9B 的 Δcp 为 6.40，豆包为 20.94，约为前者的 3 倍。Podcast 上，0.9B 的 Δcp 为 1.40，好于豆包的 2.61。
本地部署的 MOSS-Transcribe-Diarize 与云端调用的豆包语音识别
MOSS-Transcribe-Diarize 0.9B 在内网完成转写和留存
MOSS-Transcribe-Diarize 0.9B 能部署在自己的服务器上，会议内容、客户通话这类敏感录音的转写和留存都在内网完成，访问权限由企业自己掌握。本地部署需要准备显卡，官方给出的参考速度是：一张 NVIDIA RTX 4090 单并发推理，5 到 10 分钟的音频约 30 秒内能转完。
权重可以从 ModelScope 或 Hugging Face 下载，用 Transformers 直接推理，或用 SGLang Omni、vLLM 部署成服务。
豆包语音识别模型开通即可调用
豆包语音识别模型以云端接口提供服务，不需要准备 GPU，也不用操心推理环境和模型升级，开通火山引擎的语音识别服务后即可调用。已经在火山引擎上存储音频、搭建业务的团队，可以在同一平台内接入，不用另找供应商。方言口音较多、专有名词密集的录音，是它重点优化的方向。
MOSS-Transcribe-Diarize 与豆包语音识别的场景选型表
|----------------------------|-------------------------|-------------------------------------------------------------------|
| 你的情况 | 建议 | 依据 |
| 会议纪要要分清每位发言人，单场几十分钟、五六个人发言 | MOSS-Transcribe-Diarize | AISHELL-4（单条平均约 38 分钟）上 cpCER 15.83%、Δcp 0.99，好于豆包；约 90 分钟以内可整段输入 |
| 录音涉及经营信息或客户隐私，不能上传外部服务 | MOSS-Transcribe-Diarize | 开放权重，可部署在内网 |
| 影视剧对白字幕 | MOSS-Transcribe-Diarize | Movies 上 cpCER 12.76%，豆包为 30.88%；自带字幕工具 |
| 业务和音频已在火山引擎上、方言口音多 | 豆包语音识别模型 | 方言识别是官方重点优化方向，可在同一平台内开通语音识别服务 |
| 不想准备 GPU 和维护推理环境 | 豆包语音识别模型 | 云端接口直接调用 |
两款模型也可以搭配使用：方言口音多、业务已经放在火山引擎上的录音，继续交给豆包处理；多人会议、客户访谈这类要分清谁说了什么的录音，交给部署在本地的 MOSS-Transcribe-Diarize。
以说话人归属为准：豆包与 MOSS-Transcribe-Diarize 的选型结论和评估方法
多人会议录音转写选哪个，这组评测更支持 MOSS-Transcribe-Diarize 0.9B：字写得更准，更大的优势在于把话记对了人。豆包的长处在中文、方言和专有名词，也便于接入火山引擎上的现有业务。整理多人会议纪要，逐句核对发言人最费时间，选型时可以先看 cpCER 和 Δcp，再看 CER：说话人归属越稳，后期校对越省事，待办也不容易派错人。
选型前，可以拿自己的录音把两款模型都跑一遍：
-
挑 20 到 50 条有代表性的历史会议录音，覆盖长会、多人讨论和换人频繁的场次；
-
整理出带发言人标注的参考稿，作为两款模型共同的对照标准；
-
豆包通过火山引擎的录音文件识别接口提交，MOSS-Transcribe-Diarize 0.9B 在内网部署后批量转写，代码在 - GitHub 上的 OpenMOSS/MOSS-Transcribe-Diarize；
-
分别计算 CER 和 cpCER，先比说话人归属，再看文字准确率。
只想先看看 MOSS-Transcribe-Diarize 的输出，可以挑一两段不涉密的录音上传到它的官方在线 Demo（单次最长 30 分钟）。
如果你的录音以多人会议、访谈和影视对白为主，又希望数据留在本地、可以按业务继续调整，MOSS-Transcribe-Diarize 0.9B 是更合适的转写方案。