这是一个仅有0.9B参数的开源语音模型， 长音频转写+说话人声分离一次搞定! #语音转文字 #语音识别 #ASR #会议纪要#模思智能

• UP 主：今天学点啥？
• 源链接：https://www.douyin.com/video/7675312428694932776
• 时长：0:39

MOSS-Transcribe-Diarize 0.9B：一条 39 秒推介视频的信息补全

0. 先给判断：这条视频值不值得看

视频定位：不是教程，是一条 39 秒的模型推介短片，UP 主「今天学点啥？」。全片没有出现模型名字，也没有一个数字指标、没有许可证、没有硬件要求——它解决的是「让你知道有这么个东西」，不解决「怎么用、能不能用」。

值得看的：如果你完全没听过这个模型，开头十几秒把能力边界（长音频转写 + 说话人分离 + 时间戳 + 多语种）和三条上手路径（本地部署 / 在线体验 / 调 API）一次说全了，当一张线索卡片用没问题。

可以跳过的：其余部分都是同一句话的复述。真要动手，必须回到官方仓库和技术报告——本文下面的内容就是从那里抽出来的。

一句话：视频的信息量约为官方 README 的 5%，且把「Pro 在线版」和「开源的 0.9B 版」混在一起讲（见 §6）。看 30 秒知道有这么回事即可，具体别信转述，看本文。

---

1. 视频里的主张 vs 核实结果

视频文字稿本身像是自动识别的，开篇「仅有 0.9 字己」应为「0.9B 参数」，句读也有断裂（「跟着。步骤操作就能尝试…」）——拿一条讲 ASR 的视频、配着 ASR 幻觉的字幕，算是某种巧合。

视频说法（事实层：视频明确讲了）	核实结果	出处
「仅有 0.9B 参数的开源语音模型」	成立。MOSS-Transcribe-Diarize 0.9B，2026-07-09 开源，Apache-2.0	[1][2][5]
「支持中英日韩法语、西班牙语以及粤语等等多种语言」	部分可核实：官方口径是「支持 50+ 种语言」。视频列举的这张具体语种清单，我在官方材料里没有找到逐项列表，故不视为已核实	[1][2]；视频该说法标为 UNVERIFIED
「最长可以处理 90 分钟长音频」	成立。128k token 上下文窗口，论文原文即「up to 90-minute inputs」	[1][3][4]
「自动区分不同说话人，并给每句话标上时间点」	成立，且是它的核心卖点：一次前向输出带时间戳、带说话人标签（[S01]/[S02]…）的结构化文本	[1][3]
「部署也很简单，教程都准备好了」	教程确实齐全（Python / SGLang Omni / vLLM / FunASR / 自带字幕 Web 应用）。但「简单」是相对说法：需要 Python 3.12 + Transformers 5.x，vLLM 路径要装固定版本的 nightly wheel，SGLang Omni 当前面向 CUDA 13	[1][2][5]
「不想自己折腾可以在线体验、上传音频测试，也可直接调 API」	在线 Playground 存在（README 指向 platform.mosi.cn/app/playground，但注意那里挂的是 Pro）；API 由创智学院文章确认开放。文章所给 API 文档地址我实测打不开（见 §6）	[1][2][4]；API 文档链接 UNVERIFIED

---

2. 视频没说的那个名字：MOSS-Transcribe-Diarize

标题和下文的 #模思智能 标签是唯一线索。真正的模型名是 MOSS-Transcribe-Diarize 0.9B，由 OpenMOSS 团队 / 模思智能（MOSI.AI） 发布；[1] 的更新时间线显示：2026-07-09 开源 0.9B，2026-07-14 在 INTERSPEECH 2026 第二届 MLC-SLM Challenge 拿下第一名（覆盖 14 种语言），2026-07-22 字幕 Web 界面支持中英双语。

出身背景（视频完全没提，但对判断可信度有用）：模思智能由上海创智学院与复旦大学自主孵化，首席科学家为复旦大学教授邱锡鹏（也是上海创智学院全时导师）；该团队的 MOSS 是国内第一个对标 ChatGPT 并开源的对话式大语言模型，此前还发布过具有内生语音能力的 SpeechGPT、原生端到端全模态模型 AnyGPT，以及 MOSS-TTSD（对话语音合成）、MOSS-Speech（无文本引导的端到端语音大模型）[4]。同类语音模型领域，这条线是有连续发布记录的，不是一个孤立项目。

---

3. 补全的术语与背景：它到底在解决什么难题

3.1 名词对照

• ASR：自动语音识别，语音转文字。
• Diarization（说话人分离 / 说话人日志）：判断「哪一段话是谁说的」，输出说话人编号。
• SATS：论文给这个任务起的名字——Speaker-Attributed, Time-Stamped Transcription，「带说话人归属与时间戳的转写」[3]。
• VAD：语音活动检测（找哪里有人声）。
• RTF：实时因子，处理耗时 ÷ 音频时长，越小越快。
• CER / cpCER / Δcp：三个评测指标，越低越好。其中 cpCER 是「拼接后最小排列字符错误率」——先按说话人排列组合的多种可能里取最优再算错误率 [1][4]；Δcp 我没有在官方材料里看到公式定义，但用评测表逐行验算可知它等于 cpCER − CER（例如 Podcast：7.37 − 5.97 = 1.40，Movies：12.76 − 6.36 = 6.40，均为表内数值），可以理解为「纯粹识别错误之外，由说话人归属问题额外引入的损失」（此解读为推断，方向与 [4] 的表述一致）。

3.2 为什么「一次搞定」是卖点

传统做法是把两套系统拼起来：Whisper 这类 ASR 出文字，pyannote 这类说话人分离模型出说话人轨迹，再把两者对时间轴对齐。论文指出这种模块化流水线的通病是误差级联：各模块训练目标、延迟、调优数据集都不同，全局上下文很难用上，用户只能在归属准确度、时间精度和吞吐之间做取舍 [3]。

中间路线是「半级联」——用 LLM 当全局协调层做后处理（论文举 DiarizationLM 为例），但它仍然不是端到端，继承级联方案的老问题。更接近统一架构的尝试也各有短板，论文逐一列了：Sortformer 用排列不变损失做联合建模，但训练仍是两阶段的（先训说话人分离、冻结后再训 ASR）；SpeakerLM 把说话人感知并入单个多模态 LLM，但公开设置下只处理 50–90 秒量级、且最多约 4 个说话人；JEDIS-LLM 用「Speaker Prompt Cache」做分块流式推理来撑长音频，代价是依赖分块与额外机制维持全局说话人一致性 [3]。

MOSS-Transcribe-Diarize 的路线是：长上下文 + 单次前向，不做分块，直接吐出带时间戳的说话人轮次。论文把它自己定位为「第一个在一次前向中同时完成词识别、说话人归属和时间戳预测的统一多模态模型」——注意这是作者自称的贡献声明，不是第三方独立验证 [3]。

---

4. 架构与输出格式（官方规格）

组件	规格
文本主干	Qwen3-0.6B 风格的因果解码器
音频编码器	Whisper-Medium 编码器配置
音频前端	WhisperFeatureExtractor，16 kHz，80 mel 频带，30 秒分块
音频-文本桥接	4 倍时间维度合并 + MLP 适配器
特征融合	音频特征经 masked_scatter 替换 <|audio_pad|> embedding
输出格式	紧凑的 [起始时间][Sxx]正文[结束时间]

（表来自 [1][2]。官方未公布 0.9B 在主干/编码器/适配器之间的参数切分。）

时间戳以秒为单位，且时间信息以文本形式插入音频块之间，而不是绑定在绝对位置索引上——论文解释这样做的原因是：长时长下绝对位置索引会变得稀疏失效，文本化时间编码能在小时级音频上稳定输出时间戳 [3]。

官方给出的标准输出例子（[1]）：

[0.48][S01]Welcome everyone[1.66][12.26][S02]The new transcription pipeline is ready for evaluation[13.81][14.36][S01]Great, include the diarization results in the report[18.76]

两个常被宣传语盖住的细节（推断/提醒）：

1. 「不需要外挂 VAD 或说话人分离模型」≠ 模型内部不做分块。前端的 Whisper 特征提取本身就是 30 秒为单位切块的；FunASR 的部署页也专门提示了这一点：「无需外部 VAD」不表示模型内部没有分块或分段 [5]。
2. 模型还能输出可选的声学事件标注（acoustic event awareness），视频完全没提 [1][2]。

---

5. 可核验的数字

5.1 客观评测（官方口径）

评测集：AISHELL-4 Test（真实会议长音频）、Alimeeting、Podcast（YouTube 多人访谈）、Movies（影视剧短片段）。统计口径 [3]：AISHELL-4 测试集单条 2195.4–2393.9 秒（均值约 2290 秒 ≈ 38 分钟）、5–7 个说话人；Podcast 单条 1528.7–3636.5 秒（均值约 2659 秒，最长约 60 分钟）、2–11 个说话人；Movies 单条 0.418–29.888 秒（均值 11.5 秒）、1–6 个说话人。

模型	AISHELL-4 CER / cpCER / Δcp	Alimeeting	Podcast	Movies
Doubao	18.18 / 27.86 / 9.68	25.25 / 37.57 / 12.31	7.93 / 10.54 / 2.61	9.94 / 30.88 / 20.94
ElevenLabs	19.58 / 37.95 / 18.36	25.70 / 36.69 / 10.99	8.50 / 11.34 / 2.85	11.49 / 17.85 / 6.37
GPT-4o	—	—	—	14.37 / 23.67 / 9.31
Gemini 3 Pro	22.75 / 27.43 / 4.68	26.75 / 32.84 / 6.09	—	8.62 / 14.73 / 6.11
MOSS-Transcribe-Diarize 0.9B	14.84 / 15.83 / 0.99	24.86 / 22.17 / −2.69	5.97 / 7.37 / 1.40	6.36 / 12.76 / 6.40
MOSS-Transcribe-Diarize Pro	13.78 / 14.02 / 0.24	18.22 / 13.94 / −4.27	4.46 / 6.97 / 2.51	5.86 / 11.78 / 5.92

（数值来自 [1][2]；GPT-4o 指 gpt-4o-transcribe-diarize [4]。）

读表要点：0.9B 在 AISHELL-4 长会议上的 CER 比豆包、ElevenLabs、Gemini 3 Pro 低一大截，Δcp 也明显更小——也就是「说话人归属带来的额外损失」更少 [4]。Alimeeting 上 0.9B 的 CER（24.86）只比豆包（25.25）略好，cpCER 优势（22.17 vs 37.57）才明显。Podcast 与 Movies 是机构自建评测集（论文说是从播客与影视剧自行策展的），并非公开第三方基准，复现性弱于 AISHELL-4。

必须标注的三点限定：

• 表内是官方自测结果，不是第三方复现。
• 公开评测集里最长的单条音频约 60 分钟（Podcast 3636.5 秒）。90 分钟是上下文能力声明的上限，这些公开集并未直接覆盖——此为我的推断，不是官方结论。
• 0.9B 的 90 分钟是「能力上限」，不等于每个请求都能跑满：服务端 max_new_tokens 默认 5120，长音频必须手动调大（官方示例给到 65536），否则会截断 [1]。

5.2 性能与生态现状

• 单张 H100 上的官方口径：长序列任务（aishell4_long）单并发 RTF 均值 0.0197、平均延迟 45.2 秒（约等于 38 分钟会议音频 45 秒出结果）；并发 16 时单请求延迟 282.8 秒、吞吐 0.043 req/s。短序列（movies）单并发延迟 0.388 秒、RTF 0.0612 [1]。这组数据同时也是「没有显存/硬件门槛说明」的侧面证据：基准均在 H100 80GB 上做 [1][5]。
• 竞赛成绩：2026-07-14 在 INTERSPEECH 2026 第二届 MLC-SLM Challenge 获第一名，覆盖 14 种语言 [1]。
• 生态接入：FunASR 维护了面向生产的部署指南，其部署页标注验证日期 2026-09-01，固定 vLLM 0.27.1、SGLang Omni 特定 commit，并明确这是 OpenMOSS 的第三方 Apache-2.0 模型，不是 FunASR 自有模型 [5]。下游工具 FunClip 2.2.1 已支持说话人 SRT 与「按说话人剪辑」 [1]。
• 抓取仓库页面时显示 Star 约 2k、Fork 125 [1]（动态数字，仅供参考）。

---

6. 三条上手路径，以及视频没说清的坑

① 在线：README 把 Pro 版放在 Playground（platform.mosi.cn/app/playground）[1][2]。这里有个容易误解的地方：README 明确说 Playground 上是「性能更强的版本」Pro，不是开源的那份 0.9B 权重。你在网页上试到的效果和你在自己机器上跑出来的，不是同一个模型。创智学院的文章给出 API 接入文档：studio.mosi.cn/docs/moss-transcribe-diarize，并说当时为「限时免费期」[4]——我尝试打开该地址时未能取到页面（重定向后返回 404），此链接与「限时免费」的时效性均标为 UNVERIFIED。

② 本地（官方 README 给的路子）：

• Python 直用：干净的 Python 3.12 环境 + Transformers 5.x，trust_remote_code=True，装了 flash-attn 就用 flash_attention_2；eager 只是兜底，长音频会因显存平方增长 OOM（官方原话）[1]。
• 推荐后端 SGLang Omni：OpenAI 兼容的 /v1/audio/transcriptions，拿说话人分段要用 response_format=verbose_json（json 只回原始转写文本）；当前面向 CUDA 13 [1]。
• vLLM：可跑，但必须用「包含该模型注册的固定版本 nightly 构建」（cu129 / cu130 二选一），不要指望随手 pip install vllm 就能起 [1][2]。
• FunASR 生态：funasr>=1.4.12 可连已有 vLLM 服务，把官方说话人分段统一成 sentence_info [1]。
• CPU / 边缘：FunASR 部署页列出了第三方 moss-transcribe.cpp（C++17 + GGUF）与 LocalAI backend 路径，适用硬件写的是 cpu / nvidia-gpu / desktop-edge-gpu，操作系统为 Linux [5]。
• 官方还有自带的字幕 Web 应用（2026-07-22 起支持简体中文和英文界面）[1]。

③ 部署时最容易踩的两个坑：长音频被截断（调大 max_new_tokens / max_completion_tokens，并同时盯显存与输出完整性）；不同后端的响应契约不一致（vLLM 的 diarized_json 有独立 speaker 字段，SGLang Omni 的 verbose_json 把说话人编号塞在 segments[].text 的 [Sxx] 前缀里）[1][5]。

---

7. 局限与前提：哪些场景别用它

以下均为官方或生态文档明确写出的边界：

• 不适合实时流式字幕或低延迟端点检测——这是 FunASR 部署页「不适合」清单里的第一条 [5]。视频用「会议纪要」这类标签容易让人误以为可以边开会边出字幕，实际是一次性处理整段音频。
• 官方未见最低显存要求。0.9B 权重本身很小，但 128k 上下文 + 长音频激活值才是真实约束（推断）；所有官方基准都在 H100 80GB 上完成 [1][5]。想在消费级显卡上跑长音频，请自行先测。
• 公开性能数据不覆盖说话人分离与时间戳准确率：FunASR 提醒，SGLang Omni 那份 1088 条的单说话人英文 benchmark「不覆盖 diarization 或 timestamp 准确率」，生产前必须单独验证 [5]。
• 说话人数上限官方未声明。论文的合成训练数据按 2–12 个说话人采样，评测集最多 11 人 [3]；超出这一量级的表现没有依据（推断）。
• 原生 Windows 部署未经目标硬件复测 [5]。
• 语种：官方只有「50+ 种」这一句，视频列举的那张具体语种清单我无法在官方材料中逐项核实（UNVERIFIED）。
• trust_remote_code=True 是使用前提，FunASR 的建议是固定并审计对应模型 revision，不要执行浮动 main 分支代码 [1][5]。
• 许可：Apache-2.0，可商用（官方 README 与 FunASR 部署页均写明）[1][5]。

---

8. 事实 / 参考 / 推断的分层

• 事实（视频里明确讲了）：0.9B 参数、开源、多语种、最长 90 分钟、自动说话人分离与时间戳、有部署教程、可在线体验、可调 API。此外还有一条可观察事实：视频本身从未说出模型名字。
• 参考（我从外部资料补的）：模型名与发布时间线、Apache-2.0、架构规格、官方评测数字、SATS 与级联方案对比、三家部署后端、生态集成、创智/复旦与邱锡鹏团队背景、以及上述所有限制条款。
• 推断（我自己推的，已显式标注）：Δcp = cpCER − CER 的算式（可由表内数字逐行验算）、90 分钟上限未被公开评测集直接覆盖、0.9B 参数在各组件间的切分官方未公布、显存瓶颈在激活而非权重、说话人数上限大致落在十余人量级。

---

9. 来源清单

• [1] OpenMOSS/MOSS-Transcribe-Diarize 仓库 README（中文） — https://github.com/OpenMOSS/MOSS-Transcribe-Diarize/blob/main/README_zh.md
• [2] OpenMOSS/MOSS-Transcribe-Diarize 仓库 README（英文原文，raw） — https://raw.githubusercontent.com/OpenMOSS/MOSS-Transcribe-Diarize/main/README.md
• [3] MOSS Transcribe Diarize Technical Report, arXiv:2601.01554 — https://arxiv.org/pdf/2601.01554
• [4] 上海创智学院：击败GPT、Gemini，创智×复旦孵化创业团队「模思智能」，语音模型上新了 — https://www.sii.edu.cn/2026/0127/c27a664/page.htm
• [5] FunASR 产品级部署页：MOSS 统一转写与说话人分离 — https://www.funasr.com/deploy/moss-transcribe-diarize.html
• [6] HuggingFace 模型卡 OpenMOSS-Team/MOSS-Transcribe-Diarize（raw README） — https://huggingface.co/OpenMOSS-Team/MOSS-Transcribe-Diarize/raw/main/README.md

两处未能核实、请勿当结论的项：① studio.mosi.cn/docs/moss-transcribe-diarize（抓取时重定向后返回 404）；② [4] 文章页面显示的日期为 2026.01.21，但正文称技术报告「几天前」发布、所引 arXiv 版本日期为 2026 年 7 月，两者不一致，我在正文中未依赖该日期。此外，视频列举的具体语种清单亦未核实。