去年冬天，我在一个智能家居中控项目上栽了个跟头：样机演示到一半，网络抖了一下，语音助手整整沉默了六秒，台下的人以为设备死机了。那次之后我把整套方案推倒重来，做成了一个完全跑在端侧的语音助手——唤醒、ASR、LLM、TTS四段全部塞进一块几百兆内存的小板子里，断网也能一问一答，响应稳定在一秒半以内。这篇就把这条链路的选型逻辑、参数配置、代码结构和踩过的坑一次讲透，适合正在做AIoT语音交互、想从云端方案迁移到端侧，或者手里有块开发板想跑通全链路的同学参考。不管你是刚接触嵌入式语音的新手，还是已经调过几个模型的老人，里面关于延迟拆解、内存峰值控制和音频通路的细节，应该都能直接拿去用。
1. 端侧语音助手到底解决什么问题
1.1 三类典型场景与硬约束
端侧语音助手不是一个技术炫技的产物，它的价值完全由场景倒逼出来。我梳理过手上接触过的项目，大致能归成三类，每一类的约束条件完全不同。
第一类是离线可用型，比如车载中控、电梯面板、工业手持终端。这类场景最大的特点是网络不可靠甚至完全没有网络，用户按下去就得有回应，不能等。它们的算力通常不宽裕，内存普遍在512MB到1GB之间，还要和屏幕、摄像头抢资源。
第二类是隐私敏感型，比如卧室里的音箱、老人陪护设备。音频不出设备是硬要求，用户不愿意自己半夜说的话被传到某个机房里。这类场景对识别准确率的要求反而没那么极致，但对稳定性和功耗特别在意。
第三类是低延迟交互型，比如玩具、教育硬件、智能家电的语音面板。这类产品对成本极度敏感，BOM里给语音算力留的空间可能就几十块钱，同时用户对"说完立刻答"的期望非常高，超过两秒就感觉笨。
这三类场景共同指向一个结论：模型必须小、链路必须短、状态必须可控。云端方案那种"上传-排队-推理-下载"的四次网络往返，在这三类场景里基本都是不可接受的。我在实际项目里测过，同样的问答内容，云端方案在弱网下的端到端延迟可以飙到4秒以上，端侧方案最差也就2秒出头，而且方差极小——这一点在演示和验收时特别重要，用户能忍受稍慢，但忍受不了忽快忽慢。
1.2 端侧与云端的成本账怎么算
很多人第一反应是端侧省钱，其实不完全是。我把两种方案的账摊开算过，结论比想象中复杂。
云端方案的成本主要在持续的流量和推理费用上，单次语音交互按识别、大模型token、语音合成三段计费，一个日活一万台、每台每天二十次交互的产品，一年下来的服务费用相当可观，而且随着用户使用频次上升线性增长。端侧方案则是把成本前置到硬件上，一次性付出算力和内存的差价，后续边际成本接近于零。
但真正的分水岭不在钱，而在能力边界和迭代节奏。云端的大模型能力可以随时升级，端侧一旦固件出货，想换模型就得推OTA，而OTA本身有失败风险。所以我的判断标准是：如果你的问答内容高度依赖通用世界知识，端侧小模型撑不住，那就老老实实走云端或者混合方案；如果你的问答是垂直领域的、有明确意图集合的，端侧完全可以做得很漂亮，还能顺手把响应速度做到云端做不到的水平。
混合方案其实是最务实的：唤醒词和VAD永远在端侧跑，ASR和TTS在端侧跑，只有LLM这一步在本地小模型答不好的时候才上云，并且带超时降级。这个结构我在两个项目里用过，体验和成本都比较平衡。
1.3 硬件平台与算力预算怎么定
选平台这一步，我建议先用一个粗暴的公式估算，再去选具体型号。
内存预算大致等于：ASR模型文件大小 + LLM权重 + TTS模型 + KV cache + 音频缓冲 + 系统占用 + 20%余量。举个实际例子，一个40MB的流式识别模型、一个0.5B参数、INT4量化后约300MB的语言模型、一个30MB的合成模型，加上序列长度512时约50MB的KV cache，再加上系统和其他占用约150MB，合计约570MB，那么512MB的板子就不够，得上一GB。
算力预算的算法更粗略一些：把每段模型单次推理的算子量加总，除以目标帧率。语言模型的瓶颈通常在内存带宽而不是纯算力，解码一个token要读一遍权重，0.5B的INT4模型大约300MB，按DDR带宽4GB/s算，理论极限每秒十几token，实际能跑到每秒8到10个token就算不错了。这个数字决定了你的语音助手说话能不能"像人"——低于每秒5个token，用户会明显感觉到机器在憋字。
还有个容易被忽略的点：NPU的算力数字很好看，但可用性取决于算子覆盖度。我见过标称几TOPS的芯片，跑语言模型时因为缺少某个关键算子频繁回落CPU，实际速度还不如纯CPU跑。选型阶段一定要拿自己的模型去做一次实测，别只看规格书。
2. 全链路架构：四段流水线怎么拼
2.1 模块边界与数据流
整套系统的数据流是一条单向管道，但中间有几处关键的状态切换，理清楚这些切换点，代码结构就不会乱。
采集线程持续从麦克风读取PCM数据，写进一个环形缓冲区。唤醒模块常驻消费这份数据，检测到关键词后置位一个"会话激活"标志。VAD模块在会话激活后开始工作，负责判断用户什么时候说完了。一旦判定端点，就把这段完整的语音送给识别模块。识别结果是文本，送进语言模型生成回复文本。回复文本按标点切成短句，逐句送进合成模块，合成出的音频块进入播放队列。
这里的核心设计原则是每一段都要能流式。识别要出中间结果，语言模型要逐token吐字，合成要分句出声。如果任何一段退化成"等全部完成再往下传"，端到端延迟会直接翻倍。我在第一版里就是犯了这个错，识别非要等整段音频结束才开始跑，结果用户说完到有回应要三秒多。改成流式之后，用户最后一个字说完时，识别的前半段结果其实已经出来了，整体感觉快了将近一秒。
模块之间我建议用消息队列解耦，而不是直接函数调用。原因是各模块的耗时差异很大，识别可能几十毫秒出一块结果，合成可能要几百毫秒才能出第一块，直接调用会让快模块等慢模块。用队列加独立线程，每个模块按自己的节奏跑，只在队列满的时候做背压。
2.2 唤醒词、VAD、端点检测各管什么
这三个概念新手经常混为一谈，其实职责完全不同，实现方式也差很远。
唤醒词检测是常开的最低功耗环节，它的任务只有一个：判断"这句话里有没有叫我的名字"。它不需要识别内容，只需要输出一个置信度。所以它可以用非常小的模型，甚至几十KB的定点网络就跑得动，功耗控制在毫瓦级。这个环节一定要独立于主链路，因为它要一直跑，而主链路只在唤醒后才启动。
VAD（语音活动检测）判断的是"当前这帧音频是人声还是静音"，它比唤醒词更轻，通常用能量加过零率的传统算法就够，好一点的用个小网络。它的作用是给识别提供起点和终点，避免把大段静音送进模型浪费算力。
端点检测则是VAD的上层逻辑，它决定"用户说完了没有"。这个判断很微妙：用户说"帮我查一下明天……北京的天气"，中间那个停顿如果被判成结束，就会截断成两句话。我的做法是设置两级阈值——短静音（比如300毫秒）只作为"可能结束"的候选，长静音（比如700毫秒）才真正触发端点。同时如果识别已经出了稳定的中间结果，可以把长静音阈值调短一点，让响应更快。
提示：端点检测的静音阈值不要设得太激进。我见过为了追求快把阈值设到200毫秒的，结果用户稍微思考一下就被打断，体验极差。600到800毫秒是个比较舒服的区间。
2.3 延迟预算怎么分
做端侧语音，最重要的一张表是延迟预算表。没有这张表，调优就是瞎猜。
我一般按下面的方式分配，总目标控制在1.5秒以内（从用户说完最后一个字，到设备开始出声）：
| 环节 | 目标耗时 | 说明 |
|---|---|---|
| 端点确认 | 600-700ms | VAD静音判定，占比最大，但不宜再压缩 |
| ASR收尾 | 100-200ms | 最后一块音频的解码 |
| LLM首token | 300-500ms | 包含提示词拼接和预填充 |
| TTS首包 | 200-300ms | 第一句的声学模型推理 |
| 播放启动 | 20-50ms | 缓冲填充和设备打开 |
看这张表会发现一个反直觉的事实：延迟的大头其实是端点检测的等待，而不是模型推理。所以优化顺序应该是先想办法让用户在说话过程中就能看到反馈（比如识别中间结果上屏、或者播一个"嗯"的确认音），再去抠模型的那几百毫秒。很多人一上来就死磕模型加速，把LLM首token从500毫秒压到300毫秒，用户感知的提升远不如把端点阈值从800调到600来得明显。
3. 模型选型与端侧改造
3.1 ASR：流式、小模型、热词偏置
识别模型的选择，我踩过的最大坑是"只看准确率不看结构"。一个非流式的大模型在测试集上准确率能高出五个点，但它在端侧根本没法用，因为它必须等整段音频结束才能开始算。
端侧必须选流式结构的模型，也就是那种带分块编码、支持增量解码的。这类模型的参数量通常在几千万级别，量化后文件大小在40到80MB之间，单帧推理耗时能控制在几十毫秒。我第一次移植时用的是块大小固定为320毫秒的配置，后来发现块越小首字越快但准确率略降，最后折中到200毫秒左右，实测下来延迟和准确率都能接受。
热词偏置是端侧识别必须做的一件事。端侧小模型的词表有限，你家里那些设备名、联系人名、行业术语它大概率不认识。解决办法是在解码时给指定词加一个偏置分数，让解码器在遇到相似发音时优先选这些词。这个功能很多流式识别框架都支持，配置方式通常是一个词表文件加一个偏置权重。我试过权重给0.5和给3.0的差别，太大了会误触发，比如"打开客厅灯"被偏置成"打开客厅等"，一般1.5到2.5之间比较稳。
还有一个细节：中文的标点恢复。流式识别输出的通常不带标点，而后续的合成又需要按标点断句。可以在识别模型上挂一个轻量的标点预测头，或者在语言模型的提示词里要求它输出的回复本身带标点——后者更省事，但只对回复文本有效，用户的输入还是没标点。所以如果要做完整的会话记录展示，标点恢复头还是得加。
3.2 LLM：参数量、量化、KV cache
语言模型这块是整条链路里最吃资源的，也是决策空间最大的。
参数量上，我的经验是端侧实用下限在0.5B左右，低于这个数，模型的多轮上下文能力和指令跟随能力会明显崩坏，经常答非所问。0.5B到1.5B是比较舒服的区间：0.5B的INT4模型约300MB，1.5B约900MB，前者适合512MB到1GB内存的设备，后者需要至少1.5GB可用内存。
量化方案上，权重量化到INT4基本是标配，group size取128是通用选择，越小精度越高但索引开销越大。有两个地方要特别注意：embedding层和输出头不要量化得太狠，这两层参数量占比不小但精度敏感，我一般保持INT8或者干脆留FP16，代价是模型大一点点，换来的是一部分莫名其怪的胡言乱语消失了。
KV cache的大小必须提前算清楚，公式是：
KV cache 字节数 = 2 × 层数 × KV头数 × head_dim × 序列长度 × 精度字节举个例子，24层、16个KV头、head_dim为64、序列长度512、FP16存储，算下来是 2 × 24 × 16 × 64 × 512 × 2 ≈ 50MB。这个数字看着不大，但如果你把序列长度开到2048，就是200MB，直接吃掉一大块内存。端侧设备的对话上下文一般不需要那么长，我把历史轮次限制在最近三轮，加上系统提示词，控制在512个token以内完全够用。
还有个实操点：模型加载时间。从存储里读300MB权重，按100MB/s的速度算要三秒。如果每次唤醒都重新加载，用户会疯掉。解决办法是进程常驻加内存映射，让模型只加载一次，之后常驻内存。代价是这块内存一直被占着，系统其他部分要相应缩减。我在一个内存吃紧的板子上做过"分时加载"——识别和合成用完就释放，只有语言模型常驻，实测切换时会有两三百毫秒的额外开销，但省下了七八十兆。
3.3 TTS：流式合成与文本前端
合成这一环，很多人以为只要模型能出声就行，实际上文本前端处理不好，读出来的东西会很怪，而且这种怪是用户第一时间就能感知到的。
文本前端要做的事情包括：数字转读法（"2024"要读成"二零二四"还是"两千零二十四"，取决于上下文）、单位符号展开（"3.5℃"要读成"三点五摄氏度"）、英文缩写处理（"WiFi"读成"歪fai"还是逐字母）、多音字消歧。这些规则看起来琐碎，但缺一个就会在演示时被抓包。我建议直接写一个规则表加少量词典，覆盖高频场景就够，不要指望端侧跑一个完整的文本正则化模型。
声学模型选流式结构，按句合成。第一句合成完就立刻送播放，后面的话继续合成，形成"边合成边播"的流水线。这里的关键是切句策略：按句号、问号、感叹号切，同时限制单句最长字符数（比如超过25个字就在逗号处再切一刀），否则一句话太长，首包延迟会被拖得很高。
音色方面，端侧能选的通常是固定的几个预置音色，模型文件大小在20到50MB之间。如果想要更好的自然度，可以选带轻量声码器的方案，代价是每帧的计算量上升。我在一块算力吃紧的板子上试过，把声码器的上采样倍数调低一档，音质损失在听感上几乎察觉不到，但合成速度提升了三成，这个取舍很划算。
3.4 推理后端与算子适配
后端选择上，我的原则是能用现成的就别自己写。业界已经有比较成熟的端侧推理引擎，支持把模型转成中间格式再跑在CPU、GPU或NPU上，一般都能自动做算子融合和量化。
麻烦的地方在于算子覆盖。语言模型里的注意力、旋转位置编码、分组量化矩阵乘这些算子，不是每个后端都完整支持。我遇到过一个情况：模型转换成功了，但推理速度奇慢，用性能分析工具一看，某个归一化算子每次都在做CPU和NPU之间的数据搬运，光这一项就吃掉了四成时间。后来换了个后端版本，这个问题才消失。
所以流程应该是：转模型 → 跑单算子基准 → 看每层的耗时分布 → 找出回落CPU的算子 → 要么换后端版本，要么把模型结构改掉。这一步不做，后面所有调优都是空中楼阁。
4. 实操：从空板到跑通第一句话
4.1 交叉编译环境与依赖
先把编译环境搭起来。主机上装好目标平台对应的交叉编译工具链，确认编译器版本和板子上的运行库版本匹配——这一步不注意，编出来的程序在板子上会报找不到符号。
依赖上通常需要三样东西：音频库（负责采集和播放）、推理引擎的运行时库、以及各模型的前后处理代码。我建议把这三样都编成静态库链进去，减少部署时的动态库依赖问题。第一版我用动态库，结果板子上缺了一个版本不对的库，排查了两个小时。
编译参数上有几个值得注意的点：开启目标平台支持的单指令多数据指令集，浮点运算选硬件浮点，优化级别用O2或O3，同时关掉那些会让二进制膨胀的调试符号。语言模型的推理线程建议单独绑核，避开音频线程所在的核，减少上下文切换。
启动脚本里要把CPU调频策略设成性能模式，否则默认的按需调频会让模型推理的前几百毫秒跑在低频上，首字延迟莫名其妙地高。这个坑我踩过不止一次。
4.2 音频采集链路与前端参数
采集这块，参数定死：采样率16kHz、位深16bit、单声道、每帧20毫秒。20毫秒对应320个采样点、640字节，这个粒度是行业惯例，VAD和识别的分块都对得上。
采集用阻塞读加独立线程，读到的数据先做前端处理：降噪、自动增益、回声消除。降噪和增益看麦克风质量，如果用的是成型的麦克风阵列模组，这些它内部就做了。回声消除必须自己做，因为它的参考信号来自播放通路——你得把正在播放的音频数据同时喂给回声消除模块，它才能从采集信号里把这部分减掉。
回声消除做不好会引发一个经典问题：设备自己说话的声音被麦克风收进去，触发了唤醒或者被当成用户输入，形成"自问自答"的死循环。我在第一版里就出现过这个，设备播报天气播到一半突然自己接话，特别诡异。解决办法是播放期间把唤醒阈值调高，同时确保回声消除的参考信号和实际播放的数据严格对齐——差个几十毫秒，消除效果就会大打折扣。
缓冲区设计上，用一个固定长度的环形队列，采集线程写，消费线程读。队列长度留200毫秒左右的余量，太短会丢帧，太长会引入额外延迟。
4.3 ASR流式解码接入
识别模块的接入流程是：初始化模型 → 喂音频块 → 取中间结果 → 端点后取最终结果 → 重置状态。
初始化时要加载声学模型、语言模型（如果有独立的）、以及热词表。热词表建议做成可配置的文本文件，每行一个词，方便现场调试时临时加词。
喂数据的节奏要和采集对齐，每次喂200毫秒的音频。中间结果的回调频率可以低一些，比如每两块回调一次，避免频繁触发上层逻辑。中间结果主要用来做两件事：一是在界面上显示"正在识别"，让用户知道设备听到了；二是用来判断识别是否已经稳定，如果连续两次中间结果一致，可以提前触发端点。
注意：重置状态这一步千万别漏。识别模型内部有卷积缓存和注意力状态，不重置的话，下一句话会带着上一句的上下文，出现莫名其妙的串词现象。
热词偏置的配置我在前面提过，补充一个细节：偏置词不要加太多，超过一百个之后，误触发的概率会明显上升，而且解码速度会下降。真需要大词表，就得考虑用专门的偏置编码结构，而不是简单的分数加成。
4.4 LLM会话管理与提示词
语言模型这块，提示词设计比模型选型更影响最终体验。
系统提示词里我一般写三部分内容：角色设定（你是一个家庭助手）、输出约束（回答不超过两句话、用口语、不要用列表和符号）、能力边界（不知道就说不知道，不要编）。最后这条特别重要，端侧小模型的幻觉比大模型严重得多，不给它明确的"承认不知道"的许可，它会一本正经地胡说。
会话管理上，维护一个滑动窗口，保留最近三轮问答，超出就丢掉最早的。每轮记录用户输入和模型输出，拼接成模型需要的对话格式。这里要注意模板要和模型训练时一致，不同模型用的角色标记不一样，用错了会让输出质量断崖式下跌。
生成参数上，温度取0.7左右比较自然，重复惩罚给1.1防止车轱辘话，最大生成长度限制在80个token——端侧场景的回答本来就应该短，限制长度既能防止跑偏，也能保证延迟可控。
流式输出的处理方式：每生成一个token就追加到缓冲区，遇到句号、问号、感叹号、或者缓冲区超过一定长度，就把这段文本切出来送给合成模块。这样合成可以在语言模型还在生成的时候就开始工作，整体延迟能省下好几百毫秒。
4.5 TTS合成与播放通路
合成的接入相对简单：初始化 → 送入文本 → 取音频块 → 送播放队列。
文本进来先过前端处理，把数字、符号、缩写都转成读法，然后送声学模型。流式合成的输出是音频块，采样率可能是24kHz或者16kHz，如果是前者，播放前要重采样到设备支持的格式。重采样这一步别忘了做低通滤波，否则会有明显的混叠噪声。
播放通路用双缓冲：一个缓冲正在播，另一个缓冲在填充。填充线程从队列里取合成好的音频块写进去，播完一个就切换。缓冲区大小设成100到200毫秒，太小容易欠载导致卡顿，太大则增加延迟。
播放和采集的同步是个细活。播放开始前要把当前采集缓冲里的数据清掉，不然用户的话音开头会被截掉。播放结束后要留一个短暂的静默期再恢复唤醒检测，给回声消除一点收敛时间。
4.6 联调埋点脚本
联调阶段最重要的是埋点。我会在每个环节的边界打时间戳：端点确认时刻、识别完成时刻、首个token时刻、首句合成完成时刻、音频真正出声时刻。这些时间戳汇总起来，就能算出每个环节的真实耗时。
写个小脚本把这些日志解析成表格，跑二十次取P50和P90。P90比P50更能反映用户体验，因为用户记住的往往是那几次卡顿。我一般的标准是P90不超过2秒，超过就得回去看是哪个环节的尾巴太长。
联调时还要准备一组固定的测试语句，覆盖短句、长句、带数字、带专有名词、带口音几种情况，每次改完参数都跑一遍，形成对比。凭感觉调参是最容易反复的。
5. 调优：延迟、内存、功耗
5.1 首字延迟的六个压缩点
延迟优化要按收益排序，我把实际项目里有效的点列一下。
第一是端点阈值，前面说过，从800毫秒降到600毫秒，收益200毫秒，几乎零成本，但要注意别影响用户表达。
第二是识别提前收尾。当中间结果连续稳定，且后面跟着的静音已经达到短阈值，就可以提前触发最终解码，不必等长阈值。这个能省100到200毫秒。
第三是提示词预填充。系统提示词是固定的，可以在唤醒时就开始预填充KV cache，等真正的问题来了只需要处理用户输入部分。这一招能省掉几百毫秒的预填充时间，收益非常大。实现上需要推理引擎支持session持久化。
第四是首句切短。让语言模型输出的第一句话尽量短，合成就能更快出第一包。可以在提示词里明确要求"第一句话不超过十个字"。
第五是合成预热。合成模型初始化比较慢，可以在会话激活时就把模型加载并跑一次空推理，把缓存热起来。
第六是线程绑核和调频。把推理线程绑到大核，锁住高频，避免调度抖动。这个属于工程细节，但收益稳定。
5.2 内存峰值控制与分时加载
内存是端侧最容易翻车的地方，因为峰值往往出现在你意想不到的时刻。
比如识别模型刚释放、语言模型正在加载的瞬间，如果释放不彻底（有缓存没清），新旧两份内存同时存在，峰值会翻倍。我的做法是用内存池统一管理，所有模型的内存都从池子里分配，释放时归还池子而不是还给系统，这样峰值可控。
KV cache的分配也要注意。很多推理引擎默认按最大序列长度预分配，512的序列长度对应50MB，但如果你的实际对话只有100个token，这50MB就浪费了。有些引擎支持按需增长，代价是可能有内存碎片。端侧我倾向于预分配，稳定压倒一切。
分时加载策略适合内存特别紧张的场景：唤醒后加载识别模型，识别完释放，加载语言模型，生成完释放，加载合成模型。听起来很美，但每次加载都有几百毫秒开销，而且频繁的分配释放容易产生碎片。我的建议是只对最大的那个模型做常驻，其他按需加载，找到平衡点。
5.3 功耗与温控
持续推理的功耗比想象中高。一块小板子跑满语言模型，功耗可能从待机的1瓦飙到5瓦以上，如果没有散热措施，十几分钟就会触发降频，速度掉一半。
温控的策略是限制连续工作时长加主动降频。检测到温度超过阈值，就把生成的最大长度调短，或者干脆在回复里加一句"设备有点热，稍等一下"。听起来很土，但比突然卡死强。
待机功耗的优化点是唤醒模块。唤醒模型必须跑在低功耗域，如果芯片支持，把它放到 always-on 的小核上，主核休眠。这一块如果做不好，一个电池设备可能撑不过一天。
6. 问题排查实录
6.1 识别与断句类问题
现象：用户说长句子，被切成两段识别。
排查思路是先看日志里的端点触发时刻。如果触发时刻落在句子中间的停顿处，那就是静音阈值太短。解决办法是加长阈值，或者引入语义判断——如果识别出的中间结果以"的""和""然后"这类词结尾，说明话没说完，主动延长等待。
现象：某些词永远识别错。
大概率是热词表没覆盖或者偏置权重不够。先用测试音频单独跑一遍，确认是声学层面听错了还是语言层面选错了。前者要靠加训练数据或者换模型，后者调偏置就能解决。还有一种可能是麦克风的频响特性导致的，换个位置或者加个均衡器试试。
现象：识别结果里混进了设备自己的播报内容。
这是回声消除没做好。检查参考信号和播放数据是否对齐，检查回声消除的延迟估计参数是否匹配实际硬件。如果硬件本身的扬声器和麦克风离得太近，软件消除的效果有限，只能靠播放时暂停采集这种粗暴办法。
6.2 音频播放类问题
现象：播放有咔哒声或者爆音。
九成是缓冲区边界处理的问题。检查每块音频的首尾是否有突变，拼接处是否做了淡入淡出。还有一种可能是重采样时的滤波器设计不好，在块边界产生了不连续。
现象：播放断断续续。
先看是不是欠载，也就是播放线程要数据时队列是空的。如果是，要么加大缓冲，要么提升合成速度。如果缓冲够大还卡，就要看是不是被其他线程抢了CPU，用调度工具看一下上下文切换频率。
现象：语速忽快忽慢。
采样率不匹配的典型症状。合成输出是24kHz，播放设备按16kHz播，声音就会变慢变低沉。检查一下格式协商的日志，确认两边谈的是同一个采样率。
6.3 稳定性类问题
现象：跑一段时间后崩溃。
先看是不是内存泄漏，用工具监控进程的常驻内存，如果持续上涨就是漏了。常见的泄漏点是每次会话都新建模型对象但没释放，或者回调里捕获了引用导致对象无法回收。
现象：偶发的推理失败。
如果错误码指向内存分配失败，那是内存碎片问题，考虑改用内存池。如果指向算子执行失败，可能是某些输入形状没覆盖到，比如特别短的音频或者特别长的文本，加个边界检查。
现象：唤醒后没反应。
检查状态机有没有卡在某个中间态。我遇到过一次，识别模块异常退出后状态标志没复位，后续所有唤醒都被忽略。解决办法是加超时兜底，任何状态超过一定时间没推进就强制复位。
6.4 常见问题速查表
| 现象 | 最可能的原因 | 快速验证方式 | 处理办法 |
|---|---|---|---|
| 首字延迟超过2秒 | 端点阈值过长或预填充未复用 | 看各环节时间戳 | 降阈值、开session复用 |
| 识别串词 | 会话状态未重置 | 连续说两句不同的话 | 每次会话结束重置模型状态 |
| 自问自答 | 回声消除失效 | 播放时观察唤醒日志 | 对齐参考信号、提高播放期阈值 |
| 播放爆音 | 块边界突变 | 换一段音频复现 | 加淡入淡出、检查重采样 |
| 内存持续上涨 | 对象未释放 | 监控常驻内存曲线 | 用内存池、检查回调引用 |
| 推理速度骤降 | 温度触发降频 | 看温度和频率日志 | 加散热、限制连续生成长度 |
| 回答跑偏 | 提示词约束不足 | 固定问题多次测试 | 加强角色和长度约束 |
| 热词不生效 | 偏置权重过低 | 单独测试该词 | 权重调到2.0左右再试 |
7. 工程化：让这套东西能维护
7.1 指标与日志
上线之后，你需要的是可观测性，而不是更多的功能。
我固定采集这几类指标：唤醒成功率、误唤醒次数、识别字错率（用固定测试集定期跑）、首字延迟的P50和P90、会话完成率（用户说完后有没有得到回复）、异常重启次数。这些指标按天聚合，出现拐点就说明有问题。
日志分级要清晰：错误级别记录所有异常和状态机异常跳转，信息级别记录每次会话的关键时间戳和文本内容（注意隐私，文本内容建议只存哈希或者脱敏后存），调试级别记录每个模块的输入输出尺寸和耗时，默认关闭。
7.2 模型更新与回滚
端侧模型更新是个高风险动作，必须设计好回滚。
我的做法是双分区存储，新模型写到备用分区，校验通过后切换启动标志。启动时如果连续三次初始化失败，自动切回旧分区。这个机制救过我一次——推了一个量化版本上去，结果某块板子的内存不够加载，靠自动回滚才没变成砖。
灰度策略上，先推一小批设备，观察一周的崩溃率和延迟指标，没问题再放量。模型文件和固件分开更新，这样换模型不用动底层代码，风险更小。
8. 一些实际用下来的体会
这套东西我从第一版跑通到相对稳定，断断续续调了小半年。最大的感受是，端侧语音的难点从来不在单个模型跑不跑得动，而在四个模块凑在一起之后的时序和资源竞争。单看每个模块的指标都挺漂亮，合起来就是会卡、会串、会自己跟自己说话。
如果让我给正在做类似项目的同学一句建议，那就是先把时间戳埋点做扎实，再动手优化。我见过太多人凭感觉调参数，把端点阈值改来改去，最后发现瓶颈其实在模型加载上。数据不会骗人，把每个环节的真实耗时打出来，优化的方向自然就清楚了。
另外一个小技巧分享给内存紧张的方案：语言模型的输出头往往是参数量的大头，如果你的应用场景词汇有限，可以对输出词表做裁剪，只保留常用字词加领域词，模型体积能小一截，生成速度也会快一些。代价是遇到生僻词会输出成别的字，需要在前端做一次兜底替换。这个取舍在垂直场景里通常是划算的。
