端侧AI这两年从“能跑起来”到“跑得稳、跑得省、跑得准”中间隔着的不是一两个模型压缩技巧而是一整套横切式的工程权衡体系。我最早接触端侧部署是在一个智能门锁项目上当时团队花了三个月把一个人脸检测模型塞进了一颗算力只有0.5 TOPS的芯片里推理速度勉强做到200ms但功耗和发热直接把外壳温度推到了烫手的程度。那次经历让我意识到端侧AI的核心矛盾从来不是“能不能推理”而是“在九大约束同时收紧的情况下你愿意牺牲什么、保住什么”。这篇文章想聊的就是这套横切艺术九大约束怎么理解、八维评测怎么落地、以及为什么端侧AI没有免费午餐。无论你是刚接触端侧部署的工程师还是正在做硬件选型的架构师这些从实际项目里磨出来的判断逻辑应该都能帮你少走几段弯路。1. 端侧AI的九大约束不是清单是一张互相拉扯的网很多人第一次看到“九大约束”这个词会下意识把它当成一份检查清单逐项打勾就完事了。但真正做过端侧部署的人都知道这九个约束之间是互相拉扯的——你放松一个另外两三个立刻恶化。把它们理解成一张网比理解成清单要准确得多。1.1 算力、内存、功耗端侧的铁三角算力、内存、功耗这三个约束我习惯叫它们“端侧铁三角”。它们的关系不是简单的加法而是乘法式的相互制约。算力决定了单位时间能做多少乘加运算内存决定了模型权重和中间激活值能不能放得下功耗则决定了这一切能不能持续跑下去而不触发降频或过热保护。举个具体的例子。假设你有一颗标称1 TOPS算力的NPU理论上跑一个1 GOPS的模型只需要1ms。但实际项目中你会发现推理时间往往是理论值的5到10倍。原因在于内存带宽不够权重加载成了瓶颈或者中间激活值太大频繁在DDR和片上缓存之间搬运数据功耗和延迟同时飙升。我在一个智能摄像头项目里测过同一个模型把中间激活值从DDR搬到片上SRAM之后推理延迟从45ms降到了18ms功耗降低了约30%。这就是铁三角联动的典型表现。注意选型时不要只看NPU的峰值算力一定要问清楚片上缓存大小和内存带宽。峰值算力是理想值缓存和带宽才是决定实际性能的关键。1.2 热设计功耗与持续性能被低估的隐形杀手热设计功耗这个约束在实验室环境里很容易被忽略因为短时间跑分根本看不出问题。但端侧设备是要长时间工作的手机、摄像头、门锁、车载盒子没有一个允许你只跑三分钟就降频。我踩过最惨的一次坑是在一个车载疲劳检测项目上。模型在实验室跑得好好的单帧推理12ms功耗2.8W。装车之后夏天暴晒环境下设备表面温度到了65度芯片触发降频推理时间直接跳到40ms以上帧率从30fps掉到12fps检测逻辑直接失效。后来我们不得不把模型参数量砍掉40%同时把输入分辨率从640降到416才把持续功耗压到1.5W以内。这个经历给我的教训是端侧AI的功耗预算必须按“持续功耗”来算而不是“峰值功耗”。持续功耗的估算方法一般是芯片TDP乘以一个降额系数通常0.6到0.8再减去其他模块的功耗。比如一颗标称3W的芯片实际留给AI推理的持续功耗预算可能只有1.5W到1.8W。1.3 模型精度、延迟、存储用户感知的三条红线精度、延迟、存储这三个约束直接对应终端用户的感知。精度不够用户觉得“这东西不好用”延迟太高用户觉得“卡”存储占用太大用户看到安装包体积就放弃了。这三者之间的权衡非常微妙。降低输入分辨率可以同时降低延迟和存储但精度会掉量化可以降低存储和延迟但精度可能掉得更多剪枝可以降低存储和算力需求但精度损失需要微调来弥补。我在一个翻译笔项目里做过一组对比实验同一个翻译模型FP32精度下BLEU是32.5INT8量化后BLEU降到30.1延迟从280ms降到95ms模型体积从180MB降到46MB。用户实测反馈是INT8版本的翻译质量“基本够用”但响应速度的提升感知非常明显。最终我们选了INT8因为对翻译笔这个品类来说响应速度的权重远高于那2.4个BLEU点。1.4 成本、可靠性、生态决定项目能不能落地的底层约束成本、可靠性、生态这三个约束往往在项目后期才会暴露出来但它们的杀伤力最大。成本决定了你选什么芯片、用什么内存、做多大PCB可靠性决定了设备在高温、低温、振动、电磁干扰环境下能不能稳定工作生态决定了你的模型能不能顺利部署到目标芯片上以及后续维护成本有多高。我见过太多项目模型在GPU服务器上调得好好的到了端侧芯片上发现算子不支持或者支持但性能极差。比如某些NPU对Transformer结构的支持就不如CNN友好注意力机制里的矩阵乘和Softmax可能没有专门优化跑起来效率很低。这时候要么换芯片要么改模型结构要么自己写算子——三条路都有代价。约束维度典型量化指标常见妥协方向对用户体验的影响算力TOPS、MAC利用率降低模型复杂度精度下降内存权重激活值占用量化、剪枝精度下降功耗持续功耗(W)降频、降分辨率延迟增加热设计表面温度(℃)限制持续性能帧率波动精度mAP、BLEU、WER量化、蒸馏直接感知延迟单帧推理(ms)降低分辨率直接感知存储模型体积(MB)量化、剪枝安装意愿成本BOM成本(元)降配芯片性能上限可靠性MTBF、温宽降频保护稳定性生态算子覆盖率换芯片/改模型开发周期这张表不是让你逐项打勾而是让你在每次做取舍的时候能快速定位到“我动了哪个约束会牵连到哪些其他约束”。2. 八维评测把“感觉还行”变成“数据说话”端侧AI项目最容易出现的一种情况是实验室跑分很漂亮实际部署一塌糊涂。原因往往不是模型本身不行而是评测维度太单一。我后来总结了一套八维评测框架每个维度都有明确的测量方法和判断标准目的就是让“能不能上线”这个决策有数据支撑而不是靠感觉。2.1 精度维度不只是看Top-1要看业务指标精度评测最容易犯的错误是只看学术指标Top-1、mAP不看业务指标。学术指标高不代表业务效果好。比如一个人脸检测模型mAP 0.85听起来不错但如果它在小脸、侧脸、遮挡场景下的召回率很低实际业务里就是“经常漏检”。我的做法是先定义业务指标再倒推技术指标。比如智能门锁的人脸识别业务指标是“误识率低于十万分之一通过率高于98%”。倒推到技术指标就是FAR误识率和FRR拒识率的曲线要满足特定工作点。然后在这个工作点上再去测不同光照、角度、遮挡条件下的表现。具体测量方法上我一般会准备三套数据集训练集同分布的测试集看基础精度、业务场景采集的困难样本集看鲁棒性、对抗样本集看安全性。三套数据集的精度差距如果超过15个百分点说明模型的泛化能力有问题需要重新审视训练数据分布。2.2 延迟维度P50不够要看P99和抖动延迟评测最常见的坑是只看平均延迟。平均延迟20ms听起来很好但如果P99延迟是200ms用户每隔几十次就会感受到一次明显卡顿。端侧设备的用户体验对延迟抖动非常敏感尤其是交互类应用。我一般会测四个指标P50延迟、P95延迟、P99延迟、延迟标准差。P50看典型表现P95和P99看最差情况标准差看稳定性。对于实时性要求高的场景比如AR、语音交互P99延迟必须控制在可接受范围内否则就要考虑降级策略。测量方法上要注意区分“纯推理延迟”和“端到端延迟”。纯推理延迟只算模型前向传播的时间端到端延迟包括预处理、推理、后处理、数据传输的全部时间。很多项目在实验室只测纯推理延迟上线后发现端到端延迟是纯推理的3到5倍就是因为预处理和后处理的开销被忽略了。2.3 功耗与热维度持续负载下的真实表现功耗评测的关键是“持续负载”。短时间跑分看不出问题必须让设备在典型业务负载下连续跑30分钟以上记录功耗曲线和温度曲线。我通常会用功率计和热成像仪配合测量。功率计记录整机功耗热成像仪记录芯片表面和外壳温度。重点关注三个时间点启动后1分钟冷机状态、启动后10分钟热平衡初期、启动后30分钟热平衡稳定期。如果30分钟时的功耗比1分钟时高出20%以上或者温度超过芯片规格书里的降频阈值就说明散热设计或功耗预算有问题。提示端侧设备的功耗评测一定要在“最坏场景”下做比如最高环境温度、最大业务负载、最差信号条件。实验室常温常压下的数据参考价值有限。2.4 内存与存储维度峰值占用比平均占用更重要内存评测要看峰值占用不是平均占用。模型推理过程中的内存占用是动态变化的中间激活值在某些层可能会突然膨胀。如果只看平均占用很容易在某个特定输入下触发OOM内存溢出。我的做法是用内存分析工具记录整个推理过程中的内存曲线找到峰值点然后留出至少30%的余量。对于嵌入式设备内存余量留50%都不算多因为系统本身和其他进程也会占用内存。存储维度相对简单主要看模型文件大小和运行时产生的临时文件大小。但要注意某些推理框架会在首次运行时生成缓存文件比如算子编译缓存这些缓存文件可能比模型本身还大。我在一个项目里遇到过模型只有20MB但首次运行后生成的缓存文件有80MB直接把设备的存储空间占满了。2.5 启动与恢复维度冷启动时间决定第一印象启动时间这个维度很容易被忽略但它直接影响用户的第一印象。一个智能设备用户按下开关之后要等5秒才能用和等1秒就能用体验差距是巨大的。启动时间包括系统启动时间、推理框架初始化时间、模型加载时间、首次推理时间。其中模型加载时间往往是大头尤其是大模型。优化方法包括模型文件预加载、内存映射加载、模型分片加载等。恢复维度指的是设备从低功耗状态唤醒后的恢复时间。很多端侧设备为了省电会在空闲时进入休眠状态唤醒后需要重新加载模型或重新初始化推理框架。这个恢复时间如果太长用户会感觉“设备反应慢”。2.6 鲁棒性维度异常输入下的表现鲁棒性评测是看模型在异常输入下的表现。异常输入包括极端光照、遮挡、噪声、模糊、旋转、尺度变化等。端侧设备面对的真实世界远比实验室数据集复杂鲁棒性不够的模型上线后会出现各种“玄学问题”。我一般会做两组测试一组是“渐进退化测试”把输入图像逐步加噪、模糊、降低分辨率看精度下降曲线另一组是“对抗测试”用FGSM、PGD等方法生成对抗样本看模型的防御能力。对于安全相关的应用比如人脸识别对抗测试是必须的。2.7 兼容性与生态维度算子覆盖率和框架支持兼容性评测主要看目标芯片对模型算子的支持情况。我一般会分三步走第一步用芯片厂商提供的模型转换工具跑一遍看有多少算子不支持第二步对不支持的算子看有没有替代方案比如用多个支持的算子组合实现第三步如果替代方案性能太差评估自己写算子的成本。生态维度还包括推理框架的成熟度、社区活跃度、文档完整性、工具链易用性等。这些“软指标”在项目初期影响不大但在项目后期会严重影响开发效率和维护成本。我个人的经验是优先选择生态成熟的芯片和框架哪怕峰值算力低一点综合成本往往更低。2.8 成本维度不只是芯片价格成本评测不能只看芯片价格要看整体BOM成本和开发成本。整体BOM成本包括芯片、内存、存储、电源管理、散热模块、PCB面积等。开发成本包括模型适配、算子开发、调优、测试、维护等。我见过一个项目选了一颗便宜的芯片省了2块钱BOM成本但因为没有现成的算子支持团队花了两个月自己写算子人力成本远超省下的钱。所以成本评测一定要算总账不能只看单颗芯片的价格。评测维度核心指标测量工具/方法达标参考精度业务指标(FAR/FRR)困难样本集对抗集按业务定义延迟P50/P95/P99端到端计时P99业务阈值功耗持续功耗(W)功率计热成像TDP×0.8内存峰值占用(MB)内存分析工具余量30%存储模型缓存(MB)文件系统统计留足系统空间启动冷启动(ms)高速摄像/日志用户感知阈值鲁棒性退化曲线渐进退化对抗下降15%兼容性算子覆盖率转换工具报告90%这八个维度不是孤立的它们之间也有联动。比如降低分辨率可以同时改善延迟、功耗、内存但会恶化精度和鲁棒性。评测的目的就是把这些联动关系量化出来让决策有依据。3. 没有免费午餐端侧AI的权衡方法论“没有免费午餐”这句话在端侧AI领域体现得淋漓尽致。你不可能同时做到高精度、低延迟、低功耗、小存储、低成本。每次优化都是在某个维度上做牺牲换取另一个维度的改善。关键不是“能不能不牺牲”而是“牺牲哪个、牺牲多少、怎么牺牲”。3.1 量化最划算的买卖但有底线量化是端侧AI最常用的优化手段没有之一。FP32到INT8模型体积直接降到四分之一推理速度通常能提升2到4倍功耗也会明显下降。但量化的代价是精度损失而且不同模型对量化的敏感度差异很大。我的一般经验是CNN类模型对INT8量化比较友好精度损失通常在1到3个百分点Transformer类模型对量化更敏感尤其是注意力机制里的Softmax和LayerNorm量化后精度损失可能达到5到10个百分点。对于Transformer通常需要混合精度量化——敏感层保持FP16其他层用INT8。量化的另一个坑是“校准集选择”。量化需要校准集来确定激活值的动态范围校准集如果和实际业务数据分布差异太大量化后的精度会崩。我在一个项目里用过ImageNet的校准集去量化一个工业质检模型结果精度掉了15个百分点后来换成业务数据做校准精度损失控制在2个百分点以内。注意量化校准集必须从业务数据里采样而且要多覆盖困难样本。校准集数量一般500到1000张就够了但分布要广。3.2 剪枝与蒸馏用训练时间换推理时间剪枝和蒸馏是另外两种常见的优化手段。剪枝是去掉模型中不重要的权重或通道蒸馏是用大模型教小模型。两者的共同点是都需要额外的训练或微调用训练时间换推理时间。剪枝的关键是“剪多少”和“怎么剪”。结构化剪枝剪通道、剪层对硬件更友好但精度损失更大非结构化剪枝剪单个权重精度损失小但需要稀疏计算支持很多端侧芯片对稀疏计算的支持并不好。我一般优先考虑结构化剪枝因为端侧硬件的实际收益更明显。蒸馏的关键是“教师模型”和“温度参数”。教师模型不能太强也不能太弱太强了学生学不动太弱了学生学不到东西。温度参数控制软标签的平滑程度温度越高软标签越平滑学生学到的信息越多但太高的温度会让软标签失去区分度。我一般从温度4开始试根据学生模型的收敛情况调整。3.3 分辨率与帧率用户感知最直接的杠杆降低输入分辨率和帧率是最简单粗暴的优化手段也是用户感知最直接的。分辨率从640降到416算力需求降到原来的42%延迟和功耗都会明显改善但小目标的检测精度会下降。帧率从30fps降到15fps算力需求减半但快速运动场景的检测会漏帧。这两个杠杆怎么用取决于业务场景。对于静态场景比如人脸门锁帧率可以低一点分辨率可以高一点对于动态场景比如车载疲劳检测帧率不能太低分辨率可以适当降。我在车载项目里的经验是帧率低于15fps疲劳检测的眨眼识别就会开始漏帧分辨率低于320眼睛区域的细节就不够用了。3.4 模型架构选择从源头决定优化空间模型架构的选择从源头上决定了后续优化的空间。MobileNet、ShuffleNet、EfficientNet-Lite这些专为端侧设计的架构天生就比ResNet、VGG更适合端侧部署。但架构选择不是越轻越好要看业务需求。我的一般原则是如果业务对精度要求极高优先选EfficientNet-Lite系列它的精度和算力平衡做得比较好如果业务对延迟极度敏感优先选MobileNetV3或ShuffleNetV2如果业务需要检测小目标可能需要自定义架构在浅层保留更多细节。Transformer类架构在端侧的应用越来越多但要注意标准Transformer的算力需求随序列长度平方增长端侧部署通常需要做线性注意力或局部注意力的改造。我在一个语音唤醒项目里用过Conformer原始版本在端侧跑不动改成局部注意力之后才能实时运行。3.5 硬件选型算力不是唯一指标硬件选型是端侧AI最关键的决策之一但很多人只看算力。算力确实重要但内存带宽、片上缓存、算子支持、功耗特性同样重要甚至更重要。我的一般选型逻辑是先看算子支持再看内存带宽再看算力最后看功耗和成本。算子支持决定了模型能不能跑内存带宽决定了跑得快不快算力决定了上限功耗和成本决定了能不能落地。这个顺序不能反反了就容易选到“跑分高但跑不动”的芯片。优化手段主要收益主要代价适用场景INT8量化体积↓75%速度↑2-4x精度↓1-3%CNN为主混合精度精度损失小速度提升有限Transformer结构化剪枝算力↓30-50%精度↓2-5%通道冗余高的模型知识蒸馏小模型精度↑训练成本高有教师模型降分辨率算力↓50%小目标精度↓静态场景降帧率算力↓50%动态漏检非实时场景换轻量架构全面优化需重新训练新项目这张表里的“代价”都是典型值实际项目中会有波动。关键是要在项目初期就明确哪些维度是硬约束不能妥协哪些维度是软约束可以妥协。硬约束决定了优化空间的上限软约束决定了优化的优先级。4. 横切视角把约束、评测、权衡串成一条线前面三部分分别讲了九大约束、八维评测和权衡方法论但实际项目中这三者是交织在一起的。横切视角的核心就是不要把它们当成三个独立的阶段而是当成一个持续迭代的闭环。4.1 从业务需求倒推约束优先级项目启动的第一步不是选模型也不是选芯片而是明确业务需求的约束优先级。同样是端侧AI智能门锁和车载疲劳检测的约束优先级完全不同。智能门锁的核心约束是误识率极低安全、功耗极低电池供电、成本极低量大。精度和延迟可以适当妥协但安全性和功耗不能妥协。车载疲劳检测的核心约束是延迟低实时性、鲁棒性高光照变化大、持续性能稳定长时间运行。成本和功耗可以适当妥协但延迟和鲁棒性不能妥协。我一般会用“约束优先级矩阵”来梳理横轴是约束维度纵轴是优先级硬约束/软约束/可妥协每个维度填上具体的量化目标。这个矩阵是后续所有决策的依据。4.2 评测驱动迭代用数据指导优化方向约束优先级明确之后评测就是迭代的驱动力。每做一次优化量化、剪枝、换架构都要重新跑一遍八维评测看哪些维度改善了、哪些维度恶化了、恶化程度是否可接受。我一般会维护一个“评测基线”记录当前版本在所有维度上的表现。每次优化后对比新版本和基线的差异如果某个硬约束维度恶化了这次优化就不能上线如果软约束维度改善了但硬约束维度没变可以考虑上线如果硬约束和软约束都改善了那就是一次成功的优化。这个过程中最容易犯的错误是“只看改善的维度忽略恶化的维度”。比如量化之后速度提升了3倍但精度掉了5个百分点如果精度是硬约束这次量化就不能直接用需要做混合精度或者量化感知训练来弥补精度损失。4.3 常见决策陷阱与规避方法端侧AI项目里有一些反复出现的决策陷阱我踩过几次之后总结了一些规避方法。第一个陷阱是“实验室思维”在实验室环境下调优忽略了真实环境的温度、湿度、电磁干扰、用户行为差异。规避方法是尽早把设备放到真实环境里做长期测试至少跑一周以上。第二个陷阱是“单维度优化”只盯着一个维度优化忽略了其他维度的恶化。规避方法是每次优化都跑完整八维评测不要只看一两个指标。第三个陷阱是“过度优化”为了追求极致的延迟或功耗把精度压到业务不可接受的程度。规避方法是先定义业务可接受的精度下限优化不能突破这个下限。第四个陷阱是“忽略长尾场景”在典型场景下表现很好但在长尾场景下崩溃。规避方法是评测数据集必须包含长尾样本而且长尾样本的权重不能太低。提示端侧AI项目的失败很少是因为模型不够先进更多是因为对约束的理解不够全面、对评测的执行不够严格、对权衡的决策不够理性。5. 几个真实项目的权衡复盘理论讲多了容易空我挑三个不同类型的项目复盘一下当时的权衡决策和实际结果。每个项目的约束优先级不同权衡逻辑也不同但底层方法论是一致的。5.1 智能门锁人脸识别功耗优先的极限压缩这个项目的核心约束是功耗因为门锁是电池供电要求一次充电用半年以上。算力预算只有0.5 TOPS内存只有8MB模型体积必须控制在1MB以内。我们的方案是先用MobileNetV2做骨干然后做结构化剪枝把通道数砍掉一半再用INT8量化最后把输入分辨率降到112×112。最终模型体积0.8MB单帧推理80ms功耗约0.3W。精度方面在业务数据集上的通过率是97.5%误识率低于十万分之一满足业务要求。这个项目的关键决策是“降分辨率”。112×112的分辨率在人脸识别里算很低了但门锁场景下人脸距离固定、角度有限低分辨率的影响可控。如果换成开放场景的人脸识别112×112肯定不够用。5.2 车载疲劳检测延迟和鲁棒性双硬约束这个项目的核心约束是延迟和鲁棒性。延迟要求单帧推理低于30ms鲁棒性要求在各种光照条件下都能稳定检测。功耗和成本相对宽松因为车载设备有持续供电。我们的方案是用EfficientNet-Lite做骨干输入分辨率416×416INT8量化但保留了眼睛区域的FP16精度混合精度。最终单帧推理22ms功耗约2.5W在夜间、逆光、戴眼镜等场景下的检测率都在95%以上。这个项目的关键决策是“混合精度”。眼睛区域的细节对疲劳检测至关重要全INT8量化会导致眼睛状态识别精度下降所以我们对眼睛区域相关的层保持了FP16。代价是推理速度比全INT8慢了约15%但换来了鲁棒性的显著提升。5.3 智能翻译笔响应速度优先的量化取舍这个项目的核心约束是响应速度。翻译笔的使用场景是“即扫即译”用户对延迟非常敏感超过200ms就会觉得“卡”。精度方面翻译质量“基本够用”即可不需要追求极致。我们的方案是用轻量Transformer做翻译模型INT8量化输入序列长度限制在32个token以内。最终单帧推理95ms模型体积46MBBLEU从32.5降到30.1。用户实测反馈是“响应很快翻译质量可以接受”。这个项目的关键决策是“接受精度损失换速度”。2.4个BLEU点的损失在学术上不小但在翻译笔这个品类里响应速度的权重远高于翻译质量的细微差异。如果换成专业翻译场景这个取舍就不成立了。项目类型硬约束关键决策实际结果智能门锁功耗、成本降分辨率剪枝量化0.8MB/80ms/0.3W车载疲劳延迟、鲁棒性混合精度416分辨率22ms/95%检测率翻译笔响应速度INT8量化序列限制95ms/BLEU 30.1这三个项目的共同点是都没有追求“全面最优”而是在硬约束满足的前提下在软约束上做取舍。端侧AI的横切艺术本质上就是这种取舍的艺术。6. 给端侧AI工程师的实操建议最后这部分我想分享一些从实际项目里磨出来的实操建议。这些建议不一定适用于所有场景但至少能帮你避开一些常见的坑。6.1 项目初期的约束梳理清单项目启动时我一般会花半天时间做约束梳理输出一份“约束优先级矩阵”。具体包括列出所有九大约束逐项标注是硬约束、软约束还是可妥协对每个硬约束写出具体的量化目标比如功耗1W延迟50ms对每个软约束写出可接受的波动范围比如精度下降3%标注约束之间的联动关系比如降分辨率会影响精度和鲁棒性和业务方确认约束优先级确保技术目标和业务目标一致这份矩阵不是一次性的项目过程中如果业务需求变化矩阵也要更新。6.2 评测流程的标准化模板评测流程标准化能大幅提升迭代效率。我一般会建一个评测脚本输入是新模型文件输出是八维评测报告。报告包括精度业务指标学术指标三套数据集延迟P50/P95/P99标准差端到端功耗持续30分钟曲线峰值均值内存峰值占用余量存储模型缓存启动冷启动恢复时间鲁棒性退化曲线对抗测试兼容性算子覆盖率这个脚本跑一次大概需要2到4小时但能省下大量人工对比的时间而且数据更客观。6.3 优化手段的优先级排序面对多个优化手段我的一般优先级是量化 剪枝 降分辨率 换架构 蒸馏。量化收益最大、成本最低优先做剪枝次之但需要微调降分辨率简单粗暴但影响精度换架构需要重新训练成本高蒸馏需要教师模型成本最高。当然这个优先级不是绝对的。如果模型对量化极度敏感比如某些Transformer可能要先做架构改造再做量化。如果业务对精度要求极高可能要先做蒸馏再做量化。6.4 硬件选型的避坑要点硬件选型我踩过的坑包括只看算力不看带宽、忽略算子支持、低估散热需求、忽略生态成熟度。避坑要点是一定要拿实际模型去目标芯片上跑一遍不要只看规格书问清楚片上缓存大小和内存带宽这两个比峰值算力更重要确认算子覆盖率不支持的算子要有替代方案散热设计要留余量持续功耗按TDP的60%到80%估算优先选生态成熟的芯片哪怕贵一点6.5 持续迭代的心态建设端侧AI项目很少能一次做到位通常需要多轮迭代。每轮迭代都会发现新的约束、新的问题、新的权衡点。保持“没有免费午餐”的心态很重要不要指望找到一个“完美方案”而是找到一个“在当前约束下最不坏的方案”。我在实际项目里的体会是端侧AI的横切艺术说到底就是“知道自己要什么、知道自己愿意放弃什么、知道怎么验证自己没选错”。这三件事想清楚了项目就不会偏得太远。
端侧AI部署的九大约束与八维评测：没有免费午餐的工程权衡
端侧AI这两年从“能跑起来”到“跑得稳、跑得省、跑得准”中间隔着的不是一两个模型压缩技巧而是一整套横切式的工程权衡体系。我最早接触端侧部署是在一个智能门锁项目上当时团队花了三个月把一个人脸检测模型塞进了一颗算力只有0.5 TOPS的芯片里推理速度勉强做到200ms但功耗和发热直接把外壳温度推到了烫手的程度。那次经历让我意识到端侧AI的核心矛盾从来不是“能不能推理”而是“在九大约束同时收紧的情况下你愿意牺牲什么、保住什么”。这篇文章想聊的就是这套横切艺术九大约束怎么理解、八维评测怎么落地、以及为什么端侧AI没有免费午餐。无论你是刚接触端侧部署的工程师还是正在做硬件选型的架构师这些从实际项目里磨出来的判断逻辑应该都能帮你少走几段弯路。1. 端侧AI的九大约束不是清单是一张互相拉扯的网很多人第一次看到“九大约束”这个词会下意识把它当成一份检查清单逐项打勾就完事了。但真正做过端侧部署的人都知道这九个约束之间是互相拉扯的——你放松一个另外两三个立刻恶化。把它们理解成一张网比理解成清单要准确得多。1.1 算力、内存、功耗端侧的铁三角算力、内存、功耗这三个约束我习惯叫它们“端侧铁三角”。它们的关系不是简单的加法而是乘法式的相互制约。算力决定了单位时间能做多少乘加运算内存决定了模型权重和中间激活值能不能放得下功耗则决定了这一切能不能持续跑下去而不触发降频或过热保护。举个具体的例子。假设你有一颗标称1 TOPS算力的NPU理论上跑一个1 GOPS的模型只需要1ms。但实际项目中你会发现推理时间往往是理论值的5到10倍。原因在于内存带宽不够权重加载成了瓶颈或者中间激活值太大频繁在DDR和片上缓存之间搬运数据功耗和延迟同时飙升。我在一个智能摄像头项目里测过同一个模型把中间激活值从DDR搬到片上SRAM之后推理延迟从45ms降到了18ms功耗降低了约30%。这就是铁三角联动的典型表现。注意选型时不要只看NPU的峰值算力一定要问清楚片上缓存大小和内存带宽。峰值算力是理想值缓存和带宽才是决定实际性能的关键。1.2 热设计功耗与持续性能被低估的隐形杀手热设计功耗这个约束在实验室环境里很容易被忽略因为短时间跑分根本看不出问题。但端侧设备是要长时间工作的手机、摄像头、门锁、车载盒子没有一个允许你只跑三分钟就降频。我踩过最惨的一次坑是在一个车载疲劳检测项目上。模型在实验室跑得好好的单帧推理12ms功耗2.8W。装车之后夏天暴晒环境下设备表面温度到了65度芯片触发降频推理时间直接跳到40ms以上帧率从30fps掉到12fps检测逻辑直接失效。后来我们不得不把模型参数量砍掉40%同时把输入分辨率从640降到416才把持续功耗压到1.5W以内。这个经历给我的教训是端侧AI的功耗预算必须按“持续功耗”来算而不是“峰值功耗”。持续功耗的估算方法一般是芯片TDP乘以一个降额系数通常0.6到0.8再减去其他模块的功耗。比如一颗标称3W的芯片实际留给AI推理的持续功耗预算可能只有1.5W到1.8W。1.3 模型精度、延迟、存储用户感知的三条红线精度、延迟、存储这三个约束直接对应终端用户的感知。精度不够用户觉得“这东西不好用”延迟太高用户觉得“卡”存储占用太大用户看到安装包体积就放弃了。这三者之间的权衡非常微妙。降低输入分辨率可以同时降低延迟和存储但精度会掉量化可以降低存储和延迟但精度可能掉得更多剪枝可以降低存储和算力需求但精度损失需要微调来弥补。我在一个翻译笔项目里做过一组对比实验同一个翻译模型FP32精度下BLEU是32.5INT8量化后BLEU降到30.1延迟从280ms降到95ms模型体积从180MB降到46MB。用户实测反馈是INT8版本的翻译质量“基本够用”但响应速度的提升感知非常明显。最终我们选了INT8因为对翻译笔这个品类来说响应速度的权重远高于那2.4个BLEU点。1.4 成本、可靠性、生态决定项目能不能落地的底层约束成本、可靠性、生态这三个约束往往在项目后期才会暴露出来但它们的杀伤力最大。成本决定了你选什么芯片、用什么内存、做多大PCB可靠性决定了设备在高温、低温、振动、电磁干扰环境下能不能稳定工作生态决定了你的模型能不能顺利部署到目标芯片上以及后续维护成本有多高。我见过太多项目模型在GPU服务器上调得好好的到了端侧芯片上发现算子不支持或者支持但性能极差。比如某些NPU对Transformer结构的支持就不如CNN友好注意力机制里的矩阵乘和Softmax可能没有专门优化跑起来效率很低。这时候要么换芯片要么改模型结构要么自己写算子——三条路都有代价。约束维度典型量化指标常见妥协方向对用户体验的影响算力TOPS、MAC利用率降低模型复杂度精度下降内存权重激活值占用量化、剪枝精度下降功耗持续功耗(W)降频、降分辨率延迟增加热设计表面温度(℃)限制持续性能帧率波动精度mAP、BLEU、WER量化、蒸馏直接感知延迟单帧推理(ms)降低分辨率直接感知存储模型体积(MB)量化、剪枝安装意愿成本BOM成本(元)降配芯片性能上限可靠性MTBF、温宽降频保护稳定性生态算子覆盖率换芯片/改模型开发周期这张表不是让你逐项打勾而是让你在每次做取舍的时候能快速定位到“我动了哪个约束会牵连到哪些其他约束”。2. 八维评测把“感觉还行”变成“数据说话”端侧AI项目最容易出现的一种情况是实验室跑分很漂亮实际部署一塌糊涂。原因往往不是模型本身不行而是评测维度太单一。我后来总结了一套八维评测框架每个维度都有明确的测量方法和判断标准目的就是让“能不能上线”这个决策有数据支撑而不是靠感觉。2.1 精度维度不只是看Top-1要看业务指标精度评测最容易犯的错误是只看学术指标Top-1、mAP不看业务指标。学术指标高不代表业务效果好。比如一个人脸检测模型mAP 0.85听起来不错但如果它在小脸、侧脸、遮挡场景下的召回率很低实际业务里就是“经常漏检”。我的做法是先定义业务指标再倒推技术指标。比如智能门锁的人脸识别业务指标是“误识率低于十万分之一通过率高于98%”。倒推到技术指标就是FAR误识率和FRR拒识率的曲线要满足特定工作点。然后在这个工作点上再去测不同光照、角度、遮挡条件下的表现。具体测量方法上我一般会准备三套数据集训练集同分布的测试集看基础精度、业务场景采集的困难样本集看鲁棒性、对抗样本集看安全性。三套数据集的精度差距如果超过15个百分点说明模型的泛化能力有问题需要重新审视训练数据分布。2.2 延迟维度P50不够要看P99和抖动延迟评测最常见的坑是只看平均延迟。平均延迟20ms听起来很好但如果P99延迟是200ms用户每隔几十次就会感受到一次明显卡顿。端侧设备的用户体验对延迟抖动非常敏感尤其是交互类应用。我一般会测四个指标P50延迟、P95延迟、P99延迟、延迟标准差。P50看典型表现P95和P99看最差情况标准差看稳定性。对于实时性要求高的场景比如AR、语音交互P99延迟必须控制在可接受范围内否则就要考虑降级策略。测量方法上要注意区分“纯推理延迟”和“端到端延迟”。纯推理延迟只算模型前向传播的时间端到端延迟包括预处理、推理、后处理、数据传输的全部时间。很多项目在实验室只测纯推理延迟上线后发现端到端延迟是纯推理的3到5倍就是因为预处理和后处理的开销被忽略了。2.3 功耗与热维度持续负载下的真实表现功耗评测的关键是“持续负载”。短时间跑分看不出问题必须让设备在典型业务负载下连续跑30分钟以上记录功耗曲线和温度曲线。我通常会用功率计和热成像仪配合测量。功率计记录整机功耗热成像仪记录芯片表面和外壳温度。重点关注三个时间点启动后1分钟冷机状态、启动后10分钟热平衡初期、启动后30分钟热平衡稳定期。如果30分钟时的功耗比1分钟时高出20%以上或者温度超过芯片规格书里的降频阈值就说明散热设计或功耗预算有问题。提示端侧设备的功耗评测一定要在“最坏场景”下做比如最高环境温度、最大业务负载、最差信号条件。实验室常温常压下的数据参考价值有限。2.4 内存与存储维度峰值占用比平均占用更重要内存评测要看峰值占用不是平均占用。模型推理过程中的内存占用是动态变化的中间激活值在某些层可能会突然膨胀。如果只看平均占用很容易在某个特定输入下触发OOM内存溢出。我的做法是用内存分析工具记录整个推理过程中的内存曲线找到峰值点然后留出至少30%的余量。对于嵌入式设备内存余量留50%都不算多因为系统本身和其他进程也会占用内存。存储维度相对简单主要看模型文件大小和运行时产生的临时文件大小。但要注意某些推理框架会在首次运行时生成缓存文件比如算子编译缓存这些缓存文件可能比模型本身还大。我在一个项目里遇到过模型只有20MB但首次运行后生成的缓存文件有80MB直接把设备的存储空间占满了。2.5 启动与恢复维度冷启动时间决定第一印象启动时间这个维度很容易被忽略但它直接影响用户的第一印象。一个智能设备用户按下开关之后要等5秒才能用和等1秒就能用体验差距是巨大的。启动时间包括系统启动时间、推理框架初始化时间、模型加载时间、首次推理时间。其中模型加载时间往往是大头尤其是大模型。优化方法包括模型文件预加载、内存映射加载、模型分片加载等。恢复维度指的是设备从低功耗状态唤醒后的恢复时间。很多端侧设备为了省电会在空闲时进入休眠状态唤醒后需要重新加载模型或重新初始化推理框架。这个恢复时间如果太长用户会感觉“设备反应慢”。2.6 鲁棒性维度异常输入下的表现鲁棒性评测是看模型在异常输入下的表现。异常输入包括极端光照、遮挡、噪声、模糊、旋转、尺度变化等。端侧设备面对的真实世界远比实验室数据集复杂鲁棒性不够的模型上线后会出现各种“玄学问题”。我一般会做两组测试一组是“渐进退化测试”把输入图像逐步加噪、模糊、降低分辨率看精度下降曲线另一组是“对抗测试”用FGSM、PGD等方法生成对抗样本看模型的防御能力。对于安全相关的应用比如人脸识别对抗测试是必须的。2.7 兼容性与生态维度算子覆盖率和框架支持兼容性评测主要看目标芯片对模型算子的支持情况。我一般会分三步走第一步用芯片厂商提供的模型转换工具跑一遍看有多少算子不支持第二步对不支持的算子看有没有替代方案比如用多个支持的算子组合实现第三步如果替代方案性能太差评估自己写算子的成本。生态维度还包括推理框架的成熟度、社区活跃度、文档完整性、工具链易用性等。这些“软指标”在项目初期影响不大但在项目后期会严重影响开发效率和维护成本。我个人的经验是优先选择生态成熟的芯片和框架哪怕峰值算力低一点综合成本往往更低。2.8 成本维度不只是芯片价格成本评测不能只看芯片价格要看整体BOM成本和开发成本。整体BOM成本包括芯片、内存、存储、电源管理、散热模块、PCB面积等。开发成本包括模型适配、算子开发、调优、测试、维护等。我见过一个项目选了一颗便宜的芯片省了2块钱BOM成本但因为没有现成的算子支持团队花了两个月自己写算子人力成本远超省下的钱。所以成本评测一定要算总账不能只看单颗芯片的价格。评测维度核心指标测量工具/方法达标参考精度业务指标(FAR/FRR)困难样本集对抗集按业务定义延迟P50/P95/P99端到端计时P99业务阈值功耗持续功耗(W)功率计热成像TDP×0.8内存峰值占用(MB)内存分析工具余量30%存储模型缓存(MB)文件系统统计留足系统空间启动冷启动(ms)高速摄像/日志用户感知阈值鲁棒性退化曲线渐进退化对抗下降15%兼容性算子覆盖率转换工具报告90%这八个维度不是孤立的它们之间也有联动。比如降低分辨率可以同时改善延迟、功耗、内存但会恶化精度和鲁棒性。评测的目的就是把这些联动关系量化出来让决策有依据。3. 没有免费午餐端侧AI的权衡方法论“没有免费午餐”这句话在端侧AI领域体现得淋漓尽致。你不可能同时做到高精度、低延迟、低功耗、小存储、低成本。每次优化都是在某个维度上做牺牲换取另一个维度的改善。关键不是“能不能不牺牲”而是“牺牲哪个、牺牲多少、怎么牺牲”。3.1 量化最划算的买卖但有底线量化是端侧AI最常用的优化手段没有之一。FP32到INT8模型体积直接降到四分之一推理速度通常能提升2到4倍功耗也会明显下降。但量化的代价是精度损失而且不同模型对量化的敏感度差异很大。我的一般经验是CNN类模型对INT8量化比较友好精度损失通常在1到3个百分点Transformer类模型对量化更敏感尤其是注意力机制里的Softmax和LayerNorm量化后精度损失可能达到5到10个百分点。对于Transformer通常需要混合精度量化——敏感层保持FP16其他层用INT8。量化的另一个坑是“校准集选择”。量化需要校准集来确定激活值的动态范围校准集如果和实际业务数据分布差异太大量化后的精度会崩。我在一个项目里用过ImageNet的校准集去量化一个工业质检模型结果精度掉了15个百分点后来换成业务数据做校准精度损失控制在2个百分点以内。注意量化校准集必须从业务数据里采样而且要多覆盖困难样本。校准集数量一般500到1000张就够了但分布要广。3.2 剪枝与蒸馏用训练时间换推理时间剪枝和蒸馏是另外两种常见的优化手段。剪枝是去掉模型中不重要的权重或通道蒸馏是用大模型教小模型。两者的共同点是都需要额外的训练或微调用训练时间换推理时间。剪枝的关键是“剪多少”和“怎么剪”。结构化剪枝剪通道、剪层对硬件更友好但精度损失更大非结构化剪枝剪单个权重精度损失小但需要稀疏计算支持很多端侧芯片对稀疏计算的支持并不好。我一般优先考虑结构化剪枝因为端侧硬件的实际收益更明显。蒸馏的关键是“教师模型”和“温度参数”。教师模型不能太强也不能太弱太强了学生学不动太弱了学生学不到东西。温度参数控制软标签的平滑程度温度越高软标签越平滑学生学到的信息越多但太高的温度会让软标签失去区分度。我一般从温度4开始试根据学生模型的收敛情况调整。3.3 分辨率与帧率用户感知最直接的杠杆降低输入分辨率和帧率是最简单粗暴的优化手段也是用户感知最直接的。分辨率从640降到416算力需求降到原来的42%延迟和功耗都会明显改善但小目标的检测精度会下降。帧率从30fps降到15fps算力需求减半但快速运动场景的检测会漏帧。这两个杠杆怎么用取决于业务场景。对于静态场景比如人脸门锁帧率可以低一点分辨率可以高一点对于动态场景比如车载疲劳检测帧率不能太低分辨率可以适当降。我在车载项目里的经验是帧率低于15fps疲劳检测的眨眼识别就会开始漏帧分辨率低于320眼睛区域的细节就不够用了。3.4 模型架构选择从源头决定优化空间模型架构的选择从源头上决定了后续优化的空间。MobileNet、ShuffleNet、EfficientNet-Lite这些专为端侧设计的架构天生就比ResNet、VGG更适合端侧部署。但架构选择不是越轻越好要看业务需求。我的一般原则是如果业务对精度要求极高优先选EfficientNet-Lite系列它的精度和算力平衡做得比较好如果业务对延迟极度敏感优先选MobileNetV3或ShuffleNetV2如果业务需要检测小目标可能需要自定义架构在浅层保留更多细节。Transformer类架构在端侧的应用越来越多但要注意标准Transformer的算力需求随序列长度平方增长端侧部署通常需要做线性注意力或局部注意力的改造。我在一个语音唤醒项目里用过Conformer原始版本在端侧跑不动改成局部注意力之后才能实时运行。3.5 硬件选型算力不是唯一指标硬件选型是端侧AI最关键的决策之一但很多人只看算力。算力确实重要但内存带宽、片上缓存、算子支持、功耗特性同样重要甚至更重要。我的一般选型逻辑是先看算子支持再看内存带宽再看算力最后看功耗和成本。算子支持决定了模型能不能跑内存带宽决定了跑得快不快算力决定了上限功耗和成本决定了能不能落地。这个顺序不能反反了就容易选到“跑分高但跑不动”的芯片。优化手段主要收益主要代价适用场景INT8量化体积↓75%速度↑2-4x精度↓1-3%CNN为主混合精度精度损失小速度提升有限Transformer结构化剪枝算力↓30-50%精度↓2-5%通道冗余高的模型知识蒸馏小模型精度↑训练成本高有教师模型降分辨率算力↓50%小目标精度↓静态场景降帧率算力↓50%动态漏检非实时场景换轻量架构全面优化需重新训练新项目这张表里的“代价”都是典型值实际项目中会有波动。关键是要在项目初期就明确哪些维度是硬约束不能妥协哪些维度是软约束可以妥协。硬约束决定了优化空间的上限软约束决定了优化的优先级。4. 横切视角把约束、评测、权衡串成一条线前面三部分分别讲了九大约束、八维评测和权衡方法论但实际项目中这三者是交织在一起的。横切视角的核心就是不要把它们当成三个独立的阶段而是当成一个持续迭代的闭环。4.1 从业务需求倒推约束优先级项目启动的第一步不是选模型也不是选芯片而是明确业务需求的约束优先级。同样是端侧AI智能门锁和车载疲劳检测的约束优先级完全不同。智能门锁的核心约束是误识率极低安全、功耗极低电池供电、成本极低量大。精度和延迟可以适当妥协但安全性和功耗不能妥协。车载疲劳检测的核心约束是延迟低实时性、鲁棒性高光照变化大、持续性能稳定长时间运行。成本和功耗可以适当妥协但延迟和鲁棒性不能妥协。我一般会用“约束优先级矩阵”来梳理横轴是约束维度纵轴是优先级硬约束/软约束/可妥协每个维度填上具体的量化目标。这个矩阵是后续所有决策的依据。4.2 评测驱动迭代用数据指导优化方向约束优先级明确之后评测就是迭代的驱动力。每做一次优化量化、剪枝、换架构都要重新跑一遍八维评测看哪些维度改善了、哪些维度恶化了、恶化程度是否可接受。我一般会维护一个“评测基线”记录当前版本在所有维度上的表现。每次优化后对比新版本和基线的差异如果某个硬约束维度恶化了这次优化就不能上线如果软约束维度改善了但硬约束维度没变可以考虑上线如果硬约束和软约束都改善了那就是一次成功的优化。这个过程中最容易犯的错误是“只看改善的维度忽略恶化的维度”。比如量化之后速度提升了3倍但精度掉了5个百分点如果精度是硬约束这次量化就不能直接用需要做混合精度或者量化感知训练来弥补精度损失。4.3 常见决策陷阱与规避方法端侧AI项目里有一些反复出现的决策陷阱我踩过几次之后总结了一些规避方法。第一个陷阱是“实验室思维”在实验室环境下调优忽略了真实环境的温度、湿度、电磁干扰、用户行为差异。规避方法是尽早把设备放到真实环境里做长期测试至少跑一周以上。第二个陷阱是“单维度优化”只盯着一个维度优化忽略了其他维度的恶化。规避方法是每次优化都跑完整八维评测不要只看一两个指标。第三个陷阱是“过度优化”为了追求极致的延迟或功耗把精度压到业务不可接受的程度。规避方法是先定义业务可接受的精度下限优化不能突破这个下限。第四个陷阱是“忽略长尾场景”在典型场景下表现很好但在长尾场景下崩溃。规避方法是评测数据集必须包含长尾样本而且长尾样本的权重不能太低。提示端侧AI项目的失败很少是因为模型不够先进更多是因为对约束的理解不够全面、对评测的执行不够严格、对权衡的决策不够理性。5. 几个真实项目的权衡复盘理论讲多了容易空我挑三个不同类型的项目复盘一下当时的权衡决策和实际结果。每个项目的约束优先级不同权衡逻辑也不同但底层方法论是一致的。5.1 智能门锁人脸识别功耗优先的极限压缩这个项目的核心约束是功耗因为门锁是电池供电要求一次充电用半年以上。算力预算只有0.5 TOPS内存只有8MB模型体积必须控制在1MB以内。我们的方案是先用MobileNetV2做骨干然后做结构化剪枝把通道数砍掉一半再用INT8量化最后把输入分辨率降到112×112。最终模型体积0.8MB单帧推理80ms功耗约0.3W。精度方面在业务数据集上的通过率是97.5%误识率低于十万分之一满足业务要求。这个项目的关键决策是“降分辨率”。112×112的分辨率在人脸识别里算很低了但门锁场景下人脸距离固定、角度有限低分辨率的影响可控。如果换成开放场景的人脸识别112×112肯定不够用。5.2 车载疲劳检测延迟和鲁棒性双硬约束这个项目的核心约束是延迟和鲁棒性。延迟要求单帧推理低于30ms鲁棒性要求在各种光照条件下都能稳定检测。功耗和成本相对宽松因为车载设备有持续供电。我们的方案是用EfficientNet-Lite做骨干输入分辨率416×416INT8量化但保留了眼睛区域的FP16精度混合精度。最终单帧推理22ms功耗约2.5W在夜间、逆光、戴眼镜等场景下的检测率都在95%以上。这个项目的关键决策是“混合精度”。眼睛区域的细节对疲劳检测至关重要全INT8量化会导致眼睛状态识别精度下降所以我们对眼睛区域相关的层保持了FP16。代价是推理速度比全INT8慢了约15%但换来了鲁棒性的显著提升。5.3 智能翻译笔响应速度优先的量化取舍这个项目的核心约束是响应速度。翻译笔的使用场景是“即扫即译”用户对延迟非常敏感超过200ms就会觉得“卡”。精度方面翻译质量“基本够用”即可不需要追求极致。我们的方案是用轻量Transformer做翻译模型INT8量化输入序列长度限制在32个token以内。最终单帧推理95ms模型体积46MBBLEU从32.5降到30.1。用户实测反馈是“响应很快翻译质量可以接受”。这个项目的关键决策是“接受精度损失换速度”。2.4个BLEU点的损失在学术上不小但在翻译笔这个品类里响应速度的权重远高于翻译质量的细微差异。如果换成专业翻译场景这个取舍就不成立了。项目类型硬约束关键决策实际结果智能门锁功耗、成本降分辨率剪枝量化0.8MB/80ms/0.3W车载疲劳延迟、鲁棒性混合精度416分辨率22ms/95%检测率翻译笔响应速度INT8量化序列限制95ms/BLEU 30.1这三个项目的共同点是都没有追求“全面最优”而是在硬约束满足的前提下在软约束上做取舍。端侧AI的横切艺术本质上就是这种取舍的艺术。6. 给端侧AI工程师的实操建议最后这部分我想分享一些从实际项目里磨出来的实操建议。这些建议不一定适用于所有场景但至少能帮你避开一些常见的坑。6.1 项目初期的约束梳理清单项目启动时我一般会花半天时间做约束梳理输出一份“约束优先级矩阵”。具体包括列出所有九大约束逐项标注是硬约束、软约束还是可妥协对每个硬约束写出具体的量化目标比如功耗1W延迟50ms对每个软约束写出可接受的波动范围比如精度下降3%标注约束之间的联动关系比如降分辨率会影响精度和鲁棒性和业务方确认约束优先级确保技术目标和业务目标一致这份矩阵不是一次性的项目过程中如果业务需求变化矩阵也要更新。6.2 评测流程的标准化模板评测流程标准化能大幅提升迭代效率。我一般会建一个评测脚本输入是新模型文件输出是八维评测报告。报告包括精度业务指标学术指标三套数据集延迟P50/P95/P99标准差端到端功耗持续30分钟曲线峰值均值内存峰值占用余量存储模型缓存启动冷启动恢复时间鲁棒性退化曲线对抗测试兼容性算子覆盖率这个脚本跑一次大概需要2到4小时但能省下大量人工对比的时间而且数据更客观。6.3 优化手段的优先级排序面对多个优化手段我的一般优先级是量化 剪枝 降分辨率 换架构 蒸馏。量化收益最大、成本最低优先做剪枝次之但需要微调降分辨率简单粗暴但影响精度换架构需要重新训练成本高蒸馏需要教师模型成本最高。当然这个优先级不是绝对的。如果模型对量化极度敏感比如某些Transformer可能要先做架构改造再做量化。如果业务对精度要求极高可能要先做蒸馏再做量化。6.4 硬件选型的避坑要点硬件选型我踩过的坑包括只看算力不看带宽、忽略算子支持、低估散热需求、忽略生态成熟度。避坑要点是一定要拿实际模型去目标芯片上跑一遍不要只看规格书问清楚片上缓存大小和内存带宽这两个比峰值算力更重要确认算子覆盖率不支持的算子要有替代方案散热设计要留余量持续功耗按TDP的60%到80%估算优先选生态成熟的芯片哪怕贵一点6.5 持续迭代的心态建设端侧AI项目很少能一次做到位通常需要多轮迭代。每轮迭代都会发现新的约束、新的问题、新的权衡点。保持“没有免费午餐”的心态很重要不要指望找到一个“完美方案”而是找到一个“在当前约束下最不坏的方案”。我在实际项目里的体会是端侧AI的横切艺术说到底就是“知道自己要什么、知道自己愿意放弃什么、知道怎么验证自己没选错”。这三件事想清楚了项目就不会偏得太远。
