YOLOv8 Export导出功能支持的格式列表（ONNX/PB/TorchScript等）-平芜编程栈

YOLOv8 模型导出机制深度解析：打通训练与部署的“最后一公里”

在智能视觉系统从实验室走向产线、从云端落地边缘设备的过程中，一个常被忽视却至关重要的环节浮出水面——模型格式兼容性问题。你可能花了几周时间调优出一个高精度的 YOLOv8 目标检测模型，但在部署到 Android 手机或 Jetson 边缘盒子时却发现：PyTorch 的.pt文件根本跑不起来。

这正是 YOLOv8 提供强大export()导出功能的核心意义所在：它不是简单的文件转换工具，而是一套面向工程落地的“模型翻译引擎”，让开发者能以最小代价将训练成果无缝迁移至各类硬件平台。

Ultralytics 团队在设计 YOLOv8 时，已不再仅仅将其视为一个科研模型，而是作为工业级 AI 解决方案的一部分。因此，其内置的多格式导出能力成为连接算法研发与实际应用之间的关键桥梁。目前支持的主要目标格式包括 ONNX、TensorFlow SavedModel（可生成.pb冻结图）、TorchScript 等，每一种都对应着特定的部署生态和性能需求。

ONNX：跨框架互操作的事实标准

当你需要把 PyTorch 训练好的模型部署到非 Python 环境，尤其是异构硬件上，ONNX 几乎是首选路径。它的全称是 Open Neural Network Exchange，由微软、Facebook 等公司联合推出，旨在打破深度学习框架间的壁垒。

YOLOv8 对 ONNX 的支持非常成熟。底层依赖 PyTorch 自带的torch.onnx.export()接口，将动态计算图固化为静态图结构，并映射算子到 ONNX 标准操作集。整个过程对用户透明，只需一行代码即可完成：

from ultralytics import YOLO model = YOLO("yolov8n.pt") model.export(format="onnx", imgsz=640)

执行后会生成yolov8n.onnx文件，默认输入张量形状为(1, 3, 640, 640)，同时自动启用dynamic_axes参数，允许批大小和图像尺寸在推理时动态变化——这对视频流处理等场景尤为重要。

更关键的是，ONNX 并不只是个中间文件格式。它背后有ONNX Runtime这样高性能推理引擎的支持，可在 CPU、GPU（CUDA/TensorRT）、ARM 设备甚至 Web 浏览器中运行。例如，在 NVIDIA Jetson 上，你可以先导出为 ONNX，再用 TensorRT 编译成.engine引擎文件，实现 INT8 量化与层融合优化，推理速度提升数倍。

值得一提的是，虽然大多数 YOLO 结构都能顺利导出，但若你在自定义头中引入了复杂控制流（如基于输入内容的 if 分支），可能会遇到算子不支持的问题。此时建议通过--dynamic控制动态维度范围，或简化网络逻辑以保证导出稳定性。

此外，ONNX 模型可用 Netron 等可视化工具打开，直观查看节点连接、层类型和张量形状，极大方便调试与审查。这种“可解释性”在团队协作和模型交付过程中尤为宝贵。

TensorFlow 生态对接：SavedModel 与 .pb 冻结图

尽管 PyTorch 在研究领域占据主导地位，但在生产环境中，特别是移动端和云服务端，TensorFlow 仍拥有庞大的生态系统。为了兼容这一生态，YOLOv8 提供了通往 TensorFlow 的转换路径。

严格来说，YOLOv8 并不直接导出.pb文件，而是先转为 ONNX，再借助onnx-tf工具链转换为 TensorFlow 的SavedModel格式。这是一个包含图结构、权重变量和签名接口的标准目录结构，符合 TensorFlow Serving 和 TFLite Converter 的输入要求。

要启用该功能，需额外安装依赖：

pip install onnx-tf tensorflow

随后调用：

model.export(format="saved_model", imgsz=640)

此命令将生成一个名为yolov8n_saved_model/的文件夹，内含saved_model.pb和variables/子目录。这个结构可以直接用于 TensorFlow.js 部署网页应用，也可上传至 Google Cloud AI Platform 进行托管服务。

如果你确实需要单一的.pb冻结图文件（常见于旧版 TF 系统或嵌入式部署），可以通过以下脚本进一步处理：

import tensorflow as tf # 加载 SavedModel loaded = tf.saved_model.load('yolov8n_saved_model') infer = loaded.signatures['serving_default'] # 冻结图 frozen_graph = tf.graph_util.convert_variables_to_constants_v2(infer.graph.as_graph_def()) tf.io.write_graph(frozen_graph, '.', 'yolov8n_frozen.pb', as_text=False)

需要注意的是，这条转换链较长，存在一定的数值误差风险（通常应小于 1e-4）。强烈建议在转换后使用相同输入对比原始 PyTorch 模型与最终 TensorFlow 模型的输出结果，确保 MAE（平均绝对误差）控制在可接受范围内。

这类流程特别适合构建移动端 AI 应用。例如，将 YOLOv8 导出为 SavedModel 后，再通过 TFLite Converter 转换为.tflite模型，即可集成进 Android 或 iOS App 中，实现低功耗实时目标检测。

TorchScript：脱离 Python 的高性能 C++ 部署方案

如果你的应用场景追求极致性能和确定性延迟，比如工业自动化质检、自动驾驶感知模块或高频交易视觉信号识别，那么TorchScript是最值得考虑的选择。

TorchScript 是 PyTorch 官方提供的序列化格式，能将 Python 模型编译为独立于解释器的二进制文件（.torchscript），并在 C++ 环境中通过 LibTorch 运行时加载执行。这意味着你可以完全摆脱 GIL 锁、Python 垃圾回收和解释开销，获得接近原生 C++ 的推理效率。

YOLOv8 默认采用追踪模式（Tracing）进行导出：

model.export(format="torchscript", imgsz=640, dynamic=True)

该方式通过传入虚拟输入张量进行一次前向传播，记录所有实际执行的操作，生成固定结构的计算图。由于 YOLOv8 主干网络（如 CSPDarknet）结构稳定，无数据依赖型分支，因此追踪足以准确还原模型行为。

生成的.torchscript文件可通过 LibTorch 在 C++ 中轻松加载：

#include <torch/script.h> #include <iostream> int main() { // 加载模型 torch::jit::script::Module module = torch::jit::load("yolov8n.torchscript"); // 构造输入 at::Tensor input = torch::rand({1, 3, 640, 640}); // 推理 at::Tensor output = module.forward({input}).toTensor(); std::cout << "Output shape: " << output.sizes() << std::endl; return 0; }

这种方式广泛应用于 FPGA+GPU 协同架构中的主机侧调度系统、机器人控制器以及金融领域的低延迟视觉决策系统。

当然，也有局限：TorchScript 的追踪模式无法正确处理动态控制流（如循环次数由输入决定）。如果未来你扩展了 YOLO 的后处理逻辑并引入了此类结构，应改用脚本化（Scripting）模式，或提前冻结控制路径。

实际部署中的架构选择与工程权衡

在一个典型的视觉系统部署流程中，不同导出格式扮演着不同的角色。我们可以用一张简化的架构图来说明它们的流转关系：

graph LR A[PyTorch .pt] --> B[ONNX] A --> C[TorchScript] A --> D[SavedModel] B --> E[TensorRT Engine] B --> F[ONNX Runtime - Web/WASM] B --> G[OpenVINO IR] C --> H[LibTorch C++ Server] C --> I[嵌入式 Linux + CUDA] D --> J[TFLite .tflite] J --> K[Android/iOS App]

每个分支代表一条完整的部署链路：

若目标是NVIDIA GPU 边缘设备（如 Jetson AGX Orin），推荐走PyTorch → ONNX → TensorRT路径。ONNX 作为中间件，既能保留原始精度，又能被 TensorRT 充分优化，实现 FP16/INT8 加速。
若需嵌入C++ 实时控制系统（如 AGV 导航、无人机避障），优先选择TorchScript + LibTorch方案。无需启动 Python 解释器，推理延迟更可控，资源占用更低。
面向移动 App 开发者，则应走SavedModel → TFLite路线。TFLite 经过专门优化，可在 ARM CPU 上高效运行，且支持 Delegate 机制调用 NPU/GPU，兼顾功耗与性能。

无论选择哪条路径，有几个工程实践必须遵守：