背景：为什么要在树莓派上做本地语音识别

给设备加语音识别功能，最常见的做法是接云端 ASR 服务（讯飞、百度、OpenAI 等）。功能能跑通，但存在三个问题：

1. 延迟在往返不在模型：音频上传、服务器排队、推理、结果返回，这一来一回比模型本身的推理时间还长。
2. 隐私是硬约束：音频要发到第三方服务器，医疗设备、车载场景直接不适用，离线环境更是没法用。
3. 长期成本会放大：一台 7×24 持续录音的设备，按云端 ASR 的计费标准跑一年，费用相当可观。

whisper.cpp 是 ggml-org 用纯 C/C++ 重写的 OpenAI Whisper 推理引擎（GitHub 51K Star），没有 Python、PyTorch、CUDA 依赖，一条命令即可在树莓派上把音频转成文字，完全离线运行。

环境：树莓派 4/5（64 位系统）、cmake、gcc/g++。下文命令均在树莓派 64 位 OS 上验证。

一、编译安装

git clone https://github.com/ggml-org/whisper.cpp.git
cd whisper.cpp
sh ./models/download-ggml-model.sh small   # 下载模型（这里以 small 为例）
cmake -B build
cmake --build build -j --config Release

编译产物在 build/bin/ 下，核心是 whisper-cli（文件转录）和 whisper-stream（流式转录）。

二、模型选型

whisper.cpp 提供 tiny 到 large-v3 六个级别的模型，磁盘和内存占用差一个数量级，中文效果也相差很大：

模型	磁盘占用	运行时内存	中文效果	适合设备
tiny	75 MiB	~273 MB	一般	树莓派 3B+
base	142 MiB	~388 MB	凑合	树莓派 4 (1GB)
small	466 MiB	~852 MB	可用	树莓派 4 (2GB+)、树莓派 5
medium	1.5 GiB	~2.1 GB	好	树莓派 5 (4GB+)
large-v3-turbo	1.5 GiB	~2.4 GB	很好	PC / Mac / 服务器

结论：中文场景 small 是最低可用门槛，tiny 和 base 的中文断句奇怪、同音字错误多，只适合英文或极短指令。以上数据出自 README 的模型表。

三、基础转录

./build/bin/whisper-cli -m models/ggml-small.bin -l zh -f recording.wav

-l zh 指定中文，-f 指定音频文件。作者在树莓派 4（4GB）上测出：tiny 模型编码 11 秒音频约 13.8 秒，比实时慢，不适合流式；把编码器音频上下文从默认 1500 降到 512，可降到约 5 秒：

./build/bin/whisper-cli -m models/ggml-tiny.bin -l zh -f audio.wav -ac 512 -t 4

代价是长句子的上下文理解变弱，对短指令（如"打开客厅的灯"）影响不大。

四、流式转录

真正有用的是流式识别——说一句转一句。需要先装 SDL2 并重新编译：

sudo apt install libsdl2-dev
cmake -B build -DWHISPER_SDL2=ON
cmake --build build -j --config Release

./build/bin/whisper-stream -m models/ggml-small.bin \
    --step 4000 --length 8000 -c 0 -t 4 -ac 512 -vth 0.6 -l zh

三个关键参数：

• --step 4000：每隔 4 秒生成一个文本片段，步长越小越灵敏、CPU 负载越高。
• --length 8000：每次推理的音频窗口 8 秒，窗口越长上下文越好、延迟越大。
• -vth 0.6：VAD（语音活动检测）阈值，音量超过阈值才触发推理，不说话时不推理，是省 CPU 的关键。

作者在树莓派 4（4GB）上测出的数据：

配置	编码耗时	CPU 占用	实时性
tiny + ac=512 + VAD	~5s/段(4s音频)	70-80%	接近实时
small + ac=512 + VAD	~18s/段(4s音频)	95%+	延迟明显

结论：树莓派 4 跑 small 做流式不流畅，说完一句要等两三秒才出结果；但允许 2-3 秒延迟的场景（语音备忘录、会议记录）可用。树莓派 5 的 CPU 约为 Pi 4 的 2-3 倍，small 编码可降到约 6-8 秒。

五、量化

中文要准就得用 medium，但 2.1GB 运行时内存对嵌入式设备太奢侈。量化是省内存的手段：

./build/bin/quantize models/ggml-large-v3-turbo.bin \
    models/ggml-large-v3-turbo-q5_0.bin q5_0

1.5 GiB → 547 MiB，压缩比接近 65%，运行时内存从约 2.4GB 降到约 700MB。

需要说明一个反直觉的点（README 原话也这么写）：量化不一定加速。量化只加速 Decoder，Encoder 反而会变慢，整体速度不一定会变快，主要收益是省内存、省磁盘。所以内存够用就直接用原始模型，量化是「内存逼不得已」的选择。

六、注意事项与边界

• 不是实时流式引擎：树莓派 4 上开了 VAD 和降上下文也只能"接近实时"，要 < 200ms 端到端延迟需换 M 系列 Mac / x86 服务器或嵌入式专用方案。
• 准确率取决于模型：95%+ 的中文准确率要 medium/large 起步，搭配领域微调。
• 不带标点：whisper 输出是一大段无标点文字，需要标点要后处理加模型（如 FunASR 的标点模型）。
• 树莓派 4 1GB 版本会 OOM：tiny 理论只要 273MB，但加上系统开销流式模式会触发 swap，建议至少 2GB。
• 不支持训练/微调：纯推理引擎，领域微调需用原始 Python whisper 或 faster-whisper 训练，再转 ggml 格式。

七、总结

whisper.cpp 把语音识别从"云服务"变成"设备上的一个 C 库"，适合离线环境、持续录音、数据不能出本地的场景。代价是要自己选模型、调参数，并认清单片机算力的边界。选型时先明确约束：有网、延迟不敏感、不连续 7×24 运行就选云端 API；要离线、要持续录音、数据不许出本地就选 whisper.cpp。仓库里还有 iOS、Android、WebAssembly、Docker 的编译指南，模型选型和 VAD 参数官方 README 写得更细。