YOLOv13 部署项目 — 技术栈全解
本文梳理本项目的完整技术栈,从底层硬件到上层应用,逐层说明每个技术组件的角色、版本与关联关系。
总览
┌─────────────────────────────────────────────────────┐
│ 应用层 (Python) │
│ ultralytics (训练/导出) + 自研推理/评测脚本 │
├─────────────────────────────────────────────────────┤
│ 推理引擎层 │
│ PyTorch │ ONNX Runtime │ TensorRT │
├─────────────────────────────────────────────────────┤
│ 中间表示层 │
│ ONNX (.onnx) │
├─────────────────────────────────────────────────────┤
│ GPU 计算平台 │
│ CUDA 12.8 + cuDNN + TensorRT SDK 10.16 │
├─────────────────────────────────────────────────────┤
│ 硬件层 │
│ NVIDIA RTX 5080 (16GB, Blackwell SM120) │
└─────────────────────────────────────────────────────┘
一、硬件层
组件型号 / 规格说明GPUNVIDIA GeForce RTX 5080Blackwell 架构,SM120显存16 GB GDDR7足够跑 yolov13x(推理 500MB,训练 750 TFLOPS远大于 yolov13x 需求的 230 GFLOPS驱动CUDA 12.8 兼容PyTorch 2.9.1 自带 CUDA 12.8 runtime5GB)显存带宽960 GB/s(理论峰值)推理瓶颈之一(见 NOTE.md)FP16 Tensor Core 算力
二、GPU 计算平台
2.1 CUDA 12.8
角色:NVIDIA GPU 的通用并行计算平台,所有 GPU 计算的底层基础。
- PyTorch 2.9.1 自带 CUDA 12.8 runtime(
torch的lib/目录内含 DLL) - TensorRT SDK 10.16 编译于 CUDA 12.9,但运行时 DLL 由 PyTorch 的 CUDA 12.8 提供(兼容)
- cuDNN、cuBLAS 等计算库随 CUDA 12.8 一同部署
2.2 TensorRT 10.16.1.11(完整 SDK)
角色:NVIDIA 官方深度学习推理优化引擎,专为 NVIDIA GPU 设计。
- 不在 pip 默认源中,需从 NVIDIA Developer 下载完整 SDK(
TensorRT-10.16.1.11.Windows.amd64.cuda-12.9) - 安装 SDK 内的 Python wheel:
tensorrt-10.16.1.11-cp313-none-win_amd64.whl - 核心功能在本项目中的作用:
功能说明Engine 构建将 ONNX 模型编译为 .engine(GPU 原生指令),含 kernel auto-tuningFP16 推理利用 Tensor Core,将 FP32 权重/激活转为 FP16,理论吞吐翻倍INT8 量化IInt8EntropyCalibrator2 做 KL 散度校准,模型体积减 70%算子融合自动合并 Conv+BN+Activation,减少 kernel launch 次数trtexec CLI命令行构建工具,Python API 失败时的 fallback
pip 源中的
tensorrt是精简版,不含 calibrator 类,无法做 INT8 校准。
三、中间表示层 — ONNX 1.22.0
角色:通用的深度学习模型中间格式,连接"训练框架"与"推理引擎"。
PyTorch (.pt) ──(ultralytics.export)──▶ ONNX (.onnx) ──(trtexec / ORT)──▶ 推理引擎
ONNX 文件内容
组成部分说明计算图 (Graph)节点(Conv, BatchNorm, SiLU, Concat...)+ 边(数据流向)权重参数每层的 trained weights 和 bias输入/输出定义tensor 名称、形状、数据类型元信息opset 版本、producer 名称
opset 与 dynamic axes
- 本项目导出时
opset=18,dynamic=False(固定 shape[1, 3, 640, 640]) - 固定 shape 有利于 TensorRT 做更激进的编译优化
onnx.helper / onnx.checker
onnx.checker.check_model()用于验证导出的 ONNX 文件合法性onnx.load()+onnx.shape_inference推断中间 tensor 形状
四、推理引擎层
4.1 PyTorch 2.9.1+cu128
角色:训练框架 + 基准推理后端。
在本项目中的使用方式:
用途对应脚本说明模型训练02_train.pyultralytics.YOLO.train()基准推理04_benchmark.py / 05_inference.pymodel.predict(),作为性能 baselineONNX 导出03_export.pymodel.export(format="onnx")CUDA Event 计时04_benchmark.py / 07_profile.pytorch.cuda.Event 做 GPU 端精确计时
4.2 ONNX Runtime (onnxruntime-gpu) 1.19.2
角色:跨平台通用推理引擎,支持 CPU / CUDA / TensorRT 等多种执行后端。
- CUDA EP (Execution Provider):在 GPU 上运行 ONNX 模型,性能接近 PyTorch
- CPU EP:纯 CPU 推理,适合无 GPU 环境
- INT8 支持:
onnxruntime.quantization.quantize_static()做 QDQ 量化,但 GPU 上因 CPU-GPU memcpy 反而更慢(见 NOTE.md 第五节)
4.3 TensorRT Runtime
角色:NVIDIA GPU 专属高性能推理运行时。
- 支持直接加载
.engine文件并执行推理 - 使用
pycuda管理 CUDA 内存和 Stream - 推理流程:
createExecutionContext()→setInputShape()→execute_async_v3(stream)→cuda.memcpy_dtoh()
五、训练框架 — Ultralytics 8.3.63
角色:YOLO 系列模型的官方训练与导出框架。
本项目中的核心调用:
API文件说明YOLO("yolov13x.pt")下载自动从 GitHub / ultralytics assets 下载预训练权重model.train(...)02_train.py训练配置:AdamW, cosine LR, Mosaic+MixUp, early stopmodel.export(format="onnx")03_export.py导出 FP32 ONNXmodel.export(format="onnx", half=True)03_export.py导出 FP16 ONNX(需 GPU)model.val()—验证 mAP,评估模型精度
六、图像处理 — OpenCV (cv2)
角色:图像读取、预处理、后处理(NMS)、可视化。
用途说明cv2.imread()读取输入图片(BGR 格式)cv2.resize()缩放到 640×640cv2.cvtColor(..., cv2.COLOR_BGR2RGB)BGR → RGB 色彩空间转换cv2.dnn.NMSBoxes()CPU 端非极大值抑制(去除重叠检测框)cv2.rectangle() / cv2.putText()结果可视化,绘制检测框和标签
七、数值计算 — NumPy
角色:Python 端数据搬运与数学运算。
np.transpose():HWC → CHW 维度重排np.expand_dims():添加 batch 维度np.ascontiguousarray():保证内存连续(ONNX/TRT 输入要求)- 归一化:
image / 255.0
八、GPU 原生接口 — PyCUDA
角色:Python 直接操作 CUDA API,用于 TensorRT 推理的内存管理和异步执行。
用途API分配 GPU 内存cuda.mem_alloc()CPU → GPU 数据传输cuda.memcpy_htod()GPU → CPU 数据传输cuda.memcpy_dtoh()CUDA Stream 管理cuda.Stream()同步stream.synchronize()事件计时cuda.Event() (start/stop/elapsed_time)
九、Python 基础环境
组件版本说明Python3.13最新的 Python 主版本OSWindows 11开发与运行系统包管理pip + requirements.txt基础依赖管理
requirements.txt 内容
torch>=2.0
ultralytics>=8.0
onnx>=1.14
onnxruntime-gpu==1.19.2
opencv-python>=4.8
numpy>=1.24
onnxscript>=0.1
# 以下需手动安装(非 pip 默认源)
# tensorrt → NVIDIA SDK 内的 wheel
# pycuda → pip install pycuda
十、技术栈数据流全景
┌──────────────┐
│ COCO128 数据集 │ 128 张图片 + 80 类标签
└──────┬───────┘
│
▼
┌──────────────────────────────────────────────┐
│ Python 3.13 + ultralytics 8.3.63 │
│ │
│ 训练阶段: │
│ YOLO("yolov13x.yaml").train() │
│ ├── PyTorch 2.9.1 + CUDA 12.8 │
│ ├── AdamW optimizer, Cosine LR │
│ ├── Mosaic + MixUp augmentation │
│ └── 输出: best.pt │
│ │
│ 导出阶段: │
│ model.export(format="onnx", opset=18) │
│ └── 输出: yolov13x.onnx (271 MB, FP32) │
│ model.export(format="onnx", half=True) │
│ └── 输出: yolov13x_fp16.onnx (136 MB, FP16) │
│ │
│ 转换阶段 (TensorRT SDK 10.16): │
│ trtexec --onnx=yolov13x.onnx │
│ ├── --fp16 → yolov13x_fp16.engine (126 MB) │
│ ├── --int8 → yolov13x_int8.engine (74 MB) │
│ └── 默认 → yolov13x.engine (248 MB, FP32) │
│ │
│ ORT 量化: │
│ quantize_static(yolov13x.onnx) │
│ └── 输出: yolov13x_int8.onnx (68 MB) │
└──────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ 推理阶段 (统一 Detector) │
│ │
│ 输入: 图片 / 视频 / 摄像头 (OpenCV) │
│ ├── BGR→RGB, resize 640, /255, HWC→CHW │
│ │ │
│ ├── .pt → ultralytics.YOLO.predict() │
│ ├── .onnx → onnxruntime.InferenceSession() │
│ └── .engine → TensorRT execute_async_v3() │
│ + pycuda memcpys │
│ │ │
│ └── 后处理: cv2.dnn.NMSBoxes() → 绘制检测框 │
│ │
│ 评测: CUDA Event 计时 → benchmark_results.json │
└──────────────────────────────────────────────┘
十一、项目心得
了解完yolo模型部署全景后尝试的最简单的模型部署方式,直接部署在本机的GPU上,与trae code agent共同编写,代码几乎只负责review。TensorRT也较为成熟,官方文档内容很全,Debug非常流畅。下一步尝试将yolo部署在更多的边缘设备上,如一些国产芯片(rk3588等)。
ONNX 解决"框架锁定"问题,作为 PyTorch/TensorFlow 等训练框架与各类推理引擎之间的通用中间表示,使 M×N 的适配关系简化为 M+N;TensorRT 则解决"GPU 性能"问题,通过 kernel auto-tuning、算子融合(Conv+BN+SiLU→单 kernel)、精度降级(FP16/INT8)和显存优化,将通用框架产出的模型编译为特定 GPU 架构的原生指令。在延迟、速度与模型大小三者之间,本项目中 FP16 是帕累托最优 — 手工实测 yolov13x 在 RTX 5080 上:FP32 为基准(20.63ms / 248MB),转 FP16 后延迟降至 17.14ms(1.20x 加速)、体积减半至 126MB、精度几乎无损;INT8 体积再砍至 74MB(-70%)但速度持平甚至略慢(17.82ms),原因是该模型规模的瓶颈不在显存带宽而在 kernel launch 开销(753 个算子 × 0.007ms ≈ 5ms 固定成本),量化能压缩权重读写时间却减不掉 launch 次数。一般规律是:小模型(<10M 参数)launch 占比高,量化空间极小,直接用 FP16 即可;中模型(10M~100M)FP16 仍是最佳平衡点;大模型(>100M,如 ViT/LLM)结构重、launch 占比 <1%,带宽与计算才是瓶颈,INT8 才有 2~4x 的显著加速。
实验结果表格:

