我测试了一个0.9B模型，它竟然能自动区分多人讲话）

hhzz

6228人浏览 · 2026-08-27 17:48:35

hhzz · 2026-08-27 17:48:35 发布

我测试了一个 0.9B 模型，它竟然能自动区分多人讲话

会议录音转完字，最烦的不是错别字，是一锅粥。

三个人轮着说，偶尔抢话，偶尔叠音。普通 ASR 给你一整段字，你还得自己猜：这句是谁的？字幕要卡点，又得再跑一遍对齐。过去常见做法是 ASR、说话人分离、时间戳对齐各跑一套——中间错一次，后面全跟着漂。

在这里插入图片描述
图1 左：多模型拼接；右：MTD 0.9B 一次输出「时间戳 + 说话人 + 文本」

今年 7 月，模思智能（MOSI.AI）把 MOSS-Transcribe-Diarize 0.9B 开源了。它不走拼接流水线，一次生成三件东西：

时间戳 + 说话人编号 + 转录文本

我把它接到自己的开源转写项目里，当本地「多人会议 / 播客字幕」后端：下载、装环境、跑第一次推理、测热词、导出字幕、再挂一层 OpenAI 兼容 API。下面按真实仓库写，命令和接口都能对着 GitHub README 复现。

先说清楚：0.9B 解决的是哪类问题

仓库全称是 MOSS-Transcribe-Diarize（MTD）。开源版参数量 0.9B，协议 Apache 2.0。架构也不复杂：音频侧用 Whisper-Medium encoder，文本侧是 Qwen3-0.6B 风格解码器，中间 4 倍时间合并 + MLP 把音频特征送进语言模型。官方面向会议、通话、播客、访谈、讲座和长视频，支持 50+ 语言，上下文 128K，单段音频最长约 90 分钟。
在这里插入图片描述

图2 官方模型架构图（已从 GitHub 仓库下载）

标准输出格式：

[start_time][Sxx]transcribed speech[end_time]

官方英文示例：

[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]

中文场景里，你会看到类似：

[00:01][S01] 今天我们主要讨论产品发布计划。
[00:05][S02] 我先介绍一下目前的开发进度。

[S01]、[S02] 是匿名说话人编号，不是自动填人名。人名要靠后续映射，或用热词把「张三 / 产品名」听准。

同一系列还有 MOSS-Transcribe-Diarize Pro：不用备 GPU，上 platform.mosi.cn 上传就能试，也支持 API。官方评测里 Pro 在多个中文会议、播客、影视集上整体高于 0.9B。开源版适合本地和二次开发；Pro 适合直接用、直接接入业务。

用途	地址
GitHub	https://github.com/OpenMOSS/MOSS-Transcribe-Diarize
Hugging Face 权重	https://huggingface.co/OpenMOSS-Team/MOSS-Transcribe-Diarize
在线 Demo	https://moss-transcribe-diarize-demo.mosi.cn/
技术报告	https://arxiv.org/abs/2601.01554
API / Playground	https://platform.mosi.cn
AtomGit 镜像	https://ai.atomgit.com/OpenMOSS/MOSS-Transcribe-Diarize

在这里插入图片描述
图3 打开官方 Demo，上传 2～3 人对话音频，截取带 [S01][S02] 标签的结果页

开源节点：2026-07-09 放出 0.9B；2026-07-14 拿下 INTERSPEECH 2026 第二届 MLC-SLM Challenge 14 语言任务第一名；2026-07-22 字幕 Web 支持简体中文。

为什么接到开源项目里，而不是只跑 Demo

我这边已有一条本地工作流：上传音视频 → 转写 → 出 SRT/JSON → 给剪辑和纪要用。缺的是「人和时间」一次齐。
在这里插入图片描述
图4 从音视频到 segments 再到字幕/纪要的接入链路

接入策略：推理层用官方包，业务层只吃结构化片段。

音视频文件
    → moss-transcribe-diarize（Transformers / 本机 /v1/audio/transcriptions）
    → parse_transcript：start / end / speaker / text
    → 导出 JSON / SRT / ASS，可选 FFmpeg 压字幕
    → 纪要、检索、切片共用同一份 segments

官方仓库自带 mtd-subtitle、mtd-subtitle-web 和 parse_transcript，不必自己造解析器。项目里只做三件事：选后端（本机 or 平台 Pro）、把热词写进 prompt / keyterms、把 segments 接到导出逻辑。

没有 GPU 的机器，先用官方 Demo 看效果再决定是否部署。社区实测大约 6GB 显存 能跑开源版；官方 H100 基准是服务端吞吐，别直接当笔记本预期。

1. 下载模型，配环境

官方在 Python 3.12 + Transformers 5.x 上测过，依赖 torch>=2.8。建议干净虚拟环境，别塞进旧项目的 Python 3.9。

Linux / macOS：

git clone https://github.com/OpenMOSS/MOSS-Transcribe-Diarize.git
cd MOSS-Transcribe-Diarize
uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e ".[torch-runtime]" --torch-backend=auto

Windows PowerShell：

.venv\Scripts\Activate.ps1

在这里插入图片描述
图5 操作终端：uv pip install 成功 + hf download 进度

权重模型 ID（不要改字符串）：

OpenMOSS-Team/MOSS-Transcribe-Diarize

预下载（给 SGLang / vLLM 用）：

hf download OpenMOSS-Team/MOSS-Transcribe-Diarize

国内网络不稳可走镜像或 AtomGit；加载必须 trust_remote_code=True。

Attention 加载顺序（官方显式策略，不要静默降级）：

flash_attention_4 → flash_attention_3 → flash_attention_2 → sdpa → eager

落到 eager 会在长音频里撑出很大的 attention 矩阵。mtd-subtitle / mtd-subtitle-web 可用 --attn-implementation 手动指定。

环境	官方建议
CUDA 13	SGLang Omni（推荐，`/v1/audio/transcriptions`）
CUDA 12	vLLM（README 指定 nightly，`cu129` / `cu130`）
先验证效果	Transformers 直接 `generate`，或官方字幕 Web

SGLang 安装请跟官方 installation 文档走，不要随便 pip install 旧包。

2. 第一次推理：把多人音频变成说话人片段

项目里封装一层，核心仍是官方示例——不要自己拼 chat template。

import logging
import torch
from transformers import AutoProcessor

from moss_transcribe_diarize import parse_transcript
from moss_transcribe_diarize.attention import load_model_with_attention_fallback
from moss_transcribe_diarize.inference_utils import (
    build_transcription_messages,
    generate_transcription,
    resolve_device,
)

logging.basicConfig(level=logging.INFO)

model_id = "OpenMOSS-Team/MOSS-Transcribe-Diarize"
audio_path = "meeting_sample.wav"  # 建议先用 2～5 分钟、2～3 人录音

device = resolve_device("auto")
dtype = torch.bfloat16 if device.type == "cuda" else torch.float32

model, attention_report = load_model_with_attention_fallback(
    model_id, device=device, dtype=dtype,
)
model = model.to(dtype=dtype).to(device).eval()
processor = AutoProcessor.from_pretrained(model_id, trust_remote_code=True)

messages = build_transcription_messages(audio_path)
result = generate_transcription(
    model, processor, messages,
    max_new_tokens=2048,  # 长会要加大，服务端长音频常见 65536
    do_sample=False,
    device=device, dtype=dtype,
    attention_report=attention_report,
)

print(result["text"])
for seg in parse_transcript(result["text"]):
    print(seg.start, seg.end, seg.speaker, seg.text)

在这里插入图片描述
图6 Web UI 分段列表（自用平台）

第一次测别一上来丢 60 分钟。对照这四点：

换人时 [S01] / [S02] 有没有跟着换
插话、短应答会不会并进前一个人

起止时间能不能直接切字幕
专有名词错不错（错了再上热词）

短音频 max_new_tokens=2048 够用；长会议务必加大，否则后半截会被截断。官方服务默认 5120，长音频示例给到 65536。

字段	含义	下游用法
`start` / `end`	秒	SRT、对齐画面、跳转播放
`speaker`	`S01` 等	纪要分栏、声纹映射人名
`text`	该段口播	检索、摘要、翻译

3. 热词：人名和产品名别指望模型猜

会议里最容易错的是人名、公司名、模型名、中英混写产品名。开源版做法：在默认 prompt 后追加「热词提示」。

默认 prompt：

请将音频转写为文本，每一段需以起始时间戳和说话人编号（[S01]、[S02]、[S03]…）开头，正文为对应的语音内容，并在段末标注结束时间戳，以清晰标明该段语音范围。

带热词：

请将音频转写为文本，每一段需以起始时间戳和说话人编号（[S01]、[S02]、[S03]…）开头，正文为对应的语音内容，并在段末标注结束时间戳，以清晰标明该段语音范围。热词提示：MOSS-Transcribe-Diarize, 模思智能, SGLang

在这里插入图片描述
图7 同一音频、同一位置：左无热词错字，右加热词后对比截图

同一段 prompt 可传给 build_transcription_messages、mtd-subtitle、mtd-subtitle-web。英文版见 examples/prompts.md。

平台 Pro 更工程化：keyterms 字符串数组，文档写明 最多 20 个、每个最多 30 字符。接入层可统一成「热词列表」，本地转 prompt、云上转 keyterms。

4. 字幕导出，以及把模型挂成 API

官方字幕 Web（最快看到成品）

mtd-subtitle-web \
  --model OpenMOSS-Team/MOSS-Transcribe-Diarize \
  --host 127.0.0.1 \
  --port 7860

浏览器打开 http://127.0.0.1:7860，上传音视频，审片段，下载 JSON / SRT / ASS。本机有 ffmpeg 和 ffprobe 时可烧进 MP4。
在这里插入图片描述
图8 Web 界面：上传区 + 分段列表 + JSON/SRT/ASS 下载按钮（自用平台）

本地 OpenAI 兼容接口（推荐给业务接）

在这里插入图片描述
图9 客户端 → SGLang/vLLM → verbose_json 分段返回

SGLang Omni 启动：

sgl-omni serve \
  --model-path OpenMOSS-Team/MOSS-Transcribe-Diarize \
  --port 8000 \
  --max-running-requests 16 \
  --cuda-graph-max-bs 16 \
  --mem-fraction-static 0.80

要说话人分段，用 verbose_json：

curl -X POST http://localhost:8000/v1/audio/transcriptions \
  -F model=OpenMOSS-Team/MOSS-Transcribe-Diarize \
  -F file=@meeting_sample.wav \
  -F response_format=verbose_json \
  -F max_new_tokens=65536

参数	默认	说明
`file`	必填	multipart 音频
`response_format`	`json`	`json` / `verbose_json` / `text`
`max_new_tokens`	`5120`	长音频加大
`prompt`	内置转写+分人	可覆盖、可接热词
`language`	不设	可选语言提示
`temperature`	`0.0`	转写建议 0

CUDA 12 走 vLLM：

vllm serve OpenMOSS-Team/MOSS-Transcribe-Diarize --trust-remote-code

uv pip install 必须用 README 里带 hash 的 extra-index，版本不对就没有 MTD 模型注册。

5. 开源 0.9B 和平台 Pro：怎么选

官方指标 CER / cpCER / Δcp，越低越好（摘自仓库 README）：

模型	AISHELL-4 CER	Alimeeting CER	Podcast CER	Movies CER
Doubao	18.18	25.25	7.93	9.94
ElevenLabs	19.58	25.70	8.50	11.49
Gemini 2.5 Pro	42.70	27.43	7.38	15.46
Gemini 3 Pro	22.75	26.75	—	8.62
MTD 0.9B	14.84	24.86	5.97	6.36
MTD Pro	13.78	18.22	4.46	5.86

在这里插入图片描述
图10 0.9B 与 Pro 在 Alimeeting / Podcast 上的差距

0.9B 已在会议、播客、影视几项上压过不少商业系统；Pro 再往下压，尤其 Alimeeting。AISHELL-4 测试集约 36～40 分钟、5～7 个说话人，不是单人念稿场景。

	0.9B 开源版	Pro
部署	本地 GPU	浏览器 / API
协议	Apache 2.0	平台服务
热词	改 prompt	`keyterms`，最多 20 个
文件	本机路径	单文件最大 512MB
适合	开发者、数据不出域	创作者、团队、要更稳效果

在这里插入图片描述
图11 上传音频、moss-transcribe-diarize 模型、segments 结果、keyterms 输入框（自用平台）

Playground：https://platform.mosi.cn/app/playground

注册后有体验积分，够先跑几条真实录音。

云上 API（不要把 API Key 写进仓库）：

# 1）上传
curl https://api.mosi.cn/v1/files \
  -H "Authorization: Bearer $MOSS_API_KEY" \
  -F file=@meeting_sample.wav \
  -F purpose=audio

# 2）多说话人转写
curl https://api.mosi.cn/v1/audio/transcriptions \
  -H "Authorization: Bearer $MOSS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moss-transcribe-diarize",
    "version": "v20260410-streamparam-20260703",
    "file_id": "<file_id>",
    "diarize": true,
    "response_format": "diarized_json",
    "keyterms": ["MOSS", "SGLang"]
  }'

返回含 duration、text、segments[].start/end/text/speaker。还支持 stream=true（SSE）和 async=true。开源项目里把本地 verbose_json 和平台 diarized_json 映射成同一套 segments，切换后端只改配置。