SenseVoice-small模型在Android手机做离线ASR识别的效果--AI手机通话功能探索上一篇手机无网离线使用FunASR识别手机历史通话录音下一篇Android应用app实现AI电话机器人接打电话​​​​​​​一、背景我们在2024年初的时候进行了一版阿里FunASR等免费的离线语音识别的选型并将其离线的放入手机内置存储中进行本地语音ASR识别效果如下表所示编号算法-模型评价01vosk-android垃圾识别率是个渣模型库贼大02AIUI不建议它就没打算为开源社区出一点力03FunASR识别效果尚可迭代快04PaddleSpeech声势挺猛的文档比较齐全没找到离线ASR的用法另外在具体使用上这些模型库在本次需求方面还存在以下不足与缺陷1、ASR识别的时间基本都为语音时长的二分之一即一段话说话时长为20s、传入了所有语音数据后需要等待10s它才能返回识别后的文字。不利于实时结果响应。2、全双工通话或双轨录音时需要手动拆分为两个ASR模型实例占用了双倍的运行内存。两路ASR在手机上内存耗用超过1000Mb普通手机根本带不动。在实践中发现这几种方案放到手机上cpu本地运算的效果真是一塌糊涂识别速度又慢、识别精度又差还常常词不达意而且一句话还常常漏识别几个字还消耗了大量的手机内存去加载和运行。简单说就是之前版本的ASR只能依赖云端AI没法做本地识别。这几年各种新的“流式/非流式”的ASR模型和算法不断涌现识别响应速度和精准度也不断提升。有些时候我们也在想有没有必要再次对现在免费的ASR的各种算法进行试验和选型一下看看是否当前已有更好的方案来满足我们在手机本地实现AI通话功能的需求这也正是本篇章内容编写的由来。本篇章中我们将对Android手机纯本地cpu运算的ASR算法和模型库进行简单的效果整理。看看截至2026年中的当前语音ASR在终端上的识别效果如何相比较于云端AI的算力和识别效果有怎么样的差异。进而评估一下能否利用当前的ASR算法在不升级Android旗舰机NPU的情况下单靠市面上二手机的cpu算力来独立实现语音识别方面的AI手机的能力。二、流式/非流式的差异ASR模型和算法选型有一个问题一直无法绕开即到底选用“流式ASR”还是选用“非流式ASR”通俗的来说就是播放一段新闻联播主持人吧啦吧啦一堆话就没有停下过这种情况如果ASR文字一直不停输出那它就是“流式ASR”如果它需要等待主持人停顿一下然后检测到停顿了才一口气输出一堆文字那它就是“非流式”。非常的好判断。那么问题来了我们实际的需求场景不外乎就两个大类①笔记速记就是对方有个人在会议里发言或讲课手机当作录音笔来用放旁边说话人讲话的同时手机不停的输出对应的文字。然后手机使用者在旁边不停的记笔记或对ASR转译内容进行校正方便后续的记录和存档。②AI语义理解和语音交互AI需要先理解对方说的这句话/这段话是什么意思然后再思考或处理后做AI转义和语音应答。很明显我们需要的是第二种需要对方说完一整个句子表述后理解它实际想表达的蕴意然后再给它做回复。中途插话虽然快乐但对方可能不快乐。也就是说对于电话的语音场景流式实时输出不是刚需识别准确率才是刚需等对方说完才能精准的理解用户的意图。三、Android纯CPU开源ASR项目库后来我们发现GitHub上有个开源项目sherpa-onnx已经把Android和嵌入式智能设备等纯CPU平台上做的语音方面的运算ASR、VAD、TTS等的模型和依赖库整合起来了。引用地址https://github.com/k2-fsa/sherpa-onnx流式旧版框架https://github.com/k2-fsa/sherpa-ncnn直接用它就行了本文的模型和动态库也是全用的这个项目的编译结果。它的onnx中本文引用了SenseVoice-small模型来做非流式的ASR识别。依赖的模型文件和动态库体积大小用的SenseVoice模型是sherpa-onnx-sense-voice-zh-en-ja-ko-yue-int8-2025-09-09大致如下模型文件文件大小描述silero_vad.onnx0.6MBvad模型文件vad分段后再文字识别tokens.txt0.3MBASR依赖文件model.int8.onnx226MBASR模型文件Android动态库依赖文件大小arm64-v8a版如下模型文件文件大小libonnxruntime.so24.6MBlibsherpa-onnx-c-api.so4.2MBlibsherpa-onnx-cxx-api.so0.4MBlibsherpa-onnx-jni.so4.5MB四、文字识别效果实践表明没有经过知识库额外加工的ASR文字转译的效果就是稀碎。识别速度非常的快一个15MB大小的mp3文件转码解析完pcm音频需要9秒但ASR识别完毕仅需要4秒。文字的识别效果也不能说好也不能说很差反正人类能正常的通过查阅汉语的上下文自己浏览和补全句子。就是如果要用AI来LLM语义理解是否能达到预期效果就不好说了。ASR展示效果如下图所示仅供参考ASR离线识别APK178MBhttp://120.78.211.195:8060/asr.apk手机电话通话ASR识别APK7.6MBAndroid应用app实现AI电话机器人接打电话​五、ASR的CPU和内存耗用我们以asr.apk的运行状态为例app应用启动时自动加载SenseVoice模型和运行依赖的so动态库。加载完毕后的运行内存为400MB当开始做一路ASR语音识别时运行内存涨到了420MBCPU的消耗基本没有变化仍在0%左右跳动。如下图所示​正常通话时语音数据通常都是两路通话对方说话的远端上行语音自己说明的麦克风下行语音。两路通话的ASR的运行内存大致如下图所示​从上图可以看到两路语音的ASR由于使用了两个不同的VAD模型内存较一路语音要更高一些从420MB变为500MB左右CPU耗用基本上没有变化。理论上如果识别精度可以的情况下这样的模型和算法基本上能运行在市面上普通的二手机上随便运行普适性还是非常宽泛的。六、小结总体来说这一轮的选型把手机做端侧纯本地ASR的性能和适配给验证了一下发现确实这两年的ASR的模型在纯CPU上做得很好了从运行占用的内存和cpu耗用上市面上绝大多数机型都可以很好的运行和加载使用。但是识别效果上总是有些勉强。由于为了提升加载时间和减少app的手机内存耗用我们并没有增加标点符号和LLM语义理解的模型做后期处理。单纯ASR识别的内容上由于没有知识库的加持识别出来的内容理解起来还是比较费劲的而且偶尔因为口语化的原因ASR识别起来也会缺字。简单说就是但靠这个端侧本地离线ASR想要达到目前商用的云服务器AI的识别效果还有较大的距离。但如果仅仅时做“实时语音质检”这样的功能通过现有的语音文件快速解析出对应的内容文本然后与预定义的话术模板和判定合法合规的话当前的ASR效果也已基本能满足使用的要求了。仅供参考。