3. 稳定性定义与范畴

在端侧AI工程化实践中，模型推理的稳定性往往是最晚被关注、却最早引发线上事故的维度。团队通常在模型精度达标、单次推理延迟达标后便宣告“完成”，直到用户反馈“用着用着就闪退”“连续识别几次结果不一样”“内存占用越来越高”时，才意识到稳定性问题早已潜伏。本章将系统定义端侧推理稳定性的内涵，厘清其与准确性、性能的边界，并剖析崩溃、卡顿、结果漂移、内存泄漏等典型表现，为后续章节的监控指标设计与远程诊断建立统一的概念框架。

3.1 核心原理：稳定性的三重维度

端侧推理稳定性是指模型在端侧设备上持续、可重复、可预期地完成推理任务的能力。它不关注单次推理的“好坏”，而关注多次推理之间的“一致性”。这种一致性体现在三个维度：

• 时间维度：同一模型、同一输入、同一设备，在不同时间点执行推理，结果和资源消耗应保持一致。例如，连续运行1小时与刚启动时相比，推理延迟不应出现数量级变化。
• 环境维度：设备温度升高、电池电量下降、后台应用抢占CPU/GPU、系统升级等外部条件变化时，推理行为不应发生不可控的劣化。
• 输入维度：对于相似输入（如不同光照下拍摄的同一物体），模型输出应保持语义一致，不应出现“差一点就完全不同”的敏感跳变。

从工程角度看，稳定性是系统级属性，而非单纯的模型属性。它涉及推理引擎的内存管理、线程调度、算子实现、硬件适配、系统资源竞争等多个层面。一个模型在开发机上运行稳定，不代表在用户手机上同样稳定——这正是端侧推理稳定性区别于服务端推理的关键。

3.2 与准确性、性能的区别与联系

准确性、性能、稳定性是评估端侧推理质量的三个正交维度，但实践中常被混淆。下表从多个角度进行对比：

三者之间存在耦合关系：性能优化（如激进量化）可能损害准确性；稳定性问题（如内存泄漏）会间接导致性能下降和结果漂移。但它们的监控指标和诊断方法完全不同。准确性关注“输出标签”，性能关注“时间戳和内存快照”，稳定性关注“时间序列上的行为模式”。

3.3 稳定性问题的典型表现

端侧推理稳定性问题通常以四种典型形态呈现，每种形态都有其独特的根因和诊断路径。

3.3.1 崩溃（Crash）

崩溃是最严重的稳定性问题，表现为进程异常终止、闪退、系统重启等。在端侧推理场景中，崩溃的常见根因包括：

• 非法内存访问：如空指针解引用、数组越界、释放后使用（use-after-free）。常见于自定义算子或C++层代码。
• 资源耗尽：内存分配失败（OOM）、文件描述符耗尽、线程创建失败。
• 硬件异常：GPU/NPU驱动崩溃、DSP固件异常、特定芯片平台上的指令集不兼容。
• 系统信号：SIGSEGV（段错误）、SIGABRT（断言失败）、SIGBUS（总线错误）。

崩溃的监控相对容易——系统会生成崩溃日志（如Android的tombstone、iOS的crash report），但难点在于复现。端侧设备环境碎片化严重，同一崩溃可能只在特定机型、特定系统版本、特定输入下发生。

3.3.2 卡顿（Jank/ANR）

卡顿表现为推理延迟的剧烈波动或持续高延迟，导致用户体验中断。与性能问题的区别在于：性能问题关注“平均延迟”，卡顿关注“延迟的尾部分布”和“时间序列上的突变”。

// 卡顿的典型表现（以Android为例）
// 1. 单次推理延迟从30ms飙升至500ms
// 2. 主线程阻塞导致ANR（Application Not Responding）
// 3. 帧渲染时间超过16.6ms，导致掉帧
// 4. 推理延迟呈现周期性峰值（如每30秒一次）

卡顿的根因往往涉及：CPU/GPU频率调度（thermal throttling）、内存页交换（page fault）、锁竞争（lock contention）、后台任务抢占、模型输入尺寸动态变化导致的重新分配等。

3.3.3 结果漂移（Result Drift）

结果漂移是指模型在相同或相似输入下，输出结果随时间或环境变化而出现不一致。这种不一致可能是数值层面的微小波动，也可能是语义层面的显著差异。

结果漂移的隐蔽性最强，因为系统不会报错，但输出质量在不知不觉中劣化。它需要持续的质量监控才能发现，例如定期用基准测试集验证模型输出。

3.3.4 内存泄漏（Memory Leak）

内存泄漏是指推理过程中分配的内存无法被正确释放，导致进程内存占用持续增长。在长时间运行的端侧应用中（如实时视频处理、语音助手），内存泄漏最终会导致OOM崩溃或系统强制回收。

// 内存泄漏的典型模式
// 1. 每次推理分配10MB临时张量，但只释放8MB
// 2. 缓存机制未设置上限，缓存条目无限增长
// 3. 图形API（如OpenGL/CUDA）资源未正确释放
// 4. 线程局部存储（TLS）中的对象未清理

内存泄漏的监控需要趋势分析而非阈值判断。单次内存占用正常不代表没有泄漏，关键是观察内存随时间的变化斜率。

3.4 案例拆解：一个真实的内存泄漏与结果漂移复合问题

为帮助理解稳定性问题的实际表现和诊断思路，以下是一个复合型案例。

初始现象与数据采集：通过远程监控平台采集到以下指标：

• 内存占用：从启动时的180MB，以约2MB/张的速度持续增长，拍摄50张后达到280MB
• 推理延迟：前10张平均35ms，第20张后升至80ms，第40张后达到200ms
• 识别准确率：前20张准确率92%，第30张后降至78%，且错误集中在特定类别
• 崩溃日志：拍摄第47张时发生OOM崩溃，堆栈指向图像预处理模块

分析判断过程：

1. 内存持续增长且斜率稳定，排除一次性大块分配，指向每次推理都泄漏少量内存。
2. 延迟增长与内存增长呈正相关，推测是内存碎片化导致分配变慢，或GC/回收频繁触发。
3. 准确率下降并非模型本身问题——因为前20张准确率正常。进一步检查发现，图像预处理模块在内存压力下开始降低图像采样质量（为节省内存而使用低分辨率），导致输入质量下降。
4. 崩溃堆栈确认是图像预处理模块中的Bitmap对象未调用recycle()方法。

实际操作步骤：

1. 在图像预处理模块中，将Bitmap的recycle()调用从finally块移至try块之前，确保异常路径也能释放。
2. 为缓存机制增加LRU淘汰策略，设置最大缓存条目为20。
3. 在推理循环中增加内存水位检查，当内存超过阈值时主动降级为低分辨率模式（而非被动降级）。
4. 增加“内存增长斜率”监控指标，当连续10次推理内存增长超过1MB/次时触发告警。

结果对比：修复后连续拍摄200张，内存稳定在190-200MB区间，延迟稳定在32-38ms，准确率恢复至91%。

复盘经验：稳定性问题往往不是单一根因，而是多个小问题叠加。内存泄漏是“因”，延迟增长和准确率下降是“果”。监控设计必须覆盖因果链条，而非只看表面指标。

3.5 常见误区与总结复盘

在理解和处理端侧推理稳定性问题时，以下误区需要特别警惕：

总结复盘：端侧推理稳定性是一个系统工程问题，它要求我们从“单次正确”的思维转向“持续正确”的思维。稳定性监控不是简单地增加几个指标，而是建立一套覆盖时间、环境、输入三个维度的观测体系。崩溃、卡顿、结果漂移、内存泄漏这四类典型表现，分别对应了进程生命周期、时间响应、输出质量、资源管理四个层面的稳定性要求。在后续章节中，我们将围绕这些表现设计具体的监控指标和远程诊断方案。