MOSS-Transcribe-Diarize

1. 项目概览

MOSS-Transcribe-Diarize 0.9B 是一个端到端音频理解模型，核心目标是 Speaker-Attributed, Time-Stamped Transcription，简称 SATS，即“带说话人归属和时间戳的转写”。它接收原始音频或视频文件，直接生成紧凑的结构化转写文本：

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

这意味着它不是传统的“ASR 模型先转文字、再接一个 diarization 模型、最后靠后处理对齐”的拼接方案，而是通过一个多模态模型联合完成转写、说话人分离和时间戳生成。

2. 它主要能做什么

2.1 长音频转写

它可以把会议、讲座、播客、访谈、视频、通话等长音频转成文本。官方论文摘要和 README 都强调最长可处理约 90 分钟输入，并使用 128K context 来承载长音频编码后的序列。

售前价值：客户不需要把长会议切成很多小段再手工拼接，适合从“录音文件”直接进入“可检索、可总结、可质检、可生成纪要”的流程。

2.2 说话人分离

模型直接输出 [S01]、[S02] 这类匿名说话人标签。它不是识别真实姓名，而是在同一段音频内尽量保持相同说话人的标签一致。

售前价值：会议纪要、访谈整理、客服质检都需要知道“谁在说”，否则只得到一整段文字，后续摘要和责任追踪都会变弱。

2.3 时间戳标注

每个片段都有起止时间戳，便于跳转回原始音频/视频，也便于生成字幕。

售前价值：客户可以从摘要、待办、质检问题直接定位到原始音视频证据，适合会议复盘、培训回看、法务留痕、客服抽检。

2.4 声学事件感知

官方介绍提到可选择性输出 acoustic event annotations，即声学事件标注。这里更适合作为“潜在增强能力”来看，实际 PoC 时需要用客户音频验证是否能稳定输出想要的事件标签。

适合探索：

• 掌声、笑声、沉默、噪声等会议/课堂事件。
• 客服场景中的异常停顿或环境噪声。
• 视频内容中的非语音事件辅助标注。

2.5 热词提示

它支持自定义 prompt 和 hotwords。官方建议在默认转写 prompt 后追加“热词提示：热词1, 热词2, 热词3”。

这对行业客户很关键，因为通用 ASR 最容易错在：

• 人名
• 公司名
• 产品名
• 专有术语
• 地名
• 英文缩写
• 业务系统名

2.6 字幕 Web App 与批处理

GitHub 包提供本地字幕工作流：

• 上传音频/视频。
• 审阅解析后的字幕片段。
• 导出 JSON/SRT/ASS。
• 如果安装了 FFmpeg/ffprobe，可压制生成 MP4。
• Web UI 支持简体中文和英文。

这让它不只是模型，还带了一个能给业务方演示的工具界面。

3. 核心能力清单

4. 架构与技术路线

官方模型架构如下：

主要组件：

SGLang Omni cookbook 给出的推理管线如下：

可以把它理解为三阶段：

1. Encoder：音频波形转 log-mel spectrogram，再经过 Whisper encoder 得到连续音频特征。
2. LLM Prefill：音频特征被投影到 LLM embedding 空间，替换 prompt 中的音频占位符，构建 KV cache。
3. AR Decode：Qwen3 风格解码器自回归生成带说话人和时间戳的转写文本。

SGLang Omni 的优化重点包括 CUDA Graph、chunked prefill、continuous batching、KV cache 管理、async decode、encoder cache 等。对长音频来说，自回归解码是主要耗时点。

5. 适用场景

5.1 智能会议纪要

这是最直接的场景。客户上传会议录音，模型输出带时间戳和说话人的逐字稿，然后再接 LLM 做摘要、议题、待办、风险、决策项。

价值点：

• 从“录音不可检索”变成“结构化文本资产”。
• 可以追溯每句话对应原音频时间点。
• 说话人标签让总结更接近真实会议过程。
• 可与企业知识库、OA、飞书/企微/钉钉会议系统集成。

5.2 呼叫中心质检

客服录音一般是双人或多人对话，既要识别内容，也要区分坐席和客户。MOSS-Transcribe-Diarize 原生输出 speaker-aware transcript，适合进入质检规则、情绪分析、敏感词检测、销售话术分析。

价值点：

• 降低人工抽检成本。
• 自动定位违规话术和关键片段。
• 与后续质检模型、摘要模型、CRM 工单联动。

5.3 访谈与调研整理

用户访谈、专家访谈、市场调研录音通常很长，而且多人交替发言。传统 ASR 只给文字，后期整理仍很累。带说话人和时间戳的逐字稿更适合研究员做编码、摘录和归因。

5.4 课堂/讲座/培训内容沉淀

课程录音、直播回放、线下培训视频都可以转成字幕和文本，再生成课程摘要、知识点、问答题、复习材料。

价值点：

• 提升培训内容复用率。
• 支持视频字幕生成。
• 方便学习资料检索。

5.5 播客和视频字幕生产

项目自带字幕 Web App 和批处理命令，支持导出 SRT/ASS/JSON，并可用 FFmpeg 压制视频。这对媒体运营、课程团队、短视频团队很友好。

5.6 合规录音和证据追溯

在司法、金融、保险、政务热线等场景，时间戳和原始音频定位很重要。模型输出不是最终证据，但可以作为检索和人工复核入口。

6. 不太适合的场景

7. 部署资源估算

官方没有直接写“最低显存”，但公开了模型规模、权重大小和单 H100 benchmark。下面是基于官方信息和工程经验的售前估算，正式项目需要用客户真实音频压测。

官方 SGLang Omni benchmark 在单张 H100 80GB 上给出：

RTF 小于 1 代表快于实时。例如 RTF 0.1237，理论上约 1 小时音频可在 7-8 分钟级别处理完，但这是 H100 80GB 条件下，且以官方 benchmark 为准。

售前建议：

• 只做演示：单张 24GB GPU 先验证。
• 客户会议纪要 PoC：24GB 起步，优先 48GB。
• 呼叫中心批量处理：48GB 起步，按并发和每天录音小时数估算。
• 90 分钟长会议 + 多并发：直接按 80GB 卡评估。
• 24GB/48GB 卡部署时，把 max-running-requests 从官方示例的 16 降到 1-4 起测。

8. 怎么用

8.1 环境准备

官方 GitHub README 使用 Python 3.12 和 Transformers 5.x：

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

主要 Python 包要求来自 pyproject.toml：

8.2 Python 调用

import torch
from transformers import AutoModelForCausalLM, AutoProcessor

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

model_id = "OpenMOSS-Team/MOSS-Transcribe-Diarize"
audio_path = "audio.wav"

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

model = AutoModelForCausalLM.from_pretrained(
    model_id,
    trust_remote_code=True,
    dtype="auto",
).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,
    do_sample=False,
    device=device,
    dtype=dtype,
)

print(result["text"])

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

注意：Hugging Face 加载需要 trust_remote_code=True，企业生产前必须做代码审计。

8.3 SGLang Omni 服务化

官方推荐 SGLang Omni：

hf download OpenMOSS-Team/MOSS-Transcribe-Diarize

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

调用：

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

长音频可调大：

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

8.4 vLLM 服务化

CUDA 12 环境可考虑 vLLM。官方提示需要使用包含该模型注册的 pinned vLLM nightly。

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

调用：

curl http://localhost:8000/v1/audio/transcriptions \
  -F model="OpenMOSS-Team/MOSS-Transcribe-Diarize" \
  -F file=@"audio.wav" \
  -F response_format="json" \
  -F temperature="0"

8.5 字幕 Web App

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。

批处理：

mtd-subtitle /path/to/input.mp4 \
  --model OpenMOSS-Team/MOSS-Transcribe-Diarize \
  --out-dir runs/example \
  --render

9. 售前可以怎么讲

9.1 面向会议纪要客户

“它不是简单把音频转成一整段文字，而是直接输出谁在什么时候说了什么。后面接大模型摘要，就可以生成会议纪要、待办事项、争议点和关键决策，并能回跳到原始录音。”

9.2 面向呼叫中心客户

“呼叫中心质检最怕只有全文、没有角色。MOSS-Transcribe-Diarize 能输出说话人标签和时间戳，后续可以区分坐席和客户，做话术合规、投诉识别、销售机会分析。”

9.3 面向音视频内容客户

“它提供本地字幕工作流，支持导出 SRT/ASS/JSON，也能配合 FFmpeg 压制视频。对课程、播客、访谈、直播回放，能把内容资产转成可检索、可分发、可复用的文本和字幕。”

9.4 面向信息安全/政企客户

“模型是 Apache-2.0 开源，可私有化部署，音频可以不出内网。对于有隐私和合规要求的会议录音、热线录音、执法记录、培训视频，这是比纯 SaaS 转写更容易过安全评审的路线。”

10. 常见客户问题

11. PoC 建议

11.1 PoC 数据准备

建议客户提供 3 类真实数据：

11.2 验收指标

11.3 Demo 剧本

1. 上传一段 10-20 分钟多人会议录音。
2. 输出带 [S01]、[S02]、时间戳的逐字稿。
3. 展示 verbose_json 分段结果。
4. 导出 SRT 字幕。
5. 用 LLM 对转写结果生成会议纪要、待办、风险点。
6. 点击时间戳回听原始音频片段。
7. 加入客户行业热词，再对比术语识别效果。

11.4 和竞品/替代方案对比

12. 风险和注意事项

12.1 新项目成熟度

项目 2026-07 开源，热度增长快，但生产稳定性还需要客户场景压测。不要只看官方 benchmark 就承诺可直接生产。

12.2 trust_remote_code=True

Hugging Face 加载需要执行远程自定义代码。企业环境必须：

• 固定模型版本和 commit sha。
• 审计 modeling_moss_transcribe_diarize.py、processing_moss_transcribe_diarize.py 等文件。
• 做镜像固化。
• 禁止生产环境动态拉取未审计代码。

12.3 长音频显存和延迟

长音频会带来很长的编码后序列和生成输出，实际消耗受音频长度、说话人数、输出文本长度、max_new_tokens、并发数影响。售前报价时要按“每天音频小时数”和“是否需要实时返回”估算。

12.4 说话人标签不是身份认证

[S01] 只是模型生成的匿名标签。它不能证明真实身份，也不能替代声纹识别或实名参会信息。

12.5 转写结果仍需人工复核

在金融、司法、医疗、政务等高风险场景，自动转写只能作为辅助。正式文本、证据材料、合规报告应保留人工审核流程。

12.6 Pro 版本差异

README 提到 MOSS-Transcribe-Diarize Pro 性能更强，可通过在线 Playground 使用。售前时要区分：

• 开源 0.9B：适合私有化、自部署、PoC。
• Pro：可能效果更强，但涉及在线服务、商业条款、数据流向和费用。

13. 我的售前判断

MOSS-Transcribe-Diarize 是一个比早期 MOSS 对话模型更贴近业务落地的项目。它解决的是很明确的高频问题：大量音频/视频内容无法结构化、无法检索、无法快速复盘。

我认为它最适合切入三类方案：

1. 会议纪要/培训内容沉淀：音频转逐字稿，再接大模型摘要和知识库。
2. 呼叫中心质检：说话人区分 + 时间戳 + 业务规则/LLM 质检。
3. 视频字幕和内容生产：自动生成字幕、文稿、摘要、切片素材。

如果客户关注数据安全、希望私有化部署，它的 Apache-2.0 许可和开源权重是明显优势。如果客户追求极致实时、极高并发或法律级准确率，则需要谨慎评估，并建议加入人工复核、专有名词热词、声纹/身份映射和后处理规则。

我的建议：售前可以先用“会议录音 30 分钟 + 客服录音 100 条 + 课程视频 5 条”的组合做 PoC。只要转写、说话人、时间戳和字幕导出能达到客户预期，这个项目就很容易串到会议纪要、质检、知识库和音视频内容资产化几个成熟业务话题里。

14. 参考资料

• Hugging Face 模型卡：OpenMOSS-Team/MOSS-Transcribe-Diarize
• GitHub 仓库：OpenMOSS/MOSS-Transcribe-Diarize
• 中文 README：README_zh.md
• 英文 README：README.md
• SGLang Omni Cookbook：moss_transcribe_diarize.md
• 技术报告：MOSS Transcribe Diarize Technical Report
• 在线 Playground：MOSS Transcribe Diarize Pro
• OpenMOSS 官网：open-moss.com
• MOSI.AI：mosi.cn