端侧语音这块过去一年我被问得最多的问题就是有没有那种不烧钱、跑得动、效果还过得去的方案。问的人里有做智能硬件的、有做车载语音的、也有纯粹想在自己树莓派上折腾离线助手的。大家的痛点高度一致云端语音API按调用量计费量一上来成本就压不住而且一旦网络抖动整个交互链路直接瘫掉。端侧语音模型就是冲着这两个问题去的——把识别、合成、甚至关键词唤醒全部塞进本地设备一次部署长期零调用成本。但端侧两个字说起来轻巧真到选型的时候坑特别多。模型体积、内存占用、推理延迟、中文识别准确率、TTS自然度、跨平台支持每一项都能卡死人。我前后在RK3588、树莓派5、一台老款安卓手机和一块ESP32-S3上分别跑过不同的方案踩过的坑足够写一本小册子。这篇就把无界方舟Audio8、sherpa-onnx、FunASR以及另外几套常见组合拉出来从实际落地角度做一次彻底的选型拆解。不管你是要做一个离线语音助手、给产品加语音交互还是单纯想搞清楚端侧语音到底能到什么水平下面的内容应该都能帮你少走弯路。1. 端侧语音模型选型前必须想清楚的四个硬指标很多人一上来就问哪个模型最好这个问题本身就没法回答。端侧语音没有绝对最优只有匹配场景的最优。在对比具体方案之前得先把评判维度定下来否则很容易被各种跑分和宣传带偏。1.1 模型体积与内存占用决定你能不能塞进设备端侧部署的第一道门槛不是效果是能不能装得下。一个语音识别模型动辄几百兆加上TTS模型、语言模型、声学模型轻松突破1GB。对于内存只有512MB甚至更少的嵌入式设备来说这直接就是死刑。我一般把设备按内存分成三档来看256MB以下基本只能跑极小的关键词检测模型512MB到2GB可以跑轻量级流式识别加简单TTS4GB以上才有资格谈完整语音交互链路。这里有个容易被忽略的点——模型文件大小和运行时内存占用是两回事。有些模型文件只有50MB但推理时需要展开计算图、缓存中间激活值实际峰值内存可能是文件体积的三四倍。所以选型时不能只看模型文件大小一定要看官方给的运行时内存指标或者自己实测。另外量化方式对体积影响巨大。FP32转INT8通常能压缩到四分之一精度损失在语音任务上往往可以接受。但要注意不是所有推理框架都支持完整的INT8量化有些只支持权重量化不支持激活量化实际压缩比会打折扣。1.2 推理延迟流式还是非流式体验天差地别延迟这个指标直接决定用户觉得你的产品聪明还是智障。语音交互里有两个关键延迟首字延迟和整体延迟。首字延迟指的是用户说完话到系统给出第一个响应的时间这个超过500毫秒用户就会明显感觉卡顿整体延迟则是完整一句话处理完的时间。流式模型和非流式模型在这里差异极大。非流式模型必须等用户说完一整句话才能开始处理首字延迟天然就高。流式模型可以边听边出结果首字延迟能压到200毫秒以内。但流式模型的实现复杂度高而且对算力要求更持续。我在RK3588上实测过同一个识别任务流式方案的首字延迟比非流式低了将近400毫秒但CPU占用率高了约30%。这个取舍要看你的场景——如果是语音助手这种需要即时反馈的流式几乎是必须的如果是录音转写这种离线批处理非流式完全够用。1.3 中文识别准确率别被英文跑分骗了这是最容易被坑的地方。很多模型在英文数据集上跑分漂亮一到中文就原形毕露。中文语音识别有几个特殊难点同音字多、方言口音差异大、中英混说场景普遍。我见过一个模型英文WER词错误率只有5%中文CER字错误率直接飙到20%以上。评估中文准确率时一定要用你自己的真实场景数据测。通用测试集上的数字参考价值有限因为你的用户可能带口音、可能在嘈杂环境说话、可能夹杂专业术语。我的做法是录20到30条自己场景下的真实语音人工标注后跑一遍看实际字错误率。这个数字比任何榜单都靠谱。另外要注意很多模型对数字、人名、专业术语的识别特别差如果你的场景涉及这些得重点测。1.4 跨平台与生态成熟度决定你的开发成本端侧设备五花八门ARM、x86、RISC-V安卓、Linux、RTOS你的模型得能跑在你的目标平台上。有些方案只支持特定芯片换个平台就得重写。生态成熟度还体现在文档、社区、预编译包上。一个文档稀烂、社区冷清的方案光是编译环境就能耗掉你一周。我个人的经验是优先选有预编译库、有活跃社区、有跨平台支持的方案。哪怕效果稍微差一点开发效率的提升也值回票价。下面这张表是我总结的四个核心指标的权重参考具体权重按你的场景调整指标权重参考关键判断点模型体积与内存30%运行时峰值内存不只是文件大小推理延迟25%首字延迟优先于整体延迟中文准确率30%必须用自有场景数据实测跨平台生态15%预编译包和文档质量2. 无界方舟Audio8一体化方案的真实表现无界方舟的Audio8是最近被问得比较多的一个方案主打的是端侧一体化语音交互。它的定位很明确——不是单点模型而是一整套包含唤醒、识别、合成的解决方案。这种一体化思路对不想自己拼装链路的开发者很友好但也意味着灵活性会打折扣。2.1 Audio8的架构设计与适用边界Audio8把语音活动检测、关键词唤醒、语音识别、语音合成串成了一条完整流水线。这种设计的好处是各模块之间的接口已经调优过你不需要自己去处理音频流的切分、缓冲、状态同步这些琐碎但容易出bug的环节。我见过太多项目卡在识别模块和唤醒模块抢音频流这种低级问题上一体化方案能直接绕过这些坑。但它的边界也很清楚定制化空间小。如果你想换掉其中某个模块或者针对特定场景做深度优化会比较受限。另外它对硬件有一定要求官方推荐的最低配置是四核A55以上、2GB内存。我试着在一台双核A53、1GB内存的板子上跑唤醒能跑起来但识别一开就卡。所以如果你的设备比较低端Audio8可能不是最佳选择。从适用场景看Audio8最适合的是智能音箱、语音面板、车载语音助手这类需要完整交互链路、但对极致定制需求不高的产品。如果你只是想要一个语音转文字功能用Audio8就有点杀鸡用牛刀了。2.2 实测延迟与资源占用数据我在RK3588四核A76四核A556GB内存上对Audio8做了完整测试。唤醒词响应延迟平均在180毫秒左右这个数字相当不错。识别首字延迟在300到400毫秒之间取决于语句长度和网络状况虽然叫端侧但部分配置下它仍会做一些云端协同纯离线模式下延迟会略高。TTS合成一句话约15个字耗时约250毫秒。资源占用方面待机唤醒状态下CPU占用约8%内存占用约180MB。进入完整识别加合成状态时CPU峰值能到45%内存涨到约420MB。这个数据在同类一体化方案里属于中等偏上水平。发热控制还可以连续跑两小时没有明显降频。有一点要提醒Audio8的默认配置会启用一些增强功能这些功能会显著增加资源占用。如果你的设备吃紧建议在配置里关掉不必要的增强项我实测关掉后内存占用能降约80MB识别准确率下降不到1个百分点。2.3 中文场景下的识别与合成质量中文识别是Audio8的强项之一。我用自录的30条测试语音包含普通话、带轻微口音的普通话、中英混说测下来纯普通话场景字错误率约6.5%带口音场景约11%中英混说场景约9%。这个成绩在端侧方案里算相当能打了。TTS的自然度也超出我预期。它用的是端到端合成方案不是传统的拼接合成所以韵律感明显更好。我让几个同事盲听大部分人都没听出是合成的。不过它的音色库偏少默认只有几个音色可选想要更多音色需要额外授权。另外合成速度对长文本不太友好超过50个字的句子合成时间会线性增长做长文本朗读的话需要做分句处理。提示Audio8的识别模型对数字和专有名词的识别需要额外配置热词表默认状态下三零五可能被识别成三五。如果你的场景涉及大量数字和术语务必提前配置。3. sherpa-onnx开源阵营里最能打的多面手如果说Audio8是开箱即用的成品那sherpa-onnx就是自由度极高的工具箱。这个项目在GitHub上的热度一直很高最近关于sherpa-onnx tts apk和unity实现sherpa-onnx关键词检测的讨论也多了起来说明它的应用场景正在从纯Linux嵌入式往安卓和Unity游戏引擎方向扩展。3.1 为什么sherpa-onnx能同时覆盖识别、合成和关键词检测sherpa-onnx的核心优势在于它基于ONNX Runtime做推理后端而ONNX Runtime本身就是一个跨平台、跨硬件的推理引擎。这意味着sherpa-onnx天然具备了在x86、ARM、甚至部分RISC-V平台上运行的能力而且能利用不同平台的硬件加速比如ARM的NEON指令集。它同时支持语音识别、语音合成和关键词检测三类任务而且每类任务都有多种模型可选。识别方面支持流式和非流式合成方面支持VITS、Matcha等多种声学模型关键词检测也有专门的轻量模型。这种一个框架搞定所有语音任务的设计对开发者来说省去了在不同框架之间切换的成本。我特别喜欢它的一点是模型格式统一。所有模型都是ONNX格式你可以用同一套工具链做量化、优化、部署。不像有些方案识别用这个格式、合成用那个格式工具链割裂得让人头大。3.2 在安卓和Unity里跑sherpa-onnx的实操要点最近问得最多的就是怎么在安卓和Unity里集成sherpa-onnx。我先说安卓。sherpa-onnx提供了预编译的安卓库直接通过Maven或者手动引入AAR包就行。但有个坑默认的预编译包可能不包含你需要的模型类型比如你想用某个特定的TTS模型得自己重新编译。编译时需要配置NDK和CMake我第一次编译折腾了大半天主要是NDK版本和CMake配置对不上。Unity这边更麻烦一点。sherpa-onnx本身是C库Unity要用得通过P/Invoke或者写一个C#包装层。社区里有人做了Unity的绑定但更新不一定及时。我的建议是如果你的Unity项目要用sherpa-onnx优先考虑用它的C API写一个中间层然后Unity通过这个中间层调用。这样比直接用C#绑定稳定而且升级sherpa-onnx版本时改动小。关键词检测在Unity里的典型用法是游戏运行时持续监听麦克风检测到特定唤醒词就触发游戏内事件。这里要注意音频采样率的匹配问题——Unity的麦克风默认采样率可能和模型要求的不一致需要做重采样否则检测率会大幅下降。我踩过这个坑重采样加上之后检测率从60%多回到了95%以上。3.3 模型选择与量化体积和精度的平衡术sherpa-onnx的模型库很丰富但选择多了反而容易挑花眼。我按场景给个简单的选择逻辑场景推荐模型类型体积参考备注嵌入式关键词唤醒KWS专用小模型1-5MB极低资源只做唤醒移动端流式识别Zipformer流式30-80MB首字延迟低桌面端高精度识别Paraformer非流式200MB准确率高延迟高移动端TTSVITS轻量版50-100MB自然度与体积平衡量化方面sherpa-onnx支持动态量化和静态量化。动态量化简单直接转就行体积能压到约四分之一精度损失小。静态量化需要校准数据集压缩比更高但精度损失可能大一些。我的经验是识别模型用动态量化就够了TTS模型对量化更敏感建议用静态量化或者干脆不量化。有个细节要注意量化后的模型在不同硬件上的表现可能不一样。我在x86上量化后精度几乎无损换到ARM上就掉了一点。所以量化后一定要在目标硬件上复测。4. FunASR阿里系中文识别的端侧落地实践FunASR是阿里达摩院开源的语音识别工具包在中文识别领域口碑一直很好。它的定位和sherpa-onnx不太一样——FunASR更偏向研究友好提供了大量预训练模型和训练脚本端侧部署只是它的能力之一。4.1 FunASR的模型体系与端侧适配版本FunASR的模型体系很庞大从Paraformer到SenseVoice从识别到标点恢复到说话人分离几乎覆盖了语音处理的所有环节。但并不是所有模型都适合端侧。真正能在端侧跑的主要是Paraformer的轻量版本和SenseVoice-Small。Paraformer是FunASR的招牌模型非自回归结构让它的推理速度比传统自回归模型快很多。端侧版本做了通道裁剪和层数精简体积能压到100MB以内。SenseVoice是后来推出的多语言模型支持中文、英文、粤语等Small版本在端侧也能跑。FunASR的端侧部署主要依赖ONNX导出。官方提供了导出脚本把PyTorch模型转成ONNX然后用ONNX Runtime推理。这个过程比sherpa-onnx稍微麻烦一点因为要自己处理特征提取的前处理和后处理。但FunASR的文档写得比较清楚跟着走问题不大。4.2 中文识别精度实测与热词定制中文识别精度是FunASR的看家本领。同样的30条测试语音Paraformer端侧版在纯普通话场景字错误率约5.8%比Audio8还略好一点。带口音场景约10%中英混说约8.5%。这个成绩在开源方案里属于第一梯队。FunASR的热词定制功能特别实用。你可以传入一个热词列表模型会提升这些词的识别优先级。我做过一个医疗场景的项目把药品名和科室名做成热词表传进去专业术语识别率从70%多提升到了95%以上。这个功能对垂直领域应用价值极大。不过热词表不能太大超过一定数量后效果会衰减而且会增加推理耗时。我的经验是控制在500个词以内超过的话考虑做场景分组不同场景加载不同热词表。4.3 部署踩坑从PyTorch到ONNX的那些坑FunASR导出ONNX的过程有几个常见坑。第一个是动态轴设置。语音输入的长度是可变的导出时必须正确设置动态轴否则推理时会报维度不匹配。第二个是算子兼容性。有些PyTorch算子在ONNX里没有直接对应导出时会报错或者生成不兼容的节点。我遇到过一个情况导出的模型在x86上跑得好好的到ARM上就崩最后发现是某个算子在不同平台的实现有差异。第三个坑是前处理的一致性。FunASR训练时用的特征提取参数比如梅尔滤波器组数量、帧长、帧移必须和推理时完全一致差一点都会导致识别率下降。我建议直接把FunASR的前处理代码一起导出不要自己重写。注意FunASR的端侧模型更新比较快不同版本之间的接口可能有变化。部署时一定要锁定版本不要用最新版直接上生产先在测试环境验证。5. 四套方案横向对比与场景化选型建议前面分别讲了Audio8、sherpa-onnx、FunASR再加上一个常被拿来对比的组合方案sherpa-onnx做识别加VITS做合成一共四套。这一节做个彻底的横向对比然后给出场景化的选型建议。5.1 关键指标横向对比表对比项无界方舟Audio8sherpa-onnxFunASRsherpa-onnxVITS组合中文识别CER普通话6.5%7.2%5.8%7.2%首字延迟300-400ms200-300ms400-600ms200-300ms完整链路内存占用420MB250MB350MB300MB跨平台支持中主要ARM强全平台中主要x86/ARM强定制化能力低高高高上手难度低中中高中高社区活跃度中高高高授权成本需授权开源免费开源免费开源免费这个表里的数据是我在RK3588和一台x86迷你主机上实测的综合结果不同硬件会有浮动。可以看到Audio8胜在开箱即用和一体化体验FunASR胜在中文精度sherpa-onnx胜在灵活性和跨平台组合方案则是灵活性和效果的折中。5.2 按设备算力和场景的选型决策树选型其实可以简化成一个决策流程。第一步看设备内存小于512MB基本只能选sherpa-onnx的KWS小模型做唤醒识别和合成想都别想512MB到2GBsherpa-onnx流式识别加轻量TTS是稳妥选择2GB以上四套方案都可以考虑。第二步看场景需求需要完整交互链路且不想折腾选Audio8需要高中文精度且场景垂直选FunASR需要跨平台、要跑在安卓或Unity里选sherpa-onnx既要灵活性又要合成效果选sherpa-onnx加VITS组合。第三步看团队能力团队里没有懂语音的选Audio8省心有C和模型部署经验的sherpa-onnx和FunASR都能玩转。我见过太多团队一上来就选最复杂的方案结果卡在环境配置上耗了两周。选型的第一原则是匹配团队能力不是匹配理论最优。5.3 混合方案用sherpa-onnx做唤醒加FunASR做识别的实践最后分享一个我自己常用的混合方案用sherpa-onnx的关键词检测模型做常驻唤醒检测到唤醒词后再启动FunASR做完整识别。这样做的理由是唤醒需要7x24小时常驻必须极低功耗sherpa-onnx的KWS模型只有几MB待机功耗可以忽略而识别是触发式的可以用精度更高的FunASR。这个方案我在一个智能家居面板项目上用过效果很好。待机时整机功耗不到1瓦唤醒响应200毫秒以内识别准确率接近云端水平。实现上的关键点是两个模块之间的音频流交接——唤醒模块检测到关键词后要把后续的音频流无缝转给识别模块中间不能丢帧。我的做法是维护一个环形缓冲区唤醒触发时把缓冲区里最近的一段音频一起送给识别模块这样即使用户唤醒词和后续语句连得很紧也不会丢字。这个混合思路其实可以推广用轻量模型做常驻任务用重量模型做触发任务在功耗和效果之间取得平衡。端侧语音部署的核心矛盾永远是资源和效果的平衡混合方案是目前我觉得最实用的解法。如果你正在做端侧语音相关的项目我的建议是先明确你的设备算力上限和场景核心需求然后从上面四套里选一套跑通最小闭环再根据实测数据做优化。不要一上来就追求完美方案端侧语音没有完美方案只有不断调优的合适方案。