端侧语音这块我从去年开始断断续续折腾了不少方案从最早拿树莓派跑KWS到后来在安卓板子上做离线TTS踩的坑能写满一个笔记本。最近不少朋友在问“无界方舟Audio8”这套东西到底怎么选型尤其是它主推的四类端侧语音方案配合sherpa-onnx、FunASR这些工具链很多人一上来就被各种模型格式、推理框架、量化参数绕晕了。这篇就把我实际跑过的四类方案拆开讲清楚从选型逻辑到落地参数再到那些文档里不会写的坑尽量一次说透。不管你是刚接触端侧语音的新手还是已经在做产品集成的老手应该都能从里面找到能直接抄作业的部分。1. 端侧语音方案的整体选型逻辑1.1 为什么端侧语音突然成了刚需先说清楚一件事端侧语音不是新概念但这两年需求爆发是有具体原因的。最直接的一点是延迟。云端语音识别走一圈网络哪怕网络再好端到端延迟也很难压到200ms以内而端侧做KWS关键词检测可以做到50ms以内响应这个差距在交互体验上是质变的。你对着设备喊一声“小舟小舟”如果半秒后才亮灯用户会觉得这设备“笨”如果几乎同步响应感觉就完全不一样。第二个原因是隐私和成本。语音数据不出设备这在很多场景下是硬性要求比如会议室记录、车载语音、医疗问诊辅助。另外从成本算云端ASR按小时计费一个日活十万的设备如果每天每人用10分钟语音一个月下来的API费用相当可观而端侧模型一次部署边际成本几乎为零。第三个原因是离线可用性。地下车库、电梯、偏远工地这些地方网络不稳定甚至完全没有端侧方案是唯一选择。无界方舟Audio8这套方案的核心卖点就是把这几个需求打包解决提供从KWS到ASR到TTS的完整端侧链路。1.2 四类方案到底在分什么Audio8的四类方案我理解下来本质是按任务类型和资源占用两个维度切的方案类型核心任务典型模型规模内存占用适用芯片方案一KWS关键词检测唤醒词/命令词识别1-5MB20MBMCU、低端SoC方案二流式ASR实时语音转文字20-100MB100-300MB中端SoC、手机方案三离线TTS文字转语音播报30-150MB150-400MB中高端SoC方案四全链路语音交互KWSASRTTS组合300MB高端SoC、车机这个分法很实用因为实际选型时你第一个要回答的问题就是我的设备到底要做什么。如果只是做个语音开关灯方案一就够了硬上ASR纯属浪费。如果要做语音助手那方案四的全链路才是目标但资源预算要提前算清楚。1.3 选型时最容易搞错的三个点第一个坑是把模型大小等同于内存占用。一个50MB的onnx模型加载后实际内存占用可能是150MB甚至更多因为推理过程中还有中间张量、KV cache、音频缓冲区。我见过有人在256MB内存的板子上部署100MB的ASR模型结果跑起来就OOM。经验值是运行时内存 ≈ 模型文件大小 × 2.5到3倍这个系数在做预算时一定要留够。第二个坑是忽略采样率和帧长的影响。端侧语音对音频前端处理很敏感16kHz和8kHz的模型不能混用帧长10ms和25ms的KWS模型响应特性完全不同。sherpa-onnx的很多模型对输入格式有严格要求喂错采样率不会报错但识别结果会莫名其妙地差。第三个坑是低估了唤醒词误报率。KWS方案看起来简单但实际部署中最头疼的是误唤醒。电视里说句话、旁边人聊天设备突然被唤醒这种体验很糟糕。Audio8的方案里对这块有专门的调优参数后面会细讲。2. 方案一KWS关键词检测的落地细节2.1 KWS的技术原理与模型选择KWSKeyword Spotting本质是一个小型的音频分类任务把连续的音频流切成小帧每帧判断是否包含目标关键词。传统做法是MFCC特征小神经网络现在主流是端到端的轻量CNN或TC-ResNet。sherpa-onnx在这块提供了比较完整的支持它内置的KWS模型通常基于FSMN或TDNN结构模型文件在1-5MB之间。选模型时重点看两个指标准确率和误报率False Alarm Rate。很多模型标称准确率99%但那是在干净数据集上的实际带噪环境下能到90%就不错了。我实测下来sherpa-onnx的kws-zh-cn系列模型在中文唤醒词上表现比较稳尤其是对“小舟小舟”这类三到四字词误报控制得不错。如果你的唤醒词是英文或者中英混合要单独找对应的模型别指望一个模型通吃。2.2 关键词检测的实操配置在安卓上跑sherpa-onnx的KWS核心配置就几个参数但每个都影响很大# sherpa-onnx KWS 典型配置 config { feat_config: { sample_rate: 16000, # 必须和模型训练时一致 feature_dim: 80, # 特征维度常见80或40 frame_length_ms: 25, # 帧长 frame_shift_ms: 10, # 帧移 }, model_config: { keywords_file: keywords.txt, # 关键词列表 threshold: 0.25, # 触发阈值关键参数 min_trailing_silence: 1.0, # 尾部静音判定 min_keyword_duration: 0.5, # 最短关键词时长 } }这里threshold是最需要调的参数。设太高喊破喉咙也不触发设太低随便说句话就误唤醒。我的经验是从0.25起步然后在实际环境里测如果误报多就往上调到0.3-0.35如果漏报多就降到0.2。这个值跟麦克风增益、环境噪声强相关没有万能值。min_keyword_duration也很关键。设成0.5秒意味着短于0.5秒的音频片段不会被判定为关键词这能过滤掉很多突发噪声。但如果你的唤醒词本身就很短比如两个字这个值要相应调小。2.3 唤醒词设计的经验之谈唤醒词的选择直接决定KWS方案的成败。我总结了几条避开常见词“你好”“打开”这种词日常对话里出现频率太高误唤醒率必然高。选一个三到四字的、日常不常说的组合比如“小舟小舟”“方舟方舟”。声学区分度要高唤醒词里的音素最好覆盖不同频段避免全是元音或全是辅音。“小舟”里有x、i、ao、zh、ou频段分布就比较合理。长度控制在0.5-1.2秒太短容易误触发太长用户喊起来累。三到四个字刚好。多音字要小心如果唤醒词里有“行”“重”这种多音字模型可能对两种发音都敏感增加误报。提示唤醒词一旦确定最好用真实设备在目标场景里录几百条正负样本测一下误报率别只看模型标称指标。2.4 KWS在MCU上的极限优化如果你的目标平台是MCU比如ESP32、STM32资源极其紧张那KWS方案要往极限压。几个手段第一是模型量化。把FP32模型量化成INT8模型大小能压到原来的1/4推理速度提升2-3倍。sherpa-onnx支持量化模型导出但要注意量化后准确率会掉1-3个百分点需要重新测阈值。第二是特征计算下沉。MFCC计算其实挺耗CPU的如果MCU有硬件FFT加速一定要用上。没有的话考虑用定点数运算替代浮点。第三是降低帧率。不是每帧都要推理可以每2-3帧推理一次用滑窗平滑结果。这样CPU占用能降一半代价是响应延迟增加20-30ms多数场景可以接受。3. 方案二流式ASR的部署与调优3.1 流式ASR和离线ASR的区别很多人分不清流式ASR和离线ASR。简单说流式ASR是边说边出字用户说“今天天气”说到“天气”时前面“今天”已经识别出来了离线ASR是说完一整段再出结果延迟高但准确率通常更好。端侧场景下流式ASR更适合实时交互比如语音输入、实时字幕。Audio8方案二主推的就是流式ASR底层可以用sherpa-onnx的流式模型也可以用FunASR的Paraformer流式版本。FunASR是阿里开源的语音识别工具链它的Paraformer模型在中文识别上表现很好而且有专门的流式版本。sherpa-onnx则更偏向跨平台部署对安卓、iOS、嵌入式支持更完善。两者可以结合用FunASR训练/导出模型用sherpa-onnx做端侧推理。3.2 流式ASR的模型选型对比模型来源中文准确率模型大小流式延迟部署难度Paraformer-streamingFunASR高80-200MB低中Zipformer-streamingsherpa-onnx高50-150MB低低Conformer-streaming通用中高100-300MB中中Whisper-tinyOpenAI中40-80MB高低Whisper虽然名气大但它的流式支持其实不好端侧部署延迟偏高不太适合实时交互场景。Paraformer和Zipformer是端侧流式ASR的主力。我实测下来Zipformer在sherpa-onnx上的部署体验最顺模型导出、量化、推理一条龙安卓上跑起来CPU占用也比较可控。Paraformer准确率略高一点但模型转换和部署要麻烦一些适合对准确率要求极高的场景。3.3 流式ASR的关键参数配置流式ASR的配置比KWS复杂核心参数有这么几个# sherpa-onnx 流式ASR配置示例 recognizer_config { feat_config: { sample_rate: 16000, feature_dim: 80, }, model_config: { tokens: tokens.txt, encoder: encoder.onnx, decoder: decoder.onnx, joiner: joiner.onnx, # transducer结构才有 }, decoding_method: greedy_search, # 或 modified_beam_search max_active_paths: 4, # beam search时的候选数 chunk_size: 16, # 流式块大小影响延迟 }chunk_size是流式ASR最关键的参数之一。它决定每次推理处理多少帧音频chunk越小延迟越低但推理次数越多、CPU占用越高。16帧约160ms是个比较平衡的值追求低延迟可以降到8追求低功耗可以升到32。decoding_method的选择也有讲究。greedy_search最快但准确率略低modified_beam_search准确率高但慢一些。端侧如果CPU有余量建议用beam searchmax_active_paths设4左右再高收益递减。3.4 端点检测VAD的配合使用流式ASR单独用会有个问题不知道用户什么时候说完。这时候需要VAD语音活动检测来配合。VAD判断一段音频里有没有人声检测到静音超过一定时长就认为一句话结束触发ASR出最终结果。sherpa-onnx内置了VAD模块配置大概是这样vad_config { silero_vad: { model: silero_vad.onnx, threshold: 0.5, # 语音判定阈值 min_silence_duration: 0.5, # 静音多久算说完 min_speech_duration: 0.25, # 最短语音时长 window_size: 512, # 每次处理的采样点数 } }min_silence_duration设0.5秒意味着用户停顿半秒就认为说完了。这个值设太小用户思考时的自然停顿会被误判为结束设太大交互响应变慢。中文场景下0.5-0.8秒比较合适。注意VAD和ASR的采样率必须一致都是16kHz。如果VAD输出8kHz音频喂给16kHz的ASR识别结果会完全乱掉。3.5 流式ASR的延迟优化实战延迟是流式ASR的核心指标我实测过几个优化手段第一模型量化到INT8。Zipformer量化后模型从120MB降到35MB推理速度提升约2.5倍准确率掉不到1个百分点。这个性价比极高强烈建议做。第二特征计算和推理流水线化。别等特征全算完再推理用双缓冲一边算下一块的特征一边推理当前块。这样能隐藏掉特征计算的时间。第三线程绑定。安卓上把推理线程绑到大核避免被调度到小核。用taskset或者线程亲和性API都能做。第四降低采样率。如果场景允许8kHz采样率能让计算量减半。但中文识别8kHz准确率会明显下降除非是特定命令词场景否则不建议。4. 方案三离线TTS的实现路径4.1 端侧TTS的技术路线选择端侧TTS比ASR更难做因为TTS要生成音频计算量更大而且对音质要求高。目前主流路线有三条拼接式TTS预先录好音素、音节的音频片段合成时拼接起来。优点是计算量极小MCU都能跑缺点是音质生硬韵律差听起来像机器人。参数式TTS用声学模型预测声学参数如梅尔频谱再用声码器合成波形。这是目前端侧TTS的主流sherpa-onnx的TTS就是这条路。音质比拼接式好很多模型大小30-150MB。端到端TTS直接从文本生成波形如VITS、FastSpeech2HiFiGAN。音质最好但模型大、计算重端侧部署有挑战。Audio8方案三主推的是参数式TTS配合sherpa-onnx的VITS模型。VITS其实是端到端结构但sherpa-onnx做了优化能在中端SoC上实时跑。4.2 sherpa-onnx TTS的部署要点sherpa-onnx的TTS部署流程大概是加载模型→文本前端处理→声学模型推理→声码器合成→输出音频。每一步都有坑。文本前端处理是最容易被忽视的环节。中文TTS需要做分词、多音字消歧、数字转写。比如“2024年”要转成“二零二四年”“银行”的“行”要读xíng还是háng这些都需要前端规则处理。sherpa-onnx内置了基础的中文前端但多音字处理不够完善复杂场景要自己加规则。声学模型推理是计算大头。VITS模型在骁龙865上跑实时率RTF大概0.3-0.5意思是合成1秒音频需要0.3-0.5秒计算能实时。但在低端芯片上RTF可能超过1就做不到实时了。声码器合成是最后一步HiFiGAN声码器计算量也不小。有些方案会把声码器也量化进一步提速。4.3 TTS模型量化与音质平衡TTS量化比ASR量化更敏感因为音质劣化人耳很容易听出来。我的经验是声学模型可以量化到INT8音质损失很小速度提升明显。声码器尽量保持FP16量化到INT8会有明显杂音。如果必须全INT8要做A/B测试让多人盲听对比确认可接受再上线。sherpa-onnx支持导出不同精度的模型部署时根据芯片能力选择。高端芯片用FP16中低端用INT8声学模型FP16声码器的混合方案。4.4 TTS在安卓上的集成实操安卓上集成sherpa-onnx TTS核心是JNI调用。大概流程// 1. 加载native库 System.loadLibrary(sherpa-onnx-jni); // 2. 初始化TTS long tts SherpaOnnxCreateOfflineTts(ttsConfig); // 3. 合成 GeneratedAudio audio SherpaOnnxOfflineTtsGenerate(tts, text, speakerId, speed); // 4. 播放 AudioTrack track new AudioTrack(...); track.write(audio.samples, 0, audio.samples.length);speed参数控制语速1.0是正常1.2是加快20%。中文TTS建议0.9-1.1之间太快听不清太慢显得拖沓。speakerId是多说话人模型才有的参数。如果模型支持多音色可以切换不同说话人。单说话人模型这个参数忽略。提示TTS合成是阻塞操作别在主线程调用否则UI会卡。用单独线程或者协程处理合成完再回调播放。4.5 TTS缓存策略端侧TTS有个实用技巧缓存常用语句。像“已开机”“电量不足”“请稍等”这种固定播报第一次合成后把音频缓存起来下次直接播放省掉合成时间。这样常用语句响应能快到几乎无感。缓存key用文本说话人语速的组合缓存文件放应用私有目录。注意控制缓存大小别把存储撑爆可以设个LRU上限比如最多缓存100条。5. 方案四全链路语音交互的整合5.1 全链路架构设计方案四是把KWS、ASR、TTS串起来形成一个完整的语音交互闭环。典型流程是设备待机KWS持续监听唤醒词检测到唤醒词唤醒ASR开始录音ASR流式识别用户指令VAD检测到说话结束ASR出最终结果业务逻辑处理指令TTS合成回复语音并播放回到待机KWS继续监听这个流程看起来简单但实际整合时资源调度是大问题。KWS、ASR、TTS三个模型如果同时常驻内存占用会很大。合理的做法是按需加载待机时只加载KWS唤醒后再加载ASRASR用完释放需要TTS时再加载TTS。5.2 资源调度与内存管理全链路方案的内存管理是核心难点。我实测过一个配置阶段常驻模型内存占用待机KWS30MB识别中KWSASR280MB合成中ASRTTS350MB播放中TTS200MB可以看到峰值内存在合成阶段达到350MB。如果设备只有512MB内存加上系统和应用本身就很紧张了。优化手段ASR和TTS不同时加载识别完先释放ASR再加载TTS虽然增加加载时间约200-500ms但省内存。模型分片加载大模型分成多个文件用到哪部分加载哪部分。量化压缩全链路模型都量化内存能省40%左右。5.3 状态机设计与异常处理全链路交互必须有个清晰的状态机否则容易出现“说着说着突然被唤醒词打断”这种混乱。状态设计大概是IDLE待机KWS监听 → WAKING检测到唤醒词加载ASR → LISTENINGASR识别中 → THINKING业务处理 → SPEAKINGTTS播放 → IDLE每个状态转换都要有超时保护。比如LISTENING状态如果10秒没检测到语音自动回IDLESPEAKING状态如果播放异常也要能回IDLE。没有超时保护设备容易卡死在某个状态。异常处理还要考虑打断。用户在TTS播放时又说唤醒词应该立即停止播放回到LISTENING。这需要KWS在SPEAKING状态也保持监听或者用回声消除AEC避免TTS声音触发KWS。5.4 全链路的性能实测数据我在一块RK3588板子上跑过完整方案四配置是KWS用sherpa-onnx的轻量模型ASR用Zipformer流式INT8TTS用VITS INT8。实测数据唤醒响应约80ms从说完唤醒词到提示音ASR首字延迟约300msASR整句延迟约500ms说完到出完整结果TTS首音延迟约400ms全链路一轮交互约1.5-2秒这个数据在端侧算不错的用户体验基本流畅。如果芯片再弱一些比如RK3399全链路可能到3秒以上就需要进一步优化或者降级方案比如TTS用拼接式。6. 常见问题与排查技巧实录6.1 模型加载失败排查模型加载失败是最常见的问题原因通常有这么几类现象可能原因排查方法报错找不到文件路径错误/文件没打包检查assets路径和实际文件报错格式不支持模型版本不匹配确认sherpa-onnx版本和模型版本加载后推理崩溃内存不足看logcat的OOM信息推理结果全空输入格式错误检查采样率、特征维度我遇到最多的是模型版本不匹配。sherpa-onnx更新比较快不同版本对模型格式要求不同。建议锁定一个版本模型也从对应版本的仓库下载别混用。6.2 识别准确率低的调优识别准确率低先别急着换模型按这个顺序排查检查音频输入采样率对不对有没有直流偏移增益是不是太小检查特征提取特征维度和模型要求一致吗有没有做归一化检查VAD切分是不是把一句话切成了两半调整min_silence_duration。检查模型本身换个测试音频如果标准测试集上准确率正常那就是前端问题。实测中音频增益是最容易被忽视的。麦克风增益太小音频幅度低特征提取后信噪比差识别率直线下降。安卓上可以用AudioRecord的setMicrophoneMute和增益API调整或者在前端做软件增益。6.3 误唤醒的抑制手段误唤醒是KWS方案的头号敌人。除了调threshold还有几个手段二次确认检测到唤醒词后再跑一个更严格的模型确认两个都通过才真正唤醒。代价是响应延迟增加。上下文过滤如果设备正在播放音频提高唤醒阈值避免自己的声音触发。声纹验证如果场景需要可以加说话人验证只有注册用户的声音能唤醒。但这会增加计算量。多麦克风阵列用波束成形聚焦到说话人方向抑制环境噪声。硬件成本高但效果最好。6.4 TTS音质问题的排查TTS音质问题主要有几类机械音/杂音通常是量化过度或者声码器问题。试试提高声码器精度或者换FP16模型。断字/吞字文本前端处理问题。检查分词是否正确多音字有没有处理。语速异常speed参数设置问题或者模型本身的韵律预测有问题。试试不同speed值。爆音音频幅度超限。检查合成后的音频有没有做限幅limiter峰值别超过0dBFS。提示TTS音质评估最好用客观指标如MOS分主观盲听结合。自己听容易有偏差找几个人一起听更靠谱。6.5 内存泄漏的定位端侧语音应用跑久了内存涨多半是泄漏。常见泄漏点JNI对象没释放每次调用创建的对象要记得delete。音频缓冲区没回收AudioTrack用完要release。模型重复加载状态切换时没释放旧模型就加载新的。定位方法用Android Studio的Memory Profiler看native heap的增长趋势。如果每次交互后native heap都涨一点不回落基本就是泄漏。重点查JNI层的对象生命周期。7. 工具链与生态的选型建议7.1 sherpa-onnx vs FunASR怎么选这两个是端侧语音最常用的工具链但定位不同sherpa-onnx跨平台部署强安卓、iOS、Linux、嵌入式都支持C核心多语言绑定。模型格式统一onnx量化工具完善。适合产品化部署。FunASR训练和模型丰富度强Paraformer系列中文识别效果好有完整的训练、微调、导出流程。适合需要定制模型或者追求极致准确率的场景。实际项目里我经常两个都用用FunASR训练/微调模型导出onnx后用sherpa-onnx部署。这样既拿到好模型又有好的部署体验。7.2 Unity集成sherpa-onnx的注意事项Unity做端侧语音的不少尤其是做AR/VR或者互动装置的。Unity集成sherpa-onnx有几个坑第一平台差异。Unity的Android和iOS构建对native库的加载方式不同Android要放Plugins/AndroidiOS要放Plugins/iOS而且iOS还要处理bitcode和架构问题。第二音频格式转换。Unity的Microphone类拿到的音频是float数组sherpa-onnx要int16需要转换。转换时注意归一化和溢出处理。第三线程模型。Unity的主线程不能阻塞sherpa-onnx的推理要放到子线程结果通过回调或者消息队列传回主线程。第四KWS在Unity里的实现。Unity做KWS通常是每帧拿麦克风数据累积到一定长度后喂给KWS模型。注意帧率要和音频采样率匹配别丢帧。7.3 模型转换的常见坑从训练框架导出onnx模型再到sherpa-onnx能用中间有不少坑算子不支持训练框架用了sherpa-onnx不支持的算子导出后加载失败。解决方法是替换算子或者用sherpa-onnx支持的等价结构。动态shape问题onnx支持动态shape但sherpa-onnx对某些动态维度支持不好。尽量固定输入shape。量化精度损失量化后准确率掉太多需要做量化感知训练QAT或者调整量化参数。元数据丢失模型需要的元信息如采样率、特征配置在转换中丢失需要手动补上。我一般会在转换后做个完整的回归测试用标准测试集跑一遍确认准确率和原模型差距在可接受范围内再部署。8. 端侧语音的落地经验与扩展方向8.1 从Demo到产品的距离跑通Demo和做成产品之间差距比想象中大。Demo阶段你可能只测了几十条音频产品阶段要面对各种口音、各种噪声、各种设备。我的经验是测试集要覆盖真实场景别只用干净录音要包含噪声、远场、不同口音。要有降级方案端侧模型搞不定的时候能不能切云端或者给用户文字输入选项要有数据回流产品上线后收集badcase持续优化模型。端侧也要留日志上报的口子。功耗要实测语音常驻监听对续航影响很大要实测待机功耗必要时做分级唤醒。8.2 多模态融合的扩展端侧语音往深了做可以和多模态结合。比如语音视觉唤醒摄像头检测到人脸语音唤醒词双重确认误唤醒率大幅降低。语音手势特定手势配合语音指令交互更自然。语音传感器设备运动状态辅助判断比如设备在口袋里时降低唤醒灵敏度。这些融合方案能显著提升体验但复杂度也上去了适合有资源的中高端产品。8.3 端侧语音的未来趋势从我这段时间的观察端侧语音有几个明显趋势模型越来越小但效果越来越好新的网络结构和训练方法让小模型也能有不错的准确率这对端侧是利好。端云协同成为主流不是所有任务都端侧做简单的端侧处理复杂的上云按需切换。这样兼顾延迟、成本和准确率。个性化定制用户自己的声音、自己的唤醒词端侧微调成为可能。这对隐私敏感场景特别有价值。硬件加速普及NPU、DSP对语音模型的支持越来越好端侧语音的性能天花板在抬高。我在实际项目里的体会是端侧语音选型没有银弹关键是匹配场景。Audio8的四类方案给了个很好的框架但具体到你的产品还是要根据芯片能力、交互需求、成本预算来定。先把需求想清楚再对着方案选比一上来就纠结模型参数要高效得多。踩过的坑告诉我最贵的不是模型是选错方向后返工的时间。