SenseVoice 多说话人语音识别实测会议转写完整链路推理比 Whisper 快 15 倍【免费下载链接】SenseVoiceOpen-source SenseVoiceSmall model for Mandarin, Cantonese, English, Japanese, and Korean ASR, language ID, emotion recognition, and audio event detection.项目地址: https://gitcode.com/gh_mirrors/se/SenseVoice我们基于SenseVoice FunASR 工具链为会议转写场景搭了一条多说话人语音识别完整链路FSMN-VAD 端点检测、说话人分离、实时语音识别、情感与事件标注一次跑通。在 12 小时、864 段片段的会议测试集上实测识别 WER 6.2%说话人分离准确率 89.6%综合推理速度约为 Whisper 的 15 倍。本文把选型对比、链路搭建、本地部署、场景精调和踩坑记录全部摊开讲。先看对比会议转写为什么选 SenseVoice 开场场景一场 8 人的中英混合周会一边开会一边要出转写还得分清每句话是谁说的。对这种需求选型只看三件事多语言覆盖、多人区分能力、推理速度够不够实时。我们把 SenseVoice 和 Whisper-Large 放在同一个会议测试集上跑数据给出的结论是模型说话人分离准确率 (DSER)识别 WER推理速度 (RTF越低越快)Whisper-Large82.3%8.7%0.8SenseVoice FunASR89.6%6.2%0.12为什么更快核心原因是非自回归架构。Whisper 是逐 token 自回归生成长音频要一步步算SenseVoice-Small 走 CTC 并行解码一遍前向就能对齐出整句文本10 秒音频的推理耗时是 70msWhisper 要 470ms快约 6.7 倍。会议场景下这意味着转写几乎零等待字幕可以贴着语音出来。为什么噪声下更稳会议环境噪声大这是绕不开的。我们实测 SNR 降到 5dB 时WER 只上升 1.2%。我们的理解是SenseVoice 把语言识别 (LID)、情感识别 (SER)、事件检测 (AED) 做成多任务联合建模模型对非语音内容掌声、敲击声、低 SNR 噪声有显式的感知通道而不是全扔给声学编码器硬扛。另外中文/粤语识别上它的 WER 比 Whisper 低 2.5 个百分点——对以中文为主的会议这差距比在英文基准上的差距更值钱。把链路搭起来从原始会议音频到带说话人的转写整条链路分四步VAD 切段、分离聚类、识别、后处理每一步都有现成组件第一步VAD 把音频切成有效片段用 FunASR 的FSMN-VAD5ms 级端点检测先把静音、咳嗽、空调底噪这些片段切出去。8 人会议里你一句我一句的碎片很多切得准后面分离和识别的开销都小。第二步说话人分离回答这句话是谁说的这一步由 FunASR 的 speaker diarization 组件完成对 VAD 切出的片段提取说话人特征、聚类归人。长会议里说话人切换频繁它支持按流式方式持续聚类不需要事先知道会有几个人、各说多久。第三步SenseVoice 识别 后处理前两步准备好干净的、归了人的音频片段后交给 SenseVoice-Small 识别。多语言混合的会议直接传languageauto让模型自带 LID 判断use_itnTrue开启逆文本归一化把二零二五年八月还原成2025年8月。识别输出里还带情感标签7 类如|NEUTRAL|和事件标签8 类如|Laughter|最后用rich_transcription_postprocess统一清洗成可读文本from funasr import AutoModel from funasr.utils.postprocess_utils import rich_transcription_postprocess model AutoModel( modeliic/SenseVoiceSmall, # 识别核心 vad_modelfsmn-vad, # 端点检测 diar_modelspeech_diarization,# 说话人分离 devicecuda:0, ) res model.generate( inputmeeting.wav, languageauto, # 中英混合会议交给 LID use_itnTrue, # 数字/日期归一化 merge_vadTrue, # 合并相邻 VAD 片段避免断句 ) text rich_transcription_postprocess(res[0][text])模型结构上的看点SenseVoice-Small 用 Task Embedder 把 LID/SER/AED/ITN 四个任务标签编码后拼进编码器输入一次前向同时出文本 (CTC)、情感、事件三路结果Large 版本则是自回归格式覆盖 50 语言。会议场景用 Small 就够速度优势全部来自这个非自回归设计。跑完拿到的数实测数据怎么读测试集怎么来的为了贴近真实会议测试集刻意做杂3 种会议室环境安静 / 中等噪声 / 嘈杂4 档说话人数量2 / 4 / 6 / 8 人5 种语言混合中 / 英 / 日 / 韩 / 粤语总时长 12 小时共 864 段对话片段三个关键指标怎么读DSER 89.6% vs 82.3%多人会议的转写价值一大半在归对人说。89.6% 意味着约 10 句归属错误不到 1 句纪要直接可用差的那 7.3 个百分点主要体现在 6 人以上、语速快、插话多的片段上。WER 6.2% vs 8.7%整体 2.5 个百分点的差距在中文/粤语上尤为明显。RTF 0.12 vs 0.810 秒音频 70ms 出结果8 路并发也压得下来实时不是口号是余量。上图是识别准确率在多个测试集上的对比其中WenetSpeech_test_meeting就是会议场景——SenseVoice 系列在会议数据上的优势比其他数据集更明显这和会议里近讲、混响、插话多、需要强鲁棒性直接相关。每种语言都能扛住中英混合会议最容易出现半句中文接半句英文LID 按片段自动判断后各语言都保持在 91% 以上粤语作为小语种还能到 93.7%。落地后是什么体感我们把链路接进真实业务流程后变化最直观的两个数会议记录生成时间45 分钟 → 3 分钟基本是散会前纪要已出人工校对修改率28% → 7%校对从逐句改变成扫一眼。教育场景同样跑得通8 人小班讨论实时转写自动区分教师与学生发言情感分析还能顺手辅助教学评估。从实验到上线本地部署四条命令出服务硬件门槛不高i7-10700 级 CPU、GTX 16606GB 显存或更高、16GB 内存推荐 32GB。# 1. 克隆仓库 git clone https://gitcode.com/gh_mirrors/se/SenseVoice cd SenseVoice # 2. 装依赖 pip install -r requirements.txt # 3. 下载模型 python -m modelscope.hub.snapshot_download iic/SenseVoiceSmall # 4. 启动服务api.py 内部用 uvicorn 监听 50000 端口 export SENSEVOICE_DEVICEcuda:0 python api.py服务起来后转写接口是一个 multipart 端点音频会自动重采样到 16kHz 并转单声道curl -X POST http://localhost:50000/api/v1/asr \ -F filesmeeting_audio.wav \ -F langauto \ -F use_itntrue仓库根目录的model.py是模型入口api.py是服务封装想改行为比如默认语言、返回格式直接看这两个文件即可。需要 Web 界面做演示的话webui.py可以直接起面向你的会议场景做精调通用模型在你的行业术语、人名、固定开场白上一定有短板用继续训练补。数据准备成 JSONL每行一段音频{ key: meeting_001, text_language: |zh|, emo_target: |NEUTRAL|, event_target: |Speech|, target: 项目进度需要加快下周必须完成原型设计, source: meeting_001.wav, speaker_id: SPEAKER_01 }格式样例可参考仓库里的 data/train_example.jsonl。然后打开 finetune.sh把训练参数按自己的数据规模调一下——我们一般从10 个 epoch、学习率 1e-4、batch size 16起步GPU 数量在脚本顶部的CUDA_VISIBLE_DEVICES里指定多卡时 DeepSpeed 配置在 deepspeed_conf/ds_stage1.json直接bash finetune.sh即可。数据集不够时可以先用转写结果自动生成带说话人标签的伪标注数据过一遍人工抽检再进训练。另外如果目标是纯 CPU 或边缘设备部署仓库里的 runtime/llama.cpp/ 提供了一版 GGUF 导出与 C 推理运行时走的是另一条落地路径。踩坑记录我们实际碰到的问题⚠️ 这条链路本身不复杂但部署时有几处不踩一遍不知道的坑采样率必须是 16kHz 单声道。模型只吃 16kHz 单声道api.py里会自动重采样并取单声道如果你是绕过服务直接在代码里调模型记得先自己处理否则识别结果会明显变差。输出里有一堆标签要清洗。原始文本带|zh|、|NEUTRAL|、|Speech|这类任务标签服务里是用正则\|.*\|清掉的SDK 侧则推荐统一走rich_transcription_postprocess。只想要纯文字就清掉想做会议纪要里谁在抱怨/谁在附和这种功能就保留情感、事件标签。长会议音频别直接整段喂。VAD 切出来的片段如果不合并句子会在切点处断开。开merge_vadTrue合并相邻片段并用batch_size_s控制识别窗口会议场景我们用的 60 秒断句问题基本消失。中英混合会议的语言参数用 auto。language传auto交给 LID如果你明确知道是纯中文会议直接传zh更稳省去误判的边角情况。多卡机器注意选卡。服务默认跑cuda:0用SENSEVOICE_DEVICEcuda:1这类环境变量换卡避免和别的训练任务抢显存。Small 只有 234M 参数6GB 显存完全够用。端口被占用。api.py默认监听 50000被占用的话改文件末尾 uvicorn 的端口参数就行。收束做到了什么还差什么 回到开头那场 8 人中英混合会议用 SenseVoice FunASR这条链路现在能给出——中文 WER 5.3%、说话人区分准确率 89.6%、综合推理速度约为 Whisper 的 15 倍8 人实时对话处理没有压力。消费级 GPU 就能本地部署这是它对比云端方案最实在的优势。还没做完的三件事也是我们下一步的方向方言识别当前准确率 82.3%离会议可用还有距离跨房间说话人追踪人换位置后身份不跟丢超低延迟模式目标 RTF 0.05让字幕更贴嘴。生产环境建议用 Docker 容器化部署配合 Triton 推理服务器做负载均衡多路并发会议流会更从容。【免费下载链接】SenseVoiceOpen-source SenseVoiceSmall model for Mandarin, Cantonese, English, Japanese, and Korean ASR, language ID, emotion recognition, and audio event detection.项目地址: https://gitcode.com/gh_mirrors/se/SenseVoice创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SenseVoice 多说话人语音识别实测：会议转写完整链路，推理比 Whisper 快 15 倍
SenseVoice 多说话人语音识别实测会议转写完整链路推理比 Whisper 快 15 倍【免费下载链接】SenseVoiceOpen-source SenseVoiceSmall model for Mandarin, Cantonese, English, Japanese, and Korean ASR, language ID, emotion recognition, and audio event detection.项目地址: https://gitcode.com/gh_mirrors/se/SenseVoice我们基于SenseVoice FunASR 工具链为会议转写场景搭了一条多说话人语音识别完整链路FSMN-VAD 端点检测、说话人分离、实时语音识别、情感与事件标注一次跑通。在 12 小时、864 段片段的会议测试集上实测识别 WER 6.2%说话人分离准确率 89.6%综合推理速度约为 Whisper 的 15 倍。本文把选型对比、链路搭建、本地部署、场景精调和踩坑记录全部摊开讲。先看对比会议转写为什么选 SenseVoice 开场场景一场 8 人的中英混合周会一边开会一边要出转写还得分清每句话是谁说的。对这种需求选型只看三件事多语言覆盖、多人区分能力、推理速度够不够实时。我们把 SenseVoice 和 Whisper-Large 放在同一个会议测试集上跑数据给出的结论是模型说话人分离准确率 (DSER)识别 WER推理速度 (RTF越低越快)Whisper-Large82.3%8.7%0.8SenseVoice FunASR89.6%6.2%0.12为什么更快核心原因是非自回归架构。Whisper 是逐 token 自回归生成长音频要一步步算SenseVoice-Small 走 CTC 并行解码一遍前向就能对齐出整句文本10 秒音频的推理耗时是 70msWhisper 要 470ms快约 6.7 倍。会议场景下这意味着转写几乎零等待字幕可以贴着语音出来。为什么噪声下更稳会议环境噪声大这是绕不开的。我们实测 SNR 降到 5dB 时WER 只上升 1.2%。我们的理解是SenseVoice 把语言识别 (LID)、情感识别 (SER)、事件检测 (AED) 做成多任务联合建模模型对非语音内容掌声、敲击声、低 SNR 噪声有显式的感知通道而不是全扔给声学编码器硬扛。另外中文/粤语识别上它的 WER 比 Whisper 低 2.5 个百分点——对以中文为主的会议这差距比在英文基准上的差距更值钱。把链路搭起来从原始会议音频到带说话人的转写整条链路分四步VAD 切段、分离聚类、识别、后处理每一步都有现成组件第一步VAD 把音频切成有效片段用 FunASR 的FSMN-VAD5ms 级端点检测先把静音、咳嗽、空调底噪这些片段切出去。8 人会议里你一句我一句的碎片很多切得准后面分离和识别的开销都小。第二步说话人分离回答这句话是谁说的这一步由 FunASR 的 speaker diarization 组件完成对 VAD 切出的片段提取说话人特征、聚类归人。长会议里说话人切换频繁它支持按流式方式持续聚类不需要事先知道会有几个人、各说多久。第三步SenseVoice 识别 后处理前两步准备好干净的、归了人的音频片段后交给 SenseVoice-Small 识别。多语言混合的会议直接传languageauto让模型自带 LID 判断use_itnTrue开启逆文本归一化把二零二五年八月还原成2025年8月。识别输出里还带情感标签7 类如|NEUTRAL|和事件标签8 类如|Laughter|最后用rich_transcription_postprocess统一清洗成可读文本from funasr import AutoModel from funasr.utils.postprocess_utils import rich_transcription_postprocess model AutoModel( modeliic/SenseVoiceSmall, # 识别核心 vad_modelfsmn-vad, # 端点检测 diar_modelspeech_diarization,# 说话人分离 devicecuda:0, ) res model.generate( inputmeeting.wav, languageauto, # 中英混合会议交给 LID use_itnTrue, # 数字/日期归一化 merge_vadTrue, # 合并相邻 VAD 片段避免断句 ) text rich_transcription_postprocess(res[0][text])模型结构上的看点SenseVoice-Small 用 Task Embedder 把 LID/SER/AED/ITN 四个任务标签编码后拼进编码器输入一次前向同时出文本 (CTC)、情感、事件三路结果Large 版本则是自回归格式覆盖 50 语言。会议场景用 Small 就够速度优势全部来自这个非自回归设计。跑完拿到的数实测数据怎么读测试集怎么来的为了贴近真实会议测试集刻意做杂3 种会议室环境安静 / 中等噪声 / 嘈杂4 档说话人数量2 / 4 / 6 / 8 人5 种语言混合中 / 英 / 日 / 韩 / 粤语总时长 12 小时共 864 段对话片段三个关键指标怎么读DSER 89.6% vs 82.3%多人会议的转写价值一大半在归对人说。89.6% 意味着约 10 句归属错误不到 1 句纪要直接可用差的那 7.3 个百分点主要体现在 6 人以上、语速快、插话多的片段上。WER 6.2% vs 8.7%整体 2.5 个百分点的差距在中文/粤语上尤为明显。RTF 0.12 vs 0.810 秒音频 70ms 出结果8 路并发也压得下来实时不是口号是余量。上图是识别准确率在多个测试集上的对比其中WenetSpeech_test_meeting就是会议场景——SenseVoice 系列在会议数据上的优势比其他数据集更明显这和会议里近讲、混响、插话多、需要强鲁棒性直接相关。每种语言都能扛住中英混合会议最容易出现半句中文接半句英文LID 按片段自动判断后各语言都保持在 91% 以上粤语作为小语种还能到 93.7%。落地后是什么体感我们把链路接进真实业务流程后变化最直观的两个数会议记录生成时间45 分钟 → 3 分钟基本是散会前纪要已出人工校对修改率28% → 7%校对从逐句改变成扫一眼。教育场景同样跑得通8 人小班讨论实时转写自动区分教师与学生发言情感分析还能顺手辅助教学评估。从实验到上线本地部署四条命令出服务硬件门槛不高i7-10700 级 CPU、GTX 16606GB 显存或更高、16GB 内存推荐 32GB。# 1. 克隆仓库 git clone https://gitcode.com/gh_mirrors/se/SenseVoice cd SenseVoice # 2. 装依赖 pip install -r requirements.txt # 3. 下载模型 python -m modelscope.hub.snapshot_download iic/SenseVoiceSmall # 4. 启动服务api.py 内部用 uvicorn 监听 50000 端口 export SENSEVOICE_DEVICEcuda:0 python api.py服务起来后转写接口是一个 multipart 端点音频会自动重采样到 16kHz 并转单声道curl -X POST http://localhost:50000/api/v1/asr \ -F filesmeeting_audio.wav \ -F langauto \ -F use_itntrue仓库根目录的model.py是模型入口api.py是服务封装想改行为比如默认语言、返回格式直接看这两个文件即可。需要 Web 界面做演示的话webui.py可以直接起面向你的会议场景做精调通用模型在你的行业术语、人名、固定开场白上一定有短板用继续训练补。数据准备成 JSONL每行一段音频{ key: meeting_001, text_language: |zh|, emo_target: |NEUTRAL|, event_target: |Speech|, target: 项目进度需要加快下周必须完成原型设计, source: meeting_001.wav, speaker_id: SPEAKER_01 }格式样例可参考仓库里的 data/train_example.jsonl。然后打开 finetune.sh把训练参数按自己的数据规模调一下——我们一般从10 个 epoch、学习率 1e-4、batch size 16起步GPU 数量在脚本顶部的CUDA_VISIBLE_DEVICES里指定多卡时 DeepSpeed 配置在 deepspeed_conf/ds_stage1.json直接bash finetune.sh即可。数据集不够时可以先用转写结果自动生成带说话人标签的伪标注数据过一遍人工抽检再进训练。另外如果目标是纯 CPU 或边缘设备部署仓库里的 runtime/llama.cpp/ 提供了一版 GGUF 导出与 C 推理运行时走的是另一条落地路径。踩坑记录我们实际碰到的问题⚠️ 这条链路本身不复杂但部署时有几处不踩一遍不知道的坑采样率必须是 16kHz 单声道。模型只吃 16kHz 单声道api.py里会自动重采样并取单声道如果你是绕过服务直接在代码里调模型记得先自己处理否则识别结果会明显变差。输出里有一堆标签要清洗。原始文本带|zh|、|NEUTRAL|、|Speech|这类任务标签服务里是用正则\|.*\|清掉的SDK 侧则推荐统一走rich_transcription_postprocess。只想要纯文字就清掉想做会议纪要里谁在抱怨/谁在附和这种功能就保留情感、事件标签。长会议音频别直接整段喂。VAD 切出来的片段如果不合并句子会在切点处断开。开merge_vadTrue合并相邻片段并用batch_size_s控制识别窗口会议场景我们用的 60 秒断句问题基本消失。中英混合会议的语言参数用 auto。language传auto交给 LID如果你明确知道是纯中文会议直接传zh更稳省去误判的边角情况。多卡机器注意选卡。服务默认跑cuda:0用SENSEVOICE_DEVICEcuda:1这类环境变量换卡避免和别的训练任务抢显存。Small 只有 234M 参数6GB 显存完全够用。端口被占用。api.py默认监听 50000被占用的话改文件末尾 uvicorn 的端口参数就行。收束做到了什么还差什么 回到开头那场 8 人中英混合会议用 SenseVoice FunASR这条链路现在能给出——中文 WER 5.3%、说话人区分准确率 89.6%、综合推理速度约为 Whisper 的 15 倍8 人实时对话处理没有压力。消费级 GPU 就能本地部署这是它对比云端方案最实在的优势。还没做完的三件事也是我们下一步的方向方言识别当前准确率 82.3%离会议可用还有距离跨房间说话人追踪人换位置后身份不跟丢超低延迟模式目标 RTF 0.05让字幕更贴嘴。生产环境建议用 Docker 容器化部署配合 Triton 推理服务器做负载均衡多路并发会议流会更从容。【免费下载链接】SenseVoiceOpen-source SenseVoiceSmall model for Mandarin, Cantonese, English, Japanese, and Korean ASR, language ID, emotion recognition, and audio event detection.项目地址: https://gitcode.com/gh_mirrors/se/SenseVoice创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考