Sherpa-onnx v1.10.45 更新解析：FireRedASR 语音识别模型接入 12 种语言 API，这些改动值得升级

Sherpa-onnx v1.10.45 更新解析：FireRedASR 语音识别模型接入 12 种语言 API，这些改动值得升级

【免费下载链接】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 v1.10.45 值得升级——本版本把 FireRedASR 语音识别模型（AED 架构，encoder/decoder 双文件，提供 int8 量化 ONNX）正式引入框架，并在 Go 绑定和 RTF 指标计算上修掉了两处坑。只做 TTS、标点恢复或与 FireRedASR 无关的功能，可暂缓。

这次升级你能拿到什么

FireRedASR 进入 sherpa-onnx：AED 模型，中英文混合场景是强项

v1.10.45 的主体工作是把 FireRedASR 模型导出并集成进框架。它属于 AED（Attention-based End-to-End）路线，识别流程由 encoder + decoder 两个 ONNX 文件驱动，随包附带的模型包（如sherpa-onnx-fire-red-asr-large-zh_en-2025-02-16）默认给出 int8 量化版本，兼顾推理速度与精度。

仓库里实际可用的示例覆盖了它最常见的几种用法：

• 离线整段识别文件：python-api-examples/offline-fire-red-asr-decode-files.py、c-api-examples/fire-red-asr-c-api.c
• 基于 CTC 解码的变体（适合低延迟、逐帧出字的场景）：python-api-examples/offline-fire-red-asr-ctc-decode-files.py、cxx-api-examples/fire-red-asr-ctc-cxx-api.cc
• 模拟流式识别：cxx-api-examples/fire-red-asr-ctc-simulate-streaming-microphone-cxx-api.cc
• Rust 端还额外给了模拟麦克风流式的写法：rust-api-examples/examples/fire_red_asr_ctc_simulate_streaming_microphone.rs

测试音频里还准备了四川、天津、河南等方言样例（见 Python 示例文件头部的test_wavs注释），方便你直接评估口语与口音的识别表现。

API 覆盖到了什么程度

这次不是只补一个 C++ 接口，而是把 FireRedASR AED 模型铺到了框架支持的主流语言上，CHANGELOG 中对应的提交为 #1865～#1880：

也就是说，从桌面、服务器到手机和浏览器，基本都能直接调用，不需要自己拼 FFI。

稳定性与细节：修了什么坑

Go 绑定：实例"看似创建成功"的隐患被堵上了

本版本修复了一个比较隐蔽的问题（#1860）：某些情况下 Go 端调用会返回一个看起来创建成功的实例，但其底层 C 结构体实际初始化失败。后果是后续往这个"半残"实例上读写数据时可能触发非法内存访问，且现象往往延迟到几行代码之后才暴露，排查成本高。修复后，创建失败会如实报错，不会再把坏实例交回给你。如果你在用 Go 做服务端 ASR，这条修复基本算必升项。

RTF 指标计算的拼写错误被修正（#1861）

实时因子（RTF，识别耗时 / 音频时长，越小越快）的计算里有一处拼写错误，会导致跑 benchmark 时记录的指标失真。修正后你看到的 RTF 数字才可信。日常不跑性能测试的读者可以忽略这条，但做模型选型、硬件对比的同学建议升完再复测一次。

上手路径：从 Python 脚本到目标平台

1. 下载模型：模型包在项目的 release 资源（asr-models 标签）中，Python 示例头部的 docstring 给出了wget与解压命令的完整写法，解压后你会看到encoder.int8.onnx、decoder.int8.onnx、tokens.txt和一组测试 wav。
2. 跑通最小示例：先执行 python-api-examples/offline-fire-red-asr-decode-files.py，用sherpa_onnx.OfflineRecognizer.from_fire_red_asr(encoder=..., decoder=..., tokens=...)三个参数即可拿到识别器，整段逻辑不到 80 行。
3. 切到目标语言：确定选型后，直接对照上表里对应语言的示例改路径即可，接口形态各语言基本一致（encoder/decoder/tokens 三件套）。
4. AED 还是 CTC：默认推荐 AED 整段识别（精度优先、离线批处理）；如果你的场景要求逐帧出字或更低延迟，试 CTC 变体的示例做对比，两者模型文件不通用，需要分别下载。

选型建议：FireRedASR 适合放进你的方案吗

• 中文为主、夹杂英文词或专业术语：AED 模型的zh_en包是本次主打，建议优先在自有数据上验证。
• 有口音、方言的口语输入：用示例包内的方言测试 wav（四川、天津、河南）先听一遍实际效果，再决定要不要替换现有模型。
• 边缘设备 / 嵌入式：int8 量化 ONNX + 框架本身的 onnxruntime 后端，适合树莓派、NPU 板卡等受限环境，部署方式与 sherpa-onnx 现有模型一致。
• 纯 TTS、VAD、标点恢复用户：本版本与你无关，保持现状即可。

如果你已在用 sherpa-onnx，升级到 v1.10.45 的收益集中在"多一个可用的离线识别模型 + 两处修复"；还没接入的团队，可以借这次更新直接评估 FireRedASR 是否要进入你们的识别链路。

【免费下载链接】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