2025年，端侧AI（On-Device AI，也叫边缘AI）终于迎来了普及期。随着手机NPU、AI PC、智能穿戴设备的普及，越来越多的AI模型可以在设备端运行，不需要把数据发到云端。

我们团队这两年做了好几个端侧AI的项目，涉及手机、PC、嵌入式设备等多个平台。在这个过程中，我们踩了很多坑，也积累了不少实战经验。

这篇文章，我想总结一下端侧AI开发中的踩坑经验和最佳实践，从模型选择、压缩优化、部署集成到性能调优，聊聊端侧AI的挑战和解决方案。

为什么端侧AI会普及

先说说为什么端侧AI这两年突然火了。

端侧AI，就是把AI模型部署在终端设备（手机、PC、IoT设备等）上，在本地运行推理，而不是把数据发到云端的服务器上推理。

端侧AI有几个明显的优势：

第一，低延迟。数据不需要上传到云端，在本地就能推理，响应速度快。对于实时性要求高的场景（比如语音识别、图像分割、游戏AI），端侧AI的体验远好于云端。

第二，隐私保护。数据不需要离开设备，用户的隐私数据（照片、语音、健康数据等）不会上传到云端，降低了隐私泄露的风险。这在隐私法规越来越严格的今天，尤其重要。

第三，离线可用。没有网络的时候也能使用AI功能，不会因为断网就失效。对于户外、车载、工业等网络不稳定的场景，端侧AI是必须的。

第四，成本低。不需要大量的云端服务器和带宽，降低了运营成本。尤其是用户量大的时候，云端推理的成本会很高，端侧AI能大大降低成本。

第五，个性化。端侧AI可以在本地根据用户的数据进行微调，提供个性化的服务，而不需要把用户数据上传到云端。

正是因为这些优势，端侧AI越来越普及。从手机上的AI拍照、AI翻译，到PC上的AI助手、AI创作，再到智能穿戴的健康监测，端侧AI已经渗透到了我们生活的方方面面。

但端侧AI的开发，比我们想象的要复杂。下面分享我们踩过的坑。

坑一：模型选型比想象中重要

端侧AI的第一个大坑，是模型选型。很多人以为，把云端的模型直接搬到端侧就行了，结果发现根本跑不动。

端侧设备的算力、内存、功耗都有限，不是所有模型都能在端侧运行。模型选型的时候，要考虑几个因素：

第一，模型大小。端侧设备的内存有限，模型不能太大。比如，手机端的模型一般控制在几百MB以内，嵌入式设备可能只有几十MB。大模型（比如GPT-4级别的）根本不可能在端侧运行，需要用小模型或者量化后的模型。

第二，计算量。模型的FLOPs（浮点运算次数）直接影响推理速度。端侧设备的算力有限，计算量太大的模型推理会很慢。比如，手机端的图像分类模型，推理时间最好控制在几十毫秒以内，否则用户会觉得卡顿。

第三，算子支持。不同的端侧推理框架（TensorFlow Lite、ONNX Runtime、Core ML、NNAPI等）支持的算子不一样。有些模型用了特殊的算子，在某些框架上不支持，需要修改模型或者用自定义算子。

第四，精度要求。不同的场景对精度的要求不同。有些场景（比如医疗影像分析）对精度要求很高，不能用太激进的压缩；有些场景（比如图像风格化）对精度要求不高，可以大胆压缩。

我们的经验是，模型选型要从端侧的限制出发，而不是从云端的模型出发。优先选择专门为端侧设计的轻量模型（比如MobileNet、EfficientNet-Lite、TinyBERT、DistilBERT等），而不是把大模型硬压缩。

如果确实需要用大模型的能力，可以考虑模型蒸馏：用大模型（教师模型）来训练小模型（学生模型），让小模型学到大模型的能力，同时保持小模型的体积和速度。

坑二：模型压缩是一门艺术

选好模型之后，通常还需要压缩，才能在端侧流畅运行。模型压缩的方法很多，但每一种都有坑。

第一种压缩方法是量化（Quantization）。量化是把模型的权重和激活从float32转换成int8或者float16，这样模型体积减小，推理速度加快。

量化的坑：

  • 精度损失。量化后模型的精度会下降，尤其是对精度敏感的模型。有时候量化后精度下降太多，根本没法用。
  • 量化感知训练。简单的训练后量化（Post-Training Quantization）精度损失大，需要用量化感知训练（Quantization-Aware Training），在训练过程中模拟量化的影响，这样精度损失小。但量化感知训练需要重新训练模型，比较麻烦。
  • 不同框架的量化不一样。TensorFlow Lite、ONNX Runtime、Core ML的量化方式和支持程度不同，需要针对目标平台做量化。
  • 动态量化和静态量化。动态量化只量化权重，静态量化量化权重和激活。静态量化速度更快，但需要校准数据集。

我们的经验是，先试训练后量化，如果精度满足要求就用；如果不满足，再用量化感知训练。量化后一定要在真实的测试集上评估精度，不能只看几个例子就觉得没问题。

第二种压缩方法是剪枝（Pruning）。剪枝是去掉模型中不重要的权重或者通道，减少模型的参数量和计算量。

剪枝的坑：

  • 非结构化剪枝（去掉单个权重）虽然能减少参数量，但实际推理速度不一定快，因为稀疏计算的硬件支持不好。
  • 结构化剪枝（去掉整个通道或层）能真正减少计算量，但剪枝比例太大的话，精度下降严重。
  • 剪枝后需要微调（Fine-tuning）来恢复精度，这增加了训练成本。
  • 不同框架对稀疏模型的支持不同，有些框架不支持稀疏推理，剪枝了也白剪。

我们的经验是，优先用结构化剪枝（通道剪枝），因为它能真正加速。剪枝比例不要太大（比如不超过50%），剪枝后一定要微调。如果框架不支持稀疏推理，就不要浪费时间做非结构化剪枝。

第三种压缩方法是知识蒸馏（Knowledge Distillation）。用大模型（教师）来指导小模型（学生）的训练，让小模型学到大模型的知识。

蒸馏的坑：

  • 蒸馏的效果取决于教师模型和学生模型的差距。如果学生模型太小，学不到教师模型的能力，效果不好。
  • 蒸馏的温度参数（Temperature）很重要，需要调参。温度太高，学生模型学到的是软标签；温度太低，和普通训练差不多。
  • 蒸馏需要有标签的数据集，而且最好和教师模型的训练数据分布一致。
  • 蒸馏增加了训练复杂度，需要同时加载教师模型和学生模型，训练成本高。

我们的经验是，蒸馏适合在有一个好的大模型、需要一个小模型的场景。蒸馏后的小模型，精度通常比从头训练的小模型好。但蒸馏不是银弹，不能指望小模型完全达到大模型的精度。

第四种压缩方法是架构设计。直接设计轻量的模型架构，比压缩大模型更有效。比如MobileNet用深度可分离卷积，EfficientNet用复合缩放，Transformer用稀疏注意力等。

我们的经验是，如果能从头训练模型，优先选择轻量架构，而不是训练大模型再压缩。轻量架构的设计本身就是为端侧优化的，效果通常比压缩后的大模型好。

坑三：推理框架的选择和适配

模型压缩好之后，需要选择合适的推理框架，部署到目标设备上。推理框架的选择，也是一个大坑。

常见的端侧推理框架有：

  • TensorFlow Lite（TFLite）：谷歌的端侧推理框架，支持Android、iOS、嵌入式设备，生态成熟，算子支持全。
  • ONNX Runtime：微软的跨平台推理框架，支持多种模型格式（ONNX），支持CPU、GPU、NPU。
  • Core ML：苹果的端侧推理框架，专门优化iOS和macOS，能利用Apple的Neural Engine。
  • NNAPI：Android的神经网络API，能利用手机的NPU加速。
  • TensorRT：英伟达的推理加速框架，主要用于GPU和嵌入式设备（Jetson系列）。
  • MNN：阿里开源的端侧推理框架，在移动端优化得很好。
  • NCNN：腾讯开源的端侧推理框架，针对移动端优化。

选择推理框架的时候，要考虑：

  • 目标平台。iOS优先Core ML，Android可以用TFLite或ONNX Runtime，嵌入式看芯片支持。
  • 模型格式。你的模型是什么格式（TensorFlow、PyTorch、ONNX），框架是否支持。
  • 算子支持。你的模型用的算子，框架是否都支持。不支持的算子需要修改模型或者自定义实现。
  • 性能。不同框架在不同设备上的性能差异很大，需要实际测试。
  • 硬件加速。框架是否支持NPU、GPU加速，加速的效果如何。

我们踩过的坑：

第一，模型转换失败。把PyTorch模型转成ONNX，再转成TFLite或者Core ML，经常会遇到算子不支持、形状不匹配、动态维度不支持等问题。转换过程中需要反复调试，有时候需要修改模型结构来适配框架。

第二，硬件加速不稳定。用NNAPI或者Core ML的NPU加速，有时候某些算子不支持，会自动回退到CPU，导致速度反而更慢。而且不同厂商的NPU支持程度不同，同一模型在不同手机上的性能差异很大。

第三，精度不一致。不同框架的推理结果可能有细微差异，尤其是量化后的模型。有时候在一个框架上精度正常，换一个框架精度就下降了。需要在目标框架上重新评估精度。

第四，版本兼容性。推理框架更新很快，不同版本的API和行为可能不一样。升级框架版本后，可能会出现性能下降或者模型不兼容的问题。

我们的经验是：

  • 尽早在目标框架和目标设备上测试，不要等模型训练完了才发现部署不了。
  • 建立模型转换和测试的自动化流程，每次模型更新都自动转换和测试。
  • 对于关键算子，考虑用框架支持的标准算子，避免用太冷门的算子。
  • 准备好CPU fallback方案，如果NPU加速有问题，至少能在CPU上跑起来。
  • 针对不同的平台，可能需要维护不同版本的模型（比如Core ML版本和TFLite版本）。

坑四：性能优化是持续的战争

模型部署到端侧之后，性能优化是一个持续的过程。端侧设备的资源有限，每一点性能都很宝贵。

我们在性能优化方面踩过的坑：

第一，只看模型推理时间，不看端到端延迟。很多人只优化模型的推理时间，但端到端的延迟还包括数据预处理（图像缩放、归一化）、后处理（结果解析、过滤）、数据拷贝等。有时候这些预处理和后处理的时间比模型推理还长。

我们的经验是，测量端到端的延迟，找到真正的瓶颈。如果预处理是瓶颈，就优化预处理（比如用硬件加速、减少数据拷贝、用更高效的算法）。

第二，内存占用被忽视。端侧设备的内存有限，模型加载、输入输出缓冲区、中间计算结果都占用内存。如果内存占用太高，会导致系统杀死应用，或者影响其他应用的运行。

我们的经验是，监控内存使用，及时释放不需要的资源。模型加载后，释放训练用的中间数据。输入输出缓冲区复用，避免频繁分配。用内存映射（Memory Map）加载大模型，减少内存占用。

第三，功耗和发热被忽视。端侧AI推理是耗电大户，如果持续高负载运行，设备会发热，导致降频（Thermal Throttling），性能反而下降。手机还会因为发热而卡顿、掉帧。

我们的经验是，不要让AI推理持续满负载运行。对于不需要实时的任务，用低优先级、低频率运行。对于实时任务，优化模型和推理，降低计算量。监控设备温度，温度过高时降低推理频率或者暂停推理。

第四，不同设备的性能差异大。同样的模型，在高端手机上可能10ms推理完，在低端手机上可能要100ms。如果只在高端手机上测试，到了低端手机上就会卡顿。

我们的经验是，建立设备分级机制，针对不同性能的设备提供不同的模型（大模型给高端设备，小模型给低端设备），或者动态调整推理参数（比如降低输入分辨率、减少推理频率）。在多种设备上测试，确保最差的设备也能基本可用。

坑五：数据和隐私的挑战

端侧AI的一个重要优势是隐私保护，但端侧的数据处理也有自己的挑战。

第一个挑战是数据获取和标注。端侧AI模型需要训练数据，但很多端侧场景的数据（比如用户的照片、语音、健康数据）涉及隐私，不能随便收集。没有足够的训练数据，模型效果就不好。

我们的经验是，用公开数据集预训练，然后用联邦学习（Federated Learning）或者用户授权的少量数据做微调。联邦学习可以在不收集用户原始数据的情况下，让模型从用户的数据中学习，是端侧AI的一个重要方向。

第二个挑战是数据预处理的一致性。模型在训练时的预处理（图像缩放方式、归一化参数、音频采样率等）必须和端侧推理时的预处理完全一致，否则精度会下降。我们踩过很多次这个坑，训练时用一种预处理，端侧用另一种，结果模型效果很差。

我们的经验是，把预处理逻辑固化下来，训练和端侧用同一份代码或者相同的参数。在端侧实现预处理后，用测试数据验证预处理结果是否和训练时一致。

第三个挑战是动态环境的适应性。端侧设备的使用环境变化很大（光线、噪声、用户习惯等），模型在实验室环境下效果好，到了真实环境可能效果差。

我们的经验是，在训练数据中加入各种环境的变化（数据增强），提高模型的鲁棒性。在端侧做一些环境自适应的处理，比如自动曝光、噪声抑制、用户个性化校准。

第四个挑战是模型更新。端侧模型部署之后，如果发现问题或者需要优化，怎么更新？如果每次更新都要发版，周期太长。如果用热更新，又有安全和兼容性的问题。

我们的经验是，设计模型的热更新机制，把模型和应用代码分离，模型可以从服务器下载更新。同时，做好版本管理和回滚机制，更新出问题能快速回滚。

坑六：用户体验的细节

端侧AI最终是给用户用的，用户体验的细节很重要。

第一个细节是首次使用的体验。端侧AI模型通常比较大，第一次使用时需要下载模型，用户可能等很久。我们的经验是，在应用安装时或者WiFi环境下预下载模型，首次使用时给用户清晰的进度提示。如果模型太大，可以先用一个小模型提供基本功能，大模型在后台下载。

第二个细节是推理过程的反馈。AI推理需要时间，用户在等待的时候需要反馈。比如，语音识别的时候显示正在录音的动画，图像处理的时候显示进度条。不要让用户觉得应用卡死了。

第三个细节是失败的处理。AI推理可能失败（比如模型加载失败、输入不合法、推理超时），需要有优雅的失败处理。比如，提示用户重试，或者回退到非AI的功能。不要因为AI功能失败就导致整个应用崩溃。

第四个细节是功耗和性能的平衡。用户不希望用了AI功能之后手机发烫、耗电快。要在AI效果和功耗之间找到平衡。比如，提供"省电模式"，在省电模式下用更小的模型、更低的推理频率。

写在最后

端侧AI是一个充满挑战和机会的领域。随着硬件的进步和算法的优化，端侧AI会越来越普及，能做的事情也会越来越多。

我们踩过的这些坑，总结起来就是几条经验：

第一，模型选型从端侧限制出发，优先选择轻量模型，不要把大模型硬搬过来。 第二，模型压缩要谨慎，量化、剪枝、蒸馏各有适用场景，压缩后一定要评估精度。 第三，推理框架的选择要考虑目标平台、算子支持、性能，尽早在目标设备上测试。 第四，性能优化要看端到端延迟，关注内存、功耗、设备差异。 第五，数据和隐私要重视，预处理要一致，模型更新要有机制。 第六，用户体验的细节决定成败，首次使用、推理反馈、失败处理、功耗平衡都要考虑。

端侧AI的技术还在快速发展，今天的坑明天可能就不是坑了。但不管技术怎么变，理解用户需求、保证模型质量、做好性能优化，这些基本原则是不会变的。

如果你也在做端侧AI开发，或者对端侧AI感兴趣，欢迎在评论区交流。让我们一起推动端侧AI的普及，让AI更好地服务每一个人。