做嵌入式机器视觉这行，最容易产生落差感的时刻，往往不是算法跑不出指标，而是同一套模型在开发机上指标漂亮得让人放心，烧进设备之后帧率掉到个位数、精度还莫名其妙地跌了一截。嵌入式机器视觉的核心矛盾从来不在"模型够不够强"，而在"这点算力、这点内存、这点电，怎么把活干完还干得稳"。我见过不少团队把九成精力压在模型结构上，最后卡在内存带宽、预处理耗时、温漂漂移这些"不性感"的地方上。这篇内容面向的是正在或者准备把视觉算法往边缘设备上搬的工程师——无论是做工业检测、智能终端、机器人还是消费电子，只要你的算法最终要跑在一块几十块钱到几百块钱的板子上，下面这些算账方式、取舍逻辑和踩坑记录大概率能帮你少走几段弯路。
1. 嵌入式机器视觉的"嵌"字，卡的是四堵墙
很多人对嵌入式的第一印象是"性能差一点的电脑"，这个认知偏差会直接导致选型失误。服务器端的视觉系统，优化目标是吞吐量——一秒钟能处理多少张图，批大小往上堆、GPU 利用率拉满，延迟高一点无所谓。边缘端完全是另一套游戏规则：批大小基本等于 1，延迟必须可预测，功耗有硬顶，散热靠一块铝壳，设备还要在没人管的环境里连续跑五年。这四堵墙里，任何一堵没算清楚，后面所有的算法优化都是在错误的前提上做无用功。
1.1 算力不是唯一瓶颈，内存带宽常常先撑不住
新手最容易犯的错是拿 NPU 的标称算力做除法，算出来"理论 3 毫秒，那实测 5 毫秒应该够了"，结果跑出来 40 毫秒，然后开始怀疑人生。问题八成出在带宽上。卷积网络在推理过程中，每一层的输入特征图、输出特征图、权重都要在片外内存和片上缓存之间流动。片外内存的容量大但慢，片上 SRAM 快但只有几 MB，绝大多数中间特征图放不下，必须反复搬运。
举个具体的账：一个输入 3×640×640 的检测网络，中间某一层输出 256×80×80 的特征图，INT8 存储下就是 256×80×80 = 1,638,400 字节，约 1.6 MB。这层输出写出去一次、下一层读进来一次，就是 3.2 MB 的流量。整个网络如果有一百多层，哪怕平均每层只搬运 1 MB，一帧下来也是上百 MB 的片外流量。主流边缘 SoC 的 DDR 有效带宽标称十几到二十几 GB/s，听上去绰绰有余，但那是理想连续访问下的峰值，实际随机访问、多核争抢、cache miss 之后打个三到五折是常态。换算下来，一帧光搬运就可能吃掉十几到几十毫秒。
判断一个模型在目标平台上"能不能跑"，先看特征图峰值内存和总访问量，再看算力。特征图峰值超过片上 SRAM 容量两倍以上的网络，几乎必然被带宽拖死。
这也是为什么同样参数量的网络，在不同设备上的实测耗时能差三倍以上——不是算力差距，是访存模式的差距。有些网络大量使用 1×1 卷积和深度可分离卷积，计算量小但访存密集，在片上缓存小的芯片上表现反而比标准卷积更差。
1.2 功耗预算决定了你能不能用"大力出奇迹"
工业现场的设备外壳通常是密封的铝壳或钣金箱，没有风扇，靠自然对流散热。一个 10 cm × 10 cm × 5 cm 的密闭铝壳，自然对流下的散热能力大概只有几瓦。你把一颗能跑 8 TOPS 的芯片塞进去，跑满功耗 5 W，结温很快就会顶到降频阈值，然后你看到的帧率是"前三十秒正常，之后一路下滑"。
我一般会要求把整机功耗预算拆成三块：SoC 本身、传感器与补光、其他外设（网口、屏幕、电机驱动）。视觉部分能分到的往往只有总预算的一半甚至更少。这不是抠门，是因为电源模块的效率、线损、待机功耗都会在后面咬你一口。定功耗预算的时候不要只看典型值，要看最坏情况——所有外设同时工作、环境温度 55 度、外壳内部温升 20 度，这个组合下的功耗才是你真正要设计的点。
一个实用的经验值：无风扇密闭小外壳里，SoC 持续功耗控制在 2 W 以内，系统才比较从容；超过 3 W 就要认真做热仿真或者加导热结构了。
1.3 实时性要的是"最坏延迟"，不是"平均帧率"
做工业检测的同行应该对这点体会最深。产线节拍是 33 毫秒一个工件，相机 30 fps 出图，你告诉客户"平均 25 毫秒"，客户不会满意，他要的是"每一帧都在 30 毫秒内"。均值再漂亮，只要偶尔蹦出一帧 200 毫秒，产线就会漏检。
延迟抖动在嵌入式 Linux 上是常态，来源非常具体：内存碎片导致的大页分配失败、后台日志刷盘、网络中断处理抢占、CPU 频率调节策略在负载突变时的响应延迟、甚至温度触发的降频。我在项目里通常会把 CPU 的调频策略固定为性能模式，把推理线程绑核，把日志改成异步写入并且限速，把不必要的系统服务全部裁掉。这些动作看起来琐碎，但能把 P99 延迟从三位数毫秒压到稳定区间。
评估阶段就该用 P99 而不是均值做验收标准。跑一千帧，把延迟排序取第 990 个值，那个数字才是你敢写进规格书的。
1.4 生命周期与可维护性被忽略得最多
一台设备出货生命周期动辄八到十年，而算法迭代周期是三个月。这意味着你部署下去的第一版模型，一定不是最后一版。如果部署方案里没有考虑"模型怎么更新、工具链版本怎么回溯、旧模型还能不能重新编译"这些问题，三年后你会发现自己被锁死在一个再也装不上的旧工具链里。
我现在的做法是：把模型文件、预处理参数、后处理阈值、标定参数一起打包成一个带版本号的"推理包"，设备端只认识这个包的格式和版本号，不关心里面是什么网络。这样换模型对设备端固件是透明的，OTA 只更新推理包。回溯的时候也简单——旧包留着，直接回滚。
2. 选型之前先算三笔账：算力、带宽、功耗
拿到一颗候选芯片，第一件事不是跑 demo，是算三笔账。算完你就知道这个方案是"能用"还是"勉强能用"还是"根本别想"。这笔账要在写第一行代码之前算，因为算完之后你可能直接换方案，省下的时间是几个星期。
2.1 算力账：从 MACs 到真实耗时的换算系数
理论耗时的算法是：单帧 MACs（乘加次数）× 2 ÷ 峰值算力。注意是 MACs 乘 2，因为一次乘加算两次运算。比如你的模型单帧 1.2 GMACs，目标 NPU 标称 1 TOPS（每秒一万亿次运算），理论耗时 = 2 × 1.2e9 / 1e12 = 2.4 毫秒。
这个 2.4 毫秒在实际中没有任何参考价值，除非乘上一个"有效利用率"。利用率取决于网络结构和工具链成熟度，经验区间大致如下：
| 网络结构特征 | 典型有效利用率 | 说明 |
|---|---|---|
| 标准卷积为主，通道数是 32/64 的整数倍 | 40% ~ 60% | 工具链容易切分，硬件打满 |
| 深度可分离卷积占比高 | 20% ~ 35% | 计算量小但访存密集，带宽先饱和 |
| 含大量 1×1 卷积与逐元素操作 | 15% ~ 30% | 激活、add、concat 常回落 CPU |
| 含非标准算子（自定义 reshape、动态 shape） | 10% 以下 | 频繁在 NPU 和 CPU 之间切换 |
按这个系数，1.2 GMACs 的模型在 1 TOPS 芯片上，实测大概落在 5 到 15 毫秒之间。如果验收要求是 30 毫秒一帧，你还有余量给预处理和后处理；如果要求是 10 毫秒，那就得换芯片或者砍模型。
这里有个容易被忽略的点：算力账要按"最坏情况"算，也就是模型里最慢的那个算子。有些工具链会把不支持的算子甩回 CPU，一个 CPU 上跑的特殊算子就能吃掉整个预算的 30%。所以在评估阶段，一定要拿到逐层耗时分析表，而不是只看总耗时。
2.2 带宽账：算清楚每帧要搬多少数据
带宽账的算法是：把每一层的输入输出特征图字节数加起来，乘以 2（读一次写一次，还要算权重，权重可以常驻的话不计入），得到单帧总流量，再除以有效带宽。
举例：单帧总流量 80 MB，设备实测有效带宽 4 GB/s，那一帧光搬运就是 20 毫秒。这时候你发现推理耗时 15 毫秒、搬运 20 毫秒，总时间比算力账算出来的还长——这就是带宽瓶颈的典型表现。
降低带宽压力的手段按性价比排序：第一是减少中间特征图通道数（尤其是高分辨率阶段的通道数），第二是把连续的逐元素操作融合进卷积（算子融合，主流框架都支持），第三是提高输入分辨率之前先想清楚是不是真需要——分辨率翻倍，特征图面积翻四倍，流量也跟着翻。很多场景把 1280 降到 960，精度掉不到一个点，速度直接快一倍。
2.3 功耗账：从标称 TDP 到实际板级功耗
芯片手册上的功耗数字通常是"典型场景下的芯片本体功耗"，跟你板子上的实际功耗是两回事。实际要算的是：芯片本体 + DDR 颗粒 + 摄像头模组 + 电源转换损耗（效率按 85% 估）+ 其他外设。
DDR 的功耗经常被低估。一颗 LPDDR4 在满载访问时功耗能到 1 W 级别，如果你的模型访存密集，这部分功耗会实实在在地变成热量。摄像头模组的功耗跟分辨率、帧率、接口类型强相关，高分辨率高帧率的模组吃掉 0.5 W 到 1 W 很常见。
一个简单的验证方法：样机做出来之后，用可调电源供整机，跑满载推理，看输入电流。这个数字比任何手册都可靠。如果实测功耗超出预算，优化顺序是：先降帧率（如果场景允许），再降分辨率，最后才动模型结构——因为动模型结构意味着重新训练、重新验证，成本最高。
2.4 一张选型对照表
我把常见的三类方案放在一起对比，方便判断什么场景该走哪条路：
| 方案类型 | 典型算力区间 | 适合的场景 | 主要风险 |
|---|---|---|---|
| 通用 CPU + 轻量模型 | 无专用加速单元 | 低帧率、简单分类、成本极敏感 | 高分辨率检测跑不动，占用 CPU 影响其他任务 |
| SoC 内置 NPU | 0.5 ~ 8 TOPS | 主流检测、分类、分割，中等帧率 | 算子支持不全，工具链版本绑死 |
| 独立加速模块 | 8 TOPS 以上 | 多路视频、高分辨率、复杂模型 | 功耗散热压力大，成本高，接口带宽受限 |
选型的判断顺序我一般是这样的：先确定帧率和分辨率的硬指标，再反推需要的有效算力（按 0.3 的利用率保守估），再看候选芯片能不能满足，最后才看生态和成本。反过来做——先选芯片再想算法——大概率会在后面被迫砍需求。
3. 模型轻量化的三条路，每条路上都有坑
轻量化这个词被说烂了，但真到落地的时候，很多团队做的"轻量化"只是把模型换小了一号，然后发现精度掉得没法用，又换回去，来回折腾。实际上剪枝、量化、结构重设计这三条路的适用条件完全不同，选错路的代价是几周时间。
3.1 剪枝：只有结构化剪枝在通用硬件上真提速
非结构化剪枝（按权重绝对值把小的置零）在论文里能做出很高的稀疏率，但在通用 NPU 上几乎不提速，因为硬件没有稀疏计算单元，零值照样参与运算，你只是白忙一场。
结构化剪枝才有效——按通道、按层、按卷积核整块剪掉，剪完之后网络还是稠密的，硬件能直接受益。具体做法是给每个通道算一个重要性分数（常用 BN 层的缩放因子 γ 的绝对值），排序后剪掉分数最低的一批，然后重新训练几轮恢复精度。
实操上要注意两点。第一，剪枝率不要一次拉太狠，按 10% 到 20% 一档逐步剪，每档都验证精度，找到精度开始明显下滑的拐点就停。第二，剪完之后一定要看逐层耗时变化，有些层剪了通道数反而变慢——因为剪到了硬件友好的通道数对齐边界之外，比如原本 64 通道，剪到 56，硬件按 64 的倍数处理，等于白剪。通道数尽量保持在 8 或 16 的整数倍上。
3.2 量化：掉点的真实原因往往不在量化本身
INT8 量化是把 FP32 的权重和激活映射到 8 位整数，理论上能带来 2 到 4 倍的速度提升和 4 倍的内存节省。但很多人做完量化发现精度掉了三五个点，就得出"这个模型不能量化"的结论，其实大部分情况是校准没做好。
掉点的三大真实原因：
第一，校准集分布不对。校准的目的是确定每一层激活值的动态范围，校准集必须覆盖实际部署时可能出现的输入分布。用 100 张实验室打光完美的图去校准，现场强逆光、低照度的图进来就会溢出截断。我现在固定用至少 500 张，覆盖各种光照、各种工况，甚至故意掺一些极端样本。
第二，激活值离群点。Transformer 类结构或者某些归一化层会产生极少数特别大的激活值，为了覆盖这个离群点，整层的量化步长被拉得很大，绝大多数正常值都被量化得太粗。解决办法是逐通道量化（per-channel）而不是逐张量量化，或者对离群通道做特殊的截断处理。
第三，首尾层没保护。输入层和输出层对精度最敏感，通常保持 FP32 或者用更高精度处理，中间的骨干网络才量化。大部分工具链都支持这个配置，但默认不一定开。
逐层敏感度分析是我必做的一步，脚本大概长这样：
import numpy as np def layer_sensitivity(model, calib_loader, eval_fn, layers): base = eval_fn(model) report = [] for name in layers: # 只对这一层保持浮点，其余量化 cfg = build_config(exclude=[name]) q_model = quantize(model, calib_loader, cfg) acc = eval_fn(q_model) report.append((name, base - acc)) report.sort(key=lambda x: -x[1]) return report # 输出前 10 个最敏感的层，这些层保持浮点跑完之后你会发现，通常只有三到五层是真正的"精度杀手"，把这几层排除在量化之外，整体精度能回来一大半，而速度损失很小——因为这几层往往计算量占比不高。
3.3 结构重设计：训练时多用，推理时合并
有一类结构在训练阶段故意做得很复杂，推理阶段可以等效合并成单个卷积，典型代表是多分支结构。训练时用 3×3、1×1、恒等映射三条并行分支，梯度流动更顺畅、收敛更快；推理时把三条分支的卷积核和 BN 参数全部折叠进一个 3×3 卷积，得到一个没有任何分支的干净网络。
这种"训练重、推理轻"的思路在嵌入式场景特别值钱，因为推理阶段的收益是实打实的——没有分支意味着没有额外的内存读写、没有算子切换开销，硬件利用率能提升一截。代价是训练代码复杂一点，需要写参数融合的逻辑，但这部分是一次性投入。
参数融合的核心是把 BN 折叠进卷积：卷积输出 y = W*x + b，BN 是 y' = γ(y - μ)/σ + β，代入整理后得到新的权重 W' = W * γ/σ，新的偏置 b' = (b - μ) * γ/σ + β。多个分支的融合就是把各自的 W'、b' 在输入输出通道维度上拼接后相加，前提是各分支的输入输出通道数一致。
3.4 一个可复用的轻量化决策流程
我把这套判断整理成一张表，遇到新项目直接照着走：
| 当前状况 | 优先动作 | 预期收益 | 风险 |
|---|---|---|---|
| 精度达标，速度差 2 倍以内 | INT8 量化 + 算子融合 | 速度 1.5~3 倍 | 精度掉 0.5~2 个点，需重新校准 |
| 精度达标，速度差 3 倍以上 | 换主干网络 + 降输入分辨率 | 速度 3~5 倍 | 精度掉 2~5 个点，需重训 |
| 精度本身就紧张 | 先补数据、再考虑蒸馏 | 精度 +2~4 个点 | 训练成本高，周期长 |
| 模型算力小但实测很慢 | 查算子回落和访存模式 | 速度 2 倍以上 | 需要看逐层分析，可能要换结构 |
顺序很重要：先量化（成本最低、见效最快），再考虑结构替换，最后才动分辨率。反过来先降分辨率往往是最亏的——精度掉得最多，速度提升反而不如量化明显。
4. 从摄像头出图到结果回传：把链路延迟拆到毫秒
模型推理只是整条链路里的一段。真正决定端到端延迟的，是采集、预处理、推理、后处理、输出这五段加起来。我见过太多项目，推理优化到 8 毫秒，结果端到端 45 毫秒，剩下 37 毫秒全耗在没人看的环节上。
4.1 六个阶段的延迟预算表
做优化之前先把预算表拉出来，每一段填上实测值，你才知道该往哪儿使劲：
| 阶段 | 典型耗时 | 主要影响因素 | 优化手段 |
|---|---|---|---|
| 传感器曝光与读出 | 5 ~ 15 ms | 曝光时间、帧率、快门类型 | 缩短曝光、提高增益（有噪声代价） |
| 接口传输（MIPI 等） | 1 ~ 3 ms | 分辨率、位深、lane 数 | 降位深、增加 lane |
| ISP 处理 | 2 ~ 8 ms | 去噪、自动曝光、色彩转换 | 关掉不必要的后处理模块 |
| 预处理（缩放、归一化） | 1 ~ 12 ms | 是否硬件缩放、是否 CPU 拷贝 | 用硬件缩放器、零拷贝 |
| 推理 | 5 ~ 30 ms | 模型复杂度、算子支持度 | 量化、剪枝、结构优化 |
| 后处理（解码、NMS） | 1 ~ 10 ms | 候选框数量、是否定点 | 提前阈值过滤、定点化 NMS |
这张表最有价值的地方在于，它逼着你去实测每一段。很多团队只测推理，其他段全靠猜，优化方向自然就偏了。
4.2 预处理是最容易白扔十毫秒的地方
预处理包括缩放、色彩空间转换、归一化、padding。这些操作看起来简单，但在嵌入式 CPU 上做双线性缩放，一张 1920×1080 缩到 640×640，耗时能到 8 到 12 毫秒，比推理还慢。
优化路径有两条。第一条是走硬件缩放器，大部分 SoC 的 ISP 或者显示子系统里都有硬件缩放单元，能把缩放耗时压到 1 到 2 毫秒，代价是缩放算法固定（通常是双线性或者双三次），而且要走特定的数据通路。第二条是把归一化融进模型——很多框架支持在模型第一层前插一个减均值除方差的算子，让 NPU 一起算掉，省掉 CPU 上的一次全图遍历。
还有一个细节：letterbox 和直接拉伸的取舍。letterbox 保持长宽比、四周补灰边，对小目标友好，但会浪费一部分分辨率；直接拉伸会改变物体长宽比，对形状敏感的任务（比如缺陷检测里的细长划痕）不友好。我的经验是检测类任务优先 letterbox，分类类任务可以直接拉伸。这个选择要在训练阶段就定下来，训练和部署的预处理必须完全一致，否则精度会莫名其妙地掉。
4.3 零拷贝与内存对齐：省下来的都是白赚的
数据从摄像头到 NPU，中间每多一次内存拷贝，就多一次几毫秒的开销。理想路径是：摄像头 DMA 写到一块物理连续内存，ISP 处理后原地写回或者写到另一块，NPU 直接从这块内存读。全程零拷贝。
实现零拷贝的关键是搞清楚每个环节的内存约束：DMA 需要物理连续或者 IOMMU 映射，NPU 需要特定的对齐（常见是 64 字节或者 128 字节），ISP 可能要求特定的 stride（行跨距，通常是宽度对齐到 16 或 32 像素的倍数）。这三个约束不一致的时候，就必须拷贝一次做重排。
一个非常实用的调试技巧：把每一段的输入输出内存地址打印出来，如果地址在同一块 buffer 里连续变化，说明零拷贝链路是通的；如果地址反复跳变，说明中间有隐藏的拷贝。
CPU 和 NPU 共享内存的时候还要注意 cache 一致性。CPU 写完数据要刷 cache 再交给 NPU，NPU 算完要失效 cache 再让 CPU 读，否则读到的是旧数据。这个 bug 特别隐蔽，表现为"偶尔结果不对"，很难复现。
4.4 后处理的定点化：NMS 是隐藏的性能黑洞
后处理里最耗时的是 NMS。候选框数量在 3000 到 8000 之间时，标准 NMS 的复杂度是 O(n²)，在嵌入式 CPU 上跑几十毫秒完全不奇怪。
优化手段有三个层次。最有效的是提前过滤：在解码阶段就把置信度低于阈值的框扔掉，把候选框数量从几千降到几百，NMS 耗时直接降一个数量级。其次是定点化：把 IoU 计算改成整数运算，浮点除法改成移位，精度损失可以忽略。最后是算法层面，用排序加提前终止，或者按类别分组并行。
一段定点化 NMS 的核心逻辑大概是这样：
static inline int iou_fixed(int ax1, int ay1, int ax2, int ay2, int bx1, int by1, int bx2, int by2) { int ix1 = ax1 > bx1 ? ax1 : bx1; int iy1 = ay1 > by1 ? ay1 : by1; int ix2 = ax2 < bx2 ? ax2 : bx2; int iy2 = ay2 < by2 ? ay2 : by2; int iw = ix2 - ix1, ih = iy2 - iy1; if (iw <= 0 || ih <= 0) return 0; int inter = iw * ih; int area_a = (ax2 - ax1) * (ay2 - ay1); int area_b = (bx2 - bx1) * (by2 - by1); /* Q16 定点，避免浮点除法 */ return (int)(((long long)inter << 16) / (area_a + area_b - inter)); }这段代码在嵌入式 CPU 上比浮点版本快两到三倍，而且结果是确定的，不会因为浮点误差导致同一批数据两次跑出不同结果——这在工业场景里挺重要，可复现性本身就是需求。
5. 实验室里 0.9 的精度，到了产线上为什么守不住
这是嵌入式视觉最典型的落差。模型在自建测试集上 mAP 0.9，装到现场一周之后客户反馈漏检率上去了。问题几乎从来不在模型，而在"实验室和现场之间那几十个没被建模的变量"。
5.1 光照与曝光：先锁曝光，再谈模型
自动曝光在演示阶段很友好，在现场是灾难。工件表面反光变化、环境光变化、补光灯老化，都会让自动曝光不断地调整参数，导致同一个工件在不同时刻呈现出完全不同的亮度分布，模型看到的是它训练时没见过的分布。
我的做法是：现场调试时先把自动曝光关掉，手动锁定曝光时间和增益，用一组固定的补光把工件照亮到目标亮度区间，然后再看模型的稳定性。锁定之后如果还是不稳，说明补光设计有问题，而不是模型有问题。补光的原则是"均匀、无频闪、与相机同步"——用与相机帧率同步的频闪光源，能显著降低环境光干扰，同时延长光源寿命、降低发热。
还有一个容易忽略的点：曝光的稳定性依赖于光源的稳定性，而 LED 光源的亮度会随温度和老化漂移。所以要么定期校准，要么在系统里加一个亮度参考（比如固定放一块标准白板在视野边缘），让系统能感知到漂移并做补偿。
5.2 温漂：器件和结构都在动
设备冷启动和连续工作四小时之后，成像结果可能不一样。原因有两层：相机传感器的暗电流随温度上升而增大，导致暗部噪声和偏色；机械结构热胀冷缩导致相机和工件的相对位置发生微米到几十微米级别的变化。
对于高精度测量类任务（比如尺寸测量精确到 0.02 mm），这个漂移是致命的。应对手段是：结构上用低膨胀系数的材料，或者设计成对称结构抵消变形；算法上做在线标定，用视野里的固定基准点做实时补偿；流程上要求设备预热到热平衡之后再开始生产。
我一般会在设备里内置一个"预热倒计时"，冷启动后跑空转十五到二十分钟，等到连续几次标定的偏差小于阈值才允许进入生产状态。这个功能看着笨，但能省掉大量现场投诉。
5.3 相机标定与机械安装的一致性
多相机系统里，每个相机的内参、外参都必须标定，而且要保证标定时的机械状态和生产时完全一致——相机拧紧的力矩不同，光轴就可能偏零点几度。批量生产时这个问题会被放大：产线上装一百台，每台的相机位置都有微小差异，如果你用的是一套固定的 ROI 和阈值，那必然有一批设备表现异常。
解决办法是把标定流程产品化：每台设备出厂前跑一遍自动标定，把结果写进设备配置，随推理包一起管理。标定用的靶标要定期校验，靶标本身变形会让所有设备的标定一起偏。
5.4 一张现场问题排查表
现场出了问题，按这个顺序查，能覆盖八成情况：
| 现象 | 优先排查 | 常见根因 |
|---|---|---|
| 白天正常，晚上漏检 | 光源与曝光 | 环境光变化导致亮度分布偏移 |
| 刚开机正常，几小时后变差 | 温度 | 传感器暗电流上升或结构热变形 |
| 某几台设备表现异常 | 标定与安装 | 相机位置偏差、镜头个体差异 |
| 同一样品反复检测结果不一致 | 曝光与触发 | 自动曝光未锁定、触发时序抖动 |
| 边缘目标检测不到 | 预处理 | letterbox 参数与训练不一致、ROI 裁切偏移 |
| 偶发整帧结果全错 | 内存与并发 | cache 未同步、buffer 竞争、DMA 越界 |
这张表的价值在于给出排查顺序，而不是让人一上来就怀疑模型。绝大多数现场问题，模型都是无辜的。
6. 小团队把"标杆"做成可复用的工程体系
技术方案能跑通是一回事，能稳定交付一百台、并且三年后还能维护，是另一回事。前者靠个人能力，后者靠体系。这块往往是小团队最容易欠账的地方，也是真正拉开差距的地方。
6.1 回归测试集：比模型更值钱的资产
每个项目我都会要求建一个回归测试集，规模不用大，三百到五百张就够，但必须满足三个条件：覆盖所有工况（不同光照、不同批次物料、不同工位）、包含所有历史踩过的坑（每一个现场问题都补几张图进去）、标注经过双人复核。
这个测试集的作用不是评估模型上限，而是防止退化。每次改模型、改预处理、改后处理参数，跑一遍回归集，看指标有没有掉。没有这套东西，你改一个参数修好了 A 问题，同时悄悄弄坏了 B 场景，等客户反馈回来已经是两周之后。
测试集要跟着代码一起做版本管理，图片用对象存储加清单文件的方式管理，清单里记录每张图的来源、工况标签、标注版本。这样三年后你还能说清楚"当时 v2.3 版本的模型在这批数据上是什么水平"。
6.2 版本与配置管理：把不确定性关进笼子
嵌入式项目里的版本头绪特别多：固件版本、模型版本、推理包版本、标定参数版本、工具链版本。任何一个对不上，行为就可能不一样。我吃过的最大的亏是"现场设备和实验室设备跑的模型文件同名但内容不同"，排查了两天才发现。
现在我的做法是：推理包里带一个清单文件，记录模型哈希、预处理参数、后处理阈值、标定文件哈希、编译工具链版本，设备启动时校验，不匹配直接拒绝加载并报警。看着有点重，但省下来的排查时间远超这点开发成本。
# 设备启动时的推理包自检 PKG=/opt/vision/current if [ ! -f "$PKG/manifest.sha256" ]; then echo "manifest missing"; exit 1 fi sha256sum -c "$PKG/manifest.sha256" || { echo "package integrity check failed" exit 1 } # 校验通过后再加载 exec /opt/vision/bin/inferd --config "$PKG/config.json"6.3 灰度与回滚：别让一次更新干掉整条产线
设备在现场跑着，你推一个模型更新，如果新模型在某类工件上表现差，整条产线的良率就受影响了。所以更新必须能灰度、能回滚。
灰度的做法是：先在一台或者一小批设备上更新，观察一到两天，指标正常再全量。设备端要保留上一版推理包，回滚指令下来三秒内切回去。回滚的触发条件可以是人工判断，也可以是自动的——比如连续 N 帧的置信度分布异常偏离历史基线，就自动报警并暂停更新。
自动异常检测这块我一般会做一个轻量的分布监控：统计每帧检测框数量、平均置信度、类别分布，跟历史基线比，偏离超过阈值就告警。这个监控本身开销极小，但能提前发现很多问题——比如现场换了新批次的物料，颜色分布变了，模型开始漏检，监控能比客户先发现。
6.4 交付文档：写给三个月后的自己
最后说一个不起眼但很要命的事：文档。嵌入式项目的文档不是给客户看的说明书，是给团队自己看的"决策记录"。哪些参数是调过的、为什么这么调、当时试过哪些方案、为什么放弃，这些信息如果只存在某个人的脑子里，人一走项目就断档。
我的文档模板很简单，就四块：硬件配置清单（型号、接口、供电、散热）、软件依赖清单（版本号精确到小版本）、参数说明（每个可调参数的含义、取值范围、调整影响）、已知问题列表（现象、根因、临时规避方案）。最后这块最有用，因为很多问题短期修不了，但必须让后来的人知道怎么绕过去。
这套东西搭起来之后，新项目启动能省掉大量重复劳动——硬件清单改改就能用，回归测试集的框架直接搬，灰度回滚的脚本复制粘贴。所谓"行业标杆"，落到实处其实就是这些让复杂系统变得可预期、可复现、可交接的工程习惯，而不是某一个模型刷出了多高的指标。
我个人在实际项目里的体会是，嵌入式视觉的难点从来不在"能不能做出来"，而在"能不能一直稳定地做出来"。前者靠灵感和加班，后者靠账算得清楚、链路测得明白、变更管得住。把算力、带宽、功耗这三笔账在动手之前算明白，把端到端链路拆到毫秒去实测，把现场的每一个坑都变成回归测试集里的一张图，剩下的就是时间问题了。
