搞端侧 AI 的都知道样机验收永远比开发更难做。我前后经手过七八款带 NPU 的样机从摄像头模组到工业质检设备都碰过踩过的坑足以攒成一箩筐。这几年团队沉淀了一套验收方法论内部叫“超维方程”核心就一句话别让样机在“能跑”的状态下蒙混过关要把每一项能力用工程手段量化出来。这篇文章就把其中最关键的“五项工程检查”完整拆给你每一项都讲清楚做什么、怎么做、判定标准是什么以及哪些坑是我实测过才发现的。这套方法不绑定任何芯片平台也不限定模型结构适合所有正在做或者准备做端侧 AI 项目的人。不管你是刚拿到第一块开发板还是已经面临量产前的最终验收这套检查框架都可以直接拿过去用。文章不会扯太多理论尽量用项目里的真实场景说话。1. 端侧 AI 样机验收到底在验什么1.1 先看清楚端侧 AI 和云侧 AI 是两套验收逻辑端侧 AI 最核心的价值是低延迟、数据不出设备、断网可用。一套人脸识别如果跑在云端理想状态下往返也要 200ms 以上放到端侧可以做到 30ms 以内。但这个优势换来的是硬约束计算资源有限、内存有限、功耗有限而且没有随时扩容的弹性。云侧 AI 出问题可以快速加机器、重跑训练任务、灰度更新模型。端侧 AI 一旦部署出去模型迭代只能靠 OTA硬件算力就那么多跑不动的模型就是跑不动。所以端侧样机验收验的不只是“这台设备能不能跑一个 demo”而是“这台设备在未来两三年里能不能稳定承载指定业务”。传统硬件验收通常是功能、性能、可靠性三大块这套流程在端侧 AI 场景下不够用。端侧 AI 样机在这三块之外还叠加了模型、算法、推理引擎、算子、量化精度这一整条软栈。单纯照搬传统流程很容易漏掉真正的瓶颈。1.2 “能跑”和“能交付”之间隔着五道工程检查我们复盘了团队内外很多失败项目发现样机阶段被放过的问题高度集中在五个维度算力达不到预期、模型部署链路不通、内存与功耗撑不住、长稳运行不可靠、业务效果不达标。超维方程做的事情就是把这五个维度变成五道显式工程检查算力实测与性能基准模型部署链路与精度验证内存占用与功耗热设计长稳压力与异常恢复业务效果与端云协同每一道检查都有明确的输入、操作步骤和判定基线最终合成一个“可交付”或“不可交付”的结论。下面逐个展开。2. 超维方程五项工程检查怎么落地2.1 算力实测与性能基准别相信手册上的 TOPS端侧芯片常用 TOPS 标称算力这是理论峰值。但实际跑模型时算子调度、内存搬运、带宽争抢都会让有效算力大幅缩水。某款标称 4 TOPS 的平台我们拿真实检测模型实测有效吞吐只有 2.3 TOPS。差距不是 NPU 本身算不动而是数据喂给 NPU 的过程消耗了大量时间。所以第一项检查不看 TOPS看三条用厂商基准工具测的峰值算力只做参考用真实模型加真实预处理管线测端到端延迟预处理、推理、后处理全算进去连续跑 1000 帧统计延迟分布重点看 p50、p95、p99p50 决定平均体验p99 决定最差体验。如果 p99 是 p50 的三倍以上说明系统存在严重抖动。这种抖动多半来自内存带宽不足、CPU 调频策略保守或者推理线程优先级被抢占。验收时不能只看平均帧率就完事延迟分布必须记录下来。还要测不同输入尺寸下的表现。比如目标分辨率 1920×1080 能跑 30fps切到 4K 输入直接掉到 8fps这种性能悬崖在真实场景里非常常见。如果你预判业务未来会升级分辨率样机阶段就一定要把尺寸梯度测全。记录模板可以长这样检查项标称值实测值判定NPU 峰值算力4 TOPS2.3 TOPS 有效需优化数据搬运端到端延迟 p50不高于 40ms36ms通过端到端延迟 p99不高于 80ms85ms不通过排查抖动1080p 帧率30fps30fps通过4K 帧率15fps8fps不通过性能悬崖2.2 模型部署链路与精度验证精度从 95% 掉到 91% 往往就出在这模型在 PC 上表现很好不等于转换到端侧还好。训练用的 PyTorch 模型经过归一化、量化、算子融合之后数值行为会发生改变。尤其是在 INT8 量化下激活值的动态范围被压缩数据分布不均匀时精度掉得特别快。第二项检查要做三件事。第一算子支持度检查。用推理引擎导出的转换报告逐一比对算子类型标记被替换算子和 CPU 回退算子。只要出现一个回退算子整个模型都可能被拖慢因为数据要在 NPU 和 CPU 之间来回倒。我们曾经遇到过 LayerNorm 算子不被 NPU 支持结果整段网络都走了 CPU推理延迟从 20ms 涨到 180ms性能直接崩掉。第二中间层输出对比。选取训练框架原始模型和端侧转换模型用完全相同的输入导出若干个中间层的输出计算余弦相似度。相似度低于 0.99 的层要重点排查。这一步能快速定位是量化误差还是某个算子的实现偏差。第三量化校准验证。确认量化使用的校准集和数据分布接近真实场景。校准集不能用随机图片最好从真实业务数据里抽覆盖各种光照、角度和噪声情况。校准集数据不够量化后的模型对陌生数据的泛化能力会明显变差。我们有一个经验值FP16 转换一般精度损失在 0.1 到 0.5 个点以内INT8 量化在数据分布合理的情况下可以控制在 1 个点以内。如果 INT8 后精度掉了超过 2 个点先不要急着怪量化工具回头审视校准集和模型本身的冗余度往往能发现真正原因。2.3 内存占用与功耗热设计压垮项目的往往是看不见的泄漏端侧 AI 的资源边界非常清楚整机内存就那么多NPU、CPU、GPU 共用。模型太大、内存碎片化、推理引擎缓存策略不合理这些问题不会在开机第一个小时暴露但会在 48 小时长稳测试里现出原形。第三项检查要测四类指标峰值内存包括 RSS、PSS内存带宽占用用性能 profile 工具抓整机功耗曲线覆盖待机、满载、推理间歇三种状态温度曲线与降频点用热成像仪或内置温度传感器记录一个很实用的技巧在 NPU 满载推理时CPU 上同时跑一个后台录像或音频采集任务模拟真实业务环境。很多样机单独跑 AI 推理一切正常一旦加上传感器数据采集内存带宽争抢导致帧率骤降这种问题只有整机联调才会暴露。温度问题尤为隐蔽。某次实测样机运行 30 分钟后 SoC 表面温度到了 85℃NPU 开始降频推理帧率掉 30%。如果不在验收阶段做功耗热设计检查这个问题只会在用户手里爆发。功耗记录表示例场景平均功耗峰值功耗SoC 温度NPU 频率判定待机0.8W1.2W45℃空闲通过30fps 推理3.5W4.8W82℃标称频率通过满载 30 分钟后3.2W4.5W88℃降频 20%不通过2.4 长稳压力与异常恢复跑 72 小时才算数长稳测试的目标是让样机在接近真实业务的负载下连续运行观察是否存在内存泄漏、性能衰减、死机和任务堆积。建议至少跑 72 小时负载分三档满载以最高帧率连续推理业务负载模拟真实触发率比如每 500ms 触发一次推理空载无推理任务系统挂机每小时记录一次内存占用、帧率、温度和 CPU 占用。重点关注内存是否每跑 10 小时就涨 5MB这基本就是泄漏。连续 24 小时累计泄漏超过 30MB就需要列为必须解决的问题。异常恢复测试同样重要。人为制造异常强制 kill 推理进程、模拟掉电重启、注入内存压力观察系统是否会自动恢复、服务是否自动拉起、日志是否完整可追溯。端侧设备没有现场工程师守着能不能自愈直接决定售后成本。我们遇到过一起案例推理进程崩溃后没有看门狗拉起设备直接变砖只能返厂刷机。长稳测试容易出现一个误区只看有没有死机。实际上性能衰减比死机更常见。有的样机刚启动时跑 30fps跑 12 小时后悄悄掉到 22fps这种问题用肉眼看界面不一定发现必须靠每小时记录帧率才能暴露。2.5 业务效果与端云协同模型指标不等于业务指标最后一项回到业务本身。模型 mAP 有 0.85不代表业务可用因为误报率可能高到用户无法接受。延迟和功耗全部达标也不代表识别结果在真机光照环境下可靠。业务效果检查要结合具体场景识别类任务用真实采集的数据集回放统计准确率、召回率、误报率检测类任务覆盖不同光照、角度、遮挡条件查看边界案例表现语音类任务分别在安静和噪声环境下测唤醒率和误唤醒率这里强烈建议用回放方式而不是对着实验室场景现场测试。现场测试数据量太小随机性太强得出的结论不可信。我们内部会准备一套固定测试集包含几千条真实业务数据每次改版都跑同一套数据做对比。端云协同检查要看三件事云端下发的新模型能否在端侧平滑更新算法版本和云端逻辑是否有耦合OTA 失败是否有回滚机制。有一次我们在灰度升级时端侧新模型和云端旧的预处理逻辑不兼容识别准确率掉到不到一半排查了一整天才发现是版本匹配问题。所以验收时一定要把端云版本兼容性矩阵列清楚。3. 一次完整验收的具体流程3.1 验收前先把物料和版本冻结验收最怕中途换版本结果出了问题说不清是硬件问题、驱动问题还是模型问题。动手之前先做三件事。第一准备至少两台样机。一台跑全量测试一台留作备份和对比排查。单台样机一旦测试中途挂了整个验收周期就要重新计算。第二冻结所有软件版本。驱动、推理引擎、模型文件、预处理库全部锁定版本号记录 git 提交信息。验收期间不允许随意升级确需升级必须走变更申请流程。第三准备好独立的测试数据集。不能用训练集也不能用验证集应该额外留一部分数据专门用于验收。数据要覆盖真实场景的各种边界情况。硬件工具也要提前备齐功耗仪、热成像仪或者温度采集板、串口日志工具、性能 profile 工具。等你开始跑长稳测试再发现工具缺失损失的就是几十个小时的测试时间。3.2 分阶段推进单板、子系统、整机三层验证我们习惯把验收拆成三个阶段每一阶段的结论都会影响下一阶段是否启动。第一阶段是单板验证只验证 NPU 和推理引擎。在这阶段跑模型精度对比和算子支持度检查不接摄像头、不接麦克风把模型链路的问题先解决干净。模型部署问题如果是等到整机阶段才发现定位起来会很痛苦因为你分不清是传感器数据问题还是推理引擎问题。第二阶段是子系统验证接入摄像头或麦克风加入数据采集链路。这时候重点看端到端延迟、内存带宽争抢、并发任务调度。很多帧率抖动问题在这个阶段就能暴露。第三阶段才是整机验证。全流程负载加上功耗热设计和 72 小时长稳最后做业务效果和端云协同检查。三个阶段只要前一个没过就不建议草率进入下一个否则排查成本会指数级上升。3.3 验收数据记录与结论判断所有测试数据都要落到文档里包括测试时间、固件版本、模型版本、环境温度、测试脚本、原始日志。没有记录的数据等于没有发生这是验收工作最重要的原则。我们内部用一张汇总表来收敛验收结论检查项结果严重级别备注算力实测与性能基准部分通过P1p99 抖动需优化模型部署链路与精度通过-INT8 精度差 0.8%内存与功耗热设计不通过P085℃ 降频帧率衰减 30%长稳与异常恢复通过-72h 无泄漏崩溃自恢复 OK业务效果与端云协同通过-误报率低于阈值严重级别分级会在下一节专门说这里先强调一点任何一项 P0 不通过整个样机验收结论就是“不通过”。这不是研发面子问题而是量产后的风险成本问题。4. 实操中踩过的坑与排查技巧4.1 常见问题速查表这些年实测下来有些问题出现频率极高我整理成了速查表方便你对照排查。现象可能原因排查手段帧率波动大、p99 飙升内存带宽争抢关闭后台任务复测或用 profile 工具抓带宽占用推理延迟忽高忽低CPU 调频策略/DVFS锁定性能模式复测对比默认模式数据转换后精度明显下降算子回退、校准集不合适查转换报告导中间层输出做对比长时间运行内存持续上涨推理引擎缓存泄漏每 10 小时记录一次 RSS用 valgrind 或厂商 sanitizer 定位满载 30 分钟后性能下跌热降频记录温度曲线确认是否超过降频阈值掉电重启后模型状态丢失存储写入时序问题做掉电注入测试检查日志和模型文件完整性云端升级后识别异常端云版本不匹配建立版本兼容矩阵升级前检查两端版本号这里有一个通用经验不要上来就怀疑硬件。很多所谓硬件问题最后查出来都是软件配置问题。先检查驱动版本、电源策略、线程优先级再做硬件层面的定板。4.2 三个容易被忽略的细节第一个细节是掉电时序。NPU 正在推理时突然掉电存储里的模型参数文件是否还能保持完整这个测试很多人不做直到用户设备意外断电才发现模型损坏、设备无法启动。验收阶段要做掉电注入不同时机断几次电然后检查重启后系统能否自动恢复。第二个细节是动态调频对延迟稳定性的影响。跑 benchmark 的时候用固定最高频率看起来一切正常一放到真实场景里DVFS 降低频率导致延迟突增。验收时务必测默认电源策略下的延迟分布必要时还要测省电模式下的表现。第三个细节是版本一致性。实验室里测的固件和最终交付的固件经常不是同一个版本。哪怕只是推理引擎更新了一个 patch性能也可能完全不同。验收报告里必须写明固件哈希值交付时再做一次哈希比对确保出厂版本和验收版本一致。4.3 判定标准P0、P1、P2 怎么用验收结论不能模棱两可我们用三个级别来做最终裁定。P0 是阻断性问题出现任何一个就不能交付。典型场景包括int8 精度掉点超过业务可接受范围、长时间运行出现死机或重启、设备无法自恢复、功耗高到无法满足散热设计要求、端云升级导致功能不可用。P1 是严重问题必须给出明确的解决计划和时间点。典型场景包括p99 延迟抖动严重但业务可以暂时容忍、内存泄漏速度较慢但趋势确定、降频后帧率衰减可以接受但需要优化散热。P2 是一般问题不影响当前交付但需要记录在技术债清单里。典型场景包括文档不完善、日志格式不友好、部分参数没有开放配置。我个人的体会是P0 和 P1 的边界必须提前定义最好在验收启动会上就和研发、产品、硬件各方对齐。如果等结论出来再吵定级流程就失去意义了。结尾最后再分享一个实操中的小技巧。验收这件事最忌讳的是“样机只准备一台、数据只跑一遍、结论只看平均”。端侧 AI 的很多问题都是间歇性的只有在足够长的测试周期和足够丰富的负载组合下才会现形。我们团队现在坚持的做法是每轮验收至少准备两台样机、跑 72 小时长稳、每项检查都留下原始日志。这套方法看着繁琐但每一次都能在样机阶段拦住量产后的重大事故。超维方程的五项工程检查不是死教条它是一个可以随业务裁剪的框架。你的业务如果是语音唤醒就把第五项检查里的语音指标加重如果是低功耗门铃就把第三项功耗热设计的权重拉高。希望这篇文章能帮你把验收这件事从“感觉没问题”变成“确认没问题”。
搞端侧 AI 的都知道样机验收永远比开发更难做。我前后经手过七八款带 NPU 的样机从摄像头模组到工业质检设备都碰过踩过的坑足以攒成一箩筐。这几年团队沉淀了一套验收方法论内部叫“超维方程”核心就一句话别让样机在“能跑”的状态下蒙混过关要把每一项能力用工程手段量化出来。这篇文章就把其中最关键的“五项工程检查”完整拆给你每一项都讲清楚做什么、怎么做、判定标准是什么以及哪些坑是我实测过才发现的。这套方法不绑定任何芯片平台也不限定模型结构适合所有正在做或者准备做端侧 AI 项目的人。不管你是刚拿到第一块开发板还是已经面临量产前的最终验收这套检查框架都可以直接拿过去用。文章不会扯太多理论尽量用项目里的真实场景说话。1. 端侧 AI 样机验收到底在验什么1.1 先看清楚端侧 AI 和云侧 AI 是两套验收逻辑端侧 AI 最核心的价值是低延迟、数据不出设备、断网可用。一套人脸识别如果跑在云端理想状态下往返也要 200ms 以上放到端侧可以做到 30ms 以内。但这个优势换来的是硬约束计算资源有限、内存有限、功耗有限而且没有随时扩容的弹性。云侧 AI 出问题可以快速加机器、重跑训练任务、灰度更新模型。端侧 AI 一旦部署出去模型迭代只能靠 OTA硬件算力就那么多跑不动的模型就是跑不动。所以端侧样机验收验的不只是“这台设备能不能跑一个 demo”而是“这台设备在未来两三年里能不能稳定承载指定业务”。传统硬件验收通常是功能、性能、可靠性三大块这套流程在端侧 AI 场景下不够用。端侧 AI 样机在这三块之外还叠加了模型、算法、推理引擎、算子、量化精度这一整条软栈。单纯照搬传统流程很容易漏掉真正的瓶颈。1.2 “能跑”和“能交付”之间隔着五道工程检查我们复盘了团队内外很多失败项目发现样机阶段被放过的问题高度集中在五个维度算力达不到预期、模型部署链路不通、内存与功耗撑不住、长稳运行不可靠、业务效果不达标。超维方程做的事情就是把这五个维度变成五道显式工程检查算力实测与性能基准模型部署链路与精度验证内存占用与功耗热设计长稳压力与异常恢复业务效果与端云协同每一道检查都有明确的输入、操作步骤和判定基线最终合成一个“可交付”或“不可交付”的结论。下面逐个展开。2. 超维方程五项工程检查怎么落地2.1 算力实测与性能基准别相信手册上的 TOPS端侧芯片常用 TOPS 标称算力这是理论峰值。但实际跑模型时算子调度、内存搬运、带宽争抢都会让有效算力大幅缩水。某款标称 4 TOPS 的平台我们拿真实检测模型实测有效吞吐只有 2.3 TOPS。差距不是 NPU 本身算不动而是数据喂给 NPU 的过程消耗了大量时间。所以第一项检查不看 TOPS看三条用厂商基准工具测的峰值算力只做参考用真实模型加真实预处理管线测端到端延迟预处理、推理、后处理全算进去连续跑 1000 帧统计延迟分布重点看 p50、p95、p99p50 决定平均体验p99 决定最差体验。如果 p99 是 p50 的三倍以上说明系统存在严重抖动。这种抖动多半来自内存带宽不足、CPU 调频策略保守或者推理线程优先级被抢占。验收时不能只看平均帧率就完事延迟分布必须记录下来。还要测不同输入尺寸下的表现。比如目标分辨率 1920×1080 能跑 30fps切到 4K 输入直接掉到 8fps这种性能悬崖在真实场景里非常常见。如果你预判业务未来会升级分辨率样机阶段就一定要把尺寸梯度测全。记录模板可以长这样检查项标称值实测值判定NPU 峰值算力4 TOPS2.3 TOPS 有效需优化数据搬运端到端延迟 p50不高于 40ms36ms通过端到端延迟 p99不高于 80ms85ms不通过排查抖动1080p 帧率30fps30fps通过4K 帧率15fps8fps不通过性能悬崖2.2 模型部署链路与精度验证精度从 95% 掉到 91% 往往就出在这模型在 PC 上表现很好不等于转换到端侧还好。训练用的 PyTorch 模型经过归一化、量化、算子融合之后数值行为会发生改变。尤其是在 INT8 量化下激活值的动态范围被压缩数据分布不均匀时精度掉得特别快。第二项检查要做三件事。第一算子支持度检查。用推理引擎导出的转换报告逐一比对算子类型标记被替换算子和 CPU 回退算子。只要出现一个回退算子整个模型都可能被拖慢因为数据要在 NPU 和 CPU 之间来回倒。我们曾经遇到过 LayerNorm 算子不被 NPU 支持结果整段网络都走了 CPU推理延迟从 20ms 涨到 180ms性能直接崩掉。第二中间层输出对比。选取训练框架原始模型和端侧转换模型用完全相同的输入导出若干个中间层的输出计算余弦相似度。相似度低于 0.99 的层要重点排查。这一步能快速定位是量化误差还是某个算子的实现偏差。第三量化校准验证。确认量化使用的校准集和数据分布接近真实场景。校准集不能用随机图片最好从真实业务数据里抽覆盖各种光照、角度和噪声情况。校准集数据不够量化后的模型对陌生数据的泛化能力会明显变差。我们有一个经验值FP16 转换一般精度损失在 0.1 到 0.5 个点以内INT8 量化在数据分布合理的情况下可以控制在 1 个点以内。如果 INT8 后精度掉了超过 2 个点先不要急着怪量化工具回头审视校准集和模型本身的冗余度往往能发现真正原因。2.3 内存占用与功耗热设计压垮项目的往往是看不见的泄漏端侧 AI 的资源边界非常清楚整机内存就那么多NPU、CPU、GPU 共用。模型太大、内存碎片化、推理引擎缓存策略不合理这些问题不会在开机第一个小时暴露但会在 48 小时长稳测试里现出原形。第三项检查要测四类指标峰值内存包括 RSS、PSS内存带宽占用用性能 profile 工具抓整机功耗曲线覆盖待机、满载、推理间歇三种状态温度曲线与降频点用热成像仪或内置温度传感器记录一个很实用的技巧在 NPU 满载推理时CPU 上同时跑一个后台录像或音频采集任务模拟真实业务环境。很多样机单独跑 AI 推理一切正常一旦加上传感器数据采集内存带宽争抢导致帧率骤降这种问题只有整机联调才会暴露。温度问题尤为隐蔽。某次实测样机运行 30 分钟后 SoC 表面温度到了 85℃NPU 开始降频推理帧率掉 30%。如果不在验收阶段做功耗热设计检查这个问题只会在用户手里爆发。功耗记录表示例场景平均功耗峰值功耗SoC 温度NPU 频率判定待机0.8W1.2W45℃空闲通过30fps 推理3.5W4.8W82℃标称频率通过满载 30 分钟后3.2W4.5W88℃降频 20%不通过2.4 长稳压力与异常恢复跑 72 小时才算数长稳测试的目标是让样机在接近真实业务的负载下连续运行观察是否存在内存泄漏、性能衰减、死机和任务堆积。建议至少跑 72 小时负载分三档满载以最高帧率连续推理业务负载模拟真实触发率比如每 500ms 触发一次推理空载无推理任务系统挂机每小时记录一次内存占用、帧率、温度和 CPU 占用。重点关注内存是否每跑 10 小时就涨 5MB这基本就是泄漏。连续 24 小时累计泄漏超过 30MB就需要列为必须解决的问题。异常恢复测试同样重要。人为制造异常强制 kill 推理进程、模拟掉电重启、注入内存压力观察系统是否会自动恢复、服务是否自动拉起、日志是否完整可追溯。端侧设备没有现场工程师守着能不能自愈直接决定售后成本。我们遇到过一起案例推理进程崩溃后没有看门狗拉起设备直接变砖只能返厂刷机。长稳测试容易出现一个误区只看有没有死机。实际上性能衰减比死机更常见。有的样机刚启动时跑 30fps跑 12 小时后悄悄掉到 22fps这种问题用肉眼看界面不一定发现必须靠每小时记录帧率才能暴露。2.5 业务效果与端云协同模型指标不等于业务指标最后一项回到业务本身。模型 mAP 有 0.85不代表业务可用因为误报率可能高到用户无法接受。延迟和功耗全部达标也不代表识别结果在真机光照环境下可靠。业务效果检查要结合具体场景识别类任务用真实采集的数据集回放统计准确率、召回率、误报率检测类任务覆盖不同光照、角度、遮挡条件查看边界案例表现语音类任务分别在安静和噪声环境下测唤醒率和误唤醒率这里强烈建议用回放方式而不是对着实验室场景现场测试。现场测试数据量太小随机性太强得出的结论不可信。我们内部会准备一套固定测试集包含几千条真实业务数据每次改版都跑同一套数据做对比。端云协同检查要看三件事云端下发的新模型能否在端侧平滑更新算法版本和云端逻辑是否有耦合OTA 失败是否有回滚机制。有一次我们在灰度升级时端侧新模型和云端旧的预处理逻辑不兼容识别准确率掉到不到一半排查了一整天才发现是版本匹配问题。所以验收时一定要把端云版本兼容性矩阵列清楚。3. 一次完整验收的具体流程3.1 验收前先把物料和版本冻结验收最怕中途换版本结果出了问题说不清是硬件问题、驱动问题还是模型问题。动手之前先做三件事。第一准备至少两台样机。一台跑全量测试一台留作备份和对比排查。单台样机一旦测试中途挂了整个验收周期就要重新计算。第二冻结所有软件版本。驱动、推理引擎、模型文件、预处理库全部锁定版本号记录 git 提交信息。验收期间不允许随意升级确需升级必须走变更申请流程。第三准备好独立的测试数据集。不能用训练集也不能用验证集应该额外留一部分数据专门用于验收。数据要覆盖真实场景的各种边界情况。硬件工具也要提前备齐功耗仪、热成像仪或者温度采集板、串口日志工具、性能 profile 工具。等你开始跑长稳测试再发现工具缺失损失的就是几十个小时的测试时间。3.2 分阶段推进单板、子系统、整机三层验证我们习惯把验收拆成三个阶段每一阶段的结论都会影响下一阶段是否启动。第一阶段是单板验证只验证 NPU 和推理引擎。在这阶段跑模型精度对比和算子支持度检查不接摄像头、不接麦克风把模型链路的问题先解决干净。模型部署问题如果是等到整机阶段才发现定位起来会很痛苦因为你分不清是传感器数据问题还是推理引擎问题。第二阶段是子系统验证接入摄像头或麦克风加入数据采集链路。这时候重点看端到端延迟、内存带宽争抢、并发任务调度。很多帧率抖动问题在这个阶段就能暴露。第三阶段才是整机验证。全流程负载加上功耗热设计和 72 小时长稳最后做业务效果和端云协同检查。三个阶段只要前一个没过就不建议草率进入下一个否则排查成本会指数级上升。3.3 验收数据记录与结论判断所有测试数据都要落到文档里包括测试时间、固件版本、模型版本、环境温度、测试脚本、原始日志。没有记录的数据等于没有发生这是验收工作最重要的原则。我们内部用一张汇总表来收敛验收结论检查项结果严重级别备注算力实测与性能基准部分通过P1p99 抖动需优化模型部署链路与精度通过-INT8 精度差 0.8%内存与功耗热设计不通过P085℃ 降频帧率衰减 30%长稳与异常恢复通过-72h 无泄漏崩溃自恢复 OK业务效果与端云协同通过-误报率低于阈值严重级别分级会在下一节专门说这里先强调一点任何一项 P0 不通过整个样机验收结论就是“不通过”。这不是研发面子问题而是量产后的风险成本问题。4. 实操中踩过的坑与排查技巧4.1 常见问题速查表这些年实测下来有些问题出现频率极高我整理成了速查表方便你对照排查。现象可能原因排查手段帧率波动大、p99 飙升内存带宽争抢关闭后台任务复测或用 profile 工具抓带宽占用推理延迟忽高忽低CPU 调频策略/DVFS锁定性能模式复测对比默认模式数据转换后精度明显下降算子回退、校准集不合适查转换报告导中间层输出做对比长时间运行内存持续上涨推理引擎缓存泄漏每 10 小时记录一次 RSS用 valgrind 或厂商 sanitizer 定位满载 30 分钟后性能下跌热降频记录温度曲线确认是否超过降频阈值掉电重启后模型状态丢失存储写入时序问题做掉电注入测试检查日志和模型文件完整性云端升级后识别异常端云版本不匹配建立版本兼容矩阵升级前检查两端版本号这里有一个通用经验不要上来就怀疑硬件。很多所谓硬件问题最后查出来都是软件配置问题。先检查驱动版本、电源策略、线程优先级再做硬件层面的定板。4.2 三个容易被忽略的细节第一个细节是掉电时序。NPU 正在推理时突然掉电存储里的模型参数文件是否还能保持完整这个测试很多人不做直到用户设备意外断电才发现模型损坏、设备无法启动。验收阶段要做掉电注入不同时机断几次电然后检查重启后系统能否自动恢复。第二个细节是动态调频对延迟稳定性的影响。跑 benchmark 的时候用固定最高频率看起来一切正常一放到真实场景里DVFS 降低频率导致延迟突增。验收时务必测默认电源策略下的延迟分布必要时还要测省电模式下的表现。第三个细节是版本一致性。实验室里测的固件和最终交付的固件经常不是同一个版本。哪怕只是推理引擎更新了一个 patch性能也可能完全不同。验收报告里必须写明固件哈希值交付时再做一次哈希比对确保出厂版本和验收版本一致。4.3 判定标准P0、P1、P2 怎么用验收结论不能模棱两可我们用三个级别来做最终裁定。P0 是阻断性问题出现任何一个就不能交付。典型场景包括int8 精度掉点超过业务可接受范围、长时间运行出现死机或重启、设备无法自恢复、功耗高到无法满足散热设计要求、端云升级导致功能不可用。P1 是严重问题必须给出明确的解决计划和时间点。典型场景包括p99 延迟抖动严重但业务可以暂时容忍、内存泄漏速度较慢但趋势确定、降频后帧率衰减可以接受但需要优化散热。P2 是一般问题不影响当前交付但需要记录在技术债清单里。典型场景包括文档不完善、日志格式不友好、部分参数没有开放配置。我个人的体会是P0 和 P1 的边界必须提前定义最好在验收启动会上就和研发、产品、硬件各方对齐。如果等结论出来再吵定级流程就失去意义了。结尾最后再分享一个实操中的小技巧。验收这件事最忌讳的是“样机只准备一台、数据只跑一遍、结论只看平均”。端侧 AI 的很多问题都是间歇性的只有在足够长的测试周期和足够丰富的负载组合下才会现形。我们团队现在坚持的做法是每轮验收至少准备两台样机、跑 72 小时长稳、每项检查都留下原始日志。这套方法看着繁琐但每一次都能在样机阶段拦住量产后的重大事故。超维方程的五项工程检查不是死教条它是一个可以随业务裁剪的框架。你的业务如果是语音唤醒就把第五项检查里的语音指标加重如果是低功耗门铃就把第三项功耗热设计的权重拉高。希望这篇文章能帮你把验收这件事从“感觉没问题”变成“确认没问题”。
