简介：面向瑞芯微RV1126嵌入式平台开发者，这份实战资料围绕SSD目标检测从模型训练到板端部署的完整流程展开，详细说明如何利用RV1126内置的NNA加速器运行SSD算法。资料覆盖模型优化、格式转换、代码适配与性能调优等关键环节，适合具备一定深度学习基础、希望将目标检测算法落地到RISC-V架构AI硬件上的学习者。压缩包共19个文件，总大小39.29MB，主要包含6个txt标签与使用说明、3个rknn模型文件、C++源码（.cpp/.h）及CMakeLists配置，另有h264演示视频与db3数据库等，文件类型跨度大但目录整洁，便于按步骤查阅。目前已有77人学习下载。通过这份资料，读者可以获得完整的SSD模型文件、可直接参考的C++检测工程代码和标签列表，配合示例视频能直观看到运行效果；结合项目附带的说明文档，还能了解模型转换和部署流程中的常见问题，从而快速上手RV1126上的目标检测开发，并为后续项目提供可复用的代码骨架。
1. RV1126 实现 SSD 目标检测 AI 实战：先看思路再看坑
RV1126 实现 SSD 目标检测 AI 实战，听起来是一块开发板和一个老模型放在一起，实际上是边缘端视觉落地里最顺手的组合：一块带 NPU 的低功耗 SoC，跑一个成熟稳定的单阶段检测器，在几瓦功耗内实时框出摄像头画面中的目标。适合做安全帽检测、人员计数、农田鸟类预警这类设备的工程师，也适合 0 基础纯小白——SSD 的结构比 YOLO 直白，部署链路短，出问题好排查。先说结论：真正让你翻车的往往不是 SSD 网络本身，而是模型转换、量化校准、输入预处理这三层，任何一层和训练端不一致，出来的检测框就会跟你玩捉迷藏。本文只聊 SSD（Single Shot MultiBox Detector），一种目标检测网络结构，和硬盘、存储没有任何关系。
2. 为什么是 RV1126 + SSD：平台底牌与选型红线
2.1 RV1126 的底牌：NPU、ISP 与 RKNN 工具链
RV1126 是瑞芯微面向智慧视觉的一款 SoC，常见于 IPC、门锁、人脸考勤机这类设备。它最值钱的不是 CPU，而是那颗算力在 2 TOPS 级别（INT8）的 NPU。CPU 是四核 Cortex-A7，主频 1.5GHz 上下，单独拿来跑 SSD 会很吃力；但只要把卷积、全连接、激活这些算子交到 NPU 上，SSD 这种单阶段模型就能跑出可用的实时帧率。
这颗 NPU 的编程模型和英伟达 GPU 完全不一样。GPU 上你写 CUDA C++，RV1126 上你用瑞芯微的 RKNN 工具链：先在 PC 上把 Caffe、TensorFlow、ONNX、PyTorch 模型转成 .rknn 格式，再把 .rknn 文件放到板子上交给 librknnmrt.so 运行时加载。整个流程里，NPU 对于你来讲是一个黑匣子：你不需要关心算子怎么并行，只需要保证输入输出 tensor 的形状、数值范围、通道顺序和模型训练时一致。这个思维转换，是很多从服务端转过来的工程师最容易卡住的地方。
RV1126 还有一个容易被低估的点：ISP。它自带双路 ISP 输入，可以同时接一路 RGB 彩色相机和一路 IR 红外相机。很多做白天/夜晚无缝检测的 IPC 方案，就是靠这个硬件特性实现的——白天走 RGB 数据，夜间切 IR 数据，SSD 照样推理，只是输入源换一下。这点后面我会在进阶玩法里再提到。
2.2 SSD 的网络结构优势与选型边界
SSD 全称 Single Shot MultiBox Detector，是 2016 年提出的单阶段检测器。它和 YOLO 的显著差异在于：SSD 在不同的特征层上各自铺一组 prior box（先验框），然后对每个 prior box 回归位置偏移和类别置信度。这种多尺度特征图直接预测的设计，让它对小物体的敏感度天然比第一代 YOLO 好，而且结构对称，容易在 NPU 上做算子映射。相比之下，YOLO 系列在转 RKNN 时还需要处理 upsample 分支、不同 head 的 stride 等结构，后处理也更碎。SSD 的输出通常比较规整：位置输出、置信度输出、prior box 输出，三块各自独立，解析起来确定性很强。
当然选型有边界。SSD 的 anchor 是人工设计的，对训练数据里的目标尺度分布敏感；如果场景里全是小目标，比如遥感目标检测里的车辆、鸟类目标检测里的远处飞鸟，SSD 的召回率会明显不如后来带特征金字塔的 YOLO 系列和 anchor-free 模型。所以我的判断标准很简单：目标尺度比较均匀、检测帧率要求高、团队里新手多，选 SSD；目标大小差异特别大，愿意多花两周调参，才考虑 YOLO 系。标题既然锁定了 SSD，下面所有环节都围绕这条线展开。
2.3 从训练到板端的四段链路
RV1126 上跑通一个 SSD 检测模型，完整链路分四段：
第一段是模型准备。你可以直接拿公开的 SSD-MobileNet 预训练权重做迁移测试，也可以用自己的标注数据集重训。数据标注格式常见是 VOC XML 或者 COCO JSON；Caffe SSD 训练一般要转成 LMDB，PyTorch 实现则直接读文件夹。对新手来说，我建议第一轮不要自己训练，先用官方权重把整条 RKNN 链路跑通，确认板端能出框，再回头做定制化训练。
第二段是模型转换与量化。PC 上装 rknn-toolkit，把 caffemodel 或 ONNX 转成 .rknn。这一步通常伴随 INT8 量化，需要准备一个校准图片集，让工具统计每层激活值的分布。
第三段是板端运行。把 .rknn 文件拷贝到板子，写一段 C 或 C++ 程序调用 RKNN API 完成初始化、推理、后处理。这里不推荐用 Python 在板端跑推理，RV1126 的 CPU 有限，Python 解释器开销和内存拷贝会让帧率掉一大截。
第四段是业务接入。检测结果从后处理出来后，要画框、报警、上报，或者喂给上层业务做联动。常见做法是把检测结果封装成结构体，通过消息队列交给应用层，不要在上层做耗时操作来拖垮推理循环。
3. 模型转换与量化：把 Caffe/ONNX 模型变成 .rknn
3.1 准备 Caffe SSD 模型与部署必需文件
Caffe 时代的 SSD 仓库大多以.prototxt描述网络结构、.caffemodel存权重。RKNN 工具转换时需要的只是 deploy 版本，也就是去掉训练相关层、只剩前向推理结构的 prototxt。你手里如果只有训练用的train.prototxt，开启数据增强和loss层之后 RKNN 是解析不过去的。
我拿到一个模型后，习惯先做两件事：第一，用交叉编译器或者直接把 prototxt 里input_shape和layer扫一遍，确认输入分辨率。SSD 常见的是 300×300，也有 512×512 的变体，这个数值后面在板端初始化rknn_input时要一字不差地对上。第二，确认网络输出的 blob 名字。Caffe SSD 的常规输出是三段：位置输出命名类似mbox_loc，置信度输出类似mbox_conf_flatten，先验框输出类似mbox_priorbox。名字不一定完全一致，但你要知道哪一个是 loc、哪一个是 conf、哪一个给 prior box，否则板端后处理无从下手。不放心的话，可以在转换后先用 rknn-toolkit 自带的 inference 接口随便喂一张图，把输出的 tensor 形状打出来核对。
3.2 用 rknn-toolkit 做一次最小转换
最常见的转换方式是在 PC 上安装 rknn-toolkit，写一个 Python 脚本完成加载、构建、导出。下面这段是从 Caffe 版本转换的最小脚本，也是我每次新项目起步的模板：
from rknn.api import RKNN rknn = RKNN(verbose=True) # target_platform 用 rv1126，不要默认成 rk3588/rk3399pro rknn.config( target_platform='rv1126', # SSD-MobileNet 常见输入预处理是 (pixel - 127.5) / 127.5 mean_values=[[127.5, 127.5, 127.5]], std_values=[[127.5, 127.5, 127.5]], ) ret = rknn.load_caffe( model='ssd_mobilenet.caffemodel', proto='ssd_mobilenet_deploy.prototxt' ) assert ret == 0, 'load_caffe failed' ret = rknn.build( do_quantization=True, dataset='calib_data.txt' ) assert ret == 0, 'build failed' ret = rknn.export_rknn('ssd_rv1126.rknn') assert ret == 0, 'export failed'这个脚本里三个关键参数要说明。第一是target_platform，RV1126 的 NPU 指令集和 RK3588 等平台不一样，转出来的 .rknn 不能互相跑；写错平台后板端会报invalid model。第二是mean_values和std_values，这里的数值不是随便填的，必须和你训练代码或原始 Caffe 模型的数据预处理一致。SSD-MobileNet 常见预处理是(pixel - 127.5) / 127.5，所以 mean 写 127.5、std 写 127.5；如果你的训练代码是直接减均值不缩放，那 mean 写那个均值、std 写 1.0。这里填错了，量化后的模型可能在输出置信度上大面积漂移。第三是dataset指向一个文本文件，每行放一张校准图片的绝对路径，这个是量化用的，不是测试用的，后面会专门讲。
如果 RKNN 版本比较新，并且你手上的模型是 ONNX，加载那一行改成rknn.load_onnx(model='ssd_mobilenet.onnx')即可，后面的 build、export 流程完全一样。常见的坑是 ONNX 导出时把某些后处理算子也导进去了，比如NonMaxSuppression算子。我的建议是导出时只保留 backbone 和检测头，NMS 和 anchor 解码全部放到板端 C 代码实现。
3.3 量化校准集：决定 INT8 精度的隐形变量
量化并不是直接把 FP32 权重压成 INT8 那么简单。RKNN 在量化时需要一批真实图片作为校准集，统计每个中间层激活值的 min/max，然后决定 scale 和 zero point。校准集选得不好，检测框该出的时候不出，就是典型的「量化玄学」，实际上背后是有明确原因的。
校准集的核心要求是分布贴近真实部署场景。如果部署场景是园区摄像机，校准图片就要从园区摄像机的机位角度去截取，白天、阴天、傍晚都要有；如果场景是农场的鸟类目标检测，校准图里就得包含远景的鸟和近景的鸟，不能全是热门数据集里那种居中大目标。数量上不用很多，一百到三百张足够，但要避免两个极端：一是只有十张八张，统计出来的激活范围失真；二是直接从训练集里抽几百张满图大物体，导致部署时小物体激活值全部落到量化死区。我一般会直接从部署现场录像里抽帧选图，比用训练集更贴近真实链路。
量化还有一层安全网：如果 INT8 后精度掉得不可接受，先把do_quantization=False关掉，生成 FP16 模型上板跑一遍。如果 FP16 正常而 INT8 异常，说明问题出在量化敏感性，可以用更大校准集再试；如果 FP16 也不正常，那就是模型转换或预处理的问题，跟量化无关。这个排查顺序能帮你少走很多弯路。
3.4 Python 端模拟推理验证
在把 .rknn 拷到板子之前，我会先用 rknn-toolkit 的 Python 接口在 PC 上做一次模拟推理，这一步能省下大量板端调试时间。脚本关键部分是这样：
import numpy as np from rknn.api import RKNN rknn = RKNN() rknn.load_rknn('ssd_rv1126.rknn') # target=None 表示在 PC 模拟器上跑 ret = rknn.init_runtime(target=None) assert ret == 0 img = cv2.imread('test.jpg') img = cv2.resize(img, (300, 300)) # 注意 Caffe 模型通常输入 BGR，这里不要再转 RGB inputs = img.astype(np.uint8)[None, ...] outputs = rknn.inference(inputs=[inputs]) print([o.shape for o in outputs])模拟器能帮你确认三件事：输出 tensor 数量是否符合预期；每个输出 shape 是[1, 4*K, 1, 1]还是[1, 1, 4*K]；数值里有没有 NaN 或全 0。输出 tensor 的形状尤其重要，它直接决定你在 C 代码里解析 loc 和 conf 时的步长。很多后处理错位问题，深层原因都是这层 shape 理解错了。
4. 板端推理实战：RKNN C API 与 SSD 后处理
4.1 初始化与输入输出流程
板端推理用 C 写是最稳的。RV1126 上加载 .rknn 文件的流程很固定：先把文件读进内存缓冲区，调用rknn_init初始化上下文，然后用rknn_query查询输入输出的属性，接着循环执行rknn_inputs_set->rknn_run->rknn_outputs_get。下面是我常用的一段最小推理循环：
#include "rknn_api.h" static int load_file(const char *path, unsigned char **buf, size_t *size) { FILE *fp = fopen(path, "rb"); fseek(fp, 0, SEEK_END); *size = ftell(fp); fseek(fp, 0, SEEK_SET); *buf = (unsigned char *)malloc(*size); fread(*buf, 1, *size, fp); fclose(fp); return 0; } rknn_context ctx; unsigned char *model_buf; size_t model_size; load_file("ssd_rv1126.rknn", &model_buf, &model_size); // 初始化 NPU 上下文 int ret = rknn_init(&ctx, model_buf, model_size, 0, NULL); if (ret < 0) { printf("rknn_init failed: %d\n", ret); return -1; } // 查询输入输出属性 rknn_input_output_num io_num; rknn_query(ctx, RKNN_QUERY_IN_OUT_NUM, &io_num, sizeof(io_num)); printf("input_num=%d output_num=%d\n", io_num.n_input, io_num.n_output); rknn_tensor_attr input_attr; memset(&input_attr, 0, sizeof(input_attr)); input_attr.index = 0; rknn_query(ctx, RKNN_QUERY_INPUT_ATTR, &input_attr, sizeof(input_attr)); // input_attr.n_dims、input_attr.dims[] 就是模型要求的输入形状这里rknn_init的第一个参数是上下文指针，后面推理都要复用这个 ctx；模型 buffer 在 init 之后可以释放，不需要一直留在内存里。rknn_query拿到的input_attr.dims通常是[300, 300, 3]或[3, 300, 300]，取决于模型导出时的排布。拿到真实 shape 再分配输入缓冲，不要硬编码死在代码里。
推理循环里，输入结构体是这样填的：
rknn_input inputs[1]; inputs[0].index = 0; inputs[0].type = RKNN_TENSOR_UINT8; inputs[0].size = img_width * img_height * 3; inputs[0].fmt = RKNN_TENSOR_NHWC; inputs[0].buf = frame_buf; // 已经是 300x300x3 的连续内存 inputs[0].pass_through = 0; ret = rknn_inputs_set(ctx, 1, inputs); ret = rknn_run(ctx, NULL); rknn_output outputs[3]; for (int i = 0; i < 3; i++) { outputs[i].want_float = 1; // 直接拿浮点输出 outputs[i].index = i; } ret = rknn_outputs_get(ctx, 3, outputs, NULL); // 处理 outputs[0].buf、outputs[1].buf、outputs[2].buf rknn_outputs_release(ctx, 3, outputs);pass_through字段值得单独强调。它设成 0 时，RKNN 会按照模型要求自动做减均值、除方差这些预处理，前提是你在转换脚本里配置了 mean/std；设成 1 时，工具不做任何处理，直接把原始像素喂进去，适用于你已经把图像在 RGA 里预处理好的情况。我一般倾向设成 1 并自己控制预处理，这样板端对你完全透明，出现异常好排查；但新手更稳妥的做法是设 0，并确认转换脚本里的 mean/std 和板端摄像头图像格式一致。
4.2 SSD 先验框解码：把网络输出变成像素坐标
SSD 后处理的核心工作是把 loc 输出的四个偏移量、配合 prior box 的坐标，还原成图像上的检测框。这里的公式在不同实现里细节有差异，但最主流的 Caffe SSD 版本用的是下面这种：
// prior box 通常由网络输出，也可能是板端预生成的 typedef struct { float cx, cy, w, h; } PriorBox; typedef struct { float x1, y1, x2, y2; float score; int label; } SSDDect; // 假设 outputs[0] 是 loc，outputs[1] 是 conf，outputs[2] 是 priors float *loc = (float *)outputs[0].buf; float *conf = (float *)outputs[1].buf; float *priors = (float *)outputs[2].buf; int num_priors = output_shape[0] / 4; // 注意按实际 shape 算 // Caffe SSD 默认 variance 通常是前两个 0.1、后两个 0.2，不同仓库可能有差异 static const float var[4] = {0.1f, 0.1f, 0.2f, 0.2f}; for (int i = 0; i < num_priors; i++) { float prior_cx = priors[i * 4 + 0]; float prior_cy = priors[i * 4 + 1]; float prior_w = priors[i * 4 + 2]; float prior_h = priors[i * 4 + 3]; float loc_cx = loc[i * 4 + 0]; float loc_cy = loc[i * 4 + 1]; float loc_w = loc[i * 4 + 2]; float loc_h = loc[i * 4 + 3]; // 解码：中心点坐标 + 宽高 exp 回归 float cx = prior_cx + loc_cx * var[0] * prior_w; float cy = prior_cy + loc_cy * var[1] * prior_h; float w = prior_w * expf(loc_w * var[2]); float h = prior_h * expf(loc_h * var[3]); float x1 = cx - w / 2.0f; float y1 = cy - h / 2.0f; float x2 = cx + w / 2.0f; float y2 = cy + h / 2.0f; // 在这里截断到 [0, 1] 或 [0, 300]，取决于 prior 坐标是否归一化 // 再配合 conf 找到最大置信度类别 }这个解码过程中的坑在于 prior box 的坐标参考系。有的网络输出的 prior 是相对于 300×300 的像素坐标，有的会除以宽高归一化成 0~1。我拿到一个 SSD 模型后的第一件事，就是打印几个 prior 的原始数值：如果看到 200、150 这种量级，说明是像素坐标；如果看到 0.67、0.5 这种量级，说明是归一化坐标。对应地，画框时要么乘回 300，要么直接乘当前帧的实际宽度高度。expf那一步也要留意，极端回归值可能导致宽高爆炸，稳妥做法是加一个 clamp 上限，把 w/h 限制在图像尺寸的数倍以内。
4.3 置信度过滤与 NMS
解码出所有候选框之后，先做置信度过滤，再做非极大值抑制。SSD 每一帧生成的 prior box 有几千组，大部分置信度都很低，直接全量做 NMS 会拖慢板端速度。常见做法是先把每个类别的最高分找出来，只对超过阈值的框做 NMS：
float conf_thresh = 0.5f; int num_classes = output_shape[1] / num_priors; // 这里只演示做一个类别，多类别时对每个类分别过滤 for (int i = 0; i < num_priors; i++) { float max_score = 0.0f; int label = -1; for (int c = 1; c < num_classes; c++) { float s = conf[i * num_classes + c]; if (s > max_score) { max_score = s; label = c; } } if (label > 0 && max_score >= conf_thresh) { boxes[box_count++] = /* 上一步解码出的框 + 分数 */; } } // 经典贪心 NMS for (int i = 0; i < box_count; i++) { if (boxes[i].score < 0) continue; for (int j = i + 1; j < box_count; j++) { if (boxes[j].score < 0) continue; float iou = compute_iou(boxes[i], boxes[j]); if (iou > nms_thresh) { boxes[j].score = -1; // 直接置为丢弃 } } }NMS 阈值常规取 0.45~0.5，置信度阈值根据场景调。如果场景里允许少量误检，把置信度调到 0.3；如果要求误报率低，那就拉到 0.7。这里没有绝对答案，我习惯是先跑一批真实场景图，把阈值可视化成曲线再定。注意 NMS 的compute_iou函数要写成纯数学计算，不要引入 OpenCV 结构体，尽量减少板端 CPU 负担。RV1126 的 A7 核做几千个框的 NMS 不是瓶颈，但如果你把 OpenCV 的 Mat、vector 大量铺开用，帧率一定会被拖下来。
5. 部署避坑：5 个会让 SSD 全线翻车的问题
5.1 版本错配：rknn-toolkit、librknnrt 与 SDK 的三角关系
现象：在 PC 上转换时一切正常，板端加载 .rknn 后直接报错，错误码类似RKNN_ERR_MODEL_INVALID，或者rknn_run返回失败；有些更隐蔽的情况是加载成功，推理结果却完全随机。
原因：RKNN 工具链的 PC 端转换工具和板端运行库是配套发布的，老版本 librknnrt 不认识新版本转换出来的模型，反之亦然。很多网上教程看起来写得很超详细，但很少强调这一点。如果你同时从三个不同时间点的 SDK 里凑了一份转换脚本、一份 librknnrt.so、一份 rknn_server，就有可能踩中。
解决：换一个项目后，先确认三者的版本号来自同一套 SDK 包。具体操作方式是在板端执行rknn_server的版本查询命令，在 PC 端打印 rknn-toolkit 的版本号，保证大版本一致。升级任何一边，都要重新验证整条链路，这是血泪经验。
5.2 输出全是 NaN 或背景类置信度特别高
现象：模型转换成功，板端推理不报错，但 loc 输出里出现 NaN，或者 conf 输出里背景类得分接近 1、目标类别的得分永远很低。
原因：这是典型的预处理不一致。转换脚本里 mean/std 填了 127.5，但你开始用pass_through=1直接喂原始像素，模型拿到的数值范围完全偏离了训练时习惯的范围；或者反过来，模型训练时已经是归一化输入，你又让 RKNN 额外减了一次均值和方差。还有就是通道顺序反转：Caffe 模型通常吃 BGR，OpenCV 读出来是 BGR，但你在 RGA 转换时直接给了 RGB 数据。
解决：先统一预处理逻辑。我的排查顺序是：先在板端用pass_through=1和原始 BGR 数据喂给do_quantization=False的 FP16 模型，如果输出恢复正常，说明是量化或 mean/std 的问题；如果还是 NaN，就去看通道顺序和数值范围。用一张纯色图做单步调试，比对着真实复杂场景猜要快得多。
5.3 检测框整体偏移或缩放不对
现象：明明检测到了目标，置信度也很高，但框的位置歪了，或者框的大小和实际物体明显不匹配。目标在画面中央时框还行，目标出现边角时偏移更明显。
原因：训练时输入是 300×300 直接 resize，你板端却用了 letterbox（等比缩放并补黑边）。SSD 不像 YOLO 系那样习惯 letterbox，训练脚本滥用 letterbox 后，网络学到的坐标关系就不再是简单的线性映射。还有一种情况是 prior box 坐标被当作像素坐标乘以了图像宽度，但实际 prior 是 0~1 归一化。
解决：回到训练代码里，把预处理原样抄到板端。Caffe SSD 最常见的做法就是cv2.resize直接拉成 300×300，完全不管形变。如果训练端用了 letterbox，板端必须实现同样的黑边填充逻辑，且解码后的坐标要扣除黑边偏移量后再换算。拿一张已知目标位置的图，打印解码后的框原始坐标，和训练同款 Python 代码输出比对，能精确定位是哪一步引入的差异。
5.4 量化后精度掉了不只一截
现象：FP16 模型在板端检测框非常准，INT8 量化后，同一个视频流里的小目标漏检率大幅飙升，或者偶尔把背景误检成目标。
原因：校准集选得不好是最常见的。如果校准集来自公共数据集，光线、角度、目标尺寸和现场差异大，量化统计出的激活值范围就偏离真实数据；另一种情况是校准图片数量太少，统计到的 min/max 不具备代表性，导致小目标激活值在量化后全部变成同一档。
解决：重新从部署现场采集 100~200 张图做校准集，尽量覆盖一天中不同光照、目标不同远近的情况。如果还不行，再开混合量化——让部分敏感层保留 FP16。RKNN 工具在构建时暴露的算子粒度配置项有限，与其硬调，不如回到底层：换一批更贴场景的校准图，重跑一遍 build，观察检测结果是否恢复。量化调参在某种程度上靠直觉和经验，但校准集贴近真实场景是永远正确的方向。
5.5 帧率抖动、偶发丢帧
现象：推理单帧耗时看起来不高，但整个循环一跑起来，平均帧率上不去，偶尔还出现某一帧卡一下，时间戳间隔忽大忽小。
原因：多数情况下问题不在 NPU，而在数据通路。摄像头 V4L2 采集的满帧数不足、NV12 转 RGB 用 CPU 完成、输入缓冲每次都重新 malloc，这些都会造成额外耗时。RV1126 的 CPU 核只有四个 A7，你在后处理里大量使用 C++ vector 和 OpenCV Mat，帧率就会在 CPU 侧被卡住。
解决：把色彩转换和缩放放到 RGA 硬件去做，不要让 CPU 逐像素操作；输入输出缓冲在初始化时一次性分配好，循环内复用；用双缓冲等做法来绕开 V4L2 的排队延迟。每个阶段的耗时打上时间戳算出来，你会发现瓶颈经常出乎意料——先量化数据，再谈优化，不要凭感觉猜。
6. 不止跑通：SSD 在 RV1126 上的性能验证与进阶玩法
6.1 性能打点与阈值标定
跑通第一版后，我会立刻加一套毫秒级打点：把每帧拆分四个阶段分别计时——采帧与预处理、rknn_run、SSD 后处理、业务输出。在循环里用系统时钟记录每阶段耗时，统计一百帧的均值、最大值、P95。这样你就能知道当前方案的净推理耗时到底是多少，哪些阶段还能优化。RV1126 这类板子的帧率波动不可忽视，只看平均值的后果是上线后偶发卡顿。标定完性能后，再把置信度阈值和 NMS 阈值按真实场景重新标一版，不要沿用训练时或示例代码里的数值。
6.2 用双路 ISP 和上层 AI 做事件联动
SSD 跑通之后，RV1126 的杀手锏才有发挥空间。双路 ISP 可以同时喂 RGB 和 IR，白天走可见光检测，夜间切红外，SSD 模型不需要换，检测逻辑一样，只需在切帧时同步修改输入缓冲来源。再往上走，SSD 检测到的目标框可以作为感知层输入，交给上层系统做多步骤分析——比如在智慧交通事故检测场景里，SSD 只负责框出车辆和行人，后续是否有碰撞、滞留，由更上层的规则或大模型研判；在农田鸟类预警里，SSD 框出鸟群，上层再根据目标数量和轨迹决定是否驱赶。这种把单模型当作「眼睛」、把决策交给更高层的做法，正是现在多 AI 协作的落地姿势。从二维检测延伸到三维目标检测时，这套感知输出的清晰度也决定了后续深度估计的上限，所以别急着上复杂模型，先把 SSD 的每一帧结果做到稳定可靠，更重要。
我这几轮做下来最深的感受是：RV1126 上跑 SSD 不难，难的是把每一层预处理、解码、版本配套都管得明明白白。少依赖点「调完就行」的心态，多给自己留还原和打点的余地，后面接新模型、换场景时才不用从头翻车。希望帮到你。
本文还有配套的精品资源，点击获取
