资讯详情

深入了解 · 专业解读

RV1126上YOLO部署实战：从模型转换到NPU优化的完整闭环

发布时间：2026/7/10 6:08:21
RV1126上YOLO部署实战：从模型转换到NPU优化的完整闭环 1. 项目概述为什么在RV1126上部署YOLO不是“把模型拷过去就行”RV1126 是瑞芯微推出的一款面向边缘AI视觉的SoC芯片它不是一块普通ARM开发板而是一套集成了NPU3TOPS算力、ISP、双VPU和丰富视频接口的完整视觉处理平台。当标题里出现“rv1126 关于yolo 部署 步骤”时真正要解决的从来不是“怎么跑通一个YOLO”而是——如何让YOLO这个为GPU服务器设计的通用目标检测框架在一颗资源受限、指令集特殊、内存带宽紧张、驱动栈封闭的嵌入式AI芯片上既保持可用精度又满足实时性、低功耗与工业级稳定性这三重硬约束。我做过不下12个RV1126落地项目从智能闸机人脸抓拍到产线螺丝缺漏检测踩过最深的坑就是直接拿PyTorch训练好的YOLOv5s模型用ONNX导出后扔进RKNN Toolkit转换结果推理帧率只有8fpsCPU占用飙到95%NPU根本没怎么动。后来才明白RV1126的NPU不是“兼容ONNX”而是“只认它自己定义的量化规则特定算子图结构”。你给它的输入必须是它能一口吞下去的“预制菜”而不是一整头牛让你现场宰杀。所以这个“部署步骤”本质是一条精密的流水线数据标注格式决定预处理逻辑 → 训练时就要预留量化感知通道 → 模型结构得绕开RV1126不支持的算子比如Dynamic Upsample→ 导出ONNX必须冻结shape、禁用opset高版本 → RKNN转换时要手动指定input/output layout、校准数据集必须覆盖全场景明暗变化 → 最后在板端C推理引擎里还得把NPU输出的feature map按RKNN文档里那个容易被忽略的“channel_last_to_channel_first”规则重新排布否则bbox坐标全错。关键词“rv1126”“yolo”“部署”“步骤”背后实际是三个不可割裂的层次芯片层NPU架构/内存映射/DDR带宽、框架层YOLO系列模型结构演进与算子兼容性、工程层交叉编译链/内存零拷贝/多线程调度。少理解其中一层部署就卡在某个莫名其妙的段错误或nan输出上。这不是教程照着敲就能过的实验课而是需要你拿着RV1126 TRM手册第47页的NPU寄存器定义去反推YOLOv8中Detect层的anchor计算到底该用float还是int16做中间缓存。适合谁来读如果你正面临以下任一场景这篇就是为你写的已有YOLO训练好的pt模型但客户要求必须跑在RV1126模组上采购的RV1126开发板附赠的demo只能跑官方例程你自己的模型死活加载失败在rknn_toolkit2里convert成功却inference报错“invalid input shape”查日志发现是H/W alignment没对齐用OpenCV读取的BGR图像送进RKNN模型后检测框偏移20像素怀疑是色彩空间转换问题但翻遍文档找不到ISP pipeline开关位置。这不是教你怎么安装Python包而是带你亲手拆开RV1126的NPU外壳看清YOLO的每一层tensor是怎么被它咀嚼、搬运、吐出坐标的。接下来所有步骤都建立在一个铁律之上在RV1126上模型不是部署上去的是‘长’进去的——你得顺着它的血管memory layout、呼吸节奏clock gating、消化习惯quantization scheme去重塑整个YOLO流程。2. 核心技术路径拆解为什么必须放弃“通用YOLO部署思维”2.1 RV1126 NPU的底层约束决定了YOLO改造的刚性边界RV1126的NPU不是NVIDIA Jetson那种“GPUTensorRT”的通用加速思路而是典型的ASIC设计固定算子集、专用内存池、无虚拟内存管理。它的技术白皮书里明确写了三条红线直接框死了YOLO部署的改造范围第一算子支持表是硬编码的。RV1126 NPU只原生支持Conv2D、DepthwiseConv2D、ReLU、Add、Concat、MaxPool、AvgPool、Softmax、DetectionOutput仅限SSD类等约37个算子。YOLOv5/v8中广泛使用的SiLUSigmoid Linear Unit在NPU里没有对应硬件单元必须用Sigmoid Multiply两个算子拼接实现这会额外消耗2个cycle和1次内存搬运而YOLOv8新增的Upsample(modenearest)在RV1126上会被降级为ResizeBilinear导致上采样后特征图边缘出现1~2像素模糊——这对小目标检测是致命伤。我实测过同样一张1920×1080的工地安全帽图片用原生YOLOv8 Detect层输出的bbox置信度平均下降0.15而改用nn.Upsample(scale_factor2, modebilinear, align_cornersFalse)后mAP0.5提升0.8%。第二内存对齐要求苛刻到反人类。RV1126 NPU的DMA引擎要求所有输入tensor的width和height必须是16的整数倍channel数必须是4的倍数且起始地址需按64字节对齐。这意味着你不能直接把OpenCVcv2.resize(img, (640,640))的结果喂给NPU——640虽是16的倍数但若原始图像是RGB三通道640×319201920÷4480看似合规可一旦开启YUV420输入模式工业相机常用U/V分量会被单独打包此时U平面尺寸是320×320320÷1620没问题但V平面若因ISP自动裁剪变成319×320319无法被16整除NPU直接拒绝加载。解决方案不是改代码而是在Camera HAL层强制插入padding逻辑无论传感器输出什么尺寸先用libdrm申请一块64字节对齐的buffer再用memcpy把有效像素复制过去空余位置填0。这个操作在RKNN C API里叫rknn_input_set但文档里只提了一句“ensure alignment”没告诉你不做的后果是core dump。第三量化策略不可绕过且必须全程可控。RV1126 NPU只接受INT8输入输出也是INT8中间计算用INT16 accumulator。这意味着YOLO的FP32权重必须量化但YOLO的Detect层包含大量非线性计算如sigmoid、exp直接全局量化会导致anchor回归严重失真。官方推荐方案是分层量化layer-wise quantization主干网络Backbone用对称量化symmetricneck部分如PANet用非对称量化asymmetrichead部分Detect则必须保留FP16中间计算——但这需要你在RKNN Toolkit里手动修改quantize_config.json把detect.*相关layer的quantize_method设为fp16否则转换后模型在板端运行时bbox的x,y,w,h四个值全是nan。我见过太多人卡在这里三天最后发现只是json里一个逗号写成了中文顿号。提示不要迷信“自动量化”。RV1126的校准数据集calibration dataset必须包含你实际部署场景的全部光照条件。比如做停车场车牌识别校准集里必须有逆光、雨雾、黄昏三种状态下的车牌图各占30%。用纯白天晴天图校准晚上推理时所有车牌框都会向右下角偏移15像素——这是NPU在低照度下自动提升gain导致的feature map数值漂移量化参数没覆盖这个区间。2.2 YOLO系列模型的演进与RV1126兼容性断层分析YOLO从v3到v8模型结构越来越复杂但RV1126的NPU算子支持几乎停滞在v5时代。这种代际错位造成了大量“看起来能跑实际不能用”的陷阱YOLO版本关键结构变更RV1126兼容状态实测问题解决方案YOLOv5sFocus层切片拼接 CSPNet✅ 完全支持Focus层在NPU上效率极低需4次slice2次concat替换为nn.Conv2d(3,64,6,2,2)等效感受野不变NPU cycle减少37%YOLOv6RepConv重参数化卷积⚠️ 部分支持训练时RepConv正常但ONNX导出后变为普通Conv丢失重参数化优势训练阶段禁用repconv用nn.Conv2dBNAct替代精度损失0.3%YOLOv7E-ELAN扩展ELAN MPDIoU损失❌ 不支持E-ELAN中的SplitShuffleConcat组合触发NPU算子融合失败手动重写neck用nn.Sequential(ConvConv)替代E-ELAN blockYOLOv8Anchor-free Detect DFLDistribution Focal Loss⚠️ 头部不兼容DFL分支在NPU上无法正确解析output shape异常删除DFL层改用YOLOv5的Anchor-based Detect修改loss为CIoU特别注意YOLOv8的Anchor-free机制。它的Detect层输出不再是[x,y,w,h,obj,cls]而是[reg_dist, cls_score]其中reg_dist是一个80维向量假设80类表示bbox四边距的分布概率。RV1126的DetectionOutput算子只认传统SSD格式根本解析不了这个结构。强行转换会导致RKNN runtime报错RKNN_ERR_UNSUPPORT_OP。正确做法是在YOLOv8模型导出ONNX前用torch.fx重写Detect层把DFL解码逻辑torch.softmax(reg_dist, dim1) torch.arange(0, 16).float()固化进模型输出直接变成[x,y,w,h]四维tensor。这样NPU看到的就是标准格式无需在板端用CPU做后处理——省下12ms CPU时间对30fps系统至关重要。注意YOLOv8的ultralytics库默认导出ONNX时会启用dynamic_axes这在RV1126上是毒药。必须显式设置dynamic_axesNone并用--imgsz 640固定输入尺寸。否则RKNN Toolkit会报Invalid dynamic shape因为NPU不支持动态batch或动态分辨率。2.3 部署流程的本质一条从数据源头到板端推理的端到端闭环很多人把“部署”理解为“模型转换板端运行”但在RV1126上真正的闭环必须向前延伸到数据标注向后贯穿到板端C调度前端标注格式决定预处理链路RV1126 SDK里的rknn_api.h定义了rknn_input结构体其index字段必须与ONNX模型的input name严格一致。而YOLO训练时labelImg生成的txt标注是归一化坐标x_center,y_center,w,h但RV1126的NPU输入要求是绝对像素坐标类别ID。这就意味着你不能直接用labelImg导出的数据必须在训练前用脚本将txt转为COCO JSON格式再用pycocotools生成instances_train2017.json因为RKNN的rknn_eval工具只认COCO格式的评估集。我写过一个转换脚本核心逻辑是# 将labelImg的txt转为COCO annotation for img_id, txt_path in enumerate(txt_files): with open(txt_path) as f: lines f.readlines() for line in lines: cls, x_c, y_c, w, h map(float, line.strip().split()) # 转为绝对坐标假设图像宽W640,高H640 x1 int((x_c - w/2) * 640) y1 int((y_c - h/2) * 640) w_abs int(w * 640) h_abs int(h * 640) # 构造COCO annotation dict...漏掉这步后续所有评估指标都是假的。中端训练与转换的联合优化YOLO训练时必须开启--rect参数矩形训练否则不同尺寸图像pad成正方形后NPU输入的无效区域会参与计算浪费30%以上NPU cycle。同时--batch-size不能设太大RV1126的NPU内存只有2MBbatch16时feature map buffer会溢出必须设为8或4。我在做铁路轨道异物检测时把batch从16降到4训练时间增加1.8倍但转换后的rknn模型在板端内存占用从2.1MB降到1.7MB成功避免了OOM。后端板端推理的零拷贝调度RV1126的rknn_api.h提供rknn_inputs_set函数但它默认会把host内存copy到NPU memory。对于1080p视频流每帧copy耗时8ms完全吃掉实时性。正确姿势是用mmap将camera buffer直接映射到NPU可访问地址空间调用rknn_input_set时传入phys_addr而非virt_addr。这需要你修改rockchip_rga驱动在rga_submit函数里添加dma_map_single调用。虽然麻烦但实测帧率从22fps提升到29fps。这条闭环里任何一环断裂部署就变成玄学。所谓“步骤”其实是用工程手段把这三个断点焊死的过程。3. 全流程实操详解从环境搭建到板端稳定运行3.1 开发环境准备Ubuntu 20.04 RKNN Toolkit2 的精准配置RV1126部署必须用RKNN Toolkit2非旧版ToolKit1因为它支持YOLOv8的ONNX opset 17。但官网下载的rknn-toolkit2_1.6.0-cp38-cp38-manylinux2014_x86_64.whl在Ubuntu 20.04上会报ImportError: libglib-2.0.so.0: cannot open shared object file——这是因为ToolKit2依赖glib 2.56而Ubuntu 20.04默认是2.54。解决方案不是升级系统会破坏ROS等依赖而是手动安装新版glib# 下载glib 2.66源码适配RKNN Toolkit2 wget https://download.gnome.org/sources/glib/2.66/glib-2.66.8.tar.xz tar -xf glib-2.66.8.tar.xz cd glib-2.66.8 ./configure --prefix/opt/glib266 --with-pcresystem make -j$(nproc) sudo make install # 创建软链接关键 sudo ln -sf /opt/glib266/lib/x86_64-linux-gnu/libglib-2.0.so.0 /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 sudo ldconfig接着安装RKNN Toolkit2pip3 install numpy1.21.6 # 必须指定版本新版numpy会触发onnxruntime bug pip3 install onnx1.12.0 onnxruntime1.13.1 # Toolkit2 1.6.0绑定此版本 pip3 install rknn-toolkit2-1.6.0-cp38-cp38-manylinux2014_x86_64.whl验证是否成功from rknn.api import RKNN rknn RKNN() print(rknn.version) # 应输出 1.6.0注意不要用conda环境RKNN Toolkit2的C extension与conda的ld路径冲突会导致ImportError: librknnrt.so: cannot open shared object file。必须用系统Python3.8或venv。3.2 YOLO模型改造与ONNX导出绕过所有RV1126不支持的坑以YOLOv8n为例原始模型导出ONNX会失败因为ultralytics的export.py默认启用--dynamic和--simplify。我们必须手动重写导出逻辑# yolov8_rv1126_export.py import torch from ultralytics import YOLO # 加载训练好的模型 model YOLO(yolov8n.pt) # 修改Detect层移除DFL恢复Anchor-based输出 for m in model.model.modules(): if hasattr(m, export) and m.export: # 强制替换为YOLOv5风格Detect from ultralytics.nn.modules import Detect m.__class__ Detect m.anchors torch.tensor([[[10,13], [16,30], [33,23]], [[30,61], [62,45], [59,119]], [[116,90], [156,198], [373,326]]]) / 640.0 # 导出ONNX关键参数 model.export( formatonnx, dynamicFalse, # 禁用dynamic axes simplifyFalse, # 禁用simplify会破坏NPU兼容结构 imgsz640, # 固定尺寸 batch1, # batch必须为1 devicecpu # 避免GPU显存碎片 ) # 后处理用onnx-simplifier修复opset import onnx from onnxsim import simplify onnx_model onnx.load(yolov8n.onnx) model_simp, check simplify(onnx_model, input_shapes{images: [1,3,640,640]}, dynamic_input_shapeFalse) onnx.save(model_simp, yolov8n_rv1126.onnx)导出后用Netron打开检查输入节点名必须是imagesRKNN默认识别名输出节点应有3个output080×80×3×85、output140×40×3×85、output220×20×3×85维度顺序为[N,C,H,W]确保没有NonMaxSuppression、TopK等NPU不支持算子——这些必须在板端用CPU做后处理。3.3 RKNN模型转换量化校准与参数精调创建convert_rv1126.pyfrom rknn.api import RKNN RKNN_MODEL yolov8n_rv1126.rknn ONNX_MODEL yolov8n_rv1126.onnx # 初始化RKNN rknn RKNN(verboseTrue) rknn.config( target_platformrv1126, # 必须指定 mean_values[[0,0,0]], # RV1126要求输入已减均值 std_values[[255,255,255]], # 且除以std quant_img_RGB2BGRTrue, # 自动BGR-RGB转换 quantized_dtypeasymmetric_quantized-u8, # INT8量化 optimization_level3, # 最高优化 ) # 加载ONNX print(-- Loading model) ret rknn.load_onnx(modelONNX_MODEL, inputs[images], input_size_list[[3,640,640]]) if ret ! 0: print(Load model failed!) exit(ret) # 构建含量化校准 print(-- Building model) # 校准数据集必须是真实场景的100张图存于calib_dataset/目录 ret rknn.build( do_quantizationTrue, dataset./calib_dataset.txt, # 每行一个jpg路径 pre_compileTrue # 预编译提升板端加载速度 ) if ret ! 0: print(Build model failed!) exit(ret) # 导出RKNN模型 print(-- Export RKNN model) ret rknn.export_rknn(RKNN_MODEL) if ret ! 0: print(Export rknn model failed!) exit(ret) # 释放资源 rknn.release()calib_dataset.txt内容示例/home/user/calib_dataset/001.jpg /home/user/calib_dataset/002.jpg ...关键细节mean_values和std_values必须设为[[0,0,0]]和[[255,255,255]]因为YOLO训练时通常不做归一化输入是0~255的uint8而RV1126的NPU输入要求是0~255范围的INT8。如果设成[[128,128,128]]校准后所有输出bbox坐标会整体偏移——这是血泪教训。3.4 板端C推理引擎开发内存零拷贝与多线程调度在RV1126开发板上创建inference.cpp#include rknn_api.h #include opencv2/opencv.hpp #include thread #include queue class YOLOv8Inference { private: rknn_context ctx; std::vectorrknn_input inputs; std::vectorrknn_output outputs; cv::Mat frame; public: bool init(const char* model_path) { // 加载RKNN模型 int ret rknn_init(ctx, model_path, 0); if (ret 0) { printf(rknn_init error: %d\n, ret); return false; } // 获取输入输出信息 rknn_input_output_num io_num; rknn_query(ctx, RKNN_QUERY_IN_OUT_NUM, io_num, sizeof(io_num)); inputs.resize(io_num.n_input); outputs.resize(io_num.n_output); // 配置输入关键使用物理地址避免copy inputs[0].index 0; inputs[0].type RKNN_TENSOR_UINT8; inputs[0].fmt RKNN_TENSOR_NCHW; inputs[0].size 3 * 640 * 640; // RGB 640x640 // 这里不分配内存后续用camera buffer物理地址 return true; } void run_inference(uint8_t* phys_addr) { // 直接设置物理地址零拷贝 inputs[0].buf (void*)phys_addr; // 执行推理 int ret rknn_inputs_set(ctx, io_num.n_input, inputs.data()); if (ret 0) { printf(rknn_inputs_set error: %d\n, ret); return; } ret rknn_run(ctx, nullptr); if (ret 0) { printf(rknn_run error: %d\n, ret); return; } ret rknn_outputs_get(ctx, io_num.n_output, outputs.data(), nullptr); if (ret 0) { printf(rknn_outputs_get error: %d\n, ret); return; } // 后处理NMSCPU做NPU不支持 std::vectorcv::Rect boxes; std::vectorfloat scores; post_process(outputs, boxes, scores); // 自定义NMS函数 } void post_process(const std::vectorrknn_output outputs, std::vectorcv::Rect boxes, std::vectorfloat scores) { // 解析output0/1/2执行YOLOv5风格NMS // 注意RV1126输出是INT8需转为float再计算 const uint8_t* out0 (const uint8_t*)outputs[0].buf; // ... NMS逻辑略 } };编译命令必须用RV1126交叉编译链aarch64-linux-gnu-g -O2 inference.cpp -I/opt/rknn/rknn_api/include \ -L/opt/rknn/rknn_api/lib -lrknn_api -lopencv_core -lopencv_imgproc \ -o yolov8_rv1126实操心得RV1126的rknn_api.h里rknn_output结构体的buf字段指向的是NPU memory但它是cache-coherent的。如果你在多线程里同时读取outputs[0].buf必须加std::atomic_thread_fence(std::memory_order_acquire)否则可能读到脏数据。我在做双目测距时因漏掉这行左右目检测框错位达5像素。3.5 性能调优与稳定性加固从22fps到30fps的实战技巧即使模型跑通工业场景仍需应对高温降频、内存碎片、长时间运行崩溃等问题温度控制RV1126在85℃以上会自动降频。必须在/sys/devices/platform/ff3c0000.gpu/devfreq/ff3c0000.gpu/下设置min_freq600000000600MHz并用fancontrol外接风扇。我测试过无风扇时连续运行2小时帧率从30fps跌至18fps加装PWM风扇后稳定在28~30fps。内存碎片规避RV1126的NPU memory allocator对碎片敏感。每次rknn_outputs_get后必须立即调用rknn_outputs_release否则运行10小时后会出现RKNN_ERR_NO_MEM。在C类析构函数里加~YOLOv8Inference() { if (ctx 0) { rknn_outputs_release(ctx, io_num.n_output, outputs.data()); rknn_destroy(ctx); } }看门狗守护编写watchdog.sh#!/bin/bash while true; do if ! pgrep -x yolov8_rv1126 /dev/null; then echo $(date): yolov8 crashed, restarting... /var/log/yolo.log /root/yolov8_rv1126 fi sleep 5 done加入/etc/rc.local开机自启。最终实测数据RV1126 EVB板1080p30fps输入优化项帧率CPU占用NPU占用内存占用默认配置22fps85%65%1.9GB零拷贝物理地址27fps45%92%1.7GB温控看门狗30fps稳定38%88%1.6GB4. 常见问题排查与独家避坑指南4.1 RKNN转换阶段高频报错与根因分析报错信息根本原因排查步骤解决方案RKNN_ERR_INPUT_INVALIDONNX输入shape未固定或input_size_list与模型不匹配1. 用Netron检查ONNX输入shape2. 运行python -c import onnx; monnx.load(x.onnx); print(m.graph.input)在rknn.load_onnx()中显式指定input_size_list[[3,640,640]]且ONNX导出时设dynamicFalseRKNN_ERR_QUANTIZE_FAIL校准数据集图像损坏或存在全黑/全白图1. 用identify -verbose *.jpg | grep Geometry|Mean检查图像2. 运行python check_calib.py脚本见下文删除mean值10或245的图像确保所有图尺寸≥640×640NPU要求最小输入RKNN_ERR_UNSUPPORT_OPONNX中存在NPU不支持算子如NonMaxSuppression1. 用onnx.shape_inference.infer_shapes_path(x.onnx)检查2. 查找op_type NonMaxSuppression重写YOLO模型删除NMS层或用onnxoptimizer移除该节点python -m onnxoptimizer --passes eliminate_unused_initializer,eliminate_dead_end x.onnx x_clean.onnxcheck_calib.py脚本from PIL import Image import numpy as np import sys def check_image(path): try: img Image.open(path).convert(RGB) arr np.array(img) mean arr.mean() if mean 10 or mean 245: print(fWARNING: {path} mean{mean:.1f} (too dark/bright)) if img.size[0] 640 or img.size[1] 640: print(fERROR: {path} size {img.size} 640x640) except Exception as e: print(fERROR: {path} load failed: {e}) for path in sys.argv[1:]: check_image(path)4.2 板端推理异常现象与硬件级调试现象推理结果bbox坐标整体偏移20像素根因RV1126的ISP pipeline默认开启自动白平衡AWB和自动曝光AE导致同一场景下不同帧的RGB gain值不同而NPU输入是raw sensor data未经过ISP校正。调试用rkisp工具关闭ISP# 查看当前ISP状态 rkisp -c isp_status # 关闭AWB/AE关键 rkisp -c awb_enable 0 rkisp -c ae_enable 0 rkisp -c manual_gain 1.0 # 手动设增益然后重启camera服务。实测偏移消失。现象运行2小时后突然卡死dmesg显示rknn: out of memory根因rknn_outputs_get未配对rknn_outputs_release导致NPU memory leak。调试监控NPU memory使用# 实时查看NPU memory cat /sys/kernel/debug/rknpu/mem_info # 正常应1.5MB若持续增长则存在leak解决方案在C代码中确保每次rknn_outputs_get后必跟rknn_outputs_release且用RAII封装struct RKNNOutputs { rknn_context ctx; std::vectorrknn_output outputs; RKNNOutputs(rknn_context c, int n) : ctx(c), outputs(n) {} ~RKNNOutputs() { if (ctx 0) rknn_outputs_release(ctx, outputs.size(), outputs.data()); } };现象多线程调用rknn_run时偶发segmentation fault根因RV1126的NPU driver不是线程安全的rknn_run内部有全局锁。调试用strace -e traceioctl观察系统调用会发现多个线程在争抢/dev/rknpu设备文件。解决方案用单例模式互斥锁class RKNNThreadSafe { private: static std::mutex mtx; static RKNNThreadSafe* instance; rknn_context ctx; public: static RKNNThreadSafe* get_instance() { if (!instance) { std::lock_guardstd::mutex lock(mtx); if (!instance) instance new RKNNThreadSafe(); } return instance; } void run() { std::lock_guardstd::mutex lock(mtx); // 全局串行化 rknn_run(ctx, nullptr); } };4.3 YOLO训练侧的协同优化技巧部署问题常源于训练阶段埋下的坑。以下是我在12个项目中总结的RV1126-YOLO协同训练法则法则1训练分辨率必须是16的倍数且≥640RV1126 NPU的DMA引擎要求width/height为16的倍数。若训练用--imgsz 608转换后NPU会自动pad到640但pad区域参与计算浪费cycle。必须用--imgsz 640或70416×44。法则2数据增强必须禁用mosaic和mixup这两个增强在训练时会生成不规则拼接图导致NPU校准时feature map统计失真。实测开启mosaic会使mAP0.5下降1.2%。改用--augment hsv_h

相关新闻