本地语音转文字（ASR）如何选？945 条中文录音实测给出答案

本地ASR模型该如何挑选？945条中文录音从多语言覆盖、体积速度及中文质量三个方面给出实测依据！
核心内容：
1. 方法与实测背景（评分标准、模型、数据集、测试环境）
2. 中文质量、体积速度及多语言覆盖：四大模型横向评测
3. 中文/体积/多语言需求分别对应哪些模型

硅基斥候S01 · 2026.07 模型实测

最近在 HN 上热度很高的 transcribe.cpp，是一款开源本地语音转文字运行工具。Qwen、Whisper、SenseVoice等语音识别模型都能由它在本地设备运行，将音频内容转换为文字。

从会议录音整理及会议纪要逐字稿准备，到访谈、课程、播客转写和视频字幕生成，都能使用这类本地语音转文字能力；它还可嵌入桌面软件、手机应用或边缘设备，充当本地语音识别底座。

完成源码安装并下载 7 个中文或多语言模型后，我让它们分别处理同一批普通话录音。

结论先说

若优先考虑中文质量，我会选择 Qwen3-ASR 0.6B；若关注多语言覆盖，稳妥基线仍是Whisper；若优先考虑速度和体积，SenseVoice Small更具性价比。

它为何可以同时运行这些模型？

transcribe.cpp 更像一个“统一播放器”。Qwen、Whisper、SenseVoice 是不同的语音识别大脑，模型文件需要分别下载；transcribe.cpp 负责用同一套 C/C++ 接口把它们运行起来。

一段音频

↓

transcribe.cpp

↓

Qwen / Whisper / SenseVoice / 其他模型

↓

转写文字

项目名里的 .cpp 这是 C++ 源代码的常见后缀，含义是该运行时无需预先启动 Python 服务，编译为本地程序后即可嵌入边缘设备、手机应用或桌面软件。

测试环境

一台采用 Apple M5并配备32GB 内存的 Mac承担了本次测试。源码在当前主分支顺利完成编译，CPU 和Metal后端均被识别，公共头文件、静态库以及CLI也都成功生成。

测试口径

数据集：Google FLEURS 普通话 test split

规模：共 3.074 小时、945 条真人录音

模型：全部采用 Q8_0 量化版本

推理：Metal、逐文件串行、贪心解码

评分：采用中文字符错误率 CER，数值越低越好

完整处理 945 条后，Qwen位列第一

先比较完整处理完 945 条录音的四个模型。实测结果与项目公开基准几乎一致，表明此次本地安装、模型文件、C++ 推理以及评分链路值得信赖。

错字、漏字以及额外出现的字都会纳入CER 统计，因此它可理解为“平均每 100 个字符中有多少个需要修改”。Qwen 的 CER 达到 7.65%，粗略对应每 100 个标准字符约需改动 7.65 个字符。

01 · 中文质量排名第一

Qwen3-ASR 0.6B

CER 7.65%　完全正确 46.5%　速度 10.5×

02 · Fun-ASR Nano 2512

CER 8.59%　完全正确 44.7%　速度 14.0×

03 · SenseVoice Small

CER 10.11%　完全正确 33.3%　速度 57.8×

04 · Moonshine Tiny 中文

CER 13.74%　完全正确 16.5%　速度 23.0×

在945 条中共有 5 次生成失败。

此次中文质量最佳的是Qwen，代价是模型文件约 811MB，体积不算小。Fun-ASR排名紧随其后，而且运行更快。只有 241MB的SenseVoice虽然准确率稍逊，但性能差距十分明显。

将 Whisper 作为对照组

Whisper、MOSS等模型若串行处理完整数据集，所需时间更长。为确保设置相同，我按固定间隔从同一数据集抽取 100 条，让 7 个模型处理完全一致的音频。

七模型共同样本 CER

6.83 Qwen3-ASR 0.6B

7.51 Whisper Large v3 Turbo

7.91 Fun-ASR Nano 2512

9.19 SenseVoice Small

9.22 MOSS Transcribe-Diarize

12.77 Moonshine Tiny 中文

19.18 Nemotron 3.5 ASR Streaming

所有数字均以百分比表示，数值越低越好。因为100 条样本形成的置信区间较宽，且Qwen、Whisper、Fun-ASR的区间存在重叠，所以不能将小数点后的排名形容为“碾压”。

至少能够确定：面对这批普通话录音，Qwen已经与 Whisper处于同一水平，本次结果还更低。Whisper的长处仍是多语言覆盖和成熟度，并不代表其中文识别一定更准确。

除排行榜外，我还发现了这些问题

面对清晰短句，各模型的差距并不明显。六个模型都准确识别了“这并不是告别，这是一个篇章的结束，也是新篇章的开始”，只有Nemotron将句中两处“篇章”转写为“偏章”。

专有名词与中英混读依旧是共同难点。国外地名、人名以及较长的英文内容，容易被遗漏或依据读音改写。如果业务涉及药名、产品名或客户名，依然需要配置热词或使用后处理词典。

数字格式既会影响评分，也会影响文本可读性。未开启 ITN 时，SenseVoice会把“802.11n”识别为“八零二点幺幺 n”；开启后结果可还原为“802.11N”，书面文本更接近交付标准。

小模型确实需要付出代价。Moonshine Tiny只有33.8MB，确实十分轻量，但会发生重复生成、长句截断及繁简切换。Nemotron的流式接口虽然已成功运行，处理困难中文句子时却偶尔会夹杂泰文字符。

这些模型能够在CPU上运行

针对同一批 100 条音频，SenseVoice在Metal上达到 59.3× 实时速度，在CPU上也达到 18.2×。对约 19.85 分钟的音频，CPU纯推理阶段约耗时 65.3 秒。

这一结果只能说明轻量模型可在 CPU 上高效运行，不能据此认为所有模型速度都相同。Qwen、Whisper和MOSS采用不同计算路线，仍需在具体机器上分别测试。

为测试流式能力，我将 10.38 秒的一条录音拆成每段 1.12 秒，再依次送入Nemotron。partial 文本从第 3 个音频块结束后开始显示，最终输出与离线推理一致。

但这里存在一个边界：现成的麦克风采集、静音检测、实时字幕界面及编辑器并不在仓库中。仓库实际提供流式 API，而CLI仅负责将 WAV 文件切块后送入。

最后，我究竟会如何选择？

如果产品主要服务中文场景，并将最终稿质量放在首位，我会优先考虑 Qwen3-ASR 0.6B 。它虽然并非最轻量，却在本次 945 条完整测试中取得了最低错误率。

若CPU 轻松运行是目标，或需快速完成本地批处理，SenseVoice Small 更适合。若看重成熟生态，或要处理未知语言及多语言，则仍应考虑 Whisper。

transcribe.cpp的最大价值，是能把这些选项纳入同一套本地运行时。它已经具备产品底座的能力，但还不是下载后即可直接录音转文字的成品软件。

一句话结论

Qwen对应中文质量需求，SenseVoice适合轻量高性能场景，Whisper则用于多语言任务。transcribe.cpp应纳入本地、隐私、跨平台 ASR 产品的技术选型范围。

本次侦察到这里就结束了。

如果内容对你有帮助，欢迎顺手点赞 +「♥️」。

关注「硅基斥候S01」，即可第一时间获取前线情报。我们下次侦察再见。

登录查看剩余 70% 内容