尧图网页设计 
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-onnxsherpa-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.1.0不可用转换即报 Meet unsupported input dtype for gathergather 节点量化失败模型都出不来2.2.0唯一推荐转换、编译、推理三段全部实测通过2.3.2不可用推理时rknn_run内部段错误GDB 定位是运行时库与模型不兼容升级无解踩了个坑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 的库目录链接rknnrtexport SHERPA_ONNX_RKNN_TOOLKIT2_LIB_DIR/path/to/rknn-toolkit2-2.2.0/lib cmake .. -DSHERPA_ONNX_ENABLE_RKNNON -DCMAKE_BUILD_TYPERelease完整构建命令不贴了看仓库根目录的 CMakeLists.txt 和各模块构建说明即可。工具链侧注意两点librknnrt.so和头文件必须来自 2.2.0 版本版本混用必崩交叉编译工具链用 RK3566 BSP 提供的也可直接在板上编译4 核编译慢但省心。性能账本测试条件先说清RK3566 四核 Cortex-A55 2.0GHz、4GB LPDDR4、Ubuntu 20.04模型为 zipformer 中英双语流式版RKNN 2.2.0NPU 加速。数字都是这套条件下的值模型加载 1.2s——冷启动从存储读入内存上电到可用要加上这部分首次推理 0.8s——含 NPU 初始化后续请求不再付这笔钱稳态延迟 0.15s——预热后连续流式识别的平均值对话场景够用峰值内存约 180MB——RK3566 上留余量按 256MB 规划RTF 0.35——低于 1 即实时这是选型时最先要看的数字0.35 意味着还有三倍于实时的余量CPU 平均利用率 75%——主算力在 NPUCPU 主要跑特征前端和后处理结论实时性达标内存达标账是算得过来的。只有两个值得动的旋钮num-threads和chunk-size其他参数保持默认即可。判断逻辑如下num-threadsRK3566 是 4 核NPU 承担主力计算线程主要服务前后处理。整机无重负载就保持 4如果同板还有别的 CPU 任务压到 2避免抢占反而推高延迟。chunk-size决定流式处理的块大小直接权衡延迟和吞吐。块小延迟低但推理调用次数多块大吞吐好但首字延迟上升。实时对话场景保持 16优先低延迟离线批处理长音频可以适当放大用吞吐换延迟。运行命令长这样参数含义见上面两条./bin/sherpa-onnx --providerrknn \ --encoderencoder.rknn --decoderdecoder.rknn --joinerjoiner.rknn \ --tokenstokens.txt --chunk-size16 --num-threads4 test.wav结论调参空间很小这是好事——说明这套组合没有太多需要反复实验的变量。边界与局限诚实交代当前方案做不了什么避免立项时高估语言覆盖实测验证的是中英双语模型其他语言需要先确认对应模型能顺利转成 RKNN 格式再立项不要假设支持的 ASR 语言都能上 NPU。精度上限流式模型精度天然低于同量级离线大模型。如果对识别率要求高要么接受流式的精度折中要么改走 CPU 上的 ONNX 离线路线两条路不能同时要。NPU 利用率没有配套 profiling 手段无法确认每个算子的实际加速情况个别算子回退到 CPU 是存在的这部分开销已包含在上面 RTF 里。版本锁定运行时锁死 2.2.0 意味着 toolkit 停在旧版本后续想用新版 runtime 的特性必须先重新回归全部模型。模型转换环节参考仓库的 模型转换脚本转换流程本身不复杂复杂度全在版本匹配上。上项目前记住这几点RKNN 运行时必须是 2.2.02.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 sherpa-onnx 在 RK3566 上到底能不能跑？流式语音识别选型与实测避坑
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-onnxsherpa-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.1.0不可用转换即报 Meet unsupported input dtype for gathergather 节点量化失败模型都出不来2.2.0唯一推荐转换、编译、推理三段全部实测通过2.3.2不可用推理时rknn_run内部段错误GDB 定位是运行时库与模型不兼容升级无解踩了个坑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 的库目录链接rknnrtexport SHERPA_ONNX_RKNN_TOOLKIT2_LIB_DIR/path/to/rknn-toolkit2-2.2.0/lib cmake .. -DSHERPA_ONNX_ENABLE_RKNNON -DCMAKE_BUILD_TYPERelease完整构建命令不贴了看仓库根目录的 CMakeLists.txt 和各模块构建说明即可。工具链侧注意两点librknnrt.so和头文件必须来自 2.2.0 版本版本混用必崩交叉编译工具链用 RK3566 BSP 提供的也可直接在板上编译4 核编译慢但省心。性能账本测试条件先说清RK3566 四核 Cortex-A55 2.0GHz、4GB LPDDR4、Ubuntu 20.04模型为 zipformer 中英双语流式版RKNN 2.2.0NPU 加速。数字都是这套条件下的值模型加载 1.2s——冷启动从存储读入内存上电到可用要加上这部分首次推理 0.8s——含 NPU 初始化后续请求不再付这笔钱稳态延迟 0.15s——预热后连续流式识别的平均值对话场景够用峰值内存约 180MB——RK3566 上留余量按 256MB 规划RTF 0.35——低于 1 即实时这是选型时最先要看的数字0.35 意味着还有三倍于实时的余量CPU 平均利用率 75%——主算力在 NPUCPU 主要跑特征前端和后处理结论实时性达标内存达标账是算得过来的。只有两个值得动的旋钮num-threads和chunk-size其他参数保持默认即可。判断逻辑如下num-threadsRK3566 是 4 核NPU 承担主力计算线程主要服务前后处理。整机无重负载就保持 4如果同板还有别的 CPU 任务压到 2避免抢占反而推高延迟。chunk-size决定流式处理的块大小直接权衡延迟和吞吐。块小延迟低但推理调用次数多块大吞吐好但首字延迟上升。实时对话场景保持 16优先低延迟离线批处理长音频可以适当放大用吞吐换延迟。运行命令长这样参数含义见上面两条./bin/sherpa-onnx --providerrknn \ --encoderencoder.rknn --decoderdecoder.rknn --joinerjoiner.rknn \ --tokenstokens.txt --chunk-size16 --num-threads4 test.wav结论调参空间很小这是好事——说明这套组合没有太多需要反复实验的变量。边界与局限诚实交代当前方案做不了什么避免立项时高估语言覆盖实测验证的是中英双语模型其他语言需要先确认对应模型能顺利转成 RKNN 格式再立项不要假设支持的 ASR 语言都能上 NPU。精度上限流式模型精度天然低于同量级离线大模型。如果对识别率要求高要么接受流式的精度折中要么改走 CPU 上的 ONNX 离线路线两条路不能同时要。NPU 利用率没有配套 profiling 手段无法确认每个算子的实际加速情况个别算子回退到 CPU 是存在的这部分开销已包含在上面 RTF 里。版本锁定运行时锁死 2.2.0 意味着 toolkit 停在旧版本后续想用新版 runtime 的特性必须先重新回归全部模型。模型转换环节参考仓库的 模型转换脚本转换流程本身不复杂复杂度全在版本匹配上。上项目前记住这几点RKNN 运行时必须是 2.2.02.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考