企业官网建设流程全解析

端侧语音这块，过去一年我被问得最多的问题就是"有没有那种不烧钱、跑得动、效果还过得去的方案"。问的人里有做智能硬件的、有做车载语音的、也有纯粹想在自己树莓派上折腾离线助手的。大家的痛点高度一致：云端语音API按调用量计费，量一上来成本就压不住；而且一旦网络抖动，整个交互链路直接瘫掉。端侧语音模型就是冲着这两个问题去的——把识别、合成、甚至关键词唤醒全部塞进本地设备，一次部署，长期零调用成本。

但"端侧"两个字说起来轻巧，真到选型的时候坑特别多。模型体积、内存占用、推理延迟、中文识别准确率、TTS自然度、跨平台支持，每一项都能卡死人。我前后在RK3588、树莓派5、一台老款安卓手机和一块ESP32-S3上分别跑过不同的方案，踩过的坑足够写一本小册子。这篇就把无界方舟Audio8、sherpa-onnx、FunASR以及另外几套常见组合拉出来，从实际落地角度做一次彻底的选型拆解。不管你是要做一个离线语音助手、给产品加语音交互，还是单纯想搞清楚端侧语音到底能到什么水平，下面的内容应该都能帮你少走弯路。

1. 端侧语音模型选型前必须想清楚的四个硬指标

很多人一上来就问"哪个模型最好"，这个问题本身就没法回答。端侧语音没有绝对最优，只有匹配场景的最优。在对比具体方案之前，得先把评判维度定下来，否则很容易被各种跑分和宣传带偏。

1.1 模型体积与内存占用：决定你能不能塞进设备

端侧部署的第一道门槛不是效果，是能不能装得下。一个语音识别模型动辄几百兆，加上TTS模型、语言模型、声学模型，轻松突破1GB。对于内存只有512MB甚至更少的嵌入式设备来说，这直接就是死刑。

我一般把设备按内存分成三档来看：256MB以下基本只能跑极小的关键词检测模型；512MB到2GB可以跑轻量级流式识别加简单TTS；4GB以上才有资格谈"完整语音交互链路"。这里有个容易被忽略的点——模型文件大小和运行时内存占用是两回事。有些模型文件只有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，你的模型得能跑在你的目标平台上。有些方案只支持特定芯片，换个平台就得重写。生态成熟度还体现在文档、社区、预编译包上。一个文档稀烂、社区冷清的方案，光是编译环境就能耗掉你一周。

我个人的经验是，优先选有预编译库、有活跃社区、有跨平台支持的方案。哪怕效果稍微差一点，开发效率的提升也值回票价。下面这张表是我总结的四个核心指标的权重参考，具体权重按你的场景调整：

2. 无界方舟Audio8：一体化方案的真实表现

无界方舟的Audio8是最近被问得比较多的一个方案，主打的是"端侧一体化语音交互"。它的定位很明确——不是单点模型，而是一整套包含唤醒、识别、合成的解决方案。这种一体化思路对不想自己拼装链路的开发者很友好，但也意味着灵活性会打折扣。

2.1 Audio8的架构设计与适用边界

Audio8把语音活动检测、关键词唤醒、语音识别、语音合成串成了一条完整流水线。这种设计的好处是各模块之间的接口已经调优过，你不需要自己去处理音频流的切分、缓冲、状态同步这些琐碎但容易出bug的环节。我见过太多项目卡在"识别模块和唤醒模块抢音频流"这种低级问题上，一体化方案能直接绕过这些坑。

但它的边界也很清楚：定制化空间小。如果你想换掉其中某个模块，或者针对特定场景做深度优化，会比较受限。另外它对硬件有一定要求，官方推荐的最低配置是四核A55以上、2GB内存。我试着在一台双核A53、1GB内存的板子上跑，唤醒能跑起来，但识别一开就卡。所以如果你的设备比较低端，Audio8可能不是最佳选择。

从适用场景看，Audio8最适合的是智能音箱、语音面板、车载语音助手这类需要完整交互链路、但对极致定制需求不高的产品。如果你只是想要一个语音转文字功能，用Audio8就有点杀鸡用牛刀了。

2.2 实测延迟与资源占用数据

我在RK3588（四核A76+四核A55，6GB内存）上对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的模型库很丰富，但选择多了反而容易挑花眼。我按场景给个简单的选择逻辑：

量化方面，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 关键指标横向对比表

这个表里的数据是我在RK3588和一台x86迷你主机上实测的综合结果，不同硬件会有浮动。可以看到，Audio8胜在开箱即用和一体化体验，FunASR胜在中文精度，sherpa-onnx胜在灵活性和跨平台，组合方案则是灵活性和效果的折中。

5.2 按设备算力和场景的选型决策树

选型其实可以简化成一个决策流程。第一步看设备内存：小于512MB，基本只能选sherpa-onnx的KWS小模型做唤醒，识别和合成想都别想；512MB到2GB，sherpa-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毫秒以内，识别准确率接近云端水平。实现上的关键点是两个模块之间的音频流交接——唤醒模块检测到关键词后，要把后续的音频流无缝转给识别模块，中间不能丢帧。我的做法是维护一个环形缓冲区，唤醒触发时把缓冲区里最近的一段音频一起送给识别模块，这样即使用户唤醒词和后续语句连得很紧也不会丢字。

这个混合思路其实可以推广：用轻量模型做常驻任务，用重量模型做触发任务，在功耗和效果之间取得平衡。端侧语音部署的核心矛盾永远是资源和效果的平衡，混合方案是目前我觉得最实用的解法。

如果你正在做端侧语音相关的项目，我的建议是先明确你的设备算力上限和场景核心需求，然后从上面四套里选一套跑通最小闭环，再根据实测数据做优化。不要一上来就追求完美方案，端侧语音没有完美方案，只有不断调优的合适方案。