企业官网建设流程全解析

端侧语音模型这两年是真的火，但火归火，真到选型落地的时候，很多人还是会卡在同一个问题上：预算有限、设备算力有限、又不想牺牲太多识别效果，到底该选哪个？我自己前前后后折腾过七八套方案，从最早拿树莓派跑语音识别，到后来在手机、开发板、甚至旧笔记本上部署离线语音，踩过的坑能写满一个笔记本。今天这篇就围绕四款我实际用过、且社区反馈比较集中的端侧语音方案——无界方舟Audio8、sherpa-onnx、FunASR，以及一款我常用的轻量级组合方案，把选型逻辑、部署细节、实测表现和避坑经验一次性讲清楚。

如果你正在做智能硬件、离线语音助手、车载语音、工业巡检语音记录，或者只是单纯想在本地跑一个不依赖网络的语音识别，这篇内容应该能帮你省下不少试错时间。我不会只丢几个名词就完事，而是会把每套方案适合什么场景、为什么适合、部署时哪些参数最关键、实测中哪些地方容易翻车，都掰开揉碎讲一遍。全文基于我自己的实操记录和社区常见实践整理，涉及具体参数的地方我会说明计算依据，涉及操作的地方我会给出可复现的步骤。

1. 端侧语音选型前必须想清楚的四个硬约束

很多人一上来就问“哪个模型最好”，这个问题其实没有标准答案。端侧语音和云端语音最大的区别在于，云端你可以堆算力、堆带宽，端侧不行，端侧的每一个字节内存、每一毫秒延迟、每一焦耳功耗都是要精打细算的。所以在选型之前，我建议先把下面四个约束条件想明白，否则后面很容易出现“模型跑起来了但没法用”的尴尬局面。

1.1 算力预算决定了模型规模的上限

端侧设备的算力跨度非常大。低端单片机可能只有几十MHz主频、几百KB内存，而手机旗舰芯片的NPU算力已经能到几十TOPS。你手里的设备到底属于哪一档，直接决定了你能跑多大的模型。

我一般把端侧语音设备分成三档来看。第一档是资源极度受限型，比如基于Cortex-M系列的低功耗MCU，内存通常小于1MB，这类设备基本只能跑关键词唤醒，做不了连续语音识别。第二档是中等资源型，比如树莓派Zero、部分带DSP的音频SoC，内存512MB到2GB，可以跑轻量级流式识别模型。第三档是相对充裕型，比如手机、RK3588这类开发板、旧款x86笔记本，内存4GB以上，可以跑中等规模的离线识别模型，甚至做多路并发。

这里有个经验公式可以参考：模型参数量乘以2（FP16）或乘以1（INT8量化后），大致就是模型加载所需的内存下限。比如一个10M参数的模型，INT8量化后大约占10MB内存，加上运行时开销和音频缓冲区，实际预留30到50MB比较稳妥。如果你设备只剩20MB可用内存，那这个模型就别考虑了，强行跑只会频繁触发内存回收，延迟高到没法用。

1.2 延迟要求决定了流式还是非流式

语音识别有两种工作模式：流式和非流式。流式就是边说边出结果，适合实时字幕、语音助手这类场景；非流式是等一句话说完再整体识别，适合语音转写、录音整理这类场景。

流式模型通常结构更复杂，因为要处理chunk之间的上下文衔接，推理时延要求也更高。我实测下来，端侧流式识别要做到“说完一个字，200毫秒内出结果”，模型推理耗时必须控制在100毫秒以内，剩下的100毫秒留给音频采集、特征提取和后处理。如果你的设备单次推理就要300毫秒，那流式体验会很差，不如老老实实做非流式。

非流式模型相对宽松，一句话说完后一两秒内出结果都能接受。而且非流式模型可以做得更准，因为它能看到完整上下文。所以如果你的场景不是强实时，我建议优先考虑非流式方案，效果和部署难度都会友好很多。

1.3 离线程度决定了你能不能接受联网兜底

“端侧”这个词有时候会被滥用。有些方案号称端侧，但实际上首次加载模型要联网下载，或者遇到生僻词会偷偷走云端。如果你做的是完全离线场景，比如野外作业、保密环境、无网车间，那就必须确认模型和运行时都是纯本地的。

我一般会从三个维度检查离线程度：模型文件是否随应用打包、运行时是否依赖远程服务、后处理是否调用在线接口。这三项只要有一项联网，就不能算真正的端侧方案。无界方舟Audio8和sherpa-onnx在这点上做得比较干净，模型和运行时都可以完全本地化部署。FunASR的离线版本也支持纯本地，但需要自己确认下载的是离线模型包，而不是在线服务版本。

1.4 成本不只是模型本身

很多人算成本只算模型授权费，这是不够的。端侧语音的总成本包括：模型授权或开发成本、适配和调优的人力成本、运行时占用的存储和内存成本、以及后续维护成本。

开源方案看起来免费，但适配到具体硬件上可能要花好几天甚至几周。商业方案可能授权费不低，但省下了大量调优时间。我自己的判断标准是：如果团队里有熟悉语音推理优化的人，开源方案性价比很高；如果团队主要做应用层开发，没有底层优化经验，那选一个文档齐全、社区活跃的开源方案，或者考虑商业方案，反而更划算。

把这四个约束想清楚之后，再去看具体方案，就不会被各种参数和宣传带偏了。

2. 无界方舟Audio8：中文场景下的端侧语音方案拆解

无界方舟Audio8是我在中文语音场景里用得比较多的一套方案。它主打的是端侧中文语音识别和合成，对中文的声调、儿化音、常见口语表达处理得比较细。我第一次用它是在一个离线语音记录设备上，当时对比了几套方案，最后选它主要是因为中文识别准确率在同类端侧方案里比较突出。

2.1 Audio8的核心能力与适用边界

Audio8的核心能力集中在中文语音识别和语音合成两块。识别方面，它支持流式和一句话两种模式，流式适合实时交互，一句话适合录音转写。合成方面，它提供多种音色，可以离线生成比较自然的中文语音。

但要注意它的适用边界。第一，它对中文的支持明显好于英文，如果你的场景是中英混合，英文部分的识别率会下降，需要额外做语言切换或混合建模。第二，它的模型体积不算小，完整版对内存有一定要求，低端设备上需要用量化版。第三，它的生态相对封闭，二次开发接口没有sherpa-onnx那么灵活，如果你需要深度定制推理流程，可能会受限。

我一般建议这些场景优先考虑Audio8：纯中文语音交互、对中文识别准确率要求高、设备算力中等以上、不需要深度定制推理流程。反过来，如果是多语言混合、设备资源极度受限、或者需要自己改推理引擎，那可能sherpa-onnx更合适。

2.2 部署Audio8时最容易忽略的三个参数

部署Audio8的时候，很多人照着文档跑通就完事了，但实际效果和预期差很多。我踩过的坑主要集中在三个参数上。

第一个是采样率。Audio8默认支持16kHz输入，但有些设备的麦克风输出是48kHz，如果不做重采样直接喂进去，识别率会明显下降。重采样本身不难，但要注意重采样算法，简单的线性插值会引入混叠，建议用带抗混叠滤波的重采样。我一般用sox或libsamplerate做这一步，效果比手写线性插值稳很多。

第二个是VAD阈值。Audio8通常配合VAD（语音活动检测）使用，VAD阈值设得太高，会把轻声说话截掉；设得太低，会把背景噪声当语音。我的经验是，在安静环境下阈值可以设0.5左右，嘈杂环境要调到0.6到0.7，并且开启噪声抑制。这个值没有绝对标准，最好用实际场景的录音测一遍。

第三个是解码beam size。beam size越大，识别越准，但耗时也越长。端侧设备上我一般设beam size为3到5，再大延迟就明显了。如果设备算力很紧，可以设到2，准确率会降一点但还能接受。

2.3 实测表现与调优记录

我在一台4GB内存的开发板上实测过Audio8的中文识别。安静环境下，一句话识别准确率大概在92%到95%之间，流式识别延迟在300毫秒左右。嘈杂环境下准确率会降到85%左右，开启噪声抑制后能回到88%到90%。

调优过程中我发现，Audio8对语速比较敏感。正常语速识别很好，但语速过快时，流式模式容易丢字。解决办法是适当增大chunk重叠，让相邻chunk有更多上下文重叠，代价是计算量增加。我一般把重叠设成chunk长度的20%到30%，效果和开销比较平衡。

还有一个细节是标点。Audio8的识别结果默认不带标点，如果要做转写，需要额外接一个标点模型。这个标点模型也要占内存，选型时别忘了算进去。

3. sherpa-onnx：跨平台端侧语音的通用底座

sherpa-onnx是我目前用得最多的端侧语音运行时。它的定位很清晰：不绑定特定模型，而是提供一个跨平台的推理框架，让你可以把各种语音模型部署到不同设备上。它支持流式和非流式识别、语音合成、VAD、说话人分离等功能，而且对平台的支持非常广，从Android、iOS到树莓派、x86 Linux都能跑。

3.1 为什么sherpa-onnx适合做选型起点

我一般建议把sherpa-onnx作为端侧语音选型的起点，原因有三个。

第一，它把模型和运行时解耦了。你可以用同一套运行时跑不同的模型，换模型不用换框架，试错成本低。第二，它的跨平台支持很完整，同一套代码逻辑可以编译到不同平台，省去了为每个平台单独适配的麻烦。第三，它的社区活跃，文档和示例比较全，遇到问题容易找到参考。

但sherpa-onnx也不是万能的。它本身不提供模型，你需要自己找或训练模型。它的推理优化偏向通用，针对特定硬件的极致优化不如专用方案。所以如果你的场景非常固定、硬件非常明确，专用方案可能更优；但如果你需要灵活试错、多平台部署，sherpa-onnx是很合适的底座。

3.2 模型选择：从流式Zipformer到非流式Paraformer

sherpa-onnx支持多种模型结构，我常用的有流式Zipformer和非流式Paraformer。

流式Zipformer适合实时场景，模型体积相对小，延迟低。我实测在树莓派4上，流式Zipformer的推理延迟大概在150到250毫秒，具体取决于模型大小和量化方式。它的中文识别效果不错，但英文和多语言场景需要选对应的多语言模型。

非流式Paraformer适合转写场景，准确率比流式模型高，因为它能看到完整上下文。代价是必须等一句话说完才能出结果，实时性差。我在x86设备上跑非流式Paraformer，一句话识别耗时大概在200到500毫秒，取决于句子长度。

选择模型的时候，我一般会先确认三件事：模型是否支持目标语言、模型体积是否在设备内存预算内、模型是否提供INT8量化版本。INT8量化通常能把模型体积压到FP32的四分之一，推理速度也能提升，准确率损失一般在1%到3%之间，端侧场景很划算。

3.3 编译与部署中的平台差异

sherpa-onnx的编译部署在不同平台上差异不小，我踩过的坑主要集中在依赖和交叉编译上。

在x86 Linux上，编译相对简单，装好CMake和必要的依赖，基本能一次过。在Android上，需要用NDK交叉编译，要注意ABI选择，arm64-v8a是主流，armeabi-v7a在旧设备上还需要。在树莓派上，要注意系统架构，32位和64位系统的编译参数不同，我建议直接用64位系统，内存寻址和性能都更好。

交叉编译时最容易出问题的是依赖库的架构不匹配。比如你编译的是arm64版本，但链接了一个x86的库，编译能过但运行会崩。我的做法是先把所有依赖都用目标平台的工具链编译一遍，再编译sherpa-onnx本身，虽然麻烦但最稳。

还有一个细节是线程数。sherpa-onnx默认可能用多线程推理，在端侧设备上线程数设太多反而会因为调度开销导致延迟增加。我一般设成2到4，具体看CPU核心数，留一两个核心给音频采集和其他任务。

3.4 实测延迟与内存占用数据

我在几个平台上实测过sherpa-onnx的表现，数据如下。

从数据看，树莓派4跑流式识别是可行的，延迟在可接受范围。非流式在树莓派上稍慢，但转写场景可以接受。x86和手机平台表现都很好，基本能做到实时。

内存占用方面，INT8量化后模型本身不大，但运行时和音频缓冲区会占一部分。我建议设备至少预留150MB到200MB可用内存给语音模块，这样比较稳妥。

4. FunASR：从服务端到端侧的迁移实践

FunASR最早是在服务端场景用得比较多，后来推出了端侧版本。它的优势是模型丰富、中文效果好、社区活跃。但端侧部署和服务端部署差别很大，直接照搬服务端经验容易翻车。

4.1 FunASR端侧版本的能力边界

FunASR端侧版本主要提供流式和非流式的中文识别模型，以及配套的VAD和标点模型。它的中文识别准确率在开源方案里属于第一梯队，尤其是对带口音的普通话和常见专业术语处理得不错。

但它的端侧版本对设备有一定要求。完整模型在低端设备上跑不动，需要用量化版或裁剪版。而且它的端侧推理优化不如sherpa-onnx那么成熟，部署时需要自己做一些适配工作。

我一般建议这些场景考虑FunASR端侧版：中文识别准确率要求高、设备算力中等以上、团队有一定语音部署经验。如果是资源极度受限或团队没有语音部署经验，建议先用sherpa-onnx跑通流程，再考虑是否迁移到FunASR。

4.2 模型导出与量化中的关键步骤

FunASR端侧部署的第一步是模型导出。服务端模型通常是PyTorch格式，端侧需要导出成ONNX或其他推理框架支持的格式。导出时要注意算子兼容性，有些PyTorch算子在ONNX里没有对应实现，需要替换或自定义。

导出之后是量化。我一般用INT8量化，把模型体积压下来。量化时要注意校准数据的选择，校准数据要覆盖实际场景的语音特征，否则量化后准确率会掉得厉害。我的做法是从实际场景录音里抽100到200条做校准，覆盖不同说话人、不同噪声条件。

量化后一定要做精度对比。我一般会跑一个测试集，对比量化前后的识别结果，如果准确率下降超过3%，就要检查量化参数或换校准数据。

4.3 端侧部署的依赖精简与内存控制

FunASR端侧部署的另一个难点是依赖精简。服务端版本依赖比较多，端侧要尽量裁掉不必要的依赖，减小体积。

我一般会做这几件事：去掉训练相关依赖、去掉不用的模型结构、把动态库改成静态链接（如果平台支持）、开启编译优化选项。这样能把运行时体积压到比较小的程度。

内存控制方面，除了模型量化，还要注意音频缓冲区和中间张量的管理。FunASR推理过程中会产生一些中间张量，如果不及时释放，内存会持续增长。我一般会在推理循环里显式释放不再使用的张量，并限制并发数，避免内存峰值过高。

4.4 和服务端版本的性能对比

我在同一台x86设备上对比过FunASR服务端版和端侧版的性能。服务端版一句话识别耗时大概在100到200毫秒，端侧版在200到400毫秒，慢了一倍左右，但端侧版不依赖网络，总体响应时间反而更稳定。

准确率方面，端侧版比服务端版低1%到2%，主要差距在生僻词和复杂噪声场景。对于大多数端侧应用来说，这个差距可以接受。

内存占用方面，端侧版经过量化和裁剪后，内存占用大概是服务端版的三分之一到二分之一，具体取决于裁剪程度。

5. 四款方案横向对比与选型决策表

前面分别讲了无界方舟Audio8、sherpa-onnx、FunASR，再加上我常用的轻量级组合方案（sherpa-onnx运行时加轻量模型），一共四款。这一节做一个横向对比，并给出选型决策表。

5.1 准确率、延迟、内存、生态四维对比

从表里能看出来，没有一款方案在所有维度都占优。Audio8和FunASR中文准确率高，但内存和延迟表现一般。sherpa-onnx延迟和内存表现好，生态也强，但准确率略逊。轻量组合方案资源占用最低，但准确率也最低。

5.2 不同场景下的选型建议

如果你的场景是纯中文语音助手，对准确率要求高，设备算力中等以上，我建议优先考虑Audio8或FunASR端侧版。如果设备资源紧张，或者需要多平台部署，sherpa-onnx更合适。如果只是做快速原型验证，轻量组合方案能让你最快跑通流程。

还有一个考虑因素是团队经验。如果团队熟悉ONNX生态，sherpa-onnx上手最快。如果团队有PyTorch背景，FunASR可能更顺手。如果团队主要做应用层开发，Audio8的封装程度更高，集成更简单。

5.3 混合方案：用sherpa-onnx跑FunASR导出的模型

其实这几款方案不是互斥的。我常用的一个做法是：用sherpa-onnx作为运行时，跑FunASR导出的ONNX模型。这样既能利用FunASR的模型效果，又能享受sherpa-onnx的跨平台部署能力。

具体做法是：先用FunASR导出ONNX模型，确认输入输出格式，然后在sherpa-onnx里配置对应的模型路径和参数。需要注意的是，不同模型的输入输出格式可能不同，要仔细核对。特征提取参数也要对齐，否则识别结果会乱。

这个混合方案我在几个项目里用过，效果不错。它把模型选择和运行时选择解耦了，灵活性很高。

6. 部署实战：从零跑通一个端侧语音识别Demo

这一节给一个完整的实操流程，从环境准备到跑通识别，基于sherpa-onnx加轻量模型。这套流程我在树莓派和x86上都验证过，步骤基本一致。

6.1 环境准备与依赖安装

先装基础依赖。在Debian系系统上，需要装CMake、编译工具链、音频库。

sudo apt update sudo apt install -y cmake build-essential git libasound2-dev

如果要支持特定功能，可能还需要装其他库。比如要做音频重采样，可以装libsamplerate。

sudo apt install -y libsamplerate0-dev

依赖装完后，克隆sherpa-onnx源码。

git clone https://github.com/k2-fsa/sherpa-onnx.git cd sherpa-onnx

6.2 编译参数选择与常见报错处理

编译时根据目标平台选参数。x86平台直接用默认配置。

mkdir build && cd build cmake .. make -j4

树莓派上建议开启NEON优化，并指定64位架构。

cmake -DCMAKE_BUILD_TYPE=Release -DSHERPA_ONNX_ENABLE_NEON=ON .. make -j4

常见报错里，最多的是依赖找不到。比如提示找不到alsa，就是没装libasound2-dev。提示找不到某个符号，可能是链接顺序问题，调整CMake里的链接顺序通常能解决。

还有一个坑是内存不足导致编译失败。树莓派上编译大模型支持时，如果内存不够，make会卡死或报错。解决办法是减少并行编译数，用make -j2甚至make -j1，或者临时增加交换空间。

6.3 模型下载与配置

编译完成后，下载模型。sherpa-onnx的模型可以从官方模型库获取。以流式Zipformer中文模型为例，下载后解压到指定目录。

配置时要注意模型路径、特征参数、解码参数。特征参数要和模型训练时一致，否则识别会出错。解码参数里beam size和lattice参数影响准确率和速度，端侧建议beam size设小一点。

6.4 运行测试与结果验证

配置好后，用示例程序测试。sherpa-onnx提供了命令行示例，可以直接跑。

./bin/sherpa-onnx-offline \ --tokens=model/tokens.txt \ --paraformer=model/model.onnx \ --input-wav=test.wav

跑通后，用实际场景录音测试，对比识别结果和预期。如果识别结果乱，先检查采样率和特征参数。如果识别结果缺字，检查VAD和解码参数。

我一般会准备一组测试录音，覆盖安静、嘈杂、快语速、慢语速等条件，跑一遍看整体表现。这样能快速发现参数是否合适。

7. 踩坑记录：端侧语音部署中最容易翻车的五个点

最后分享几个我踩过的坑，都是实际部署中容易忽略但影响很大的点。

第一个坑是采样率不匹配。这个问题很隐蔽，因为程序不报错，只是识别率下降。解决办法是统一采样率，或者在输入端做重采样。

第二个坑是内存泄漏。长时间运行后内存持续增长，最后被系统杀掉。解决办法是检查推理循环里的资源释放，特别是中间张量和音频缓冲区。

第三个坑是线程竞争。音频采集和推理在不同线程，如果没做好同步，会出现丢帧或重复处理。解决办法是用环形缓冲区加锁保护，或者用无锁队列。

第四个坑是模型版本和运行时版本不匹配。模型是用新版本导出的，运行时是老版本，可能加载失败或结果异常。解决办法是固定版本组合，升级时一起升级。

第五个坑是忽略功耗。端侧设备很多是电池供电，语音模块持续运行会显著影响续航。解决办法是按需唤醒，用低功耗VAD做前端检测，检测到语音再启动识别。

这几个坑我都实际遇到过，有的排查了好几天。希望这些经验能帮你少走弯路。端侧语音选型没有银弹，关键是先想清楚自己的约束条件，再根据约束去匹配方案。多试几套，用实际场景数据验证，比看任何参数表都靠谱。