1. 端侧AI样机验收到底在验什么端侧AI样机这个词这两年出现的频率越来越高。所谓端侧指的是模型推理不依赖云端服务器直接在本地设备上跑比如手机、开发板、边缘盒子、嵌入式模组。样机则是从原型走向量产之前的最后一版硬件加软件的组合体。验收这件事说白了就是在样机阶段把该暴露的问题全部暴露出来别等到量产之后才发现模型跑不动、发热降频、内存泄漏。我参与过几个端侧AI项目的交付验收踩过的坑不算少。最典型的一次是某图像处理Demo在实验室跑得好好的到了现场连续运行四小时之后帧率直接掉了一半排查了半天才发现是散热设计没跟上芯片温度到了阈值之后自动降频。这种问题如果不在样机阶段抓出来量产之后就是批量召回。所以端侧AI样机的验收跟传统软件测试完全不是一个维度的事情它要同时覆盖硬件、软件、模型、系统集成四个层面。这篇文章面向的是正在做端侧AI产品落地的工程师、项目经理和测试负责人。不管你是刚接触端侧部署的新手还是已经做过几轮交付的老手下面这五项工程检查都能直接拿来当验收清单用。我会把每一项检查背后的逻辑、具体的操作步骤、参数怎么定、常见坑怎么避全部拆开讲清楚。2. 五项工程检查的整体设计思路2.1 为什么是五项而不是十项验收检查项不是越多越好。我见过一些团队搞了几十页的验收清单结果执行的时候根本跑不完最后变成走过场。端侧AI样机的验收核心矛盾在于时间有限、资源有限但需要覆盖的风险面很广。所以检查项的设计原则是——抓住那些一旦出问题就会导致项目失败的维度而不是面面俱到。五项检查分别覆盖算力与模型匹配度、内存与存储边界、功耗与热管理、系统稳定性与异常恢复、端到端业务指标。这五项的逻辑关系是层层递进的。算力和模型匹配是基础跑都跑不动后面不用谈内存和存储是边界条件决定了能不能长时间稳定运行功耗和热管理是端侧特有的约束直接影响到用户体验系统稳定性是工程底线端到端业务指标是最终验收标准。2.2 验收顺序不能乱这五项检查有严格的先后顺序。我试过先测业务指标再测底层性能结果业务指标波动很大根本定位不到原因。正确的顺序应该是从底层往上层走先确认算力够用、模型能跑再确认内存不爆、存储不溢然后看功耗和温度是否可控接着做长时间稳定性压测最后才跑端到端的业务指标。这样每一步都有明确的基线出了问题也能快速定位到是哪个层面的事情。注意验收顺序一旦确定不要因为某个领导想看业务效果就临时调整。底层没验完就跳上去看业务指标数据没有参考价值。2.3 验收环境的搭建原则验收环境要尽量贴近真实使用场景但又要可控。我的做法是搭两套环境一套是实验室环境温度湿度可控供电稳定用来做精确测量和问题复现另一套是模拟现场环境加上真实的散热条件、不稳定的供电、实际的外壳装配用来做长时间运行测试。两套环境的数据对比着看很多问题就藏在这个差异里面。3. 第一项检查算力与模型匹配度验证3.1 算力评估的正确打开方式算力评估不是看芯片手册上写的TOPS数字就完事了。那个数字是理论峰值实际能用到多少取决于内存带宽、算子支持程度、模型结构等多个因素。我一般会分三步走第一步查芯片的实测算力数据找第三方评测或者自己跑基准测试第二步把目标模型转换成芯片支持的格式看转换过程中有多少算子需要回退到CPU第三步实际跑一遍模型看单帧推理延迟和吞吐量。这里有个经验公式可以参考实际可用算力 ≈ 标称算力 × 0.3~0.6。这个系数取决于模型的算子类型卷积为主的模型系数偏高Transformer类的模型系数偏低。比如某款芯片标称4TOPS跑卷积网络可能实际用到1.5~2TOPS跑注意力机制为主的模型可能只有0.8~1.2TOPS。3.2 模型转换与算子兼容性检查模型转换是端侧部署最容易翻车的环节。训练框架导出的模型要经过转换工具变成芯片能执行的格式。这个过程中如果某个算子芯片不支持转换工具会自动把它切回CPU执行或者直接报错。CPU执行的算子会严重拖慢整体速度而且往往不容易发现。检查方法很直接转换完成之后看转换工具输出的日志统计有多少算子跑在NPU上、多少跑在CPU上。如果CPU算子占比超过10%就要警惕了。我遇到过一个案例某检测模型转换后有15%的算子回退到CPU单帧延迟从预期的30毫秒涨到了120毫秒完全达不到实时要求。后来通过替换不支持的算子、调整模型结构把CPU算子占比压到了3%以下延迟才回到正常水平。3.3 实测延迟与吞吐量的标准延迟和吞吐量要分开测。延迟是单次推理的时间吞吐量是单位时间内能处理的请求数。对于实时性要求高的场景比如视频分析延迟比吞吐量更重要对于批量处理的场景吞吐量是核心指标。测试方法准备一组有代表性的输入数据至少100条覆盖各种边界情况。逐条跑推理记录每条的处理时间算出平均值、P95、P99。P99延迟比平均延迟更能反映实际体验因为用户感知到的卡顿往往来自那些慢的请求。我一般要求P99延迟不超过平均延迟的1.5倍如果超过说明系统存在长尾问题需要排查。指标合格标准优秀标准测量方法平均延迟满足业务要求低于业务要求30%100条输入取平均P95延迟不超过平均值的1.3倍不超过平均值的1.2倍排序后取第95条P99延迟不超过平均值的1.5倍不超过平均值的1.3倍排序后取第99条吞吐量满足峰值需求满足峰值需求1.5倍连续跑10分钟统计3.4 算力预留与余量设计样机验收的时候算力不能用到100%。必须留余量因为量产之后可能会有新的需求加进来或者模型需要迭代升级。我的经验是样机阶段算力占用控制在70%以内留30%的余量。如果样机阶段就已经跑到90%以上量产之后稍微加点功能就会崩。实操心得算力余量不是拍脑袋定的。你可以这样估算——未来半年内可能增加的模型层数、可能提升的输入分辨率、可能增加的并行任务数把这些折算成算力需求再加到当前占用上看是否超过芯片能力的80%。4. 第二项检查内存与存储边界测试4.1 内存占用的构成分析端侧设备的内存通常很紧张几百MB到几GB不等。AI模型的内存占用分几块模型权重占一块推理时的中间激活值占一块输入输出缓冲区占一块系统和其他应用占一块。很多人只关注模型权重的大小忽略了中间激活值结果跑起来才发现内存不够。中间激活值的大小跟输入分辨率、batch size直接相关。输入分辨率翻倍激活值可能翻四倍。所以验收的时候要用最大可能的输入尺寸去测而不是用默认尺寸。我一般会做一个内存占用表把各个部分列清楚然后看总占用是否在安全线以内。4.2 内存泄漏的检测方法内存泄漏是端侧AI应用最常见的稳定性问题。表现是运行时间越长内存占用越高最终OOM崩溃。检测方法写一个循环脚本连续跑推理1000次以上每隔100次记录一次内存占用。如果内存占用持续上升基本可以确定有泄漏。泄漏的常见来源推理框架的缓存没有释放、图像缓冲区没有回收、日志文件持续写入。排查的时候可以用内存分析工具看是哪块内存在增长。我遇到过一个案例某推理框架每次推理都会缓存一份输入数据的副本跑了几百次之后内存就爆了。后来在每次推理后手动清空缓存才解决。4.3 存储空间的规划与检查存储空间主要看三块模型文件、日志文件、临时文件。模型文件大小是固定的但日志和临时文件会随着运行时间增长。验收的时候要模拟长时间运行看存储空间是否够用。检查方法设定一个运行时长比如连续运行72小时记录存储空间的变化曲线。如果72小时之后存储占用超过了总空间的70%就要考虑日志轮转或者临时文件清理策略。我一般要求日志文件设置大小上限和保留天数临时文件在每次任务完成后立即清理。4.4 内存与存储的边界条件测试边界条件测试是验收的重头戏。要测的场景包括内存几乎用满时能否正常推理、存储空间不足时能否优雅降级、同时处理多个任务时内存是否够分。这些场景在实验室不一定能复现但可以通过工具模拟。比如用内存限制工具把进程的可用内存限制到刚好够用的水平然后跑推理看是否会崩溃。如果崩溃了说明内存管理不够健壮需要优化。优雅降级的做法包括降低输入分辨率、减少batch size、暂停非关键任务等。5. 第三项检查功耗与热管理实测5.1 功耗测量的正确姿势功耗测量不是看电源上显示的瓦数就完事了。端侧设备的功耗是动态变化的推理时功耗高空闲时功耗低。要测的是不同负载下的功耗曲线以及峰值功耗是否超过了供电能力。测量工具方面可以用功率计串在供电线上也可以用设备自带的功耗监测接口。我一般会测三种状态空闲状态、典型负载、峰值负载。典型负载就是实际业务场景下的平均功耗峰值负载是连续跑推理时的最高功耗。峰值功耗不能超过供电模块额定功率的80%否则会有掉电风险。5.2 热管理的验收标准热管理是端侧AI最容易被忽视的环节。芯片温度过高会触发降频降频之后性能直接打折。验收的时候要测芯片表面温度、环境温度、以及降频触发的时间点。我的验收标准是在25度环境温度下连续跑典型负载2小时芯片温度不超过85度且不触发降频。如果触发了降频要看降频后的性能是否还能满足业务要求。如果降频后性能不达标就要改散热方案比如加散热片、改外壳材质、优化模型降低功耗。测试项合格标准测试条件测量工具空闲功耗低于额定值20%常温常压功率计典型负载功耗低于供电额定80%连续跑业务模型功率计峰值功耗低于供电额定90%连续跑最大模型功率计芯片温度低于85度25度环境2小时热电偶/红外降频触发不触发或降频后达标25度环境2小时性能监控5.3 散热方案的验证方法散热方案验证要在最恶劣的条件下做。什么是恶劣条件环境温度高、通风差、外壳装配紧密。我一般会把样机放在恒温箱里设定40度环境温度跑满载推理看多久触发降频。如果在40度下能坚持1小时不降频那在正常环境下基本没问题。如果散热不达标优化方向有几个一是降低模型功耗比如用更高效的算子、减少计算量二是改善散热路径比如加导热垫、改散热片形状三是动态调频根据温度调整推理频率牺牲一点性能换稳定性。5.4 功耗与性能的平衡策略端侧设备永远面临功耗和性能的取舍。验收的时候要明确业务场景的优先级是续航重要还是响应速度重要如果是电池供电的设备续航优先那就要限制峰值功耗如果是插电设备性能优先那就可以放宽功耗限制。我的做法是做一个功耗性能曲线横轴是功耗纵轴是推理速度找到业务能接受的最低性能对应的功耗点把这个点作为验收基准。这样既保证了业务需求又避免了过度设计。6. 第四项检查系统稳定性与异常恢复6.1 长时间运行稳定性测试长时间运行测试是端侧AI验收的必修课。测试时长至少72小时条件允许的话跑7天。测试期间要持续跑推理任务同时监控内存、温度、功耗、推理延迟等指标。任何一项指标出现异常波动都要记录并排查。我经历过一次7天稳定性测试前6天一切正常第7天凌晨出现了推理延迟飙升。排查发现是系统日志文件写满了磁盘导致推理框架写临时文件失败触发了重试机制。这个问题如果只跑24小时根本发现不了。所以稳定性测试的时长不能打折扣。6.2 异常场景的模拟与恢复异常场景包括突然断电、网络中断、输入数据异常、传感器故障等。验收的时候要逐一模拟这些场景看系统能否优雅处理并恢复。突然断电测试在推理过程中直接拔掉电源然后重新上电看系统能否正常启动并恢复到可用状态。有些设备断电后文件系统损坏启动不了这就是严重问题。解决办法是用只读文件系统或者带掉电保护的文件系统。输入数据异常测试给模型输入全黑图像、超大尺寸图像、损坏的图像文件看系统是否会崩溃。健壮的系统应该能捕获异常并返回错误码而不是直接挂掉。6.3 日志与监控的完备性检查日志是排查问题的生命线。验收的时候要检查日志是否完整、是否可读、是否包含足够的信息。我要求日志至少包含时间戳、推理耗时、内存占用、温度、错误码。如果出了问题看日志就能定位到大概原因。监控方面要有实时的性能面板能看到当前的推理延迟、内存占用、温度等关键指标。如果指标超过阈值要能触发告警。告警方式可以是日志、指示灯、或者推送到管理端。6.4 恢复策略的有效性验证恢复策略包括自动重启、任务重试、降级运行等。验收的时候要验证这些策略是否真的有效。比如模拟推理失败看系统是否会自动重试模拟内存不足看系统是否会降级运行。我遇到过一个案例系统设计了自动重启策略但重启之后模型加载失败因为模型文件在重启过程中损坏了。这就是恢复策略没有考虑周全。正确的做法是模型文件做备份重启时从备份加载或者做文件完整性校验。7. 第五项检查端到端业务指标验收7.1 业务指标的选取原则业务指标要跟实际应用场景挂钩。比如人脸识别场景业务指标是识别准确率和误识率视频分析场景业务指标是帧率和检测精度语音交互场景业务指标是响应延迟和识别准确率。选取原则是可量化、可复现、与用户体验直接相关。我一般会选3到5个核心业务指标不要太多。指标太多会导致验收周期拉长而且很多指标之间是相关的测一个就够了。比如帧率和延迟测了延迟基本就能推断帧率。7.2 测试数据集的设计测试数据集要覆盖真实场景的各种情况。以图像处理为例数据集要包含不同光照条件、不同角度、不同遮挡程度、不同背景复杂度。数据集的数量至少几百条太少的话统计意义不够。数据集的标注要准确。我见过一些项目测试数据集标注错误导致准确率算出来偏低排查了半天才发现是标注的问题。所以验收之前要抽查数据集的标注质量确保标注准确率在99%以上。7.3 指标达标判定与容差业务指标达标判定要有容差。比如要求准确率95%实测94.5%算不算达标我的做法是设定一个容差范围比如±1%。在容差范围内算达标超出容差范围就要整改。容差的设定要跟业务方沟通确认不能自己拍脑袋定。另外要注意指标的统计方法。准确率是取所有测试样本的平均还是取最差场景的准确率我一般要求两个都看平均准确率达标且最差场景的准确率不低于平均值的90%。这样才能保证在各种场景下都有可用的表现。7.4 验收报告的编写要点验收报告要包含测试环境描述、测试方法、测试数据、测试结果、问题列表、结论。测试结果要用表格和图表呈现直观清晰。问题列表要按严重程度排序每个问题要有复现步骤和影响分析。报告的结论部分要明确通过、有条件通过、不通过。有条件通过的情况要列出整改项和整改期限。我一般要求整改项在两周内完成并复测复测通过才算最终验收。验收项权重合格标准实测结果判定算力匹配20%CPU算子占比10%5%通过内存边界20%72小时无泄漏无泄漏通过功耗热管理20%不触发降频未触发通过系统稳定性20%7天无崩溃无崩溃通过业务指标20%准确率95%96.2%通过8. 验收过程中的常见问题与排查技巧8.1 模型跑不起来怎么办模型跑不起来是最常见的问题原因通常有几个模型格式不对、算子不支持、输入尺寸不匹配、内存不够。排查顺序先看错误日志确定是哪一类错误然后检查模型转换步骤确认转换参数是否正确接着检查输入数据的格式和尺寸最后看内存是否够用。我遇到过一个案例模型转换的时候没有指定输入尺寸转换工具用了一个默认尺寸结果实际推理时输入尺寸不匹配直接报错。后来在转换命令里显式指定了输入尺寸才解决。所以转换参数一定要写清楚不要依赖默认值。8.2 性能不达标的排查思路性能不达标要从上往下排查。先看整体延迟确定是推理慢还是前后处理慢。如果是推理慢看是哪个算子慢用性能分析工具定位。如果是前后处理慢看是图像解码慢还是数据拷贝慢。常见原因CPU算子太多、内存拷贝次数太多、线程数设置不合理、输入分辨率太高。优化方向替换不支持的算子、减少内存拷贝、调整线程数、降低输入分辨率。我一般会做一个性能分解表把每个环节的耗时列出来找到瓶颈环节重点优化。8.3 稳定性问题的定位方法稳定性问题最难排查因为往往要跑很久才复现。我的方法是加日志、加监控、做压力测试。日志要记录关键状态的变化监控要能实时看到指标曲线压力测试要模拟各种极端条件。如果问题复现了先看日志确定问题发生的时间点然后看监控曲线确定问题发生前的指标变化最后结合代码分析可能的原因。我遇到过一个内存泄漏问题跑了三天才复现最后通过内存分析工具定位到是某个缓存没有释放。8.4 验收不通过后的整改流程验收不通过不可怕可怕的是整改没有章法。我的整改流程是第一步把问题分类是硬件问题、软件问题还是模型问题第二步评估每个问题的整改难度和周期第三步制定整改计划明确责任人和完成时间第四步整改完成后复测复测通过才算闭环。整改过程中要注意不要引入新的问题。每次修改代码或配置之后要跑一遍回归测试确保之前通过的项目没有被破坏。我一般会维护一个回归测试集每次修改后自动跑一遍。实操心得验收不通过的时候不要急着改代码。先把问题复现出来确定根因再动手改。我见过太多人一看到问题就改改了半天发现改错了地方反而引入了新问题。9. 验收完成后的收尾工作验收通过不代表事情结束了。还有几件收尾工作要做第一把验收过程中发现的所有问题整理成文档包括问题描述、根因分析、解决方案作为知识库沉淀下来第二把验收用的测试脚本、测试数据、配置文件归档方便后续复测第三跟量产团队做交接把样机的状态、已知问题、注意事项交代清楚。我在实际项目中的体会是验收阶段发现的问题越多量产阶段就越顺利。如果验收阶段什么问题都没发现要么是验收做得不够细要么是运气太好。但运气这东西靠不住还是把验收做扎实比较靠谱。最后分享一个小技巧验收的时候找一个不参与项目开发的人来执行验收。开发人员对自己的东西太熟悉了容易忽略一些显而易见的问题。找个局外人来测往往能发现一些意想不到的问题。这个做法我在多个项目里试过效果很好。
