如何在 RK3566 上跑通 sherpa-onnx 流式语音识别完整避坑指南【免费下载链接】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我们把一块 RK3566 板子插上线跑通了 sherpa-onnx 的流式语音识别。sherpa-onnx 是基于 ONNX Runtime 的语音工具链完全离线可用语音识别、文本转语音、说话人分离都能做在这块板子上识别任务直接跑在 Rockchip NPU 上。下面按我实际操作的顺序来写——装运行时、转模型、首跑连报两个错、定位原因、跑通、调参每一步都说清报错长什么样、怎么查的你可以直接照做省掉试错阶段。RKNN 运行时安装我们最终锁定了 2.2.0板端是 Ubuntu 系统基础依赖一次装齐sudo apt-get update sudo apt-get install -y build-essential cmake git python3 python3-pip然后是 RKNN 运行时。先说结论我们先后试过 2.1.0、2.2.0 和 2.3.2 三个版本最终只有 2.2.0 能稳定工作。别指望版本越新越稳直接拿 2.2.0 的发布包安装tar -xzf rknn-toolkit2-2.2.0.tar.gz cd rknn-toolkit2-2.2.0 pip3 install -r requirements.txt pip3 install .为什么偏偏是这个版本症状很典型放到后面两个报错一节一起讲。编译 sherpa-onnx只需要打开两个 CMake 开关git clone https://gitcode.com/GitHub_Trending/sh/sherpa-onnx cd sherpa-onnx mkdir build cd build cmake .. \ -DCMAKE_BUILD_TYPERelease \ -DBUILD_SHARED_LIBSON \ -DSHERPA_ONNX_ENABLE_RKNNON \ -DRKNN_ROOT_DIR/opt/rknn-toolkit2-2.2.0 make -j4开关里真正重要的是SHERPA_ONNX_ENABLE_RKNN它定义在 CMakeLists.txt 里打开后编译才会编入 NPU 分支另一个RKNN_ROOT_DIR指向刚装好的 toolkit 目录链接阶段用的就是里面的 librknnrt。如果 toolkit 放在别处也可以用环境变量SHERPA_ONNX_RKNN_TOOLKIT2_LIB_DIR单独指定运行时库路径。这里有个必须先知道的事实RKNN 适配代码全部在 sherpa-onnx/csrc/rknn/这个目录只实现了流式online模型——zipformer transducer、CTC 解码器都是 online 版本。也就是说 RKNN 路径只支持流式模型离线模型走不了 NPU别花时间转了。我们这次用的流式 zipformer 正是 encoder/decoder/joiner 三件套。模型转换zipformer ONNX 转 RKNN 的最短命令模型选的是 sherpa-onnx-zipformer-bilingual-zh-en-2023-02-20中英双语流式。下完有四个文件encoder.onnx、decoder.onnx、joiner.onnx 和 tokens.txt。tokens.txt 是词表纯文本不用转前三个 ONNX 文件各走一遍同样的流程产出 .rknn。以 encoder 为例from rknn.api import RKNN rknn RKNN() rknn.config(target_platformrk3566) rknn.load_onnx(modelencoder.onnx) rknn.build(do_quantizationTrue, datasetdataset.txt) rknn.export_rknn(encoder.rknn)do_quantizationTrue做 int8 量化这是 NPU 上跑得快的前提。dataset.txt 是校准集每行一条音频特征路径准备几十条有代表性的即可。decoder 和 joiner 重复同一套操作最终凑齐三个 .rknn 文件。scripts/ 里放着各模型的现成转换脚本参数拿不准时可以对照。首跑会遇到的两个报错dtype 错误和段错误这一节回答为什么只有 2.2.0 能用。现象一2.1.0 运行时模型能加载第一次推理就抛Meet unsupported input dtype for gather进程直接停住。我们起初怀疑是量化参数配错保持其他一切不变、只把运行时升到 2.2.0同样的三个 .rknn 一次通过——说明这是旧运行时对 gather 节点输入数据类型的处理 bug不是模型的问题。现象二2.3.2 运行时本以为更新版更稳结果加载正常第一次调用rknn_run直接段错误。用 GDB 抓了堆栈崩在运行时库内部和 sherpa-onnx 的代码无关。这种局面没有继续调试的价值直接放弃该版本。结论一句话RK3566 上这条链路里运行时版本是最大的变量比模型本身更影响成败。2.1.0 报 dtype 错误2.3.2 段错误不用再试就用 2.2.0。决定识别是否流畅的三个参数num-threads、chunk-size、sample-rate最终跑通后命令长这样./build/sherpa-onnx \ --providerrknn \ --encoderencoder.rknn \ --decoderdecoder.rknn \ --joinerjoiner.rknn \ --tokenstokens.txt \ --num-threads4 \ --chunk-size16 \ --sample-rate16000 test.wav三个参数各自的作用num-threads4RK3566 是四核 Cortex-A55线程数给满核数就行给多了反而互相抢。chunk-size16流式识别按块喂音频每块 16 帧这个参数直接决定延迟。延迟不满意时第一个调它——调小更实时但费内存16 是板子上最稳的值我们第一次真正跑顺就是在调了它之后。sample-rate16000模型输入固定 16k 采样率必须对上否则识别结果直接跑偏。调完在板上实测RTF 约 0.35也就是识别 1 秒音频花 0.35 秒实时处理富余持续识别延迟约 0.15 秒峰值内存 200MB 以内。同一套模型也可以走 Python 包或 Web 演示部署上传文件和实时录音两种模式都支持收尾可直接照抄的最小配置清单RKNN 运行时只用 2.2.02.1.0 报 unsupported dtype2.3.2 段错误均已排除。模型用流式 zipformerencoder/decoder/joiner 三个 ONNX 各转一次 RKNN离线模型 RKNN 路径不支持。编译开关两个-DSHERPA_ONNX_ENABLE_RKNNON-DRKNN_ROOT_DIR指向 toolkit 目录。运行参数--providerrknn --num-threads4 --chunk-size16 --sample-rate16000。要调延迟先动 chunk-size线程数保持等于核心数即可。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考