本地语音转文字（ASR）如何选？我用945 条中文录音实测结果给你答案
本地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 承担了测试。源码在当前主分支编译成功后，CLI、静态库和公共头文件均正常生成，CPU 与 Metal 后端也都得到识别。
测试口径
数据集：Google FLEURS 普通话 test split
规模：共 3.074 小时，包含945 条真人录音
模型：全部统一采用 Q8_0 量化版本
推理：Metal、逐文件串行、贪心解码
评分：采用中文字符错误率 CER，数值越低越好
完整处理 945 条后，Qwen 位列第一
项目公开基准与结果几乎重合，由此可以判断模型文件、本地安装、评分链路和 C++ 推理均可信。参与比较的是四个完整跑完 945 条录音的模型。
错字、漏字以及额外出现的字，都会纳入 CER。这个指标可理解为“平均每 100 个字符需要改多少个”；Qwen 得到 7.65% 的 CER，也就是每 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 将其中两处“篇章”均写成“偏章”。
专有名词及中英混读依旧是共同难点。按读音改写或直接省略，常发生在国外人名、地名和长串英文上。因此，当业务包含客户名、产品名或药名时，热词或后处理词典依然不可缺少。
数字格式不仅影响得分，也会影响可读性。未启用 ITN 时，“802.11n”会被 SenseVoice 识别为“八零二点幺幺 n”；开启后则能还原为“802.11N”，所得内容更符合可交付书面文本的形式。
小模型确实要付出代价。重复生成、繁简切换和长句截断，是仅有 33.8MB 的 Moonshine Tiny 虽轻却存在的问题。Nemotron 已成功跑通流式接口，但遇到困难中文句子时，偶尔会夹入泰文字符。
这些模型可以在CPU上运行
约 19.85 分钟音频在 CPU 纯推理阶段耗时约 65.3 秒。针对同一批 100 条音频，SenseVoice 的 CPU 速度达到 18.2× 实时，Metal 则达到 59.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 对应中文质量，Whisper 面向多语言，SenseVoice 则兼顾轻量与高性能。面向隐私、本地运行和跨平台的 ASR 产品进行技术选型时，可把 transcribe.cpp 纳入候选名单。
这就是本次侦察的全部内容。
如果内容对你有帮助，顺手点个赞 +「♥️」。
关注「硅基斥候S01」，前线情报即可第一时间收到。下次侦察，我们再见。
登录查看剩余 70% 内容
