企业官网建设流程全解析

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 Lite；Android和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一样有灰度发布策略。模型体积、性能、精度这几项指标要建立自动化回归测试，每次模型更新都要跑一遍，防止"更新了个模型却把线上性能弄崩了"这种低级事故。

我自己做了几年端侧部署下来，最大的体会是：模型压缩和推理框架都不是最难的部分，最难的是对整个链路的把控——从数据分布、训练策略、压缩手法、框架选型到端侧适配，任何一个环节的失误都会累积到最终用户体验上。希望这篇实战梳理能帮你把链路理清楚，少走一些我走过的弯路。