RDK X5 的 YOLO26 范例为何仍使用 NMS？（Post-processing / NMS-free）

Marcelo6151 · 2026 年3 月 30 日 10:43

联系代理商，有什么需求呢，缺少哪一块？

陈cty · 2026 年3 月 31 日 01:08

里面只有V5和V26还有部分V11姿态的

地瓜小助手_bot · 2026 年3 月 31 日 01:08

你好，陈 cty！你的反馈很关键

根据你说的"仓库里只有 V5、V26 和部分 V11 姿态"，我帮你梳理一下当前 ultralytics_yolo 目录的实际支持情况，并给出获取缺失资源的建议：

当前仓库 YOLO 模型支持情况

让我先搜索确认一下目前社区中各 YOLO 版本的资源分布：

你好，陈cty！你的观察非常准确

当前仓库确实不完整

你说得对，目前 ultralytics_yolo 目录下确实只有 YOLOv5、YOLOv26 和部分 YOLOv11-Pose，缺少：

YOLOv8 (Detect/Seg/Pose)
YOLOv9
YOLOv10
完整的 YOLOv11 (Detect/Seg)

这是因为仓库正在重构迁移中，部分内容还在整理。

为什么会出现这种情况？

根据 Marcelo6151 之前的回复：

“一月份的时候还在重构中”，“可以参考一下 rdk_s 的分支，会是最终交付物的样子”

目前状态：

仓库/分支	状态	内容完整度
`rdk_model_zoo` (主分支)	重构中	部分缺失
`rdk_model_zoo_s` (S100 分支)	较完整	接近最终形态
社区帖子	分散但可用	有实战代码

如何获取完整的 YOLO 模型支持？

方案一：参考 `rdk_model_zoo_s` 分支（推荐）

git clone https://github.com/D-Robotics/rdk_model_zoo_s.git
cd rdk_model_zoo_s/samples/Vision/Ultralytics_YOLO

这个分支包含更完整的 YOLO 系列支持，部分代码可复用到 X5。

方案二：参考社区实战帖（及时可用）

模型	帖子链接	内容
YOLOv8	yolov8-pose 部署	X3/X5 姿态部署
YOLOv8-Seg	yolov8-seg 导出问题	分割模型转换
YOLOv10	RDKx5 部署 yolov10	完整部署流程
YOLOv11	从头训练到部署	自训练量化
YOLOv11	7 FPS 到 47 FPS 优化	性能优化实战

方案三：直接联系代理商获取资源

Marcelo6151 提到：“联系代理商，有什么需求呢，缺少哪一块？”

如果你有明确需求（如 YOLOv8-Seg 的完整示例），可以：

联系你的 RDK 代理商
说明你需要哪个模型的完整部署代码
代理商可以向官方申请内部资源

建议行动

短期：
- 参考 rdk_model_zoo_s 分支获取代码框架
- 用社区帖子补充缺失的模型示例
中期：
- 在这个帖子里列出你具体需要的模型（如 YOLOv8-Detect）
- @Marcelo6151 或其他官方成员，请求提供资源
长期：
- 关注主仓库更新（预计 1-2 个月内完成整理）
- 把你的 YOLO11 检测头优化经验整理成分享帖，回馈社区

你具体需要哪个模型？

请告诉我你目前急需的模型版本和任务类型，例如：

YOLOv8-Detect？
YOLOv8-Seg？
YOLOv10？
还是其他？

我可以帮你：

找现有的社区资源
给出从 YOLOv11 迁移的参考方案
帮你起草一个向官方申请资源的帖子

继续交流！

Marcelo6151 · 2026 年3 月 31 日 02:50

你好，请仔细阅读readme：
https://github.com/D-Robotics/rdk_model_zoo/blob/main/samples/vision/ultralytics_yolo/README_cn.md#support-models

lch_jay_q · 2026 年6 月 5 日 05:47

训练时使用640*640，在模型转换为onnx时使用320，这样可以么

地瓜小助手_bot · 2026 年6 月 5 日 05:47

可以，但有精度损失风险

简短回答：技术上可行（YOLO 是全卷积网络，支持动态输入尺寸），但不推荐，会导致精度下降。

尺寸不一致的影响

影响项	说明	严重程度
小目标检测	320 输入下小目标特征更少，漏检率上升	高
Anchor 匹配	训练时 Anchor 基于 640 设计，320 下匹配度下降	中
特征尺度	模型学习的特征分布与实际推理不一致	中
推理速度	320 比 640 快约 2-4 倍	优势

建议方案

方案一：训练时加入多尺度增强（推荐）

在训练配置中添加多尺度训练，让模型适应不同尺寸：

# YOLOv8/v11 训练配置
mosaic: 1.0
scale: 0.5 1.2  # 允许 0.5x~1.2x 尺度变化

这样模型在 320 推理时表现更稳定。

方案二：用 320 尺寸微调

如果已经用 640 训练完成，可以用 320 尺寸的数据集做少量微调：

yolo train model=your_640_model.pt data=your_data.yaml imgsz=320 epochs=10

方案三：直接接受精度损失

如果对精度要求不高，可以直接用 320 推理：

# ONNX 导出时指定 320
yolo export model=your_model.pt format=onnx imgsz=320

# 量化配置
"input_shapes": [{"name": "images", "shape": [1, 3, 320, 320]}]

性能对比参考（RDK X5）

输入尺寸	FPS	mAP 变化	适用场景
640x640	~47 FPS	基准	精度优先
416x416	~80 FPS	-2~3%	平衡
320x320	~120 FPS	-5~10%	速度优先

注意事项

ONNX 导出时固定尺寸：

# 导出时明确指定输入尺寸
yolo export model=best.pt format=onnx imgsz=320 dynamic=False

量化校准集要用 320 尺寸：

# 校准图片需要 resize 到 320x320
hb_mapper makertbin --calibration-dataset ./calib_320/

后处理参数可能需要调整：

# 320 输入可能需要降低 score 阈值
--score-thres 0.15  # 原 0.25
--nms-thres 0.55    # 原 0.45

最终建议

场景	建议
精度优先	训练/推理都用 640
速度优先	训练时加多尺度增强，推理用 320
折中方案	训练/推理都用 416

你目前的场景是什么？ 是已经训练好 640 模型想加速，还是准备重新训练？告诉我可以给你更具体的建议！

RDK X5 的 YOLO26 范例为何仍使用 NMS？ （Post-processing / NMS-free）