4. 模型交付规范
无人车项目交付中，模型交付是连接算法开发与车辆实际运行的关键环节。一个完整的模型交付物，不仅仅是几个权重文件，而是一套包含模型结构、参数、运行环境、推理逻辑和性能基准的标准化工程包。如果交付物缺乏规范，轻则导致集成方无法复现实验结果，重则因模型格式不兼容或性能指标失真，引发车辆在真实道路上的决策异常。本章将围绕模型文件格式、权重文件、配置文件、推理脚本及性能指标五个核心模块，讲解无人车模型交付的工程规范与实操要点。
上图展示了无人车模型交付物的完整组成与验证链路。从模型文件格式到性能指标验证，每个环节都相互关联，缺一不可。下面我们将逐一拆解每个模块的规范要求与实战注意事项。
4.1 模型文件格式：选择与转换策略
核心原理
模型文件格式决定了模型在目标平台上的可执行性与运行效率。无人车项目通常涉及感知（目标检测、语义分割）、预测（轨迹预测）和决策规划（强化学习策略）等模型。训练阶段常用PyTorch或TensorFlow，而部署阶段则需转换为推理引擎支持的格式。常见的部署格式包括：
- ONNX（Open Neural Network Exchange）：跨框架的开放格式，适合作为中间转换层，支持PyTorch、TensorFlow等主流框架导出。
- TensorRT Engine：NVIDIA针对其GPU的优化推理引擎，支持FP16/INT8量化，延迟低，适合Orin/Xavier等车载计算平台。
- TorchScript：PyTorch的原生部署格式，适合纯PyTorch链路，但跨平台性较弱。
- TFLite：主要用于嵌入式或移动端，在无人车中较少用于主感知模型，但可用于某些轻量级传感器预处理。
判断方法与操作流程
选择模型格式时，需遵循以下判断路径：
- 确认部署硬件：若使用NVIDIA Orin/Xavier，优先考虑TensorRT；若使用x86+GPU工控机，ONNX Runtime或TensorRT均可。
- 评估算子支持：将训练模型导出为ONNX后，使用Netron可视化检查算子是否被目标推理引擎支持。例如，某些自定义ROI Align算子需替换为TensorRT支持的版本。
- 精度与速度权衡：FP32精度最高但速度慢；FP16速度提升约1.5-2倍，精度损失可忽略；INT8速度最快但需校准数据集，精度可能下降1%-3%。
- 转换验证：转换后必须用同一组输入数据对比输出张量，确保数值误差在容忍范围内（如余弦相似度>0.99）。
案例拆解：YOLOv5目标检测模型的TensorRT转换
某无人车项目需将YOLOv5s模型部署到Orin平台。初始模型为PyTorch权重（.pt），目标格式为TensorRT FP16 Engine。操作步骤如下：
- 导出ONNX：
python export.py --weights yolov5s.pt --include onnx --dynamic - 使用Netron检查ONNX，发现Focus层和SPP层在TensorRT中支持良好，无需替换。
- 构建TensorRT Engine：
trtexec --onnx=yolov5s.onnx --saveEngine=yolov5s_fp16.engine --fp16 - 验证精度：使用100张验证图片，对比PyTorch输出与TensorRT输出的mAP差异，结果为mAP下降0.2%，在可接受范围内。
- 性能测试：单帧延迟从PyTorch的12ms降至TensorRT的4.5ms，满足实时性要求。
复盘经验：转换过程中，需注意TensorRT的显存分配策略。若Engine文件过大（超过500MB），需检查是否误用了FP32模式或未启用层融合。
4.2 权重文件：版本管理与完整性校验
核心原理
权重文件是模型训练结果的载体，包含网络层的所有参数。在无人车项目中，权重文件不仅是模型文件的一部分，更是模型迭代的“源代码”。权重文件管理混乱会导致无法追溯模型性能变化，甚至因文件损坏引发推理错误。
| 权重格式 | 适用框架 | 特点 | 推荐场景 |
|---|---|---|---|
| .pth / .pt | PyTorch | 包含模型参数和优化器状态，文件较大 | 训练中断恢复、继续训练 |
| .safetensors | PyTorch / HuggingFace | 安全、加载快，不包含代码执行逻辑 | 模型发布、推理部署 |
| .ckpt | TensorFlow / PyTorch Lightning | 包含完整训练状态，便于断点续训 | 训练阶段存档 |
| .bin | TensorFlow / ONNX | 二进制权重，常与配置文件分离 | 跨框架部署 |
操作流程与规范
- 命名规范：权重文件命名应包含模型名称、版本号、训练日期和精度指标。例如：
yolov5s_v2.1_20240515_mAP0.85.pt。 - MD5校验：在交付前生成MD5值，并在交付文档中记录。集成方加载权重前先校验，防止文件传输损坏。
- 版本记录：在配置文件中记录训练框架版本（如PyTorch 2.1.0）、CUDA版本、cuDNN版本，确保环境可复现。
- 权重与模型结构分离：权重文件不应包含模型结构定义，模型结构应通过代码或配置文件加载，避免因结构变更导致权重无法加载。
4.3 配置文件：参数解耦与可复现性
核心原理
配置文件是模型交付的“说明书”，它定义了模型运行所需的全部参数，包括数据预处理参数、模型超参数、推理后处理参数和路径定义。良好的配置设计应实现“代码与参数分离”，使集成方无需修改代码即可适配不同场景。
一个标准的无人车模型配置文件（YAML格式）示例如下：
model:
name: "yolov5s"
version: "v2.1"
input_shape: [1, 3, 640, 640] # NCHW
conf_threshold: 0.45
iou_threshold: 0.5
max_detections: 100
preprocess:
resize_mode: "letterbox"
normalize: true
mean: [0.485, 0.456, 0.406]
std: [0.229, 0.224, 0.225]
color_format: "BGR"
postprocess:
nms_type: "NMS"
class_names: ["person", "car", "bicycle", "traffic_light"]
runtime:
device: "cuda:0"
precision: "fp16"
engine_path: "/opt/models/yolov5s_fp16.engine"
batch_size: 1
paths:
weights: "/opt/weights/yolov5s_v2.1.safetensors"
output_dir: "/tmp/inference_results"配置文件的验证方法
- 参数完整性检查：使用脚本读取配置文件，检查所有必填字段是否存在，类型是否正确。
- 路径有效性检查：启动推理前，验证所有路径是否存在且具有读写权限。
- 参数范围检查：例如conf_threshold应在0到1之间，input_shape的宽高应为32的倍数（满足大多数CNN下采样要求）。
4.4 推理脚本：接口标准化与依赖管理
核心原理
推理脚本是模型与无人车软件栈之间的桥梁。它封装了模型加载、输入预处理、推理执行、输出后处理的完整流程，并提供统一的调用接口。推理脚本的质量直接影响系统的可维护性和可测试性。
一个标准的推理脚本应包含以下模块：
- 模型加载器：根据配置文件加载不同格式的模型（TensorRT Engine、ONNX等），并处理异常情况。
- 预处理模块：实现图像resize、归一化、通道转换等操作，需与训练时的预处理完全一致。
- 推理执行器：调用推理引擎的API，管理输入输出张量的内存分配与拷贝。
- 后处理模块：执行NMS、阈值过滤、坐标映射等操作，输出结构化结果（如检测框列表）。
- 性能监控：记录每次推理的延迟、显存占用，便于性能评估。
依赖管理规范
交付推理脚本时，必须附带requirements.txt或environment.yaml文件，明确依赖库的版本。例如：
torch==2.1.0
tensorrt==8.6.1
onnxruntime==1.17.0
numpy==1.26.0
opencv-python==4.9.0.80
pyyaml==6.0.1pip install tensorrt直接安装，TensorRT需通过NVIDIA官网下载与CUDA版本匹配的deb包或tar包。若未在交付文档中说明，集成方可能因安装错误版本导致推理失败。
4.5 性能指标：量化与报告规范
核心原理
性能指标是模型交付的验收标准。无人车模型需要同时满足精度指标和实时性指标。精度指标反映模型识别能力，实时性指标反映计算资源占用情况。两者需在特定硬件和软件环境下测量，并记录测试条件。
| 指标类别 | 具体指标 | 测量方法 | 无人车典型要求 |
|---|---|---|---|
| 精度 | mAP@0.5:0.95 | COCO评估工具 | ≥0.50（感知模型） |
| 精度 | IoU（分割模型） | 像素级对比 | ≥0.70（车道线） |
| 延迟 | 单帧推理时间（ms） | 预热后取100次平均值 | ≤30ms（感知） |
| 吞吐量 | FPS | 连续推理1000帧计算 | ≥30 FPS |
| 资源占用 | 显存占用（MB） | nvidia-smi监控 | ≤4GB（Orin 8GB） |
| 鲁棒性 | 不同天气/光照下mAP | 使用场景测试集 | 下降≤10% |
性能测试流程
- 环境准备：记录硬件型号（如Orin 64GB）、JetPack版本、TensorRT版本、GPU频率设置。
- 预热运行：运行50次推理，使GPU达到稳定温度，避免冷启动影响。
- 正式测量：使用1000张代表性图片（包含白天、夜晚、雨天等场景），记录每帧延迟和显存峰值。
- 结果统计：计算平均延迟、P99延迟（99%请求的延迟上限）、平均FPS。
- 生成报告：输出性能测试报告，包含测试环境、测试数据、结果表格和结论。
案例拆解：性能瓶颈定位与优化
某项目在Orin上部署BEV感知模型，初始平均延迟为45ms，超出30ms的预算。通过性能分析发现：
- 预处理（图像resize和归一化）耗时8ms，原因是使用CPU执行。
- 模型推理耗时30ms，其中Transformer编码器占20ms。
- 后处理NMS耗时7ms，原因是Python实现且未使用TensorRT的NMS插件。
优化措施：
- 将预处理迁移到GPU，使用CUDA核函数，耗时降至2ms。
- 将Transformer编码器替换为TensorRT的EfficientNMS插件，后处理降至1ms。
- 启用FP16推理，模型推理降至18ms。
优化后总延迟为21ms，满足要求。复盘经验：性能优化需从全链路考虑，不能只关注模型推理时间，预处理和后处理往往成为瓶颈。