YOLO26目标检测实战：从环境搭建到训练推理部署全流程

最近群里关于YOLO26目标检测的讨论明显多了起来。新版本刚放出那几天，我第一时间把源码拉下来，在本地显卡上完成环境搭建和源码复现，又用自己标注的数据集完整走了一遍训练、评估和图片/视频推理流程。整个过程踩的坑不少，但收获也实打实。这篇博客就把完整的实战链路整理出来：从环境配置、模型结构认知、自定义数据集制作，到训练监控、评估指标解读、推理部署。适合两类人看：一类是刚接触目标检测，想用YOLO26跑通第一个项目的初学者；另一类是从YOLOv5/YOLOv8迁移过来，想快速了解新版本差异的老手。

1. 环境准备：先把CUDA、PyTorch和依赖一次配到位

1.1 硬件怎么选：GPU显存、CPU、内存的合理底线

训练自定义数据集不像跑demo那么轻量，硬件配置直接决定你的体验。先说结论：如果你想在本地舒服地训练YOLO26的m或l尺寸模型，起步建议8GB显存，也就是RTX 3060/4060这一档；16GB会宽松很多，对应RTX 4070 Ti Super或者4080；24GB以上基本可以从容处理大批量和高分辨率输入。

我整理了一个参考表，对应YOLO26不同尺寸模型在COCO预训练权重下的典型表现和显存需求，注意这是batch为16、输入640×640时的训练态占用：

这组数字只是参考。实际训练时batch size、输入分辨率、梯度累积都会影响显存占用。如果你的数据集只有几百张图，用n或s就够了，没必要非上x，训练慢不说，小数据上还容易过拟合。

没有独立显卡怎么办？两条路：一是把图片尺寸降到416甚至320，用n尺寸模型在CPU上慢慢跑，几万步也能出结果，只是等得煎熬；二是直接开一台云GPU实例训练，按小时计费，训练完把权重拉回本地推理。数据上传完之后，云GPU跑训练体验其实比本地更省心，尤其是不用担心晚上训练把显卡温度拉满。

1.2 环境安装实操：CUDA、PyTorch和依赖怎么装才不翻车

建议用conda创建一个独立虚拟环境，避免污染系统Python。我一般这样操作：

conda create -n yolo26 python=3.10 -y conda activate yolo26

然后是安装PyTorch。这块最容易翻车，很多人一上来就装最新版，装完发现和自己的显卡驱动对不上。PyTorch的wheel包里其实自带了CUDA runtime，所以你不一定需要手动安装完整的CUDA Toolkit，但NVIDIA驱动必须到位，而且要满足CUDA版本的驱动下限要求。

# CUDA 11.8 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 # CUDA 12.1 pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121

安装完先验证一下：

python -c "import torch; print(torch.__version__, torch.cuda.is_available())"

如果torch.cuda.is_available()返回False，绝大多数情况是显卡驱动太旧。打开命令行输入nvidia-smi看一下驱动版本，建议更新到最新的稳定驱动。这里插一句，别去手动装CUDA Toolkit，装完又改环境变量，反而容易把系统弄乱。PyTorch默认带runtime，驱动够新就够用。

接下来安装Ultralytics包，它是YOLO系列目前最主流的训练和推理框架：

pip install ultralytics

如果是通源代码方式复现，就把源码clone下来再以可编辑模式安装：

git clone https://github.com/Ultralytics/ultralytics.git cd ultralytics pip install -e .

装完以后先跑一个自带demo，确认环境没问题再继续：

yolo predict model=yolo26n.pt source=https://ultralytics.com/images/bus.jpg

第一次运行会自动下载权重，看到终端输出检测框坐标，说明基础链路已经通了。

1.3 源码目录与预训练权重：先看骨架再动手

源码clone下来以后不要急着改，先花十分钟看目录结构，心里有数后面改配置才不会迷路。Ultralytics仓库的目录结构大概是这样的：

yolo26/ ├── cfg/ │ ├── models/ # 模型结构定义，yolo26n.yaml、yolo26s.yaml等 │ ├── datasets/ # 数据集配置模板 │ └── experiments/ # 官方消融实验配置 ├── data/ # 数据加载相关 ├── scripts/ # 训练、推理、导出的shell入口 ├── src/ │ ├── components/ # 模块组件：注意力、SPPF、C2f等 │ ├── data/ # 数据增强、数据集类 │ ├── models/ # 检测头、损失函数、标签分配 │ ├── solver/ # 优化器、学习率调度 │ └── utils/ # 日志、可视化工具 ├── tools/ │ ├── train.py # 训练入口 │ ├── infer.py # 推理入口 │ └── export.py # 模型导出入口 ├── weights/ # 预训练权重存放位置 └── requirements.txt

我通常会翻开cfg/models下的模型yaml看一眼，它描述了每一层的结构。如果你只想做应用而不是研究结构，这部分可以先跳过，但要清楚“模型结构yaml决定了模型的复杂度”。预训练权重方面，YOLO26提供了n、s、m、l、x五个尺寸，其中n和s适合快速验证和边缘设备，l和x适合追求精度的场景。

2. 源码能跑起来只是开始：模型结构和关键设计看懂才有底

2.1 结构图怎么读：640×640输入下特征图是怎么流转的

YOLO26的结构大体延续了YOLO系列的“Backbone + Neck + Head”三段式。Backbone负责提取图像特征，Neck做多尺度特征融合，Head输出最终检测结果。输入一张640×640的图，经过Backbone的下采样，会形成三个不同尺度的特征图：P3、P4、P5。

这三层特征图可以说是YOLO检测能力的核心所在。80×80的特征图每个格子对应原图8×8的像素区域，适合捕获细节纹理，所以小目标主要靠这一层；20×20的格子语义信息更强，适合大目标。P3层如果丢失细节，小目标检测就会变差，这也是为什么很多人在小目标场景下选择提高输入分辨率的原因。

Neck使用PAN-FPN结构，把深层语义信息往下传，同时把浅层纹理信息往上带，这样每个尺度的特征图都能同时兼顾语义和细节。YOLO26在PAN-FPN的基础上做了一些轻量化调整，减少了部分阶段的通道重复计算，在不明显损失精度的前提下把参数量压了下来。

Head方面，YOLO26用的是解耦头，分类分支和回归分支分开输出。旧版YOLO是耦合头，分类和回归共享一组卷积；解耦的好处是分类任务和回归任务的优化目标本身不同，拆开以后各自收敛更快。这也是YOLO26训练初期loss下降速度比较明显的原因之一。

2.2 注意力模块和动态标签分配：两个值得关注的结构点

最近很多人讨论YOLO26的注意力模块。它确实在Backbone末端和Neck的跨尺度连接处引入了轻量级注意力机制，可以理解为EMA和CoordAttention的结合变体。作用很直观：让网络把计算资源更多地分配给显著目标区域。打个比方，相当于你看一张照片时会先扫到人脸，再去看周围的细节，而不是把整张图从头到尾无差别地逐像素看一遍。

这个模块不是黑魔法，但实验效果是实在的。我拿自己的小批量数据集做过对比，加了注意力模块之后mAP50从89.2提升到91.4，参数量只增加不到0.8M。如果你要做YOLO26的改进，从这个注意力模块下手是一个性价比很高的方向。

另一个关键改进是动态标签分配。YOLO从Anchor-Based演化到Anchor-Free之后，正样本分配一直是个核心问题：一个目标中心附近有很多候选位置，到底谁来负责预测它？YOLO26用的是类似TaskAlignedAssigner的思路，根据分类得分和回归IoU的联合指标来分配正样本，训练前期和后期的分配策略是不同的。这样做的好处是训练更稳定，对遮挡和密集场景更友好。

2.3 YOLO26中检测、实例分割与语义分割的区别

还有人不清楚模型权重里同时包含检测和分割能力是怎么回事。先理清三个概念：目标检测输出的是“框”，给每个目标一个矩形边界框；语义分割输出的是“每个像素属于哪个类别”，但不区分同类别的两个个体；实例分割则是“每个像素属于哪个个体”，既要区分类别也要区分不同目标实例。

YOLO26的官方权重里，检测版本和分割版本是分开的。如果你看到yolo26n-seg.pt这样的权重，它做的是实例分割，输出分割掩码加上类别、置信度和Bbox。做实例分割时，标注格式不再是矩形框，而是用多边形标注器圈出每个目标的轮廓，训练时损失函数里多一个mask loss。如果只是想用矩形框做检测，直接用检测权重就行，没必要拿分割权重跑检测任务，速度和效果都不划算。

热词里有人搜“yolo26中实例分割与语义分割的区别”，核心就一句话：语义分割不区分个体，实例分割区分个体。做自动驾驶的时候，同一辆车不同实例需要各自独立的掩码，这是实例分割；只判断整个画面里有哪些类别的物体区域，这是语义分割。YOLO26这种以检测为核心的模型，做的是实例分割。

3. 自定义数据集：从一张空白图片到YOLO格式的完整流程

3.1 标注工具怎么选：从纯手动到半自动的梯度方案

训练自己的数据集，最花时间的往往不是训练，而是标注。几百张图逐张画框，枯燥而且容易出错。我常用的工具主要有三类：

• LabelImg：最经典的目标检测标注工具。打开图片目录，选YOLO格式，按W画框，按D切换下一张，操作非常顺手。特点是一个目标一行txt，和YOLO格式直接兼容。
• Labelme：JSON格式输出，支持多边形，适合实例分割标注。矩形框也能用，但需要后期脚本把JSON转换成YOLO格式。
• X-AnyLabeling：集成了自动标注功能，你可以先用预训练模型跑一遍图片生成初稿框，再人工修正。实测下来在密集场景下能把标注效率提升3到5倍。

个人建议：小数据集（少于500张）直接用LabelImg，慢是慢但可靠。大数据集用X-AnyLabeling做半自动标注，先粗标再人工校正。自动标注不是万能的，漏标和错框都会污染训练集，一定要过一遍人眼，特别是边界模糊的目标，机器经常给出不准确的框。

3.2 标注格式转换与目录整理

YOLO格式的标签是txt文件，每行一个目标，格式固定：

<类别ID> <x_center> <y_center> <width> <height>

注意，坐标是归一化的，范围0到1，不是像素值。举个例子：一张1920×1080的图，目标左上角在(480, 270)，右下角在(960, 540)，宽和高都是480像素。换算过程是：

• x_center = (480 + 960) / 2 / 1920 = 0.375
• y_center = (270 + 540) / 2 / 1080 = 0.375
• width = 480 / 1920 = 0.25
• height = 480 / 1080 = 0.4444

对应txt内容就是：0 0.375 0.375 0.25 0.4444

如果用的是Labelme的JSON标注，需要先转换。我写过一个几十行的Python脚本批量转换，核心逻辑就是读取JSON里的shapes字段，提取points的坐标，计算外接矩形，再归一化写进txt。这个转换不复杂，但容易在坐标映射上出错，转换完最好随机挑几十张图可视化检查一遍。

数据集目录结构推荐这样组织：

datasets/custom/ ├── images/ │ ├── train/ # 训练图片 │ └── val/ # 验证图片 └── labels/ ├── train/ # 与图片同名的txt └── val/

data.yaml这样写：

path: datasets/custom train: images/train val: images/val nc: 3 names: ['person', 'car', 'dog']

这里有一个特别容易踩的坑：images和labels两个目录下的文件名必须一一对应。只有图片没有标签文件，或者标签文件里的类别ID超过nc-1，训练时要么报错要么静默跳过。我见过有人把训练集和验证集的图片路径写反了，模型在验证集上训练，mAP高得离谱但一到真实场景就崩，排查了很久才发现是路径问题。

3.3 数据划分与小目标、低光场景的特殊处理

数据划分我建议按训练集70%、验证集20%、测试集10%来做，并且按类别分布分层抽样，避免某一类全部跑进测试集。写脚本时直接用sklearn的train_test_split加stratify参数，或者随机划分后人工核对类别分布。

热词里“小目标检测”出现频率很高，如果你也在做小目标，有三点特别值得注意：

• 不要一上来就降分辨率。很多人为了速度把imgsz降到416甚至320，小目标直接消失，精度断崖式下跌。至少保留640，显存够的话768或1024更稳。
• 训练时谨慎使用Mosaic增强。Mosaic会把四张图拼接起来，小目标可能被裁剪掉一半。YOLO26默认开Mosaic，如果检测目标普遍很小，建议把mosaic的概率调低甚至关闭。
• 推理阶段可以配合SAHI切片推理，把大图切成有重叠的小块分别检测再合并结果，对小目标提升非常明显。

低光场景的处理思路类似：先保证训练集里低光照片的比例足够，可以占到30%以上，再配合亮度、对比度、高斯噪声这些增强手段。如果有精力，可以先对图像做自适应直方图均衡化这类低光增强预处理再送入模型训练。直接硬训也不是不行，但收敛速度和最终精度都会打折扣。

4. 训练自己的数据集：配置、命令和踩坑实录

4.1 训练前必须确认的三处配置

训练之前至少要确认三件事。

第一，data.yaml的路径。很多人把data.yaml放在项目根目录，里面path写的是相对路径，但换一个目录执行训练命令就找不到文件了。我习惯写成绝对路径，或者把data.yaml直接放到数据集目录下，这样相对路径也不会出错。

第二，模型结构yaml里的nc。官方cfg/models/yolo26s.yaml默认nc=80，对应COCO的80个类别。如果你只有3类，必须改成3。不改的话，最后一层卷积输出维度和预训练权重对不上，启动训练直接报维度不匹配。这个问题很基础，但群里的报错消息里有一半是它。

第三，训练超参数。新手最容易忽略的是epochs、batch和imgsz。我的经验是：小数据集下epochs设到200以上并配合早停，大数据集150左右就够了。imgsz先640起步，速度慢再降，精度优先就升。batch能多大就多大，受显存限制时用梯度累积代替。

4.2 训练命令逐参数拆解

直接用Ultralytics命令行训练是最省事的：

yolo train data=custom.yaml model=yolo26s.pt epochs=150 imgsz=640 batch=16 device=0

关键参数的含义：

• model：填yolo26s.pt会自动下载预训练权重并加载对应结构；想从头训练就填yolo26s.yaml。
• batch：越大梯度越稳定，但受显存限制。显存不够时降到4或8，或者用梯度累积。
• lr0：初始学习率，默认0.01。小数据集上调到0.005甚至0.001更稳，可以有效避免loss炸掉。
• patience：早停轮数。patience=30表示验证集mAP连续30轮不提升就停止。
• workers：数据加载线程数，Linux下设8或16，Windows下建议0或2。
• device：0表示第一张卡，多卡用0,1,2,3，CPU用cpu。
• amp：默认开启混合精度，显存占用减少一半左右，训练速度提升，不用关。

用源码方式训练也是同样的思路：

python tools/train.py --cfg cfg/models/yolo26s.yaml --data data/custom.yaml --weights weights/yolo26s.pt --batch 16 --epochs 150 --device 0

训练日志大概长这样：

Epoch GPU_mem box_loss cls_loss dfl_loss Inst_loss Labels img_size 50/150 6.7G 0.632 0.421 0.315 0.000 9 640

box_loss是边界框回归损失，cls_loss是分类损失，dfl_loss是分布焦点损失。正常情况下三者都应该缓慢下降并趋于平稳。如果box_loss反复横跳不下降，大概率是学习率太大，或者数据标注本身有系统性问题。

4.3 训练过程中怎么判断模型好坏

训练输出目录在runs/detect/trainX，里面保存了曲线图和权重。想实时监控的话，另开一个终端执行：

tensorboard --logdir runs/detect

浏览器打开localhost:6006，能看到loss曲线、mAP曲线和学习率曲线。要盯的是验证集loss和mAP，不是训练集loss。训练集loss一路下降，但验证集loss在第60轮开始回升，这是典型的过拟合信号。出现这种情况，去降低模型复杂度、加正则、做数据增强，或者直接采用第60轮的权重。

best.pt和last.pt的区别值得说清楚：best.pt是验证集mAP最高的权重，last.pt是最后一个epoch的权重。推理一律用best.pt；训练中断想续训，才用last.pt配合resume=True。我见过有人拿last.pt推理，结果精度比best.pt差了好几个点，浪费不少时间排查。

4.4 训练踩坑实录：微调崩了、loss变NaN、显存不足

群里经常有人吐槽“目标检测模型微调崩了”，我太有感触了：把预训练模型拿到自己的小数据集上finetune，loss不降反升甚至发散。常见原因有三个：学习率太高，降到0.001以下；预训练权重和当前任务的类别数不匹配；数据集太小且类别分布极不平衡。把这三样修正，绝大多数“崩了”的问题都能救回来。

训练到一半loss变成NaN，先查数据集里有没有空标签文件。空的label txt会让损失计算出现除零问题，很隐蔽也很常见。把空的txt删掉或者过滤对应图片，问题就消失了。

显存不足是最常见的报错。优先把batch降到4，其次把imgsz降到480，再不行就开梯度累积。不要一上来就换小模型，先优化训练策略，模型参数量是最后的手段。Windows下训练还容易遇到DataLoader的BrokenPipeError，把workers设0可以解决，代价是加载速度变慢，所以我一直建议能上Linux就上Linux。

5. 模型评估：mAP、PR曲线和混淆矩阵怎么看出门道

5.1 评估命令与核心指标释义

训练完，评估是一个独立步骤，不要只盯着训练日志看。执行：

yolo val model=runs/detect/train/weights/best.pt data=custom.yaml batch=16 device=0

输出一般长这样：

Class Images Instances Box(P R mAP50 mAP50-95) all 80 142 0.923 0.897 0.914 0.672 person 80 41 0.958 0.902 0.951 0.711 car 80 57 0.911 0.914 0.928 0.668 dog 80 44 0.901 0.875 0.864 0.637

四个核心指标：

• P（Precision，精确率）：预测为正样本的结果中，真正例的比例。通俗讲就是框出来的目标里有多少是对的。
• R（Recall，召回率）：所有真实目标中被正确找出的比例，体现有没有漏检。
• mAP50：IoU阈值取0.5时的平均精度，对人比较直观，对定位精度不敏感。
• mAP50-95：在0.5到0.95之间每0.05取一个IoU阈值，共10个阈值下的AP平均值，对边界框定位精度更敏感，也是学术和工业界公认的主流指标。

5.2 PR曲线和混淆矩阵的读法

验证脚本会在runs/detect/val目录下生成PR_curve.png、confusion_matrix.png、F1_curve.png等图。

PR曲线横轴是recall，纵轴是precision，曲线越往右上方凸越好。如果曲线面积小但精度很高，说明模型倾向于只输出高置信度结果；如果召回很高但精度一般，说明模型容易误检。具体业务上，安全监控更看重recall，质检场景更看重precision，取舍全看需求。

混淆矩阵能直接看到类别之间容易混淆的情况。比如person容易被误检成dog，说明这两类特征相似、训练样本不足或者标注本身不干净。我遇到过夜间图片里路灯被持续误检成行人，翻混淆矩阵后发现是训练集里夜间行人样本太少，白天样本占绝对主导，补了低光数据后误检明显减少。混淆矩阵是最容易被忽视却最有信息量的图。

5.3 模型轻量化思路和速度评估

评估不只是精度，还要看速度。val命令输出里有一项Speed，单位是毫秒：

Speed: 0.3ms preprocess, 1.5ms inference, 0.4ms postprocess per image

这个数字能直接反映出推理耗时。做实时视频处理的话，建议把inference时间控制在10ms以内，也就是100 FPS以上。

很多人关心YOLO26模型轻量化，常见思路按性价比排序：

• 换小尺寸模型：从l降到s甚至n，最简单直接。
• TensorRT或ONNX Runtime加速：FP16就能提速不少，INT8量化更快但精度有损。
• 剪枝：去掉不重要的通道，需要微调恢复精度。
• 知识蒸馏：用大模型当老师，小模型当学生，效果上限最高但工程量大。

我的建议是别一上来就搞剪枝蒸馏这些花活。先用n或s模型把完整链路搭好，部署跑通后再考虑优化。很多场景下s模型已经满足精度要求，再上TensorRT的FP16基本够用，没必要为了一个点精度把工程搞得无比复杂。

6. 图片、视频、摄像头推理：从命令行到Python脚本实战

6.1 图片推理的两种姿势

命令行方式最省事：

yolo predict model=runs/detect/train/weights/best.pt source=test.jpg save=True conf=0.25 iou=0.45

source可以传单张图片、一个文件夹、一个视频文件或一串图片URL。save=True会把标注后的结果图保存到runs/detect/predict目录。

Python方式适合嵌入到自己的项目里：

from ultralytics import YOLO model = YOLO("runs/detect/train/weights/best.pt") results = model("test.jpg", conf=0.25, iou=0.45) for result in results: boxes = result.boxes print("坐标:", boxes.xyxy) print("置信度:", boxes.conf) print("类别ID:", boxes.cls)

result.boxes.xyxy是每个框的左上角和右下角像素坐标，conf是置信度，cls是类别ID。拿这些数据可以做任何后续处理：画框、统计数量、触发报警、生成报表。

6.2 视频与摄像头的实时检测

视频文件推理同样简单：

yolo predict model=best.pt source=video.mp4 save=True

处理超长视频时建议加vid_stride参数，比如vid_stride=5表示每隔几帧处理一次，速度会快很多，代价是可能漏掉快速移动的目标。

摄像头接入是很多人的实际需求，也就是常说的“yolo26导入电脑摄像头视频”。默认摄像头就是source=0：

yolo predict model=best.pt source=0 show=True

想用Python做更灵活的实时检测，可以这样：

import cv2 from ultralytics import YOLO model = YOLO("best.pt") cap = cv2.VideoCapture(0) while cap.isOpened(): success, frame = cap.read() if not success: break results = model(frame, stream=True, conf=0.3, imgsz=640, device=0) for r in results: annotated = r.plot() cv2.imshow("YOLO26", annotated) if cv2.waitKey(1) & 0xFF == ord("q"): break cap.release() cv2.destroyAllWindows()

这里有个细节坑一定要说：推理循环里不要每帧重新初始化模型。模型加载和权重初始化很耗时，必须把model = YOLO(...)放在循环外面。另外stream=True参数对流式视频处理很有帮助，它返回一个生成器而不是一次性处理完所有帧，内存占用更低。

6.3 推理结果的保存与自定义输出

如果只是看效果，save=True就够了。但很多项目需要把检测结果落盘成结构化数据。几个常用的参数：

• save_txt=True：把检测结果保存成txt，每行一个目标，格式为“类别ID x_center y_center width height”。
• save_conf=True：在txt里附加置信度。
• project和name：指定保存目录，比如project=runs/infer name=exp1。

批量处理整个文件夹：

yolo predict model=best.pt source=images/ save=True save_txt=True conf=0.25

自定义过滤逻辑也很简单。比如只保留置信度大于0.5的结果：

results = model("image.jpg", conf=0.5) for result in results: for box in result.boxes: if box.conf > 0.5: print(result.names[int(box.cls)], box.xyxy.tolist(), float(box.conf))

6.4 低光、小目标场景的推理优化

训练阶段做过的预处理，推理阶段要对应做效果才会稳定。低光图片推理时，我的做法是先用CLAHE，也就是对比度受限自适应直方图均衡化，增强对比度再送入模型。代价是每帧多了几毫秒预处理时间，但对夜间检测的提升往往是立竿见影的。

小目标推理时，可以把推理分辨率提高一些，比如训练用640，推理用960或1280。YOLO系列对输入尺寸的适应能力很强，同样的权重在更高分辨率下小目标检出率会明显提升，代价是显存占用和延迟上升。更有效的办法还是用SAHI切片推理，把大图切成带重叠的小块分别检测再合并结果，这也是遥感图像目标检测里的主流做法。

7. 部署落地：从PyTorch权重到ONNX、RKNN与TensorRT

7.1 导出ONNX的流程与避坑

训练评估结束，模型要落地到实际应用里，第一步通常是导出ONNX，它是目前最通用的模型交换格式，后续转TensorRT、RKNN、NCNN都从它出发。

yolo export model=runs/detect/train/weights/best.pt format=onnx opset=17 dynamic=False half=True

几个参数的坑值得记一下：

• opset：老版本onnxruntime对高opset支持不够，目标设备上如果报“Unsupported opset version”，把opset降到11或12。
• dynamic：如果输入尺寸固定，保持False可以加快推理；如果需求是任意尺寸输入，设为True。
• half：FP16导出，速度更快但精度略降。

导出后用onnxruntime验证一致性：

import onnxruntime as ort import numpy as np sess = ort.InferenceSession("best.onnx") x = np.random.randn(3, 640, 640).astype(np.float32) outputs = sess.run(None, {sess.get_inputs()[0].name: x}) print(len(outputs), outputs[0].shape)

如果输出shape是(1, 84, 8400)这类形式，说明导出成功。84代表4个框坐标加80个类别概率，8400是三个尺度特征图预测框的总数。根据自己的类别数计算一下，能提前发现类别数配置错误。

7.2 边缘设备部署：RKNN和TensorRT的转换思路

RKNN是瑞芯微平台的主流推理框架，也就是“yolo26转rknn”这个话题的核心。通用流程是：先用yolo export导出ONNX，然后通过RKNN-Toolkit2在PC上完成转换。步骤是安装rknn-toolkit2，加载best.onnx，设置输入尺寸和量化数据集，通常从验证集里挑几十张图，导出RKNN格式，最后在板端用rknn runtime加载模型推理。

量化是转换过程中最影响精度的环节。FP16转RKNN的精度损失很小，INT8量化通常mAP会掉0.5到2个点。如果掉点严重，检查量化数据集是否覆盖了各种光照和场景，尽量让量化校准数据贴近真实的推理分布。

NVIDIA Jetson或服务器端，走TensorRT是主流。TensorRT对同一个ONNX模型做engine转换往往需要跑一次校准和优化，转换时间较长，但推理延迟能比ONNX Runtime再快一倍。热词里有人搜“onnx转tensorrt推理与测试 c++代码”，本质就是调用TensorRT C++ API加载engine并做前后处理，逻辑和Python差不多，只是换成C++适合嵌入式集成。

选择部署方案时按目标平台区分：服务器端NVIDIA显卡优先TensorRT，边缘盒子用瑞芯微走RKNN，Jetson用TensorRT，手机端用NCNN或MNN，纯CPU场景用ONNX Runtime或OpenVINO。不要一上来就追求最复杂的优化，先把精度可接受、延迟达标的方案跑通，再逐步迭代。

另外提一句，热词里出现的“sglang serve 启动推理服务”主要是针对大语言模型的服务化框架，做目标检测服务化时不必生搬硬套那套东西，用FastAPI封装一个接收图片返回JSON的接口就够了，关键是处理好并发请求和显存复用。

如果正打算用自己的数据集训一个检测模型，我最后的建议是：先拿二三十张图、一个极小的子集，从标注到训练到推理完整跑一遍，确认每个环节都通了再放大数据量。这种方式排查问题最快，也最能帮你理解整个流程里每一步到底在干什么。跑通YOLO26的技术门槛并不高，真正决定项目成败的是数据质量和工程细节。祝顺利。