端侧语音这块，我从去年开始断断续续折腾了不少方案，从最早拿树莓派跑KWS，到后来在安卓板子上做离线TTS，踩的坑能写满一个笔记本。最近不少朋友在问“无界方舟Audio8”这套东西到底怎么选型，尤其是它主推的四类端侧语音方案，配合sherpa-onnx、FunASR这些工具链，很多人一上来就被各种模型格式、推理框架、量化参数绕晕了。这篇就把我实际跑过的四类方案拆开讲清楚，从选型逻辑到落地参数，再到那些文档里不会写的坑，尽量一次说透。不管你是刚接触端侧语音的新手，还是已经在做产品集成的老手，应该都能从里面找到能直接抄作业的部分。
1. 端侧语音方案的整体选型逻辑
1.1 为什么端侧语音突然成了刚需
先说清楚一件事：端侧语音不是新概念，但这两年需求爆发是有具体原因的。最直接的一点是延迟。云端语音识别走一圈网络，哪怕网络再好，端到端延迟也很难压到200ms以内，而端侧做KWS（关键词检测）可以做到50ms以内响应，这个差距在交互体验上是质变的。你对着设备喊一声“小舟小舟”，如果半秒后才亮灯，用户会觉得这设备“笨”；如果几乎同步响应，感觉就完全不一样。
第二个原因是隐私和成本。语音数据不出设备，这在很多场景下是硬性要求，比如会议室记录、车载语音、医疗问诊辅助。另外从成本算，云端ASR按小时计费，一个日活十万的设备如果每天每人用10分钟语音，一个月下来的API费用相当可观，而端侧模型一次部署，边际成本几乎为零。
第三个原因是离线可用性。地下车库、电梯、偏远工地，这些地方网络不稳定甚至完全没有，端侧方案是唯一选择。无界方舟Audio8这套方案的核心卖点，就是把这几个需求打包解决，提供从KWS到ASR到TTS的完整端侧链路。
1.2 四类方案到底在分什么
Audio8的四类方案，我理解下来本质是按任务类型和资源占用两个维度切的：
| 方案类型 | 核心任务 | 典型模型规模 | 内存占用 | 适用芯片 |
|---|---|---|---|---|
| 方案一：KWS关键词检测 | 唤醒词/命令词识别 | 1-5MB | <20MB | MCU、低端SoC |
| 方案二：流式ASR | 实时语音转文字 | 20-100MB | 100-300MB | 中端SoC、手机 |
| 方案三：离线TTS | 文字转语音播报 | 30-150MB | 150-400MB | 中高端SoC |
| 方案四：全链路语音交互 | KWS+ASR+TTS | 组合 | 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的技术原理与模型选择
KWS（Keyword 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-streaming | FunASR | 高 | 80-200MB | 低 | 中 |
| Zipformer-streaming | sherpa-onnx | 高 | 50-150MB | 低 | 低 |
| Conformer-streaming | 通用 | 中高 | 100-300MB | 中 | 中 |
| Whisper-tiny | OpenAI | 中 | 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 search，max_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、FastSpeech2+HiFiGAN。音质最好，但模型大、计算重，端侧部署有挑战。
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，唤醒后再加载ASR，ASR用完释放，需要TTS时再加载TTS。
5.2 资源调度与内存管理
全链路方案的内存管理是核心难点。我实测过一个配置：
| 阶段 | 常驻模型 | 内存占用 |
|---|---|---|
| 待机 | KWS | 30MB |
| 识别中 | KWS+ASR | 280MB |
| 合成中 | ASR+TTS | 350MB |
| 播放中 | TTS | 200MB |
可以看到峰值内存在合成阶段，达到350MB。如果设备只有512MB内存，加上系统和应用本身，就很紧张了。优化手段：
- ASR和TTS不同时加载：识别完先释放ASR再加载TTS，虽然增加加载时间（约200-500ms），但省内存。
- 模型分片加载：大模型分成多个文件，用到哪部分加载哪部分。
- 量化压缩：全链路模型都量化，内存能省40%左右。
5.3 状态机设计与异常处理
全链路交互必须有个清晰的状态机，否则容易出现“说着说着突然被唤醒词打断”这种混乱。状态设计大概是：
IDLE（待机，KWS监听） → WAKING（检测到唤醒词，加载ASR） → LISTENING（ASR识别中） → THINKING（业务处理） → SPEAKING（TTS播放） → IDLE每个状态转换都要有超时保护。比如LISTENING状态如果10秒没检测到语音，自动回IDLE；SPEAKING状态如果播放异常，也要能回IDLE。没有超时保护，设备容易卡死在某个状态。
异常处理还要考虑打断。用户在TTS播放时又说唤醒词，应该立即停止播放，回到LISTENING。这需要KWS在SPEAKING状态也保持监听，或者用回声消除（AEC）避免TTS声音触发KWS。
5.4 全链路的性能实测数据
我在一块RK3588板子上跑过完整方案四，配置是KWS用sherpa-onnx的轻量模型，ASR用Zipformer流式INT8，TTS用VITS INT8。实测数据：
- 唤醒响应：约80ms（从说完唤醒词到提示音）
- ASR首字延迟：约300ms
- ASR整句延迟：约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/Android，iOS要放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的四类方案给了个很好的框架，但具体到你的产品，还是要根据芯片能力、交互需求、成本预算来定。先把需求想清楚，再对着方案选，比一上来就纠结模型参数要高效得多。踩过的坑告诉我，最贵的不是模型，是选错方向后返工的时间。
