🔥 BRAVE 質押池已上線 — 在錢包搜尋 BRAVE 即可委託
简体

Brave基地

主权个人导向的本地中文语音识别技术选型（2026版）

Brave
@47c132035ed7a1105a867946b99d67af 人工智能研究 公开

云端语音识别服务的工作方式很直接：设备采集音频，上传到服务器，服务器返回文字。这个过程对使用者是透明的，但音频确实离开了本地设备。会议录音、客户通话、家庭对话都属于敏感内容，一旦上传，后续的存储、留存和二次使用就不再由使用者控制。

把识别过程放在本机可以避免这个问题，但模型选择会直接影响结果。Whisper 是目前知名度最高的开源方案，它以多语言通用性见长，中文并不是它的强项；在只有 CPU 的机器上，较大的 Whisper 模型也很难满足实时性要求。

本文讨论三个问题：这些模型之间是什么关系，哪些基准数字可以参考，以及在普通硬件上应该怎样选择和部署。

一、模型、引擎与流水线

语音识别系统通常由三层组成，区分这三层可以避免很多误解。

第一层是模型权重，也就是训练得到的参数。它决定了识别的能力上限，包括准确率、支持的语言和能否输出时间戳。常见的权重有 Whisper、SenseVoice、Paraformer 等。

第二层是推理引擎，负责把权重在具体硬件上运行起来。同一个权重可以有不同的引擎实现，例如 Whisper 可以用 faster-whisper、whisper.cpp 或 MLX Whisper 运行。引擎影响速度、内存占用和量化方式，但不改变模型的准确率上限。

第三层是流水线，包括语音活动检测（VAD）、分句、时间戳对齐和说话人分离等环节。流水线决定了长音频的处理效果和实时体验。

层次作用常见例子
模型权重决定准确率与能力边界Whisper large-v3、SenseVoiceSmall、Paraformer
推理引擎决定运行速度与资源占用faster-whisper、whisper.cpp、MLX
流水线决定长音频与实时体验VAD、标点模型、说话人分离

faster-whisper 经常被误认为是一个新模型，实际上它只是 Whisper 权重的一种推理实现。它使用 CTranslate2 并将权重做 int8 量化，在 CPU 上通常能把耗时降低到原来的二分之一到四分之一。更换引擎可以让同样的模型跑得更快，但不会让它变得更准。

二、三条技术路线

1. 自回归模型：Whisper

Whisper 将音频切分为 30 秒的窗口，由编码器提取声学特征，再由解码器逐 token 生成文本。每生成一个 token，解码器都需要重新运行一次；如果启用 beam search，还要同时维护多条候选路径。

这种结构带来两个结果。第一，计算量随输出长度增长，长句的延迟明显高于短句。第二，解码过程无法并行，在 CPU 上尤其明显。Whisper 的优势在于语言覆盖广、支持翻译、时间戳完善，生态也最成熟，因此它仍然是多语言场景的默认选择。

2. 非自回归模型：Paraformer 与 SenseVoice

这类模型采用非自回归结构，一次前向计算就能输出整段文本，不需要逐 token 迭代。阿里 FunASR 家族是主要代表：Paraformer 面向中文，参数量约 220M，支持时间戳和流式识别；SenseVoiceSmall 参数量约 234M，支持中文、粤语、英语、日语和韩语，并额外输出情感与音频事件标签。

由于省去了逐 token 解码，这类模型在 CPU 上的延迟通常比同参数量的自回归模型低数倍。代价是建模能力略弱，在极复杂的声学环境下准确率不一定占优，因此需要通过数据规模和训练策略来弥补。

3. LLM 式模型

第三类方案将语音编码器接入大语言模型，用生成的方式完成识别。代表模型包括 Fun-ASR（7.7B）、Fun-ASR-Nano（0.8B）、FireRedASR2（LLM 版 8B+，AED 版 1B）、Qwen3-ASR（1.7B 与 0.6B）和 GLM-ASR-Nano（1.5B）。

这类模型的准确率目前最高，但解码过程仍然是自回归的，参数量也大得多。它们适合有独立显卡的机器；在 CPU 上，Fun-ASR-Nano 大约只能达到 3.6 倍实时，可以用于离线转录，不适合实时字幕。

路线代表模型参数量语言覆盖CPU 实时性
自回归Whisper large-v31.55B99 种较差
非自回归SenseVoiceSmall234M5 种好
非自回归Paraformer220M中文为主好
LLM 式Fun-ASR-Nano0.8B中英日及方言勉强
LLM 式Qwen3-ASR1.7B52 种需要 GPU

三、如何阅读基准数字

字符错误率（CER）是最常用的指标，计算方式是替换、删除、插入的字符数除以参考文本的总字符数。CER 越低，识别越准确。但在比较不同来源的数字之前，需要先确认三件事。

第一是测试集。AISHELL-1 是近场朗读语料，WenetSpeech 的会议集包含远场、重叠语音和口音，同一模型在这两套数据上的 CER 可能相差数倍。

第二是文本归一化。是否去除标点、是否把数字统一写成阿拉伯数字，都会显著影响结果。FunASR 的官方基准使用 normalize_zh，会去掉标点并统一大小写。

第三是音频切分方式。长音频是否经过 VAD 切分、每段多长，会改变模型的实际输入，因此带 VAD 的端到端结果不能和纯模型结果直接比较。

一个常见的误读是拿 FireRedASR2 在 AISHELL-1 上的 0.64% 与 SenseVoice 在 184 条长音频基准上的 7.81% 相比。两组数字的测试集难度完全不同，这样的比较没有意义。

下面三组数据来自不同来源，应当分开阅读。

普通话与方言。 FireRedASR2 的论文在 24 个公开中文测试集上做了评测。普通话四个测试集的平均 CER 为：FireRedASR2-LLM 2.89%，FireRedASR2-AED 3.05%，Qwen3-ASR-1.7B 3.76%，豆包 ASR 3.69%，Fun-ASR 4.16%。19 种方言的平均 CER 分别为 11.55%、11.67%、11.85%、15.39% 和 12.76%。在普通话上，开源模型已经超过商业 API；方言仍然是所有模型的短板。

干净朗读。 一份 2026 年 10 月的第三方测试使用 136 段朗读音频，结果为：Qwen3-ASR-1.7B 2.4%，Qwen3-ASR-0.6B 2.8%，FireRedASR2-AED 2.9%，Fun-ASR-Nano 3.0%，Paraformer 与 SenseVoice 均为 4.4%，Whisper-large-v3 为 7.1%。

中文长音频。 FunASR 官方使用 184 条长音频（约 192 分钟）测试，SenseVoice 的 CER 为 7.81%，Fun-ASR-Nano 为 8.06%，Paraformer 为 10.18%。作为对照，whisper.cpp 的 small 为 22.12%，large-v3-turbo 为 23.15%，base 为 31.33%。

从第三组数据可以看出，在中文长音频上，同规模 Whisper 的错误率大约是 FunASR 系列的三倍。这个差距主要来自训练数据的语言分布，换推理引擎无法弥补。

四、一次实测

为了确认这些结论在实际硬件上是否成立，我在一台没有独立显卡的旧机器上做了一组对比。测试音频为 11 秒、16kHz 单声道语音，解码参数为 int8 量化、4 线程、beam size 5，并开启词级时间戳，与流式服务的默认配置保持一致。每组只运行一次，因此结果存在波动，适合看相对关系。

后端端到端耗时常驻内存
Whisper tiny18.4 秒0.53GB
Whisper small53.8 秒0.88GB
SenseVoiceSmall6.7 至 15.4 秒2.42GB

纯解码的速度差异同样明显：Whisper tiny 的实时因子为 0.11，base 为 0.18，small 为 0.53。实时因子小于 1 才能跟上说话速度，而流式管线会反复重解码，因此端到端耗时远高于单次推理。

测试过程中还发现了两个问题，它们会影响对结果的判断。

第一个问题是后端参数没有生效。服务默认使用 simulstreaming 策略，该策略会加载 PyTorch 版本的 Whisper，并额外下载约 460MB 的权重文件，此时 --backend faster-whisper 被忽略。只有显式指定 --backend-policy localagreement，才会真正使用 CTranslate2 加速。

第二个问题是内存代价。SenseVoice 的常驻内存约为 2.4GB，是 Whisper tiny 的四倍多。在内存有限的机器上，这意味着必须预留足够空间，否则系统会开始使用交换分区，延迟随之上升。

五、为什么 SenseVoice 在这类硬件上更合适

原因可以归结为五点。

第一，解码结构不同。非自回归模型一次前向就能输出整段文本，而 Whisper 需要逐 token 生成，beam search 还会成倍增加解码次数。在 CPU 上，这一项对速度的影响最大。

第二，训练数据的中文占比更高。Whisper 需要在 99 种语言之间分配模型容量，中文只是其中一部分；FunASR 系列以中文为主要目标，语料分布更集中。

第三，输出可以直接使用。SenseVoice 自带标点和逆文本归一化，能够把口语中的数字、日期转换为书面形式，不需要额外挂载标点模型。

第四，稳定性更好。Whisper 的小模型在静音、噪声或口音较重的段落容易重复输出或编造内容，非自回归结构不会出现这类逐字累积的错误。

第五，量化损失较小。在官方基准中，SenseVoice 的 fp32 结果为 7.81%，量化后的 Q8 运行时为 8.17%，差距有限，适合在 CPU 上部署。

这些优点都有对应的代价。SenseVoice 只支持五种语言，不能翻译，时间戳精度一般，长音频必须依靠 VAD 切分。它也不输出说话人信息，如果需要区分说话人，必须另外接入 CAM++、pyannote 或 Sortformer 等模型。

因此它并不适合所有场景。需要多语言互译时，Whisper large-v3 更合适；需要高精度词级时间戳时，Paraformer 或带强制对齐的流水线更可靠；方言和重口音场景下，FireRedASR2 与 Fun-ASR-Nano 的表现更好。

六、选型建议

使用条件建议选择主要原因
CPU、中文、实时SenseVoiceSmall准确率与延迟平衡较好
CPU、中文、离线批处理SenseVoiceSmall 或 Fun-ASR-Nano后者略准，速度更慢
8GB 显存Qwen3-ASR-1.7B 或 FireRedASR2-AED准确率进入第一梯队
24GB 显存FireRedASR2-LLM 或 Fun-ASR公开基准表现最好
多语言、翻译、时间戳Whisper large-v3语言覆盖与翻译能力
方言、口音FireRedASR2 或 Fun-ASR-Nano方言测试集优势明显
说话人分离ASR 模型加 pyannote 或 Sortformer两类能力解耦，便于分别优化
极低延迟流式Paraformer-streaming专为流式场景设计

如果硬件只有 CPU，且主要处理中文，SenseVoiceSmall 是一个合理的选择。继续提升准确率需要更强的硬件，而不是继续更换模型。

七、部署要点

我使用 WhisperLiveKit 作为服务端，它已经实现了 VAD、分句、流式协议和网页界面，后端可以在 Whisper、FunASR、Qwen3 等之间切换。

安装脚本会自动创建虚拟环境、安装 FunASR 依赖、修正 torch 与 torchaudio 的版本，并预先下载约 940MB 的模型文件。配置文件位于 packages/whisperlivekit/.wlk_env：

WLK_BACKEND=funasr
WLK_MODEL=SenseVoiceSmall
WLK_LANGUAGE=zh
WLK_HOST=127.0.0.1
WLK_PORT=9000

如果需要改回 Whisper，把 WLK_BACKEND 改为 faster-whisper，把 WLK_MODEL 改为 tiny 或 base，然后重启服务即可。

部署过程中有三个问题值得注意。

第一，后端参数可能被忽略。默认的 simulstreaming 策略不会使用 --backend faster-whisper 指定的引擎，而是加载 PyTorch 版 Whisper。需要 CTranslate2 加速时，应显式添加 --backend-policy localagreement。

第二，torchaudio 可能被安装成 CUDA 版本。FunASR 的依赖会从 PyPI 拉取 CUDA 版 torchaudio，与 CPU 版 torch 混用时导入失败，错误信息为 libcudart.so.13: cannot open shared object file。解决方法是从 PyTorch 的 CPU 索引重新安装：

uv pip install torch torchaudio --index-url https://download.pytorch.org/whl/cpu

第三，服务可能被启动两份。systemd 单元设置了自动重启，安装脚本又提供了 nohup 方式，两者同时存在时会启动两个进程。它们会并发写入同一个模型缓存文件，导致缓存损坏，表现为每次重启都重新下载模型。可以用下面的命令检查，正常情况下应当只有一行输出：

ps -eo pid,cmd | grep bin/wlk | grep -v grep

八、隐私边界

本地推理可以避免音频离开设备，但这并不自动意味着运行过程完全不联网。实际使用中需要确认几件事。

首先，模型文件通常来自公开仓库，首次安装时需要下载。下载完成后，部分库在启动时仍会检查更新。我观察到，即使模型已经缓存，模型仓库的下载接口仍然会联网校验并重新拉取若干小文件，整个过程约 5 秒。也就是说，"模型在本地"与"启动时不联网"是两件事。

常见的离线开关是设置 HF_HUB_OFFLINE=1 和 MODELSCOPE_OFFLINE=1。这两个变量能否让服务完全离线启动，我没有完成验证，建议在断网环境下重启一次服务并实际测试。

其次，服务默认应当只监听回环地址。需要给局域网内其他设备使用时，再改为监听所有地址，并放在带身份认证的反向代理后面。WhisperLiveKit 提供了 --api-token 参数，但它只提供基本的访问控制，不能替代完整的鉴权系统。

第三，解码上传音频时可能会写入临时文件。应当确认缓存目录位于加密磁盘上，或者定期清理。对于使用交换分区的机器，内存中的音频也可能被写入磁盘。

第四，模型权重本身也是需要信任的对象。PyTorch 的 .pt 文件使用 pickle 反序列化，加载过程可能执行代码；GGUF 和 ONNX 是纯数据格式，风险小得多。SenseVoice 同时提供这两种格式。如果供应链安全是首要考虑，应优先选择 GGUF 或 ONNX，并在下载后记录文件哈希。

隐私保护不是一句"部署在本地"就能完成的，它取决于运行时是否联网、数据落在哪里、以及依赖是否可信。

九、小结

对于中文、实时、无独立显卡这三个条件同时成立的场景，SenseVoiceSmall 是目前比较务实的选择。它在通用性上不如 Whisper，在准确率上不如 LLM 式模型，但在 CPU 上能够同时满足可用的准确率和可接受的延迟。

如果硬件条件改变，选择也应该随之改变。有独立显卡时，Qwen3-ASR 和 FireRedASR2 能把准确率再提高一个档次；需要多语言或翻译时，Whisper large-v3 仍然不可替代。

模型选型没有统一答案，只有对使用条件的清楚描述。

附录：来源