在做端侧AI部署这几年，我越来越觉得“跑通一个模型”和“搞定一个端侧AI产品”之间，隔着的是一整个系统工程的距离。很多人拿到一个新模型，急着转格式、急着调接口，结果一上真机就卡成PPT，或者内存直接爆掉，再或者模型效果在实验室好好的，一上线用户反馈全是误报——这些坑我都踩过，而且每次补救的成本都远高于一开始就把链路设计清楚。
这篇文章我想把自己在端侧AI工程化上沉淀下来的东西做个梳理，核心就四个字：闭环设计。从最开始的模型选型，到中间的系统工程落地，再到上线之后的监控和迭代，这是一条完整的链路，而不是一个个孤立的点。我尽量用实际踩坑的经历来讲，少一点空话，多一点能直接拿去用的思路和参数。
1. 端侧AI的工程定位：为什么选型只是第一步
1.1 端侧AI的“系统复杂度”远超想象
先说一个我自己的体会：端侧AI和云端AI最大的区别，不是算力大小，而是约束的维度完全不同。云端你只要考虑性能上限，GPU不够就加卡，显存不够就扩机器，反正机房里什么都有。端侧不行，你是在一部手机、一个摄像头、一块开发板上做AI，这四个字意味着你要同时面对四项硬性约束：
- 算力约束：端侧芯片的算力有限，哪怕是最新的旗舰级平台，和云端显卡相比也是几个数量级的差距。你不能指望跑一个完整的ResNet或者ViT，更不能让模型把NPU、GPU全部占满，因为设备还要跑系统、跑应用、跑通信。
- 内存约束：端侧的内存是共享的，模型权重占一块、中间张量占一块、系统本身还要占一块。我见过很多次模型在PC上推理好好的，一移植到手机上就OOM，原因就是没做内存规划，模型一加载就把系统内存吃光了。
- 功耗约束：端侧设备大多是电池供电，AI推理是功耗大户。连续高负载推理会让设备发热，触发系统降频，最终导致帧率暴跌，体验直接从“流畅”变成“卡成狗”。功耗问题不只是续航，还直接决定了你模型的可用性上限。
- 兼容性约束：端侧设备的碎片化极其严重，不同厂商、不同芯片、不同SO库版本，都会影响模型的运行表现。你很难在测试机上“一切正常”，到了用户手机上就“到处报错”——这个问题做端侧的人应该都深有体会。
这四个约束凑到一起，意味着你绝对不能像做云端Demo一样，拿到模型就开跑。你需要一条完整的工程链路来管理它们，否则最后上线的一定是一个“玩具”，而不是一个稳定的功能。
1.2 从“模型为中心”转向“系统为中心”
我在早期踩过一个很大的坑：花了很多精力去优化模型本身的精度，用NAS搜结构、用蒸馏提效果，结果拿到真机上一测，推理延迟200多毫秒，帧率直接完蛋。当时第一反应是“这个模型还不够好”，然后又去换更小的模型，结果精度又不够了，陷入了“换模型—精度不够—再换更大的—延迟又不行”的死循环。
后来我才慢慢想明白，端侧AI工程的本质不是“模型精度优先”，而是“系统体验优先”。在这个前提下，模型的精度只是多个权衡维度之一，你需要去优化的是整套系统在设备上的综合表现。同样的模型，在不同的框架、不同的算子实现、不同的内存策略下，运行效果天差地别。比如同一个MobileNet，TFLite和MNN的延迟能差一截；同样的weights，做了通道对齐和没做，Cache命中率完全不一样；同样一段检测逻辑，放在CPU还是放在NPU，功耗能差出一个量级。
所以我后来做端侧方案，首先要求每个成员脑子里都装着一条完整的链路：业务场景 → 模型设计 → 推理框架适配 → 系统集成 → 监控反馈 → 模型再迭代。只有当所有人都理解这个闭环，我们才能真正把一个模型做成一个稳定的产品功能。
2. 模型选型的硬约束：从三维度建立可落地的决策框架
2.1 延迟、内存、精度：三方权衡别想“既要又要”
模型选型是整个闭环的起点，也是最容易拍脑门的地方。很多人上来就盯着“精度最高”的模型，忽略了端侧的硬约束，结果后面工程怎么调都救不回来。我自己的经验是，选型阶段至少要立起三个指标：目标延迟、峰值内存、精度基线，缺一不可。
先说目标延迟。延迟不是随便提的，它取决于你的业务场景。人脸解锁，从检测到比对完成，整个流程延迟绝对不能超过200ms，否则用户就会觉得“卡了一下”；扫码检测类功能，单帧推理起码要跑到30ms级别，才能保证视频流里的实时跟踪；语音唤醒，模型需要常驻后台，单次推理的功耗和延迟更是敏感中的敏感。所以我的建议是，选型第一步不是挑模型，而是先定义好业务对延迟的忍耐底线，再把这个底线换算成模型的限制条件。
然后是峰值内存。峰值内存主要来自两块：模型权重本身，和推理时的中间张量。前者好估算，也算透明：一个FP32的模型，参数量×4字节；量化到INT8后除以4，就是权重占用。后者才是隐藏炸弹。同样是MobileNet的单次推理，显式内存规划做得好与不好，中间张量峰值可能相差2到3倍。我后来做选型一定会要求对方给出“峰值内存预算”，而不是只给“模型大小”，不然等工程集成时才发现内存爆了，返工成本非常高。
精度基线则比较容易理解：你的模型在离线评测集上的表现，至少要高于你业务目标的下限。这里要特别提醒一句，精度基线的计算方式，尽量贴近真实端侧场景。很多公开模型指标是在高分辨率、不压缩、原图上测的，放到端侧摄像头采集的画面里，效果可能掉一个档次，因为端侧往往有压缩、旋转、光照变化等干扰。我的做法是，选型阶段就把公开的评测代码改造成“端侧友好”版本，加入图像缩放、旋转、噪声，这样评估出来的精度才有参考意义。
2.2 经典模型族怎么挑：从体验细节来看
具体到模型的选择，我不打算重复太多榜单上的参数堆砌，因为那些数字和真机感受往往是两回事。我只从工程角度看几类常见选择：
- 轻量级CNN（MobileNetV3 / MobileNetV4 系列）：这是大多数端侧任务的默认起跑点。速度快、框架支持好、量化成熟度高。我个人的体会是，MobileNet家族作为基线模型非常稳，尤其是MobileNetV3-Large 或者V4的中等规格，精度和延迟平衡相对合理，适合作为第一版上线的保守方案。
- 轻量级Transformer（MobileViT / EdgeNeXt 等）：如果你发现CNN在关键任务上精度到顶了，可以考虑这类模型，它们在结构上引入了注意力机制，往往能在相似延迟下拿到比纯CNN更好的精度。但注意，Transformer类模型在端侧推理框架里的支持度参差不齐，算子兼容性、量化支持度、NPU映射方案都要在选型阶段就确认，别等部署时再来看。
- 检测/分割专用模型（YOLO系 / PP-LiteSeg 等）：这类模型往往是任务必选，但它们的优化空间通常在“输入端”。比如YOLO系列的输入分辨率、Anchor 设计、NMS策略，都会显著影响端侧表现。我见过不少团队把YOLOv5s跑在端侧，发现CPU推理根本扛不住，后来换成YOLOv8n + 输入分辨率从640降到416，延迟和精度都平衡了，这就是选型阶段要有“端侧视角”的典型例子。
这里再多说一句：不要迷信“最新SOTA”。很多新模型的优秀指标是基于云端算力的，而且是在TensorFlow/PyTorch原生框架里测出来的。转到端侧后，算子融合、内存分配、NPU调度这些环节会显著拉低实际表现。选型不是说“哪个榜第一选哪个”，而是“在目标设备上实测表现最好的那一个”。
2.3 模型压缩与量化：选型阶段就要考虑的事
模型压缩与量化，严格来说是系统工程的一部分，但它在选型阶段就应该被纳入考量，因为压缩手段直接决定了你选模型的自由度。我常用的三件套是：
- 知识蒸馏：用一个大的教师模型去引导小模型训练，让小模型在保持结构轻量的同时，尽量逼近大模型的精度。这个手段在分类和检测任务上尤其有效。选型阶段就可以规划好“教师模型”和“学生模型”的搭配，这样训练时一次性把蒸馏流程做进去，而不用等模型选完再临时加蒸馏环节。
- 结构性剪枝：把不重要的通道或者注意力头剪掉，减少参数量和计算量。注意，剪枝需要和框架的算子支持配合，有些通道剪完后，框架做不了有效的稀疏加速，等于白剪。所以我建议剪枝前先确认框架对稀疏计算的支持度。
- 量化：端侧部署最常见的是PTQ（训练后量化）和QAT（量化感知训练）。PTQ快，但精度损失风险高，尤其对敏感任务；QAT稳，但需要训练流程配合。从工程效率上讲，我会优先尝试PTQ，如果精度掉太多再切QAT，但选型阶段就要预判“这个算子族能不能量化好”，比如某些激活函数在INT8下精度损失严重，就得提前调整结构。
这部分的实操心得是：压缩不是模型选型完成后的“附加题”，而是选型阶段就该同步做的一个维度。我见过有人选了一个精度非常高的Transformer，然后到了部署阶段发现INT8量化后精度崩得一塌糊涂，最后只能前功尽弃换模型。如果选型阶段就把量化后的精度和延迟一并测出来，整个链路的风险就小很多。
3. 系统工程化的核心环节：框架、调度与内存
3.1 推理框架选型与算子适配
模型选好以后，马上要面对的就是推理框架。端侧目前主流的有TFLite、MNN、NCNN、Core ML、ONNX Runtime，以及各家芯片厂商自带的NPU SDK。框架选型的判断标准，我总结下来无非三点：算子覆盖度、性能表现、生态成熟度。
从我从实际项目中感受到的经验来说：
- TFLite：无论是支持度还是社区还是工具链，成熟度都是最高的。TensorFlow系模型的部署路径最短，量化工具链也很完备，遇到问题有大量文档和帖子可查。如果你团队主用TensorFlow，选TFLite是最平滑的。
- MNN：阿里出品的框架，CPU性能优化做得很极致，尤其在ARM平台上有大量手写汇编优化。如果你的重点平台是安卓和高通芯片，MNN经常能给你惊喜。我见过有几款模型的CPU推理表现，MNN比TFLite快出明显一截。
- NCNN：腾讯出的，移植性很强，轻量级，适配了多种后端，适合做嵌入式平台，比如开发板、工业设备。但它的高级功能和工具链相对TFLite会薄弱一些。
- Core ML：如果你做iOS端，那基本没得选，Core ML是苹果官方主推路径，对ANE（苹果神经引擎）的利用最充分。跨平台的话，虽然也可以接TFLite/MNN，但苹果平台的性能最优解大概率还是Core ML。
还有一个不能忽略的关键点：NPU/GPU/CPU的异构调度。很多端侧推理框架都支持多后端，但默认是“全跑CPU”保守方案。我见过不少团队，模型在CPU上跑得勉强可用，但一旦有复杂任务接入，CPU占用飙升，系统交互卡顿明显。后来我们改成“CPU+GPU/NPU”混合调度，把关键推理任务分流到GPU或NPU上，体验才明显改善。这个调度策略需要在工程阶段设计好，框架只负责给你后端选择的能力，是否切换、何时切换，完全是你自己系统的设计。
3.2 内存策略：峰值控制与复用技巧
内存是端侧AI最容易翻车的地方，而且不像延迟那样能一眼看出来。我自己的经验是，做端侧AI工程，必须把“内存预算表”当成项目的一等公民来维护。每一步推理消耗多少内存、哪一层算子产生了峰值、哪些中间Tensor可以复用，都要清清楚楚。
这里有几个实操技巧：
- 内存复用：推理框架内部大多有内存池机制，可以复用中间张量，减少分配和释放开销。但你做系统集成的时候，自己也要注意：不要每次推理都new一整套输入输出缓冲，尽量在上层就把BufferPool做好，推理时从池子里取。
- 输入输出对齐：很多端侧AI的额外内存爆点不是模型本身，而是预处理和后处理。比如YOLO，需要把摄像头帧先缩放到416×416，再归一化，再排成模型输入的排布。如果你每次都临时分配一个大Bitmap或者中间Buffer，内存峰值会很难看。建议做法是：在初始化阶段就把固定尺寸的缓冲分配好，预处理直接在这块共享内存里做。
- 内存对齐与Cache友好：在ARM CPU上做推理时，张量在内存里的排布方式对性能影响极大。NCHW还是NHWC？是否做了通道对齐？这直接影响Cache命中率。我遇到过一次情况：同一个模型，因为输入张量的内存对齐从4字节改成16字节，推理延迟直接下降了20%多，这就是Cache友好性的力量。平时多做profile，留意一下内存对齐，性价比很高。
内存这块我强烈建议引入“内存峰值监控”，而不是只看模型文件大小。你在集成阶段跑一遍批量推理，把应用的内存曲线拉出来，看看峰值出现在什么阶段，是一开始加载权重，还是某一层推理时，还是后处理阶段。只有定位到具体位置，才能做针对性的优化。
3.3 多线程与功耗调度
端侧AI另一个容易忽略的环节是线程与功耗。框架默认的并发策略往往追求“最小延迟”，也就是把所有能占的CPU核心都占满，但这在端侧是不合适的。因为端侧的任务往往不是孤立存在的，设备同时还在跑渲染、网络、IO等，你如果让AI任务把所有核心占满，就会导致整机卡顿。
我后来引入了“线程预算”机制：在系统初始化时，先确定当前设备的核心数和负载情况，给AI推理任务分配固定数量的线程，并限制在特定核心上。也就是不追求单次推理最快，而是保证“整机用户可感知的流畅度”最优。实测下来，适当降低AI的线程数、提高线程调度优先级，配合一个合理的时间片管理，整体用户体验反而更好，功耗也下降明显。
功耗方面，除了线程调度，你还可以利用框架的“低功耗模式”。很多芯片的NPU在低负载场景下可以降频运行，代价只是单次推理延迟增加一点点，但功耗大幅下降。这个在语音唤醒、后台监控这类常驻场景尤其重要。工程上建议在初始化阶段就开放功耗档位的API，按场景动态切换，而不是一刀切“高性能优先”。
4. 监控设计：上线后你才真正开始面对问题
4.1 为什么要做监控：离线测试永远测不出真实分布
模型上线前的评测再充分，也只是离线条件下的一个快照。真实用户场景里，光照条件、遮挡角度、摄像头模组参数、设备发热情况、系统负载状态，各种变量叠加在一起，一定会有你在测试机上看不到的失效模式。我做了几个端侧项目之后越来越确信，端侧AI的可靠性不是测出来的，而是监控出来的。
举个例子，我们有一个物体识别功能，离线测试集上准确率98%，结果上线一周，从用户反馈后台看实际误识别率却比预期高一倍。后来加了结构化日志分析才发现，问题不是模型本身，而是很多低端机的摄像头在弱光条件下自动启用了降噪，画面涂抹严重，喂给模型的图像质量远低于测试集。这个原因在实验室里很难复现，只有监控数据能告诉你“设备环境里到底发生了什么”。
所以监控不是“出了问题再查的补救工具”，而是端侧AI闭环里和模型本身同等重要的一环。它让你能感知线上分布的变化，并形成下一轮迭代的数据来源。
4.2 端侧监控的指标设计与数据采集
做端侧监控，很容易犯“只采集技术指标”的毛病，比如只记录延迟、帧率、崩溃率。这些当然要，但不是全部。我建议至少分成三类指标来看：
- 性能类：单帧推理延迟（区分P50/P95/P99）、视频流帧率、CPU占用率、峰值内存、功耗等级。为什么特意区分P50和P99？因为端侧设备碎片化，平均值完全没用，你的模型可能在低端机上P99达到了300ms，而P50只有80ms。不为P99做优化，你的体验就永远被低端机拖垮。
- 质量类：业务效果指标，比如识别置信度的分布、误报率、漏报率、空响应率。这类指标最能暴露模型在真实场景下的短板。如果你发现某个时间段的置信度普遍偏低，大多意味着光照或者场景分布有变化，这就是下一轮迭代的信号。
- 用户侧：用户主动行为，比如页面停留时长、功能使用频次、负面反馈上报。这其实是端侧AI最值得看的数据，因为用户并不会像评测集那样配合你，他们会做各种奇怪的操作，这些操作背后就是新的数据资产。
采集方式上我建议分层上报：低频、轻量的统计信息（延迟分布、错误码计数）每次会话结束后聚合上报；高频、重量的原始推理日志（比如输入图特征、置信度分数）则要按采样率上报，比如千分之一。这里有一个合规点需要格外注意：采集任何用户数据都要做脱敏和明确授权，尤其是图像类数据。你可以在端侧直接把敏感区域处理掉再回传，或者干脆在端侧完成统计，只返回聚合结果。这块做不好，再好的监控架构都会变成合规风险。
4.3 排查实录：一个线上误报率飙升的案例
分享一个我印象最深的案例。某版本上线后，后台数据发现夜间时段的误报率飙升，白天完全正常。我们第一反应是夜间的光照变化导致模型效果下降，于是开始排查图像增强、白平衡处理这些环节。但看了日志后发现，出问题的设备有一个共同点：系统升级过相机驱动，夜间模式的处理管线变化了，降噪强度变更大，画面被抹得更狠，喂给模型的图像和训练集差异更明显了。
后来我们把排查流程固化下来：收到“某时段/某机型效果异常”的告警后，先拉三块数据——设备型号分布、系统版本分布、相机参数特征分布，再结合采样上报的图像特征，看是哪个维度发生了分布偏移，最后再做业务侧验证。这套流程比我们以前“翻代码+瞎猜+复现”的效率高太多了。监控的价值就在这里：它不告诉你问题的答案，但能告诉你去哪里找答案。
5. 数据回流与迭代闭环：让模型越用越准
5.1 闭环设计的前提：数据怎么回来
监控做完以后，你就有了一个重要的副产品：真实场景的数据信号。但要把这个信号变成模型迭代的养分，需要闭环设计。闭环的第一关，就是数据怎么合法、合规、高效地回到算法团队手里。
隐私合规这块必须前置，图像数据默认不能回传，能回传也要做模糊化和脱敏。更常见的做法是提取“特征级”信息，比如模型中间层的Embedding，或者统计特征，不依赖原始图像。另一个方案是端侧“联邦式”更新，也就是模型更新时，终端根据本地数据计算出梯度或扰动参数，只把更新的差值回传，再在云端聚合。这个方案工程复杂度高，但是目前在不合规风险的情况下，能做到相对理想的“越用越准”效果。
我自己的经验是：先做好“日志分层”，把日志里的数据划分为：A级（可远程回传）、B级（脱敏后回传）、C级（只留在端侧做本地统计）。A级给监控报警用；B级给模型迭代和测评用；C级只在端侧做分布统计，不回传原始内容。这套方案落地后，整个闭环才真正“转起来”。
5.2 线上验证机制：灰度、A/B与Shadow模式
数据回来了，模型也迭代了，但直接全量上线依然是高风险动作。我在项目里通常会搭三套验证机制：
- Shadow模式（旁路验证）：新模型和旧模型同时在后台跑，但新模型的推理结果不出现在用户界面里，只记录这个结果和旧结果的差异。这个模式适合验证模型替换后的效果差异、性能开销，不用冒任何用户可见的风险，灰度前必跑的环节。
- A/B测试：将用户分组，一部分用旧模型，一部分用新模型，对比业务指标。这是最终的胜负判断，但要注意A/B的前提是分流均匀、样本量足够。端侧设备的碎片化天然会引入变量，所以分组时要对设备档次、系统版本做分层，避免跑偏。
- 灰度发布：按用户比例逐步放量，比如先1%，观察1~2天无异常再升到5%，再观察再升。灰度期间盯紧监控指标，尤其是前文提到的P99延迟、崩溃率和质量类指标。如果灰度过程中任何一个指标突破阈值红线，就会自动熔断回滚，不至于让一个坏版本影响全量用户。
这三套机制合起来，我认为是“闭环”里最关键的验证层。它们的作用不仅是防止新模型出问题，更关键的是积累经验：哪些改动对线上效果好、哪些改动在细节上会坑人，全都沉淀成团队的策略资产。
5.3 迭代节奏：用监控驱动模型更新，而不是靠发布排期
最后聊聊迭代节奏。我见过太多团队把模型更新做成“赶版本”，测完就发，发完再测，没有数据和监控的驱动，纯靠运气。闭环做好了之后，模型迭代应该更像“数据驱动的连续流”：
新数据进来后，先自动进入“挖掘—清洗—标注”管道，标注完成直接进入离线评测基准集，对比新旧模型效果。如果新模型在基准集上质量指标有明显提升，就进入Shadow模式验证；Shadow通过，就放量A/B；A/B赢了，灰度上线。每一步都有数据门禁，不再靠人来拍脑袋“我觉得这次模型没毛病”。
这个流程跑顺之后，迭代周期会明显缩短，而且每一次迭代都不只是“更新模型文件”，而是把模型修改和线上反馈连成了闭环。我也经常和团队讲，端侧AI做得好不好，其实不是看单次模型效果有多SOTA，而是看整个迭代飞轮转得有多快，这才是一个系统工程真正值得追求的目标。
6. 常见问题与排查技巧实录
6.1 真机与模拟器差异巨大
这是端侧AI最大的“坑”之一。模拟器里的CPU指令集、GPU能力、内存带宽和真机差距巨大，尤其ARM架构相关的优化，模拟器上基本看不出效果。我的建议是：所有性能指标必须在至少3台不同档位的真机上测，不要只看模拟器或单一测试机。有条件还可以接一下“云真机”平台，全型号矩阵跑一遍，重点盯P99延迟和内存峰值。
6.2 量化后模型精度“掉点”严重
量化掉点是端侧部署最常见的问题，很多团队在量化后就卡在这里成了钉子户。我的排查步骤是：
- 先用“逐层误差分析工具”定位掉点最严重的层。
- 看这一层用的什么激活函数，是否适合INT8量化，比如某些近似函数在量化域上误差放大。
- 如果只是少数几层有问题，可以用“混合精度量化”，把这几个敏感层留在FP16或FP32，其余全量化，这样性价比最高。
- 如果整体都掉得多，那就建议直接切QAT，在训练阶段让模型去适应量化噪声。
还有个容易被忽略的因素是输入的归一化方式，推理时输入的数值分布和训练时不一致，量化误差会加倍。每次换模型部署前，建议先用一小批真实端侧输入过一遍，对比量化前和量化后的输出差异。
6.3 后台运行时轮询高耗电
后台常驻的端侧AI功能，比如语音唤醒、运动检测，很容易把功耗做爆，然后被系统厂商的省电策略直接杀掉。我的经验是：
- 一定要使用系统最低功耗的唤醒方式，比如传感器的“Always-On”通道，不要用用户态轮询。只在事件到达时才把AI推断“叫醒”。
- 推理时优先选择NPU，因为它相比CPU在低负载时功耗优势明显；推理完成后马上释放VPU/NPU资源，有功耗档位的话切到最低档。
- 实测时注意一个指标叫“平均电流/待机电流”，迭代前后都要横测对比，不然你上了用户的手机后可能直接触发系统的电池优化干掉后台进程。
6.4 排查“内存泄漏”与“性能劣化”
有些端侧AI功能刚开是好的，用着用着越来越卡，大概率不是模型本身的问题，而是内存泄漏或缓存无限膨胀。排查方法：
- 边缘任务运行前后打一次Dump内存快照，对比Heap增长。
- 重点查三个位置：预处理循环是否每次都在新建Bitmap/ByteBuffer；后处理是否在创建大型List而不是复用；推理框架的Session是否每次推理都在创建/销毁。
- 另外要检查是否把高频推理结果放在了“无限Cache”里，比如存放在HashMap里只增不删，这种在长时间运行场景下会逐渐拖垮整机性能。建议对任何缓存都设置容量上限和淘汰策略。
这里也强烈建议在监控体系里加一条“长时间压力测试”的指标，比如连续运行8小时以上，看推理延迟和内存曲线的漂移。很多线上性能问题都是慢漂移导致的，而不是突然爆发的。
6.5 日志上报格式：结构化比人可读更重要
很多团队在日志上报这块比较随意，用字符串拼接，到了云端再做解析，不仅效率低，而且容易出错。我建议上报日志直接用结构化格式（如JSON），并且定义好统一schema，每个字段都带设备ID（脱敏）、模型版本号、框架版本号、推理参数、性能指标这些元数据。这样后续做数据分析和问题回溯的效率会指数级提升。
提示：日志字段版本化，迭代时新增字段要向后兼容，老版本客户端没这个字段也不影响整体统计分析。这看起来是个很小的细节，但真的能救你命。
7. 写在最后的实操体会
讲了这么多，最后聊点个人实操层面的体会。
做端侧AI工程三年多，我最深的感触是：这个领域真正考验人的不是模型有多聪明，而是你对系统约束的理解和对闭环的坚持。模型选型再优秀，没有系统工程落地也是空中楼阁；系统工程做得再好，没有监控和闭环，上线后就是听天由命。只有把选型、部署、监控、回流、迭代这条链路串起来，让每个环节都变得可测量、可决策、可改进，这个“端侧AI系统工程”才算是真正闭环了。
另外有一个小技巧想分享：初期项目别急着上大而全的监控平台，先定义好三个黄金指标——首屏场景延迟P50/P99、崩溃率、核心业务质量指标，就足够支撑第一轮闭环的运转了。随着版本迭代，再逐步增加更细粒度的指标。这是我踩过几次坑之后得出的经验：监控系统本身也是需要“迭代”的，一上来就建几十张报表、几十个告警项，最后大概率都是摆设，没人看。
如果你也在做端侧AI项目，希望这篇文章能帮你少走一些我走过的弯路。端侧AI的工程化路还很长，但从选型到监控的这条闭环链路，是无论如何都值得先走通的。
