本地ASR模型怎么挑？看945条中文录音对中文质量、多语言覆盖、体积速度的实测！
核心内容：
1. 测试环境、数据集、模型及评分标准：实测方法与背景
2. 从多语言覆盖、体积速度及中文质量比较四大模型性能
3. 中文/体积/多语言优先时，不同需求对应的模型选择

硅基斥候S01 · 2026.07 模型实测

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

会议录音可由这类本地语音转文字能力整理，并为会议纪要准备逐字稿；访谈、课程与播客也能借此转写，视频字幕同样可以生成。它还可嵌入桌面软件、手机应用或边缘设备，成为本地语音识别底座。

同一批普通话录音被我用于逐个测试此前下载的 7 个中文或多语言模型，安装方式则是从源码完成。

先说结论

若把中文质量放在首位，我会选择 Qwen3-ASR 0.6B；SenseVoice Small 适合把体积和速度放在首位的需求，更加划算；Whisper 则在需要覆盖更多语言时，仍可作为稳妥基线。

它为何能运行这些不同模型？

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

一段音频

↓

transcribe.cpp

↓

Qwen / Whisper / SenseVoice / 其他模型

↓

转写文字

项目名里的 .cpp 表示 C++ 源代码的常用后缀。也就是说，这套运行时无需先启动 Python 服务，便能编译成本地程序，并被桌面软件、手机应用或边缘设备嵌入。

测试环境

一台内存为32GB、搭载 Apple M5 的 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的结果紧跟其后，速度反而更快；SenseVoice虽然准确率稍低，文件却仅有 241MB，性能差距由此十分明显。

以 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的错误是将两处“篇章”均写成“偏章”。

中英混读和专有名词依然是共同难题。人名、国外地名和较长英文内容容易被漏掉，或被按照读音改写。若业务包含药名、产品名、客户名，仍需借助热词或后处理词典。

数字格式不仅影响评分，也会影响文本可读性。“八零二点幺幺 n”是SenseVoice 默认对“802.11n”的写法；ITN启用后，结果能还原为“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则用于多语言场景。若产品要求兼顾跨平台 ASR、本地和隐私，技术选型名单中值得加入transcribe.cpp。

本次侦察到此结束。

如果内容有用，顺手点个赞 +「♥️」。

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

登录查看剩余 70% 内容