首页8 月 18 日，k2-fsa 发布 sherpa-onnx v1.13.6，新增 VAD 加 ASR Flutter 示例，统一 Flutter 和 Dart CLI 初始化 API，修 Android 示例，修 Java 示例，修 iOS SPM 示例，也修了 Dart 包发布。看起来有点碎。
但如果你正在做移动端语音，这种碎更新反而很要命。语音识别不是模型文件下载下来就结束了，麦克风采集怎么接，VAD 怎么判断起止点，ASR 怎么吃音频片段，Flutter 怎么把结果丢回业务层，Android 和 iOS 的接口是不是一致，Dart CLI 调通以后能不能顺手搬到 App 里，这些地方才是开发者真正花时间的地方。看这次 release 写出来的改动，方向已经很清楚，它在补移动端离线语音最需要的工程路径。
一. sherpa-onnx 是什么
sherpa-onnx 是 k2-fsa 维护的开源语音推理项目，偏工程落地的端侧语音底座。语音识别、语音合成、说话人识别、关键词唤醒、VAD，这些能力都可以通过 ONNX Runtime 跑到不同平台上。
覆盖的平台也很广，桌面端、服务器、Android、iOS、WebAssembly、Flutter、Dart、Python、C++ 都在它的范围里。端侧语音项目最怕的不是模型本身，而是平台一多，接入方式就开始分裂。Python 能跑，Android 要重写。Android 能跑，iOS 又遇到包管理。CLI 能跑，Flutter App 里又要重新接一遍音频流。sherpa-onnx 一直在解决的就是这个问题。
k2-fsa 这一支长期在语音识别、有限状态转录器、流式 ASR、端侧部署这些方向上做开源工具，sherpa-onnx 把模型和运行时做成开发者更容易拿去接产品的形态。目前 14,245 Star、1,633 Fork，端侧离线语音确实有大量团队在做。
移动端和 IoT 的语音链路太容易被真实环境打断。网络会抖，权限会丢，耳机会切，App 会进后台，设备算力还不一样。云端 ASR 很强，短指令、本地唤醒、弱网转写、隐私敏感这几类场景却不太适合完全依赖远端。端上有一层语音能力，这些场景处理起来会更稳。
二. VAD 加 ASR Flutter 示例补的是链路感
v1.13.6 里最值得看的是 VAD 加 ASR Flutter 示例。VAD 负责先判断用户有没有说话，ASR 负责把有效语音转成文字。两个能力单独看都不新鲜，放进移动端 App 里才麻烦。
用户点开 App 说一句话，端上先拿到麦克风数据。VAD 判断这段声音是不是有效语音，切出合适的片段，ASR 接着推理，把结果返回给界面或业务逻辑。只要有一步接得别扭，用户看到的就是延迟、误触发、识别断句怪，甚至没有任何反馈。这不是那种靠模型更强就能解决的问题。
Flutter 项目里，团队往往希望一套代码覆盖 Android 和 iOS，可语音能力一涉及底层音频、线程、回调和模型加载，就很容易掉进平台差异。示例越完整，开发者越容易判断这套方案能不能接到自己的 App。少猜一点参数，少翻一点绑定代码，少踩一点初始化坑，研发节奏就能快很多。
三. 统一初始化 API
统一 Flutter 和 Dart CLI 初始化 API，听起来不像热点，但对开发者很友好。Dart CLI 通常更适合先跑通模型和参数，Flutter 才是最终产品形态。两边初始化写法不一致，验证阶段和接入阶段之间就会多一道坎。
这次把初始化 API 往统一方向收，开发者可以先在 Dart CLI 里验证 VAD 和 ASR 的模型、参数、音频输入，再把同样的初始化思路搬到 Flutter App 里。路径越顺，端侧语音越容易从 demo 进入产品。
这种更新不太适合拿来做热闹传播，不会让人一眼觉得有大突破。但做产品的人会知道，很多语音项目卡住，卡的就是这种不起眼的接口和示例。小摩擦多了，项目就慢了。慢到一定程度，团队就会放弃端侧方案，重新回到全云端——接入成本太高，不是端侧不值得。
四. 端侧离线语音的位置
端侧能力更大的用途，是把一部分实时判断放到离用户更近的位置。VAD 可以先在本地判断用户是否开口，ASR 可以先处理短语音和基础转写。系统不用把所有原始音频都送出去，也不用等远端返回后才知道用户大概在说什么。对隐私敏感、网络不稳、交互频率高的场景，这个差别很实际。
移动 RTC 场景里，这个前移会变得很有用。用户可能在地铁里开会，也可能在室外连麦，还可能拿着一台性能一般的 Android 机。网络和设备一起不稳定时，端侧 VAD 能帮系统更早判断语音状态，端侧 ASR 可以为字幕、指令、质检或后续 Agent 流程提供更快的文本输入。
IoT 场景更典型。很多设备不是一直处在理想网络里，用户说的也经常是短指令——开灯、暂停、下一首、呼叫客服、开始会议。端上能先处理这些指令，云端就可以只接管更复杂的理解和业务逻辑。设备不必每次都把全部交互压到远端，用户也不必每次都等完整链路转一圈。sherpa-onnx 在这里的位置很清楚：给设备一个更可靠的入口判断能力。
五. v1.13.6 的价值
sherpa-onnx v1.13.6 没有发布新的语音大模型，也没有把端侧智能讲得很大。它做的事很具体，Flutter 里补了 VAD 加 ASR 示例，初始化 API 往 Dart CLI 对齐，顺手修了一批 Android、Java、iOS SPM 和 Dart 包发布的问题。
开发者真正接产品时，麻烦通常出现在这些地方。CLI 里跑通了，Flutter 里还要重新接音频流。ASR 能识别一段 wav 文件，但 App 里要先判断用户什么时候开始说、什么时候停。Android 示例能跑，iOS 包管理又冒出别的问题。短指令、实时字幕、IoT 弱网转写这些场景，需求一直在，难点是App 里的音频流怎么切、VAD 的结果怎么喂给 ASR、识别结果怎么稳定回到业务层。
所以 v1.13.6 更像是把这些接入缝隙补了一点。它没有让 sherpa-onnx 变成另一个东西，但让开发者少绕一点路。端侧语音最后能不能进移动 RTC 和 IoT 场景，看的不只是识别效果，也看这条链路能不能被反复接入、验证和维护。
