1. 模型上手机前的第一道坎移动端资源约束为什么这么紧1.1 移动端不是小号的服务器很多刚接触端侧部署的同学会有个错觉服务器上能跑的模型手机上也一定能跑大不了慢一点。这是整个移动端AI部署项目中最大的误解。我在实际项目里见过太多类似案例——拿一个在服务器GPU上跑到50毫秒的目标检测模型原封不动塞进手机结果单帧推理飙到两三秒机身发烫到可以煎鸡蛋App直接被系统杀掉。问题不出在模型本身而出在移动端这套资源模型和服务器完全不在一个维度上。先看算力。手机上的CPU和GPU无论是理论峰值算力还是持续算力和桌面级GPU都不是一个量级。以当前主流旗舰手机SoC为例CPU单核心的浮点能力大概在几十GFLOPS到上百GFLOPS区间NPU的算力看着唬人动辄几十TOPS但实际访存带宽和算子支持会打很大折扣跑通用卷积还行跑复杂算子经常喂不饱。更关键的是端侧算力是公用的——系统UI渲染、后台任务、其他App都在抢CPU和GPU资源AI推理只能拿到其中一部分。内存就更紧张。服务器上显存动不动就是16GB、32GB手机上App能申请的内存上限取决于系统和机型通常也就几百MB到1GB上下。模型权重加中间激活值一算一个几百MB的模型就可能把App撑爆。iOS上系统对内存使用特别敏感内存偏大会直接触发Jetsam把进程杀掉Android这边虽然宽松些但杀后台、系统回收内存也是家常便饭。还有功耗发热。手机没有主动散热风扇高负载运行全靠机身被动散热。持续推理带来的发热一旦超过阈值系统就会触发降频推理速度反而会越来越慢形成恶性循环。这点在长时间使用场景里体现得尤其明显——比如视频流实时推理前五分钟和跑了一小时之后的帧率可能差出一倍还多。1.2 显存、带宽与发热三项硬指标决定模型能不能跑做端侧部署方案设计时我会先锚定三项硬指标所有技术选型和优化手段都围绕它们展开。第一项是模型体积。严格说模型体积不等于部署包体积但它直接决定了用户下载成本、App包体膨胀速度和首启加载时间。现在用户的耐心非常有限一个极为轻量的工具类App如果因为内置模型多了几十MB转化率都会受影响。所以多数情况下我会把模型文件控制在50MB以内作为一条红线超过这个值就要认真评估是否值得往里塞。第二项是内存峰值。推理过程中的内存消耗通常由三部分组成模型权重常驻内存、输入输出张量、每一层的中间激活值。峰值往往不在权重上而在特征图特别大的那一层。一个典型的例子是分割模型输入分辨率一旦拉到1024×1024中间特征图的累计大小很容易超过200MB这在手机上是不可接受的。所以端侧模型在设计阶段就要考虑分辨率输入上限不能照搬服务端的做法。第三项是单次推理耗时。一个能被接受的移动端推理耗时取决于你的业务场景实时视频流要求单帧30~50毫秒以内交互式功能比如点击按钮后识别一次可以放宽到100~300毫秒离线批处理可以再宽一些。超过一秒钟的推理基本就告别了实时交互场景。这三项指标之间是互相牵制的。模型体积小了精度可能掉分辨率降了耗时下降但召回率也降内存和耗时都压下来往往意味着量化、剪枝等一系列压缩手段全都要上。这就是为什么所有端侧部署项目的起点一定是先明确这三项指标的底线而不是先把模型搞出来再想办法优化——顺序反了后面每一步都会非常痛苦。2. 压缩不是魔法量化、剪枝与蒸馏的取舍逻辑2.1 量化从FP32到INT8精度与速度的守恒量化是端侧部署里最常用、性价比最高的压缩手段基本思路很简单把模型里的浮点参数从FP32变成INT8甚至INT4用更少的bit存储同样的信息模型体积直接缩小到原来的四分之一推理速度由于整数运算更快以及访存压力更小也能得到明显提升。但你得清楚量化是有代价的。FP32到INT8的映射本质上是一个有损过程压缩掉的精度来自数值的量化误差。实际操作中产生误差最明显的地方往往是激活值的分布——权重参数还好说范围相对稳定激活值在不同输入下的差异很大一旦有离群点整个量化范围被拉宽正常值的表示精度就被压缩得很严重。端侧部署最常用的是两类量化方案训练后量化PTQ和量化感知训练QAT。PTQ的流程最省事——模型训练完拿一批代表性数据在推理框架里跑一遍统计每一层激活值的min/max或分布然后据此确定量化参数整个过程不需要重新训练。它最常踩的坑是校准数据集选得不好校准集如果和线上真实数据分布差异大量化后的精度损失会超出预期。我一般建议校准集至少500到1000张要覆盖边角案例而不是随手拿几张看着顺眼的。QAT是在训练过程中就模拟量化误差让模型自己适应低精度表示。它的精度通常比PTQ高不少代价是要重新训练一遍模型训练时间、GPU成本都得算进去。按照我的经验如果PTQ后在验证集上掉点超过2个百分点那就别硬凑合了直接上QAT省下来的是后面排查精度问题的工时。这里还有一个容易被忽略的问题量化精度不仅取决于量化算法还取决于推理框架对量化算子的实现质量。同一个PTQ模型在框架A里跑掉点0.5%换到框架B里可能掉点2%。选了哪个推理框架就要用那个框架自带的量化工具走一遍完整流程别指望跨框架套用别人的量化产物。2.2 剪枝与蒸馏结构化裁剪、知识搬迁怎么配合量化之外剪枝和蒸馏是另外两个高频使用的压缩手段。剪枝的本质是把模型中对最终输出贡献不大的参数或结构删掉。非结构化剪枝是最基础的形态——把权重矩阵里绝对值接近零的小权重直接置零得到稀疏矩阵。但这种方式在端侧非常不友好目前主流的CPU、GPU硬件对稀疏矩阵的加速支持并不好稀疏度达不到一个很高的比例比如90%以上推理速度不仅不提升反而可能因为稀疏索引的计算开销更慢。所以端侧部署我更推荐结构化剪枝——按通道、按行或按卷积核整体剪掉得到的还是密集矩阵运算硬件友好得多。通道剪枝后的模型推理速度提升是实打实的。蒸馏的思路完全不同它不直接压缩已有模型而是训练一个新的小模型去学大模型的能力。做法是先训练或拿到一个高精度的教师模型再用教师模型的输出soft label软标签去监督一个小学生模型的训练。学生模型学到的不仅是真实标签还有教师模型对类别之间相似性的理解这比直接用小模型在原始数据上训练精度要高不少。蒸馏在端侧的价值在于它和小模型结构设计是天然配合的。你可以先用蒸馏把小模型训到一个可以接受的精度然后再对这个小模型做量化和剪枝层层压缩下来最终部署体积能控制得很小。实践中我经常看到蒸馏量化的组合因为量化掉的精度可以靠蒸馏先把精度基线拉高留出冗余。剪枝和蒸馏不应该被看作二选一而是可以叠加的流水线。常见做法是先训练大模型用大模型蒸馏出中尺寸模型再对中尺寸模型做通道剪枝最后量化部署。每一步都会掉一点精度但每一步掉的量都可以控制在可接受范围内叠起来整体收益非常可观。2.3 组合方案的推荐次序关于压缩方案的组合顺序我做了不少实验后总结出了一个比较稳的固定套路这里直接分享省的大家自己反复试错。第一步永远是先做精度基线的测量。拿原始FP32模型在测试集上跑一遍记录精确率、召回率、F1这些关键指标这就是后续所有压缩方案的对照基准。第二步是模型结构层面的压缩优先做蒸馏和低秩分解这类改动结构的手段。蒸馏得到一个基础小模型之后再评估它的精度和体积。到这里如果模型体积已经达标、精度掉点在可接受范围那么后面的量化就可以更激进一点如果体积还没达标需要结合剪枝继续压。第三步是剪枝。建议先做敏感度分析——逐层评估剪掉不同比例通道对精度的影响找出对剪枝不敏感的层优先从这些层下手。不要一上来就全局同一比例剪那样大概率一刀切下去精度崩盘。第四步才是量化。把量化放到最后是有原因的量化的精度损失难以预测如果在没做剪枝蒸馏之前就量化产生的精度损失会混在一起出了问题你根本不知道是哪一步造成的。先做好前两步量化只承担最后一小部分精度损失排查起来清晰得多。这个次序不是绝对的比如个别框架对某种量化方式支持特别好你可以根据实际情况微调。但大方向记住结构改动靠前、数值压缩靠后每一步都单独记录精度整个过程可追溯。3. 压缩完成后去哪跑主流端侧推理框架选型实录3.1 五个主流框架的实际体验模型压缩完了接下来就是选推理框架。这一步决定了你后面的工程量选错框架返工成本极高。我自己深度接触过五个主流的开源框架逐一说下实际感受。TensorFlow Lite现在叫LiteRT是应用最广的方案之一。它最大的优势是生态成熟几乎TensorFlow训练的模型都有非常成熟的转换工具链社区案例多、文档全任何奇怪的报错几乎都能搜到前人踩坑记录。它对AI处理单元、GPU委托的支持比较完善在Android上的兼容性尤其好。缺点也不含糊架构有些不思进取部分新算子跟进速度慢如果模型里用了比较新的结构转格式时经常要处理不支持的算子。ONNX Runtime Mobile是个很有意思的选择。ONNX作为模型中间格式在生态互通性上优势明显——PyTorch、TensorFlow、PaddlePaddle训练的模型都能先转成ONNX再用它推理。它能加载标准ONNX格式模型工程上很方便算子覆盖面也比较广。但对iOS的后端优化个人感觉不如Android上做得极致不同后端的性能差异也比较大。Core ML是iOS生态里的亲儿子和Apple设备的硬件配合最紧密。在iPhone上它支持CPU、GPU和神经引擎的统一调度很多模型同样配置下能够达到比通用框架更好的性能。但Core ML有个硬伤开发流程严重依赖Mac环境转换工具链和Xcode紧紧地绑在一起如果团队不是苹果全家桶的开发方式光环境问题就能磨掉不少工期。NCNN是腾讯开源的轻量级框架以极致优化出名。它的特点是专门针对手机CPU做了大量汇编级优化在纯CPU推理场景下性能表现非常出色。很多做端侧实时视频处理、玩机圈搞本地模型运行的人特别爱用它。缺点是生态相对封闭模型格式需要专门转换部分算子需要自己实现或适配如果项目周期紧、团队没有底层优化经验上手成本会偏高。MNN是阿里的开源框架我实际用下来感觉它的工程化程度很成熟跨平台支持和多后端调度做得不错支持CPU、GPU、NPU多种硬件且对华为等国产芯片的适配比较积极。在Android端的综合表现稳定iOS端也不差。它的模型转换工具也比较顺手文档更新比较勤。如果团队需要一个Android和iOS统一方案的框架MNN是我目前比较愿意推荐的优先选项。3.2 选型逻辑算子覆盖、硬件加速与业务场景各家框架各有侧重真正选型时我建议从三个维度去卡。第一个维度是算子覆盖。把你模型结构里的算子列出来逐个去候选框架里对照支持情况。这一步务必要在选型阶段做不要等到模型转换时报错了再去查框架支不支持。特别是用了Transformer类的模型里面涉及到的LayerNorm、GELU、多头注意力相关算子每个框架的支持程度差异很大。一个简单的经验模型里特殊算子越多选型的自由度越小这时候ONNX Runtime或TensorFlow Lite这类生态大的框架优势更大。第二个维度是硬件加速。你的目标用户的手机是什么配置决定了你需不需要、能不能用到GPU、NPU这类加速单元。如果你的用户群体集中在中低端Android机那主要优化目标就是CPU下的运行效率NCNN、MNN这类优先做CPU优化的框架更稳。如果App主要跑在旗舰机、且iOS和Android都想覆盖那要考虑框架的多后端支持能力。这里提醒一句别迷信硬件加速。在某些低端设备上GPU驱动素质差用GPU委托推理的速度反而不如CPU来得稳实际项目里一定要在目标机型上做灰度验证不能只看实验室数据。第三个维度是团队的技术栈和工程量。如果团队里有人熟悉某个框架的内部实现那选这个框架前期踩坑成本就低很多。如果都没有选社区活跃度高的、文档全的出了问题能查到解决方案TensorFlow Lite和ONNX Runtime在这方面的兜底能力是最好的。别小看这一点端侧推理的坑往往不在主流程而在各种设备、系统版本的边角组合这个只能在社区经验库里去捞。给个比较省心的参考配置纯Android项目团队没有框架底层优化能力优先TensorFlow LiteAndroid和iOS都要项目周期允许折腾优先MNN重度依赖iOS生态、团队主要用Xcode开发那就好好用Core ML对极致CPU性能有追求、也愿意填坑NCNN值得投入。4. 从PyTorch权重到端侧可执行文件完整部署链路拆解4.1 出发点导出ONNX与算子兼容性检查确定框架之后整个部署链路的起点是把训练好的模型导出成目标框架能吃的格式。目前最主流的中间步骤是先把PyTorch或TensorFlow模型导出成ONNX再从ONNX转到具体的端侧框架格式。PyTorch导出ONNX的操作看起来简单一行torch.onnx.export就能出文件但实际工程中细节极多。最常见的坑是动态输入尺寸。很多模型在训练时习惯了固定分辨率导出时如果不显式指定动态轴生成出来的ONNX模型就被锁死成固定输入shape了。比如一个检测模型在测试集上用的是640×640但线上用户上传的图片五花八门你要么把所有图片都缩放到640×640再送进模型要么就在导出时指定为动态轴。后者在推理框架里处理起来复杂一些但换来的是输入灵活性两者需要根据业务权衡。另一个高频问题是算子版本不匹配。PyTorch某个版本生成的ONNX算子集可能需要较高的ONNX opset版本才能导出但你的目标推理框架不认这个版本。整个链路里最让我头疼的就是这种版本矩阵问题——PyTorch版本、ONNX版本、目标框架版本任何一环不匹配都可能导出失败或运行时崩。建议项目一开始就把这组版本固定下来写进项目文档谁都不能自行升级。我在一个项目里用PyTorch 2.1导出的模型换到同事的PyTorch 2.0环境就报Unsupported operator排查了整整一天最后就是版本差异导致的纯浪费工时。导出之后不要急着转格式先用工具检查一下ONNX模型的结构和算子列表能提前发现一批明显问题。onnxruntime自带的Python推理接口可以当作一个快速验证器直接把ONNX模型加载进来喂一组真实输入看输出是否正常。这一步通过基本可以确定模型结构本身没大问题接下来再去适配目标框架。4.2 转格式与量化校准的具体操作以TensorFlow Lite为例ONNX模型转TFLite的常规路径是先把ONNX转成TensorFlow的SavedModel再用TFLite Converter转成.tflite文件。这一步里经常碰到的问题是ONNX模型里的算子在TFLite转换时没有一一对应的算子实现转换器会尝试用若干个基础算子拼接替代如果替代不了就直接报错。一个通行的做法是先把模型里的自定义层或特殊算子降到基础算子组合比如用卷积加reshape替代某些复杂的矩阵操作。但这也意味着精度可能损失所以能做的前提还是模型结构本身别太花哨。如果你的模型结构非常复杂绕来绕去都转不过去那就要回看选型阶段第三次提到的建议了——框架的算子覆盖能力现在就是它起作用的时候。格式转换通过后下一步是量化校准。以PTQ为例TFLite官方的转换流程里有一个提交代表性数据集的参数它会拿这批数据在FP32模型上跑一遍统计激活分布来确定量化参数。这里有几个实操细节值得注意校准数据要保证类别均衡不能全是某一类样本否则量化参数偏向于那一类其他类别精度容易掉校准集的规模也不要贪多几千张图片跑校准在端侧工具上会非常耗时1000张左右通常就足够了校准过程中批量大小会影响统计数据如果模型里有BatchNorm层校准阶段的统计数值一定要准确不然量化误差会被放大。转换结束后立刻用准备一套完整的测试集对量化后的模型做精度验证和FP32基线对比。这一步往往能发现一些直观问题比如量化后某一类的召回率暴跌说明校准数据里这类样本太少再比如整体精度都掉了不少需要回炉用QAT方案重新训练。4.3 Android/iOS端集成要点模型格式准备好之后最后一步是集成到App里。这一环节看似简单——把模型文件放到assets目录调用框架接口加载推理但实际上工程细节非常多。Android这边TFLite的集成有完整的依赖和示例代码加载模型的路径、输入输出的预处理后处理都有固定模板可循。最容易出问题的地方是输入张量的排列方式模型训练时用的是CHW通道在第三维但Android上拿到的是Bitmap转出来的像素数据是HWC排列这个转换必须自己处理。很多新人就在这里翻车输出的张量形状对不上或者结果完全错误排查半天才发现是维度顺序的问题。所以在写预处理代码之前务必确认模型输入张量的shape免得做了无用功。iOS端Core ML的集成路径依赖Xcode的自动转换工具链整体上问题少一些但有一个坑也值得提醒Core ML模型文件会打包进App的bundle里如果你用的是.mlmodelc格式而模型有点大加载到内存里的耗时是不可忽视的最好放到后台线程去加载不要阻塞UI线程否则就是滴一下卡死的体验。内存管理方面推理引擎在初始化时会分配线程池、工作区等内存Session的创建和销毁要尽量避免频繁操作否则GC压力会非常明显。我自己常用的方式是在App启动后按需懒加载推理引擎做成长驻单例反复复用推理的输入输出缓冲区而不是每次推理都新建。这样既能降低峰值内存也能减少内存抖动对帧率的干扰。5. 打开Profiler看真实战场耗时、内存与发热的联调优化5.1 先看耗时算子级耗时定位模型在目标机型上能跑起来只是完成了第一步。真正的大头工作是性能调优——这个环节里别凭直觉猜瓶颈一定要用Profiler数据说话。以TensorFlow Lite为例它在Debug模式下可以打印出每个算子占用的推理耗时你能清清楚楚看到时间都花在哪里。我接手过的一个语义分割模型目测以为耗时大头会是最后一层上采样结果Profiler打出来的数据显示真正吃时间的是中间一个看似不起眼的5×5卷积。这就是算子级剖析的价值——经验主义在性能优化里能不碰就不碰。拿到算子耗时表之后优化方向通常集中在几个点上耗时占比最高的算子是不是有可替代的轻量实现比如标准卷积换成深度可分离卷积某一层的输入尺寸是不是明显大于其他层能不能在预处理阶段直接做分辨率压缩模型里有没有冗余的维度变换和张量复制操作这些在端侧访存开销极大能省则省。算子级剖析也要注意测试条件的一致性。手机在充电、高性能模式下和高负载运行下的性能表现差得很多所以做性能测试时固定一个宽容的测试条件同一台机器、同一系统版本、固定充电状态、后台应用清空、散热条件一致。只有这样才能保证前后数据的可比性不会被温度导致的降频干扰判断。5.2 内存复用与并发推理的代价说完耗时看内存。端侧推理框架在运行时会创建大量中间张量默认行为是每做一次推理就申请一批内存用完释放这个逻辑在服务端没什么大问题在移动端就是灾难——没完没了地申请释放会造成内存碎片和GC抖动体现在外部就是卡顿。合理的做法是启用框架提供的内存复用机制。大多数主流推理框架都支持设置一个执行计划或内存池让每层计算复用同一块缓冲区。TensorFlow Lite的Interpreter对象本身就会在多次推理时复用部分工作区但前提是你复用的输入输出张量是同一个对象不要在每次推理时重新创建张量。MNN里有更显式的内存分配器管理可以对Session级别的内存做池化。实际观测下来正确复用内存后推理过程的分配次数能下降几个数量级对GC的触发频率改善非常明显。关于多线程并发推理我要泼一盆冷水移动端大部分推理框架默认只能在单线程下跑开跨线程并发执行多个推理实例参数看起来是并行了实际效果往往适得其反。手机CPU是大小核架构多核并发带来的调度开销、缓存争抢和功耗飙升会让单次推理耗时反而变长。如果你的业务场景是并发处理多个请求更合理的做法是串行化推理或者预创建多个推理实例分摊负载而不是简单堆线程。5.3 发热降频与设备差异处理发热和降频是端侧推理优化里最难处理的一环因为它不单纯是软件层面的问题。CPU、GPU、NPU任何一路长时间高负载运转热量就会累积到机身表面触发系统热管理机制。降频一旦发生推理速度会断崖式下跌。具体的表现是连续跑了几十帧之后推理耗时从30毫秒涨到60毫秒、80毫秒甚至更高。这个坑在实验室里很容易被忽略因为测试跑几十帧就结束了还没到降频的临界点。但真实用户会拿着你的App长时间使用降频几乎是必然会发生的。应对思路有几个层面。首先是硬件选择层面不同SoC对持续推理的耐受差异巨大旗舰芯片降频相对晚、散热更好中低端芯片扛不住几轮高负载推理。所以在做性能测试时一定要纳入低端机型作为底线目标不能只看旗舰机的表现。其次是策略层面推理任务可以适当做限频不追求每帧都实时推理而是通过帧率控制、定时器调度等方式让推理任务有节奏地进行给SoC留出散热喘息的时间。比如视频流场景与其满负荷跑60帧推理不如降为30帧推理把省下来的时间用来做更精细的后处理用户体感反而更好。最后是工程层面推理引擎的线程数设置要克制。四核CPU最大性能模式下的线程数不等于最优线程数很多情况下2到4个线程是功耗与性能的最佳平衡点线程太多纯粹是给功耗预算添堵。这些参数我没有办法给出一个通用值因为不同模型、不同SoC下的最优值差异很大你需要在自己的目标机型上做一轮线程数扫描测试找出曲线拐点。6. 踩坑实录与渐进式落地建议6.1 三个印象深刻的坑做移动端AI部署这么久踩过的坑多到数不过来挑三个印象最深的说说给后来者提个醒。第一个坑是量化后精度分布偏移。当时手头一个文本分类模型整体精度只掉了1个百分点看着一切正常结果上线后用户投诉某类内容频繁误判。一查才发现量化误差集中在样本数比较少的那个类别上——而不是整体掉点。整体指标掩盖了尾部类别的恶化。后来我们改了策略量化验证时不止看整体指标还要分开看每个类别的单类召回率和误判率把尾部分布纳入验收标准。这里也提醒各位量化的影响不是均匀分布的可能对某些子群体特别不友好做量化评估时务必做分层评估。第二个坑是模型体积比预期大得多。有个模型剪枝压缩后理论计算应该压到30MB结果产物还是80MB。排查下来发现模型虽然变小了但Embedding映射表没有跟着压缩占了大部分体积。剪枝、量化通常不会专门处理Embedding表需要单独用矩阵分解或词表裁剪去压。这类问题在NLP模型里很容易碰到图像模型反而少见。第三个坑是硬件加速在某些设备上反噬性能。我们在部分中低端Android机型上做GPU委托测试发现开启GPU委托后推理速度不仅没变快反而比CPU慢将近一倍。原因是这些机型GPU驱动实现有问题算子提交和同步开销远大于计算节省。后来我们学乖了硬件加速默认在高端设备上开启在中低端设备上做运行时检测实测速度没有优势就回退到CPU执行实现一套动态的后端选择逻辑。这个动态回退机制成了我们所有端侧模型的标配。6.2 给团队的部署节奏建议最后聊聊部署节奏。移动端AI部署最忌讳一步到位的思维——用一个超复杂的压缩方案折腾两三个月最后验证完发现就为了省那20MB体积值吗我的建议是分阶段推进。第一阶段先把FP32模型直接部署到端侧跑通体积大点、速度慢点没关系目的是验证推理框架选型是否正确、端侧环境和业务是否匹配。这个阶段不要花时间做压缩能跑起来就行。第二阶段做量化这一项最简单的压缩看精度和速度是否达标。如果达标这个项目就基本落地了不用追求极限压榨。第三阶段只有量化满足不了需求时才引入剪枝和蒸馏。每引入一项技术就要留足验证时间不要一起压在同一个版本里上线。从工程管理角度看移动端模型部署的版本管理也很容易被忽视。模型文件要和代码版本管理分开追踪模型更新要像发布App一样有灰度发布策略。模型体积、性能、精度这几项指标要建立自动化回归测试每次模型更新都要跑一遍防止更新了个模型却把线上性能弄崩了这种低级事故。我自己做了几年端侧部署下来最大的体会是模型压缩和推理框架都不是最难的部分最难的是对整个链路的把控——从数据分布、训练策略、压缩手法、框架选型到端侧适配任何一个环节的失误都会累积到最终用户体验上。希望这篇实战梳理能帮你把链路理清楚少走一些我走过的弯路。