企业官网建设流程全解析

sherpa-onnx 在 RK3566 上到底能不能跑？流式语音识别选型与实测避坑

【免费下载链接】sherpa-onnxSpeech-to-text, text-to-speech, speaker diarization, speech enhancement, source separation, and VAD using next-gen Kaldi with onnxruntime without Internet connection. Support embedded systems, Android, iOS, HarmonyOS, Raspberry Pi, RISC-V, RK NPU, Axera NPU, Ascend NPU, x86_64 servers, websocket server/client, support 12 programming languages项目地址: https://gitcode.com/GitHub_Trending/sh/sherpa-onnx

sherpa-onnx 是一个基于 ONNX Runtime 的离线语音识别框架，ASR、TTS、VAD、说话人分离全部可以在没有网络的环境下跑完。嵌入式场景选它的理由很直接：模型可以走 RKNN 转换流程丢到 RK NPU 上执行，不依赖云端 API，也不依赖常驻服务。

本文不是部署手册——"怎么装怎么编译"查仓库 README 和构建脚本就够了。这里说的是动手前该知道的事：RKNN 哪个版本会崩、为什么模型必须挑流式 zipformer、编译链路的关键开关在哪、性能数字到底什么水平，以及这套方案现在做不了什么。

读完你能拿到一个完整的决策依据：一个运行时版本号、一个模型类型判断、一组带测试条件的性能数字、一份"做不到"清单。值不值得上，看完自己判断。

RKNN 运行时版本怎么选

实测过 2.1.0 / 2.2.0 / 2.3.2 三个版本，结论先行：只有 2.2.0 能用，其他两个直接排除。这不是保守，是它们分别挂在转换阶段和推理阶段。

踩了个坑：2.3.2 段错误不是自己代码的问题，别浪费时间去修业务侧，版本降级是唯一出路。所以选型时把 "RKNN 2.2.0 toolkit" 直接写进 BOM，锁定版本，后续升级运行时前必须先回归一轮。

为什么流式 zipformer 是硬要求

流式和离线在 RKNN 上的机制差异，决定了这不是偏好问题而是可行性问题：

• 流式 zipformer 是 chunk-based 架构，encoder 每次吃固定长度的输入块，张量形状静态，RKNN 转换稳定，推理内存有上限。
• 离线模型输入长度可变，转成 RKNN 格式后在 RK3566 上实测无法稳定运行，再叠加 4GB LPDDR4 的内存压力，这条路不值得投入。
• 仓库的 RKNN 适配层（sherpa-onnx/csrc/rknn/）里，online zipformer transducer/ctc 模型、online stream 和对应的流式解码器是完整成体系的，RKNN 这条路径实际上就是围绕流式 zipformer 设计的。

结论：RK3566 上直接指定流式 zipformer（如中英双语 2023-02-20 版），不要花时间试离线大模型。

编译链路的关键开关

核心开关只有一个：SHERPA_ONNX_ENABLE_RKNN，默认 OFF，不打开整个 RKNN 代码路径都不进构建。打开后需要指定 RKNN toolkit 的库目录，链接rknnrt：

export SHERPA_ONNX_RKNN_TOOLKIT2_LIB_DIR=/path/to/rknn-toolkit2-2.2.0/lib cmake .. -DSHERPA_ONNX_ENABLE_RKNN=ON -DCMAKE_BUILD_TYPE=Release

完整构建命令不贴了，看仓库根目录的 CMakeLists.txt 和各模块构建说明即可。工具链侧注意两点：librknnrt.so和头文件必须来自 2.2.0 版本，版本混用必崩；交叉编译工具链用 RK3566 BSP 提供的，也可直接在板上编译，4 核编译慢但省心。

性能账本

测试条件先说清：RK3566 四核 Cortex-A55 @ 2.0GHz、4GB LPDDR4、Ubuntu 20.04，模型为 zipformer 中英双语流式版，RKNN 2.2.0，NPU 加速。数字都是这套条件下的值：

• 模型加载 1.2s——冷启动从存储读入内存，上电到可用要加上这部分
• 首次推理 0.8s——含 NPU 初始化，后续请求不再付这笔钱
• 稳态延迟 0.15s——预热后连续流式识别的平均值，对话场景够用
• 峰值内存约 180MB——RK3566 上留余量按 256MB 规划
• RTF 0.35——低于 1 即实时，这是选型时最先要看的数字；0.35 意味着还有三倍于实时的余量
• CPU 平均利用率 75%——主算力在 NPU，CPU 主要跑特征前端和后处理

结论：实时性达标，内存达标，账是算得过来的。

只有两个值得动的旋钮

num-threads和chunk-size，其他参数保持默认即可。判断逻辑如下：

• num-threads：RK3566 是 4 核，NPU 承担主力计算，线程主要服务前后处理。整机无重负载就保持 4；如果同板还有别的 CPU 任务，压到 2，避免抢占反而推高延迟。
• chunk-size：决定流式处理的块大小，直接权衡延迟和吞吐。块小延迟低但推理调用次数多，块大吞吐好但首字延迟上升。实时对话场景保持 16，优先低延迟；离线批处理长音频可以适当放大，用吞吐换延迟。

运行命令长这样，参数含义见上面两条：

./bin/sherpa-onnx --provider=rknn \ --encoder=encoder.rknn --decoder=decoder.rknn --joiner=joiner.rknn \ --tokens=tokens.txt --chunk-size=16 --num-threads=4 test.wav

结论：调参空间很小，这是好事——说明这套组合没有太多需要反复实验的变量。

边界与局限

诚实交代当前方案做不了什么，避免立项时高估：

• 语言覆盖：实测验证的是中英双语模型，其他语言需要先确认对应模型能顺利转成 RKNN 格式再立项，不要假设"支持的 ASR 语言都能上 NPU"。
• 精度上限：流式模型精度天然低于同量级离线大模型。如果对识别率要求高，要么接受流式的精度折中，要么改走 CPU 上的 ONNX 离线路线，两条路不能同时要。
• NPU 利用率：没有配套 profiling 手段，无法确认每个算子的实际加速情况，个别算子回退到 CPU 是存在的，这部分开销已包含在上面 RTF 里。
• 版本锁定：运行时锁死 2.2.0 意味着 toolkit 停在旧版本，后续想用新版 runtime 的特性，必须先重新回归全部模型。

模型转换环节参考仓库的 模型转换脚本，转换流程本身不复杂，复杂度全在版本匹配上。

上项目前记住这几点

• RKNN 运行时必须是 2.2.0，2.1.0 转换挂、2.3.2 推理挂，没有第三种选项。
• 模型只用流式 zipformer，离线模型在这块板子上这条路走不通，别试。
• 编译只开SHERPA_ONNX_ENABLE_RKNN，库路径指向 2.2.0 toolkit。
• 验收标准看两个数：RTF 低于 1（实测 0.35），峰值内存按 256MB 留余量（实测 180MB）。

一个留给读者的问题：如果 RKNN 后续版本修复了 2.3.x 的兼容性问题，流式和离线的选择天平会不会重新摆回来？值得盯一下上游 release notes，有变化时先拿本文这组数字做基线回归，结论会很快出来。

【免费下载链接】sherpa-onnxSpeech-to-text, text-to-speech, speaker diarization, speech enhancement, source separation, and VAD using next-gen Kaldi with onnxruntime without Internet connection. Support embedded systems, Android, iOS, HarmonyOS, Raspberry Pi, RISC-V, RK NPU, Axera NPU, Ascend NPU, x86_64 servers, websocket server/client, support 12 programming languages项目地址: https://gitcode.com/GitHub_Trending/sh/sherpa-onnx