企业官网建设流程全解析

1. 项目概述：导出只是起点，验证才是交付的临门一脚

“从 PyTorch 到 ONNX：导出成功之后，还要验证什么？”——这句话背后藏着太多人踩过的坑。我带过三届校招新人，几乎每届都有人在模型导出后兴冲冲地发邮件说“ONNX 模型生成成功”，结果一跑推理就报错：输出 shape 对不上、数值偏差超 1e-3、甚至直接 segfault。导出命令torch.onnx.export()执行完没报错，控制台打印出.onnx文件路径，这只代表语法通过、图结构合法，绝不等于功能正确、数值可信、部署可用。真正决定你这个模型能不能上线、能不能进产线、能不能被下游服务调用的，是导出之后那套系统性验证动作。它不是可选项，而是模型交付流水线里强制卡点的“质量门禁”。核心关键词 PyTorch、ONNX、模型导出、验证、ONNX Runtime，每一个都指向一个实操环节：PyTorch 是源头，ONNX 是中间表示，导出是转换动作，验证是质量判据，ONNX Runtime 是落地载体。适合谁？不是只写 demo 的学生党，而是正在把训练好的 YOLOv8 检测模型塞进边缘盒子的嵌入式工程师，是把 Whisper 语音识别模型打包进 Windows 客户端的客户端开发，是给金融风控模型做量化部署的数据科学家。他们不需要知道 ONNX IR 的 opset 版本兼容性细节，但必须清楚：为什么导出时加了dynamic_axes却在 Runtime 里 infer 出来全是 1？为什么 float32 导出后 int8 量化，精度掉点超过 5%？为什么同样的.onnx文件，在 Ubuntu 上跑得飞起，在 Windows 上却提示 “Node input ‘x’ not found”？这些问题的答案，全藏在验证环节的设计里。这不是调参，是工程闭环；不是调试，是质量审计。接下来，我会用真实项目中的操作日志、报错截图（文字还原）、参数对比表格和避坑清单，带你把这套验证流程拆解到螺丝钉级别。

2. 内容整体设计与思路拆解：为什么不能只信 export() 的返回值？

2.1 导出成功的幻觉：三个层面的“假阳性”

很多人误以为torch.onnx.export()不报错 = 模型导出成功，这是最危险的认知偏差。实际上，导出过程存在三个独立的质量维度，它们彼此解耦，任何一个出问题都会导致后续部署失败，而 export() 只对第一个维度负责：

1. 语法层（Syntax）：ONNX 图的结构是否符合 IR 规范？节点类型、输入输出名、属性格式是否合法？这是 export() 唯一检查的层面。它会校验opset_version是否支持所用算子，会检查input_names是否重复，但绝不会去比对 PyTorch 和 ONNX 的输出数值。就像编译器能告诉你 C++ 代码语法没错，但不保证逻辑正确。

2. 语义层（Semantics）：ONNX 图的行为是否与原始 PyTorch 模块完全一致？这包括：所有算子的数学定义是否等价（例如torch.nn.functional.interpolate在不同 mode 下对应 ONNX 的Resize还是Upsample？）、动态轴（dynamic axes）的传播是否准确（batch size 维度设为-1，但实际 infer 时传入 batch=4，ONNX Runtime 能否正确推导出所有 tensor 的 shape？）、控制流（if/else, for loop）是否被正确展开为 subgraph？export() 对此完全不干预，它只负责“翻译”，不负责“校验翻译质量”。

3. 运行层（Runtime）：生成的.onnx文件能否被目标平台的 ONNX Runtime 成功加载、初始化、执行？这涉及更底层的依赖：Windows 上缺少onnxruntime-gpu的 CUDA 驱动绑定，ARM 设备上未启用--enable-arm编译选项，或者模型里用了opset=18的新算子，但 Runtime 版本只支持到opset=17。export() 根本不接触 Runtime，它连你的机器上装没装 onnxruntime 都不知道。

提示：我曾在一个医疗影像分割项目中栽过跟头。导出命令一行不报错，模型文件也生成了。但拿到客户现场的 Jetson AGX Orin 上一跑，onnxruntime.InferenceSession()直接抛InvalidGraph: This is an invalid model. Error in Node:xxx : No Op registered for xxx with domain_version of xx。查了三天才发现，我们用的 PyTorch 2.0 新增的torch.nn.functional.silu算子，在 ONNX opset=16 中被映射为com.microsoft::Silu，而客户环境的 onnxruntime 1.14 默认不启用com.microsoft域扩展。解决方案不是降级 PyTorch，而是导出时显式指定custom_opsets={'com.microsoft': 1}并在 Runtime 初始化时加载扩展库。这个教训让我彻底抛弃了“export 不报错就万事大吉”的想法。

2.2 验证策略的三维坐标系：数值、形状、性能

基于上述三层风险，我构建了一套“三维验证坐标系”，覆盖模型交付前必须完成的全部检查项。它不是线性流程，而是并行交叉验证：

• X轴：数值一致性（Numerical Consistency）
  核心问题：PyTorch 模型和 ONNX 模型在完全相同输入下，输出 tensor 的每个元素值是否在可接受误差范围内？这是验证的黄金标准。误差阈值不是拍脑袋定的：float32 模型通常要求max(|pytorch_out - onnx_out|) < 1e-4，int8 量化模型则放宽到1e-1（因量化本身引入噪声）。验证方式必须是逐元素比对（element-wise），而非只看 mean/sum 这类统计量——后者会掩盖局部异常。

• Y轴：形状与类型一致性（Shape & Dtype Consistency）
  核心问题：ONNX 模型的输入/输出 signature（shape、dtype、name）是否与 PyTorch 模型声明的一致？尤其当使用dynamic_axes时，Runtime 推理时传入的实际 shape 是否能被 ONNX 正确解析？例如，YOLOv5 的输出是(1, 3, 80, 80, 85)，但导出时若未正确设置dynamic_axes={'images': {0: 'batch'}}，Runtime 加载后可能显示输入 shape 为(1, 3, 640, 640)，导致无法动态 batch 推理。验证手段包括：用onnx.shape_inference.infer_shapes()补全静态 shape，用onnx.checker.check_model()做基础合规检查，以及最关键的——用 Runtime 的get_inputs()/get_outputs()API 实时读取 session 的元信息并与 PyTorch 的model.forward()签名比对。

• Z轴：运行时行为一致性（Runtime Behavior Consistency）
  核心问题：ONNX 模型在目标硬件和 Runtime 环境下的实际表现，是否与 PyTorch 在开发机上的表现一致？这包括：推理耗时是否在预期范围内（CPU 推理慢 2 倍可接受，慢 10 倍需排查）、内存占用是否暴涨（ONNX Runtime 的 memory pattern 与 PyTorch 不同）、是否出现非确定性结果（如某些 GPU 算子在不同 driver 版本下结果微异）、以及最关键的——错误处理一致性。PyTorch 遇到非法输入（如全零图像）会抛RuntimeError，ONNX Runtime 是否也抛出语义相同的异常？还是静默返回垃圾值？这点在金融、医疗等高可靠性场景至关重要。

这套三维坐标系决定了验证不是“跑个脚本看看输出一样不一样”，而是要像 QA 工程师一样，设计测试用例集（test case suite），覆盖正常输入、边界输入（如最小/最大尺寸图像）、异常输入（如 NaN、Inf、空 tensor），并记录每一项的通过率。我在公司内部推行的《ONNX 模型交付 checklist》里，明确要求这三项验证的通过率必须达到 100%，任何一项 fail 都不能进入 CI/CD 流水线。

2.3 为什么 ONNX Runtime 是唯一可信的验证载体？

有人会问：既然要验证数值一致性，为什么不直接用onnxruntime.InferenceSession加载模型，再用numpy做比对？答案是：必须用 ONNX Runtime，且必须用与生产环境完全一致的版本和配置。原因有三：

1. 算子实现差异：ONNX 是一个开放标准，但具体算子由各 Runtime 实现。onnxruntime、onnx-tensorrt、onnx-mlir对同一Gemm算子的优化策略、数值精度处理、线程调度完全不同。你在onnxruntime里验证通过，不代表在tensorrt里也能过。所以验证环境必须锁定为最终部署环境。

2. 硬件加速绑定：onnxruntime的ExecutionProvider（EP）决定了计算在哪跑。CUDAExecutionProvider会把算子下发给 GPU，TensorrtExecutionProvider会进一步用 TensorRT 优化，而CPUExecutionProvider则纯 CPU 计算。不同 EP 的数值结果可能有微小差异（GPU 的 FP32 累加顺序不同导致），这些差异必须在验证阶段就被捕获。因此，验证脚本必须支持动态切换 EP，并分别记录各 EP 下的误差分布。

3. 配置敏感性：onnxruntime.SessionOptions中的graph_optimization_level（图优化等级）、intra_op_num_threads（单算子线程数）、execution_mode（并行/串行模式）都会影响结果。例如，开启ORT_ENABLE_ALL优化可能将多个Add节点融合，改变中间计算顺序，从而影响浮点误差累积。验证时必须使用生产环境的 exact same options。

注意：我见过最离谱的案例是一个 TTS 模型（sherpa-onnx tts engine），在onnxruntimeCPU 模式下验证完美，但切换到CUDAExecutionProvider后，语音合成的韵律突然失真。排查发现是torch.nn.functional.interpolate导出的Resize算子，在 CUDA EP 下默认使用cubic插值，而 CPU EP 用的是linear。解决方案是在导出时显式指定resize_mode='linear'，并在验证脚本中强制固定 EP 的插值参数。这再次证明：验证不是“有没有”，而是“在什么条件下有没有”。

3. 核心细节解析与实操要点：手把手拆解验证四步法

3.1 第一步：构建可复现的输入数据管道（Input Pipeline）

验证的前提是输入绝对可控。如果每次 run 都用随机torch.randn()，那数值误差波动会淹没真实问题。我的做法是：固化输入种子 + 保存为 numpy 文件 + 多样化样本集。

• 种子固化：在验证脚本开头，统一设置torch.manual_seed(42)、np.random.seed(42)、random.seed(42)。这确保 PyTorch 和 numpy 生成的随机数序列完全一致。

• 输入样本集：绝不只用一个输入！我至少准备三类样本：

  1. 典型样本（Typical）：来自真实业务数据的代表性样本，如一张 640x480 的安防监控截图（YOLO）、一段 3 秒的客服通话录音（Whisper）、一个长度为 128 的电商评论文本（BERT）。这是主验证集。
  2. 边界样本（Boundary）：触发模型极端行为的输入，如 YOLO 的输入尺寸设为1x3x1x1（最小合法尺寸）、BERT 的输入 token 数设为512（最大长度）、TTS 的输入文本为空字符串""。这些样本专门用来验证 dynamic axes 和 error handling。
  3. 异常样本（Anomaly）：故意构造的非法输入，如图像 tensor 包含NaN或Inf、文本 token ID 超出 vocab size、音频 waveform 全为零。用于验证模型鲁棒性。

• 存储与加载：将所有输入样本保存为.npz文件（压缩 numpy archive），包含input_0,input_1... 等 key。验证脚本先np.load('inputs.npz')，再转成torch.tensor和ort_inputs字典。这样保证 PyTorch 和 ONNX Runtime 使用完全相同的二进制数据，排除数据预处理差异。

# 示例：构建输入样本集 import torch import numpy as np def create_input_samples(): # 典型样本：模拟 YOLO 输入 (1, 3, 640, 640) typical_img = torch.randn(1, 3, 640, 640) # 边界样本：最小尺寸 (1, 3, 1, 1) boundary_img = torch.randn(1, 3, 1, 1) # 异常样本：含 NaN anomaly_img = torch.randn(1, 3, 640, 640) anomaly_img[0, 0, 0, 0] = float('nan') # 保存为 npz np.savez_compressed( 'input_samples.npz', typical_img=typical_img.numpy(), boundary_img=boundary_img.numpy(), anomaly_img=anomaly_img.numpy() ) print("Input samples saved to input_samples.npz") create_input_samples()

实操心得：很多团队忽略“异常样本”的价值。我在一个金融风控模型项目中，PyTorch 模型对缺失值（NaN）会自动填充为 0 并继续推理，而 ONNX Runtime 直接 crash。这个 bug 在上线前一周才被发现，导致整个灰度发布延期。从此，我的验证 pipeline 强制包含 5 类异常输入：NaN、Inf、负数（对只接受正数的特征）、超长文本、空输入。这已成为我们团队的铁律。

3.2 第二步：PyTorch 前向推理与结果快照（PyTorch Forward Snapshot）

这一步的目标是获取 PyTorch 模型在完全相同输入下的“黄金标准”输出。关键在于：必须关闭所有非确定性行为，并确保输出是 detached 的 numpy array。

• 关闭非确定性：PyTorch 的 cudnn benchmark 会根据输入 shape 自动选择最优卷积算法，但这会导致相同输入在不同运行中结果微异。必须在验证前全局禁用：

  torch.backends.cudnn.benchmark = False torch.backends.cudnn.deterministic = True

• 禁用梯度与 eval 模式：即使模型没有 trainable params，也要显式调用model.eval()并用torch.no_grad()包裹前向：

  model.eval() with torch.no_grad(): pytorch_out = model(input_tensor)

  这确保 BatchNorm 使用 running_mean/var，Dropout 被关闭。

• 输出处理：pytorch_out可能是 tuple、dict 或 nested tensor。必须递归遍历，将所有 leaf tensor 转为cpu().detach().numpy()，并保存为结构化 dict：

  def tensor_to_numpy(obj): if isinstance(obj, torch.Tensor): return obj.cpu().detach().numpy() elif isinstance(obj, (list, tuple)): return type(obj)(tensor_to_numpy(x) for x in obj) elif isinstance(obj, dict): return {k: tensor_to_numpy(v) for k, v in obj.items()} else: return obj pytorch_snapshot = tensor_to_numpy(pytorch_out) np.savez_compressed('pytorch_snapshot.npz', **pytorch_snapshot)

• 关键细节：输出命名对齐：ONNX 模型的输出 name 来自output_names参数或模型本身的forward()返回值。PyTorch 快照的 key 名必须与之严格一致，否则后续比对会失败。例如，如果导出时指定了output_names=['boxes', 'scores', 'labels']，那么pytorch_snapshot的 dict 必须有这三个 key。

提示：我曾经在一个多输出检测模型上栽过坑。PyTorch 的forward()返回{'pred_boxes': ..., 'pred_scores': ...}，但我导出时写了output_names=['boxes', 'scores']。结果pytorch_snapshot里是pred_boxes，ONNX 输出是boxes，比对脚本直接 KeyError。解决方案是：在 PyTorch 快照生成前，用一个 wrapper 函数重命名输出：

def wrapped_forward(model, x): out = model(x) # 假设 out 是 dict，按导出时的 output_names 重命名 return {'boxes': out['pred_boxes'], 'scores': out['pred_scores']}

3.3 第三步：ONNX Runtime 加载与推理（ONNX Runtime Inference）

这一步是验证的核心执行体。重点在于：精确复现生产环境的 Runtime 配置，并捕获所有可能的异常。

• Session 初始化：必须显式指定providers和sess_options。以下是我的标准模板：

  import onnxruntime as ort # 生产环境配置：假设是 Windows + CUDA providers = [ ('CUDAExecutionProvider', { 'device_id': 0, 'arena_extend_strategy': 'kSameAsRequested', }), 'CPUExecutionProvider' ] sess_options = ort.SessionOptions() sess_options.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_EXTENDED sess_options.intra_op_num_threads = 0 # 使用系统默认 sess_options.execution_mode = ort.ExecutionMode.ORT_SEQUENTIAL # 加载模型 ort_session = ort.InferenceSession('model.onnx', sess_options, providers=providers)

• 输入准备：ONNX Runtime 的输入是dict[str, np.ndarray]，key 为 input name，value 为 numpy array。必须确保 dtype 和 shape 与 ONNX 模型声明完全一致。常见陷阱：

  • PyTorch 的torch.float32对应 numpy 的np.float32，但torch.float64对应np.float64，而 ONNX 通常只支持float32。导出时务必用input_sample = input_sample.to(torch.float32)。
  • 图像输入的 channel order：PyTorch 是NCHW，ONNX 也是NCHW，但如果你的预处理是 OpenCV（BGR）或 PIL（RGB），必须在输入前统一。

• 异常捕获：必须用 try-except 包裹ort_session.run()，并记录完整的 error message 和 stack trace：

  try: ort_outs = ort_session.run(None, ort_inputs) # 成功，继续比对 except Exception as e: print(f"ONNX Runtime failed: {type(e).__name__}: {str(e)}") # 记录到 error log，标记该样本 fail continue

• 输出解析：ort_session.run()返回List[np.ndarray]，顺序与output_names一致。必须将其构造成与pytorch_snapshot结构一致的 dict：

  ort_snapshot = {} for i, name in enumerate(ort_session.get_outputs()): ort_snapshot[name.name] = ort_outs[i]

注意：ort_session.get_outputs()返回的是NodeArg对象列表，其name属性就是输出名。这是确保名称对齐的唯一可靠方式，绝不能硬编码。

3.4 第四步：多维度结果比对与报告生成（Multi-dim Comparison & Reporting）

这是验证的“判决时刻”。比对不是简单np.allclose()，而是分层、分级、可追溯的审计。

• 层级一：形状与 dtype 检查
  遍历pytorch_snapshot和ort_snapshot的每个 key，比对shape和dtype：

  for key in pytorch_snapshot.keys(): if key not in ort_snapshot: print(f"ERROR: ONNX missing output '{key}'") continue pt_shape, pt_dtype = pytorch_snapshot[key].shape, pytorch_snapshot[key].dtype ort_shape, ort_dtype = ort_snapshot[key].shape, ort_snapshot[key].dtype if pt_shape != ort_shape: print(f"SHAPE MISMATCH for '{key}': PyTorch {pt_shape} vs ONNX {ort_shape}") if pt_dtype != ort_dtype: print(f"DTYPE MISMATCH for '{key}': PyTorch {pt_dtype} vs ONNX {ort_dtype}")

• 层级二：数值一致性检查
  对每个输出 tensor，计算三种误差指标：

  1. 最大绝对误差（MAE）：np.max(np.abs(pt_arr - ort_arr))
  2. 均方根误差（RMSE）：np.sqrt(np.mean((pt_arr - ort_arr) ** 2))
  3. 相对误差（Relative Error）：np.max(np.abs(pt_arr - ort_arr) / (np.abs(pt_arr) + 1e-8))

  然后按阈值判断：

  def check_numerical_consistency(pt_arr, ort_arr, atol=1e-4, rtol=1e-3): mae = np.max(np.abs(pt_arr - ort_arr)) rmse = np.sqrt(np.mean((pt_arr - ort_arr) ** 2)) # 相对误差，避免除零 rel_err = np.max(np.abs(pt_arr - ort_arr) / (np.abs(pt_arr) + 1e-8)) passed = True if mae > atol: print(f" MAE {mae:.2e} > atol {atol}") passed = False if rel_err > rtol: print(f" RelErr {rel_err:.2e} > rtol {rtol}") passed = False return passed

• 层级三：报告生成
  最终生成 HTML 报告（用 jinja2 模板），包含：

  • 每个输入样本的通过/失败状态
  • 失败详情：哪个输出、哪种误差超标、具体数值
  • 性能数据：PyTorch vs ONNX 的 avg latency（ms）、p95 latency、内存峰值
  • 环境信息：PyTorch version、ONNX version、ONNX Runtime version、CUDA version、OS

  报告不是给人看的，是给 CI/CD 流水线 parse 的。我用一个report.json文件输出结构化结果，包含{"overall_status": "PASS", "failed_tests": [...], "metrics": {...}}，上游系统据此决定是否阻断发布。

实操心得：数值阈值不是固定的。我在做 int8 量化模型验证时，发现atol=1e-1在大多数情况下够用，但对 softmax 输出（概率分布）必须用rel_err，因为其值域是 [0,1]，绝对误差意义不大。后来我写了一个自适应阈值函数：对每个输出 tensor，根据其值域动态调整atol。例如，如果pt_arr.min() > 0.9（softmax 输出），则atol = 0.05；如果pt_arr.std() < 1e-5（极小值 tensor），则atol = 1e-6。这个技巧让量化模型的验证通过率从 82% 提升到 99.7%。

4. 实操过程与核心环节实现：一个 YOLOv8 导出验证的完整 walkthrough

4.1 场景设定：将 Ultralytics YOLOv8n 检测模型导出为 ONNX 并验证

我们以开源的 Ultralytics YOLOv8n（nano 版本）为例，这是一个典型的计算机视觉检测模型，输入(1, 3, 640, 640)图像，输出三个尺度的检测头：(1, 84, 80, 80)、(1, 84, 40, 40)、(1, 84, 20, 20)（其中 84 = 4 bbox coords + 80 class scores）。目标是导出为 ONNX，并在onnxruntime-gpu下验证。

• 环境准备：

  # 创建干净环境 conda create -n yolo-onnx python=3.9 conda activate yolo-onnx pip install ultralytics onnx onnxruntime-gpu==1.16.3 # 固定版本

• PyTorch 模型加载与预处理：

  from ultralytics import YOLO import torch import numpy as np # 加载预训练模型 model = YOLO('yolov8n.pt') # 获取模型的 forward 方法（Ultralytics 封装了 detect） # 我们需要访问底层的 DetectionModel pt_model = model.model # 这是 torch.nn.Module # 构建典型输入：模拟一张 640x640 的 RGB 图像 input_tensor = torch.randn(1, 3, 640, 640, dtype=torch.float32) # 注意：Ultralytics 的预处理会 normalize，但验证时我们用 raw tensor，确保一致性

4.2 导出命令详解：为什么这些参数一个都不能少？

Ultralytics 官方提供了model.export()方法，但其默认参数对验证不友好。我手动调用torch.onnx.export()，并解释每个关键参数：

import torch.onnx # 关键参数解析： torch.onnx.export( model=pt_model, args=(input_tensor,), # 必须是 tuple，即使只有一个输入 f="yolov8n.onnx", opset_version=17, # 选 17 而非最新 18，因 ORT 1.16.3 默认支持 17，兼容性更好 do_constant_folding=True, # 折叠常量，减小模型体积，提升推理速度 input_names=['images'], # 输入名，必须与后续 ort_inputs key 一致 output_names=['output0', 'output1', 'output2'], # 输出名，Ultralytics 的 Detect head 有三个输出 dynamic_axes={ 'images': {0: 'batch', 2: 'height', 3: 'width'}, # 动态 batch、height、width 'output0': {0: 'batch', 2: 'height', 3: 'width'}, 'output1': {0: 'batch', 2: 'height', 3: 'width'}, 'output2': {0: 'batch', 2: 'height', 3: 'width'} }, verbose=False, # 关闭冗余日志 enable_onnx_checker=True, # 启用 ONNX 内置 checker，提前发现问题 )

• opset_version=17的深意：Ultralytics 2023 年底的版本开始默认用opset=18，但onnxruntime-gpu==1.16.3（当时生产环境稳定版）对opset=18的NonMaxSuppression算子支持不完善，会导致 NMS 结果错乱。降级到opset=17，其NonMaxSuppression是标准算子，兼容性 100%。这不是倒退，是工程权衡。

• dynamic_axes的陷阱：YOLO 的三个输出 tensor 的 spatial dimensions（height/width）与输入图像的 height/width 严格相关（80=640/8, 40=640/16, 20=640/32）。如果只设{'images': {0: 'batch'}}，ONNX Runtime 无法推导出输出的 spatial shape，导致get_outputs()返回的 shape 是(-1, 84, -1, -1)，无法进行 shape 检查。必须显式声明所有动态维度。

• do_constant_folding=True的收益：Ultralytics 模型中有大量torch.tensor([1.0])这样的常量，折叠后可减少图节点数 15%，实测推理速度提升 8%，且数值更稳定（避免 runtime 创建常量的微小差异）。

4.3 验证脚本核心代码：从零开始构建

以下是完整的验证脚本validate_yolov8.py，已在我司所有 YOLO 项目中复用：

import numpy as np import torch import onnxruntime as ort from ultralytics import YOLO # ------------------- 配置区 ------------------- MODEL_PATH = "yolov8n.onnx" PYTORCH_MODEL_PATH = "yolov8n.pt" INPUT_SAMPLE_PATH = "yolov8_input.npz" OUTPUT_SNAPSHOT_PATH = "yolov8_snapshot.npz" # ONNX Runtime 配置 PROVIDERS = ['CUDAExecutionProvider', 'CPUExecutionProvider'] SESSION_OPTIONS = ort.SessionOptions() SESSION_OPTIONS.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL # 数值阈值 ATOL = 1e-4 RTOL = 1e-3 # ------------------- 步骤1：准备输入 ------------------- def prepare_inputs(): # 固定种子 torch.manual_seed(42) np.random.seed(42) # 典型输入：640x640 typical = torch.randn(1, 3, 640, 640, dtype=torch.float32) # 边界输入：320x320（一半尺寸） boundary = torch.randn(1, 3, 320, 320, dtype=torch.float32) # 保存 np.savez_compressed(INPUT_SAMPLE_PATH, typical=typical.numpy(), boundary=boundary.numpy()) print(f"Inputs saved to {INPUT_SAMPLE_PATH}") # ------------------- 步骤2：PyTorch 快照 ------------------- def pytorch_snapshot(): # 加载模型 model = YOLO(PYTORCH_MODEL_PATH).model model.eval() # 关闭非确定性 torch.backends.cudnn.benchmark = False torch.backends.cudnn.deterministic = True # 加载输入 inputs = np.load(INPUT_SAMPLE_PATH) snapshots = {} for name, input_np in inputs.items(): input_tensor = torch.from_numpy(input_np) with torch.no_grad(): # Ultralytics 的 forward 返回 tuple of tensors # 我们需要适配其 Detect head 的输出结构 outputs = model(input_tensor) # outputs 是 list: [output0, output1, output2] snapshots[name] = { 'output0': outputs[0].cpu().numpy(), 'output1': outputs[1].cpu().numpy(), 'output2': outputs[2].cpu().numpy() } np.savez_compressed(OUTPUT_SNAPSHOT_PATH, **snapshots) print(f"PyTorch snapshot saved to {OUTPUT_SNAPSHOT_PATH}") # ------------------- 步骤3：ONNX Runtime 推理 ------------------- def onnx_inference(): # 加载 ONNX 模型 ort_session = ort.InferenceSession(MODEL_PATH, SESSION_OPTIONS, providers=PROVIDERS) # 加载输入 inputs = np.load(INPUT_SAMPLE_PATH) snapshots = {} for name, input_np in inputs.items(): # 构造 ort_inputs dict ort_inputs = {'images': input_np.astype(np.float32)} try: # 运行推理 ort_outs = ort_session.run(None, ort_inputs) # outputs 是 list: [output0, output1, output2] snapshots[name] = { 'output0': ort_outs[0], 'output1': ort_outs[1], 'output2': ort_outs[2] } except Exception as e: print(f"ONNX Runtime failed on {name}: {e}") snapshots[name] = None return snapshots # ------------------- 步骤4：比对与报告 ------------------- def compare_and_report(pytorch_snap, onnx_snap): report = { 'overall_status': 'PASS', 'details': [] } for sample_name in pytorch_snap.keys(): detail = {'sample': sample_name, 'status': 'PASS', 'errors': []} if onnx_snap[sample_name] is None: detail['status'] = 'FAIL' detail['errors'].append('ONNX Runtime execution failed') report['overall_status'] = 'FAIL' report['details'].append(detail) continue # 比对每个输出 for output_name in ['output0', 'output1', 'output2']: pt_arr = pytorch_snap[sample_name][output_name] ort_arr = onnx_snap[sample_name][output_name] # 形状检查 if pt_arr.shape != ort_arr.shape: detail['status'] = 'FAIL' detail['errors'].append(f"{output_name} shape mismatch: {pt_arr.shape} vs {ort_arr.shape}") continue # 数值检查 mae = np.max(np.abs(pt_arr - ort_arr)) if mae > ATOL: detail['status'] = 'FAIL' detail['errors'].append(f"{output_name} MAE {mae:.2e} > {ATOL}") report['details'].append(detail) if detail['status'] == 'FAIL': report['overall_status'] = 'FAIL' # 打印摘要 print("\n=== VALIDATION REPORT ===") print(f"Overall: {report['overall_status']}") for d in report['details']: print(f" {d['sample']}: {d['status']}") for err in d['errors']: print(f" - {err}") return report # ------------------- 主流程 ------------------- if __name__ == "__main__": print("Step