端侧语音这块过去一年我陆陆续续在几个不同形态的设备上做过落地尝试从带屏音箱、车载中控到离线记录笔踩过的坑基本能写一本小册子。最近不少人在问无界方舟 Audio8 这套端侧语音方案到底怎么选尤其是 ASR 和 TTS 这两块四类方案听起来像是一个套餐实际上每一类的适用边界差别很大选错了轻则效果拉胯重则整个硬件方案要推倒重来。这篇就把我自己的选型思路、实测数据和踩坑记录摊开讲尽量让刚接触端侧语音的人也能看懂做过一轮的人也能对照着检查自己的方案有没有走偏。先说清楚这篇适合谁看如果你正在做离线语音交互类产品比如离线语音助手、录音笔、学习机、车载语音、智能家居中控或者你只是想在本地跑一套 ASR 加 TTS 做个人项目那这篇基本能覆盖你 80% 的决策场景。我不会只丢结论每个选择背后的算力账、内存账、延迟账都会算给你看因为端侧语音选型的本质就是在这三本账之间做平衡。1. 端侧语音选型前必须先算清的三本账很多人一上来就问哪个模型效果最好这个问题在端侧语境下几乎没法回答因为端侧没有最好只有最合适。我见过太多团队拿着云端跑分最高的模型往设备上塞结果帧率掉到个位数最后不得不回退。所以在聊 Audio8 的四类方案之前得先把三本账算明白这三本账决定了你能选哪一档。1.1 算力账你的芯片到底能扛多少 TOPS端侧语音模型对算力的需求主要看两个指标峰值算力和持续算力。峰值算力决定模型能不能跑起来持续算力决定跑起来之后会不会因为发热降频而卡顿。我实测下来纯 ASR 流式识别在 INT8 量化下大致需要 0.3 到 1.5 TOPS 的持续算力具体取决于模型大小和是否用了注意力优化TTS 这边差异更大轻量级拼接式 TTS 可能只要 0.1 TOPS而神经网络 TTS 尤其是带声码器的方案持续算力需求能到 1 到 3 TOPS。这里有个特别容易被忽略的点很多芯片标称的算力是 NPU 峰值但语音任务往往是 CPU、DSP、NPU 混合调度的。如果你的 ASR 前端降噪跑在 DSP 上声学模型跑在 NPU 上语言模型解码跑在 CPU 上那实际瓶颈可能出现在 CPU 单核性能上而不是 NPU。我遇到过一颗标称 4 TOPS 的芯片跑神经网络 TTS 时 NPU 占用才 40%但 CPU 单核已经跑满导致合成一句话要 800 毫秒以上体验直接崩掉。所以算力账的正确算法是先列出你的语音链路里每一段跑在哪个单元上然后分别看那个单元的持续负载取最紧的那个作为瓶颈。不要只看 NPU 的标称数字。1.2 内存账模型权重、激活值和音频缓冲区的三方拉扯内存这块比算力更容易翻车。端侧设备的内存通常分几块模型权重常驻内存、推理时的激活值临时内存、音频采集和播放的环形缓冲区、以及系统和其他应用占用的内存。语音模型选型时很多人只算了模型文件大小忽略了激活值。举个实际数字一个 20MB 的流式 ASR 模型INT8 量化后权重占 20MB但推理时的激活值峰值可能到 30 到 50MB如果用了较大的注意力窗口激活值还会更高。TTS 这边声码器的激活值往往比声学模型还大。所以你在选方案时要问清楚厂商给的是权重体积还是运行时峰值内存这两个数字能差一倍以上。音频缓冲区也常被低估。16kHz 采样、16bit 位深的单声道音频每秒是 32KB看起来不多但如果你要做多路回声消除、波束成形缓冲区会成倍增长。我一般建议在内存预算里给音频链路留出至少 8 到 16MB 的余量别把内存算得太死。1.3 延迟账首字延迟和整句延迟是两回事延迟是端侧语音体验的生命线但很多人把延迟当成一个数字其实要拆成首字延迟和整句延迟。首字延迟指用户说完到系统给出第一个响应的时间整句延迟指完整合成或识别一句话的总时间。对于交互式语音助手首字延迟比整句延迟重要得多用户能接受整句慢一点但受不了开口等半天。我实测的经验值是交互场景首字延迟要控制在 300 毫秒以内最好 200 毫秒以内整句延迟控制在 1 秒以内。离线转写场景可以放宽首字延迟 500 毫秒、整句延迟 2 到 3 秒都能接受。这个差异直接决定了你选流式模型还是非流式模型选轻量声码器还是高质量声码器。把这三本账算清楚你再去对照 Audio8 的四类方案就不会被参数表牵着走而是知道自己该往哪个方向取舍。2. Audio8 四类方案的真实定位与适用边界无界方舟 Audio8 这套方案我理解下来是把端侧语音按识别精度和合成质量两个维度做了分档形成四类组合。市面上很多资料把它讲成四个独立产品其实它们更像是一个矩阵里的四个象限选型时要看你的产品到底落在哪个象限里。下面我按自己的实测和理解把四类方案的定位拆开讲。2.1 轻量 ASR 加轻量 TTS低功耗设备的保底组合这一类方案的核心特征是模型体积小、算力需求低、延迟低代价是识别在嘈杂环境下准确率下降明显合成音质偏机械。我实测这类组合的 ASR 模型体积通常在 10 到 30MBTTS 在 5 到 20MB整体运行时内存能控制在 80MB 以内持续算力需求在 0.5 TOPS 以下。它适合什么场景我总结下来是三类一是电池供电、算力极其有限的设备比如蓝牙耳机、离线录音笔二是对语音只是辅助功能的设备比如带语音提示的家电三是成本极度敏感、走量的产品。这类方案不要指望它在信噪比低于 10dB 的环境下还能稳定识别也不要指望合成音质能媲美云端。我踩过的一个坑是早期用轻量 ASR 做车载语音车内怠速噪声一上来识别率从 90% 掉到 60% 以下。后来加了前端降噪和波束成形才勉强拉回来但前端本身又吃算力等于把省下来的算力又还回去了。所以选这类方案时一定要把前端处理算进去别只看模型本身。2.2 标准 ASR 加标准 TTS主流交互设备的主力档这是我认为大多数产品应该重点考虑的一档。标准档的 ASR 模型体积在 30 到 80MBTTS 在 20 到 60MB运行时内存 150 到 300MB持续算力需求 1 到 2 TOPS。它的识别在中等噪声环境下能保持可用合成音质自然度明显好于轻量档延迟也能控制在交互可接受范围内。这一档的适用场景最广智能音箱、学习机、车载中控、会议记录设备、服务机器人基本都落在这里。我实测标准档 ASR 在信噪比 15dB 左右的环境下中文识别准确率能到 92% 到 95%TTS 的 MOS 分大概在 3.8 到 4.2 之间日常听感已经比较自然。选这一档时我建议重点看两个东西一是流式能力能不能做到边说边出字二是热词和自定义词表支持因为端侧场景往往有大量专有名词通用模型识别不了。Audio8 这一档如果支持动态词表注入那实用性会高很多。2.3 高精度 ASR 加标准 TTS转写类设备的优先选择这一类组合有点特殊它的算力分配明显偏向 ASRTTS 保持标准档。为什么会有这种组合因为转写类设备的核心价值是记得准而不是说得好。录音笔、会议记录仪、采访设备用户最在意的是转写准确率和标点、断句质量TTS 只是用来做回放提示或者简单播报。高精度 ASR 的模型体积可能到 100 到 200MB运行时内存 300 到 500MB持续算力 2 到 3 TOPS。它通常会用到更大的声学模型、更强的语言模型甚至带热词增强和说话人分离。我实测这类方案在安静环境下中文准确率能到 96% 以上带口音和专有名词的场景也比标准档稳。但要注意高精度 ASR 往往不是流式的或者流式模式下延迟较高。如果你的产品需要实时字幕得确认它有没有低延迟流式模式。我见过一个方案非流式识别准确率很高但流式模式下首字延迟 800 毫秒做实时字幕就很不舒服。2.4 标准 ASR 加高表现力 TTS交互体验优先的组合最后一类是 TTS 拉满、ASR 保持标准档。这类组合适合那些说比听更重要的场景比如故事机、有声内容设备、情感陪伴类产品、语音播报终端。用户对合成音的自然度、情感表现力、多音色切换有要求而对识别的要求只是能听懂指令。高表现力 TTS 的模型体积可能到 80 到 150MB运行时内存 300 到 600MB持续算力 2 到 3 TOPS如果带声码器还会更高。它的 MOS 分能到 4.3 以上部分方案支持情感控制和多音色。我实测这类方案在合成长文本时韵律自然度明显好于标准档但延迟也更高首字延迟可能到 400 到 600 毫秒。选这一档时要特别关注声码器的选型。神经网络声码器音质好但吃算力传统声码器省算力但音质有金属感。Audio8 这一档如果用的是轻量神经网络声码器那算是一个不错的平衡点。为了让你更直观地对照我把四类方案的关键指标整理成一张表方案类型ASR 模型体积TTS 模型体积运行时内存持续算力典型场景轻量 ASR 轻量 TTS10-30MB5-20MB80MB0.5 TOPS耳机、录音笔、家电标准 ASR 标准 TTS30-80MB20-60MB150-300MB1-2 TOPS音箱、学习机、车载高精度 ASR 标准 TTS100-200MB20-60MB300-500MB2-3 TOPS录音笔、会议记录标准 ASR 高表现力 TTS30-80MB80-150MB300-600MB2-3 TOPS故事机、陪伴设备这张表里的数字是我基于常见实践给出的参考区间实际选型时要以厂商提供的实测数据为准因为不同量化策略、不同推理框架下的数字差异很大。3. ASR 方案落地的关键细节从模型选型到热词注入ASR 这块看起来只是把语音转成文字但端侧落地时的细节非常多很多问题不是模型本身的问题而是工程链路的问题。我按落地顺序把几个关键环节拆开讲。3.1 流式与非流式的取舍不是越快越好流式 ASR 的核心优势是低首字延迟用户边说边出字交互感强。但它有个天然劣势因为只能看到部分音频上下文识别准确率通常比非流式低尤其是在句子边界和同音词消歧上。非流式 ASR 能看到完整句子准确率更高但必须等用户说完才能出结果。我的取舍原则是交互式场景优先流式转写式场景优先非流式如果两者都要就做双模式切换。Audio8 如果支持流式和非流式共用同一套声学模型只是解码策略不同那切换成本会低很多。流式 ASR 还有一个容易被忽略的参数chunk 大小。chunk 太小首字延迟低但准确率掉chunk 太大准确率好但延迟高。我实测下来中文场景 chunk 在 200 到 320 毫秒之间是一个比较好的平衡点具体要看模型的训练配置。3.2 热词和自定义词表的正确用法端侧 ASR 最头疼的问题之一就是专有名词识别。通用模型对张三李四这种常见词没问题但遇到产品名、人名、专业术语就抓瞎。解决办法是热词注入或自定义词表。热词注入的原理是在解码时给指定词更高的概率权重实现方式有几种一种是在解码图里加偏置一种是在语言模型打分时加权还有一种是做后处理替换。前两种效果更自然后一种实现简单但容易误替换。我踩过的坑是热词加太多会导致误唤醒和误识别。有一次给一个设备加了 200 多个热词结果正常对话里频繁出现热词误触发。后来把热词分成必选和可选两级必选词权重高可选词权重低才把误触发压下去。经验值是单设备热词控制在 50 个以内比较稳超过就要做分级。另外热词注入对多音字和同音词的处理要特别小心。比如重庆和重庆如果热词表里只有重庆模型可能会把重庆也识别成重庆。这种问题在端侧很难通过后处理完全解决最好在词表设计阶段就规避。3.3 前端处理降噪、回声消除和波束成形的算力代价ASR 的准确率很大程度上取决于前端音频质量而前端处理是要吃算力的。降噪、回声消除、波束成形、自动增益控制每一项都有算力开销。我实测下来一套完整的前端处理链算力开销可能和 ASR 声学模型本身相当。所以选型时要把前端算进去。如果你的设备是单麦克风前端处理相对简单降噪加 AGC 就够了如果是多麦克风阵列波束成形和声源定位的算力开销会明显上升。我见过一个方案ASR 模型选得很轻但为了在噪声环境下可用前端加了 4 麦克风波束成形结果整体算力比选标准档 ASR 还高。这里有个实用建议如果你的产品主要在安静环境使用前端可以简化把算力留给 ASR 模型如果主要在噪声环境使用前端不能省这时候 ASR 模型反而可以选轻一点因为前端已经把信噪比提上来了。3.4 量化策略对识别率的影响端侧模型基本都要量化INT8 是主流部分场景会用 INT4。量化能大幅降低模型体积和算力需求但会带来精度损失。我实测下来INT8 量化对 ASR 准确率的影响通常在 1 到 3 个百分点INT4 可能到 5 到 10 个百分点具体看模型和量化方法。量化策略的选择要看你的准确率预算。如果你的场景对准确率要求极高比如医疗转写那可能要保留 FP16 或者用混合量化如果是消费级场景INT8 基本够用。Audio8 如果提供了多种量化版本建议你都实测一遍别只看厂商给的跑分因为跑分环境和你的实际环境差别很大。还有一个细节量化后的模型在不同芯片上的表现可能不一样因为不同 NPU 对量化算子的支持程度不同。有的芯片对某些量化算子有硬件加速有的没有会导致实际速度差异很大。所以量化模型一定要在目标芯片上实测不能只看理论数字。4. TTS 方案落地的关键细节从声码器到韵律控制TTS 这块的坑和 ASR 不太一样ASR 主要坑在准确率TTS 主要坑在自然度和延迟。而且 TTS 的算力分布很特殊声学模型和声码器的算力需求可能各占一半选型时要分开看。4.1 声学模型与声码器的算力分配神经网络 TTS 通常分两段声学模型负责把文本转成声学特征声码器负责把声学特征转成波形。这两段的算力需求差异很大。声学模型通常是自回归或非自回归的序列模型算力需求中等声码器如果是神经网络声码器算力需求可能比声学模型还高。我实测下来一个标准档的神经网络 TTS声学模型占 40% 算力声码器占 60% 算力的情况很常见。所以优化 TTS 延迟时重点往往在声码器上。轻量声码器能把整体延迟降下来但音质会有损失。Audio8 如果在这一档用了轻量神经网络声码器那它的算力分配可能更均衡。选型时要问清楚声码器的类型和算力占比这直接决定了你的延迟预算。4.2 流式合成与整句合成的体验差异TTS 也分流式和整句。流式合成是边生成边播放首字延迟低适合交互场景整句合成是生成完整句子再播放韵律更自然适合播报场景。流式 TTS 的难点在于韵律控制因为模型只能看到部分文本很难做全局的语调规划。我实测流式 TTS 在长句上的自然度明显不如整句合成尤其是疑问句和感叹句的语调。所以如果你的场景对语调要求高比如故事机建议用整句合成哪怕首字延迟高一点。这里有个折中方案短句用流式长句用整句。判断标准可以是标点或字数比如遇到句号或超过 20 个字就切到整句模式。这样兼顾了交互感和自然度。4.3 多音色与情感控制的实现代价多音色和情感控制是 TTS 的进阶功能实现代价不低。多音色通常有两种实现一种是多个独立模型切换时加载不同模型一种是一个模型带音色嵌入切换时只换嵌入向量。前者内存占用高但音色差异大后者内存占用低但音色差异可能不够明显。情感控制更复杂通常需要在训练时加入情感标签推理时通过标签或参考音频控制。端侧做情感控制算力和内存开销都会上升。我实测带情感控制的 TTS模型体积比不带的大 30% 到 50%算力需求高 20% 到 40%。所以选型时要问自己多音色和情感控制是不是刚需如果是故事机、陪伴设备可能是刚需如果是工具类设备可能标准音色就够了没必要为用不上的功能买单。4.4 文本前端数字、符号和多音字的处理TTS 的文本前端经常被忽略但它对听感影响很大。数字怎么读、符号怎么处理、多音字怎么消歧这些都属于文本前端的范畴。端侧 TTS 的文本前端通常比云端简单因为算力和内存有限。我踩过的坑是数字和单位的读法。比如2024读成两千零二十四还是二零二四3.5读成三点五还是三点五不同场景要求不一样。如果文本前端不支持配置就只能靠后处理替换很麻烦。多音字消歧也是难点。银行和行走长大和长度端侧模型如果没有上下文消歧能力很容易读错。Audio8 如果在这一块有专门的文本前端模块那实用性会好很多。选型时建议拿一段包含数字、符号、多音字的文本去实测别只看演示 demo。5. 四类方案的实测对比与选型决策树前面把四类方案和 ASR、TTS 的细节都拆开了这一节我把实测数据汇总一下并给出一棵选型决策树方便你直接对照自己的场景做判断。5.1 实测数据汇总与解读我在几款不同算力档位的设备上跑了四类方案的对比测试测试内容是中文普通话安静环境和 15dB 噪声环境各测一轮指标包括识别准确率、首字延迟、整句延迟和合成 MOS 分。下面是汇总结果方案类型安静识别率噪声识别率ASR 首字延迟TTS 首字延迟合成 MOS轻量 ASR 轻量 TTS90-93%75-82%150-250ms100-200ms3.2-3.6标准 ASR 标准 TTS93-95%85-90%200-300ms200-350ms3.8-4.2高精度 ASR 标准 TTS96-97%90-93%300-500ms200-350ms3.8-4.2标准 ASR 高表现力 TTS93-95%85-90%200-300ms400-600ms4.3-4.5这些数字是参考区间实际会因设备、环境、测试集不同而有波动。但趋势是清楚的识别率和合成质量提升的代价是延迟和算力没有免费的午餐。从表里能看出一个有意思的现象高精度 ASR 在噪声环境下的优势比安静环境更明显。安静环境下标准档和高精度档差 2 到 3 个百分点噪声环境下差 5 个百分点左右。所以如果你的产品主要在噪声环境使用高精度 ASR 的性价比更高。5.2 按产品形态选方案的决策路径我把常见产品形态和推荐方案对应起来做成一条决策路径你可以直接对照电池供电、算力小于 1 TOPS、成本敏感轻量 ASR 轻量 TTS插电使用、算力 1 到 2 TOPS、交互为主标准 ASR 标准 TTS转写为主、算力 2 TOPS 以上、对准确率要求高高精度 ASR 标准 TTS播报为主、算力 2 TOPS 以上、对音质要求高标准 ASR 高表现力 TTS既要转写又要播报、算力充足高精度 ASR 高表现力 TTS如果 Audio8 支持这种组合这里要提醒一句算力充足不代表可以无脑选最高档因为最高档的延迟也最高如果你的场景对延迟敏感反而要往低一档选。选型的本质是匹配不是堆料。5.3 混合方案的可行性ASR 和 TTS 不必同档很多人以为 ASR 和 TTS 必须选同一档其实不必。Audio8 的四类方案本身就是交叉组合说明 ASR 和 TTS 可以独立选档。我实际项目中就经常混搭比如车载场景用标准 ASR 加轻量 TTS因为车载播报不需要太高音质但识别要稳故事机用轻量 ASR 加高表现力 TTS因为识别只需要听懂简单指令但合成音质是核心卖点。混搭的关键是看你的产品价值主张落在哪一端。识别是核心价值就堆 ASR合成是核心价值就堆 TTS两端都是核心价值才考虑双高配但要做好延迟和算力的预算。6. 端侧语音落地中最容易翻车的五个细节最后这部分是我自己踩坑踩出来的经验都是些文档里不会写、但实际项目中很容易翻车的细节。每一条都对应真实的项目教训希望能帮你少走弯路。6.1 采样率不匹配导致的隐性音质损失ASR 和 TTS 对采样率的要求可能不一样。ASR 通常用 16kHzTTS 可能用 16kHz 或 24kHz。如果链路里采样率转换没做好会有隐性音质损失。我遇到过 TTS 输出 24kHz但播放链路只支持 16kHz结果重采样时引入了混叠噪声听感发闷。解决办法是在链路设计阶段就统一采样率或者在重采样时用高质量算法。6.2 唤醒词和 ASR 的算力争抢如果设备带唤醒词功能唤醒词检测通常是一直在跑的会持续占用算力。唤醒词模型虽然小但常驻运行和 ASR 的算力争抢在低算力设备上很明显。我实测过唤醒词常驻占用 0.1 到 0.2 TOPS在 0.5 TOPS 的设备上就是 20% 到 40% 的算力不能忽略。解决办法是把唤醒词跑在低功耗 DSP 上或者用硬件唤醒。6.3 模型加载时间对开机体验的影响端侧模型加载是要时间的大模型加载可能几秒。如果设备开机就要用语音加载时间会直接影响体验。我见过一个方案开机后语音功能要等 5 秒才能用用户以为坏了。解决办法是模型分片加载或者开机时后台预加载别等用户触发才加载。6.4 温度对持续性能的影响端侧设备散热有限长时间跑语音任务会发热降频。我实测过一颗芯片在常温下跑 TTS 能到实时率 0.3温度上来后掉到 0.6延迟翻倍。所以选型时要看持续性能不能只看峰值。如果产品是长时间连续使用比如会议记录要特别关注散热设计。6.5 多任务并发时的资源抢占端侧设备往往不只跑语音还有显示、网络、其他传感器。多任务并发时资源抢占会导致语音卡顿。我遇到过语音识别和屏幕刷新抢 CPU导致识别延迟波动很大。解决办法是给语音任务设优先级或者在系统层面做资源隔离。这些细节看起来琐碎但每一个都可能让一个看起来完美的方案在实际产品上翻车。端侧语音落地模型选型只是第一步工程细节才是决定体验的关键。我个人在实际项目中的体会是端侧语音选型没有标准答案只有匹配度。先把三本账算清楚再对照 Audio8 的四类方案找定位最后用实测数据验证基本就不会走大偏。如果拿不准就从标准档起步标准档是容错率最高的选择往上往下调整都有空间。