sherpa-onnx 模型与部署选型

sherpa-onnx 能适配多种 ASR 模型，但“框架支持”不等于“模型适合产品”。选型要把实时性、语言、热词、结果能力、硬件预算、交付包体和许可证放到同一张表里，再用真实录音和目标设备验证。

官方模型目录持续增加，本文不维护完整名单，而是用几类常见结构说明判断方法。下载和发布时应回到官方预训练模型目录确认当前文件、参数和许可证。

先定义产品约束

模型比较之前先固定以下条件：

约束	要明确的结果
运行模式	真正流式、VAD 加非流式、文件批处理
语言	普通话、中英混合、粤语、多语言或特定口音
业务词	是否需要动态联系人、设备名或行业词热词
输出	文本、token、时间戳、语言、情感、事件、标点
设备	CPU 架构、可用线程、内存、NPU/GPU、功耗
交付	动态库、模型、词表、附加模型和应用总包体
合规	原始音频是否离开设备，模型许可证是否可商用

如果这些约束尚未确定，直接比较模型榜单很难得到可执行结论。

常见模型家族

Zipformer Transducer

Transducer 结构适合真正的流式识别，也有非流式模型。sherpa-onnx 的热词机制当前以 Transducer 加 modified_beam_search 为前提，因此实时识别和动态业务词同时存在时，应优先验证这一类模型。

需要关注 encoder、decoder、joiner 与词表是否来自同一模型包，不能混用不同版本的组件。

Paraformer

Paraformer 在中文和中英识别中有较多模型选择，官方目录同时提供流式与非流式方向。选择时要确认具体模型是 online 还是 offline，不能根据“Paraformer”名称推断运行模式。

SenseVoice

SenseVoice 常用于中文、英语、日语、韩语和粤语短句识别，部分模型还能返回语言、情感或音频事件信息。它适合先跑通多语言非流式链路，也常与 VAD 组合处理麦克风或长音频。

附加字段必须以当前模型和 API 结果为准；业务不能因为模型家族支持某项能力，就假设每个导出版本都有相同字段和效果。

Whisper

Whisper 适合多语言文件转写和具有复杂语言变化的录音。在 sherpa-onnx 中按非流式模型使用，更适合完整文件或 VAD 切段后的识别，不应期待它像真正流式模型一样逐块稳定输出。

其他模型

官方非流式适配还会持续加入新的 CTC、Transducer 和生成式 ASR 模型。例如当前仓库已经提供 Qwen3-ASR 的非流式 Python 示例。新模型进入框架后仍要重新验证算子支持、内存、首轮加载时间、结果格式和目标平台，不应只依据桌面端示例决定移动端选型。

场景选型

场景	推荐起点	重点验证
中文短句和离线命令	SenseVoice INT8 或合适的中文非流式模型	终句延迟、命令成功率、包体
中文实时字幕	流式 Zipformer 或流式 Paraformer	首字延迟、中间结果稳定性、RTF
动态联系人和设备名	Transducer + modified_beam_search	热词命中率与误命中率
多语言文件转写	Whisper 或多语言非流式模型	语言切换、长音频切段、时间戳
会议或录音质检	VAD + 非流式 ASR	切段完整性、批处理吞吐、时间轴恢复
移动端或嵌入式	INT8 小模型作为第一候选	内存、发热、耗电、ABI 和包体

推荐起点只用于缩小验证范围，不能替代自己的测试集。

模型资产检查

不同结构需要的文件不同，常见组合包括：

单模型：
model.onnx
tokens.txt

Transducer：
encoder.onnx
decoder.onnx
joiner.onnx
tokens.txt

Whisper：
encoder.onnx
decoder.onnx
tokens.txt

接入前检查：

• 所有模型和词表来自同一个发布目录。
• 文件没有在下载、解压或复制时损坏。
• FP32 与 INT8 文件没有被配置项混淆。
• 模型要求的采样率和特征维度已经确认。
• 附加词典、语言模型、热词文件或 tokenizer 已纳入交付。
• 每个资产都有版本和哈希，日志能定位实际加载版本。

性能评估

准确率

中文短句常用 CER，英文或明确分词语料常用 WER。业务命令还应统计意图成功率，因为少量文字错误不一定影响设备控制，文本完全一致也不代表槽位解析正确。

CER = (替换字数 + 删除字数 + 插入字数) / 参考文本字数
WER = (替换词数 + 删除词数 + 插入词数) / 参考文本词数

测试集至少按语言、口音、距离、噪声、设备型号和业务词分组，避免平均值掩盖某一类严重退化。

实时因子

RTF 表示处理音频所需时间与音频时长之比：

RTF = 推理耗时 / 音频时长

RTF 小于 1 说明平均处理速度快于音频播放速度，但不代表实时体验一定好。流式系统还要测首字延迟、每个音频块的最坏解码耗时和端点后的最终延迟。

资源

同一模型至少记录：

• 首次加载时间和第二次识别时间。
• 峰值内存、稳定内存和是否出现内存抖动。
• 1、2、4 线程下的 RTF、CPU 占用和发热。
• 动态库、模型、词表、VAD 和其他附加资产的总包体。
• 连续运行 10 分钟以上的功耗和温升。

线程更多不一定更快。移动端可能因为调度、缓存和温控出现吞吐提升有限、功耗明显上升的情况。

FP32 与 INT8

INT8 常用于减少模型体积和计算压力，但不能预设精度无损。正确的比较方式是固定模型家族、测试集、设备、线程数和音频输入，只替换量化版本。

观察项	FP32 与 INT8 都要记录
效果	CER/WER、业务成功率、热词表现
性能	RTF、首字延迟、最终延迟
资源	峰值内存、包体、CPU、功耗
稳定性	长时间运行、不同设备和系统版本

如果 INT8 只在安静语音上接近 FP32，还要补充低 SNR、远场、口音和专有名词测试。

推理后端路线

部署优化建议按以下顺序推进：

1. 在桌面 CPU 上用官方示例验证模型和音频。
2. 在目标设备 CPU 上测出可复现的基线。
3. 对比 INT8 和线程数，先完成低成本优化。
4. 明确 CPU 基线无法满足的指标，再评估 CUDA、CoreML 或设备 NPU。
5. 加速后重新验证算子、精度、内存、功耗和异常回退。

NPU 不是替换一个 provider 字符串就能完成的通用优化。Rockchip RKNN、Qualcomm QNN、Ascend、Axera 等后端的支持范围、模型转换和算子限制不同，应使用官方对应文档和示例做单独交付链路。

跨平台集成

sherpa-onnx 的核心实现位于 C/C++，再通过 C API 或语言绑定进入不同平台。产品工程应把模型配置、音频采集、推理封装和业务状态分层，避免页面代码直接管理原生指针和模型路径。

产品页面或业务状态机
  -> 平台语音服务（Kotlin / Swift / Dart / JS）
  -> sherpa-onnx 语言绑定或 JNI / FFI
  -> C/C++ 核心与 ONNX Runtime
  -> 模型和词表资产

推荐的集成边界：

• 平台层负责权限、麦克风、音频焦点、线程和生命周期。
• 语音服务负责 Recognizer/Stream、模型版本和错误码。
• 业务层只消费临时文本、最终文本和状态事件。
• 构建层负责 ABI、动态库、模型资产和许可证清单。

Android 与移动端检查

Android 交付通常至少包含 sherpa-onnx JNI 动态库、ONNX Runtime 动态库、模型和词表。包体评估不能只看 .so，模型往往占据更大空间。

需要逐项检查：

• arm64-v8a、armeabi-v7a 等 ABI 是否与目标设备一致。
• 模型是否放入 APK/AAB、首次启动解压目录或外部下载目录。
• 资产复制是否有原子性、磁盘空间和哈希校验。
• 麦克风采集采样率与送入框架的参数是否一致。
• 后台、来电、音频焦点变化时是否暂停并释放资源。
• 混淆、裁剪和打包是否误删 JNI 或模型文件。
• 低端机连续运行是否出现发热降频和音频队列积压。

许可证与发布

sherpa-onnx 代码仓库使用 Apache-2.0 许可证，但预训练模型可能来自不同项目，拥有独立许可证和使用限制。商业交付前需要分别记录：

• 框架代码许可证。
• ONNX Runtime 或设备后端许可证。
• 每个模型的来源、版本和许可证。
• 词典、词表、语言模型和测试语料的授权。
• 应用内或交付包中需要保留的声明。

“代码可以商用”不能自动推导出“下载的所有模型都可以商用”。

上线回归

每次替换模型、运行时、线程数或音频前处理后，都应执行同一套回归：

1. 校验模型和词表哈希。
2. 跑官方样本，确认基本接入没有破坏。
3. 跑固定业务回放集，比较 CER/WER 和业务成功率。
4. 在目标设备记录 RTF、延迟、内存、功耗和温升。
5. 连续识别、反复进出页面、切换音频设备和撤销权限。
6. 检查异常日志能否定位模型、设备、输入和阶段耗时。

总结

模型选型不是比较单个准确率数字，而是寻找满足语言、运行模式、业务词和设备预算的可交付组合。先建立 CPU 基线，再评估 INT8 和硬件加速；先确认模型能力，再设计热词和结果字段；最后用固定测试集和真实设备完成发布闭环。