1. 课程导入与场景锚定
在数据中心里，模型上线往往意味着一次容器镜像替换或一次推理服务重启；而在 Jetson 边缘设备上，模型交付的复杂度会被放大数倍。原因并不神秘：边缘设备分散在产线、路口、门店、无人机和机器人上，算力、内存、功耗、散热、网络带宽都受限，设备可能长期离线，也可能在升级过程中断电。更关键的是，同一台 Jetson 上往往同时存在 JetPack/L4T、CUDA、TensorRT、DeepStream、驱动、容器运行时、应用代码和模型权重等多个版本维度。任何一个维度错配，都可能表现为推理精度下降、引擎反序列化失败、显存溢出，甚至设备无法启动。
本课程要解决的核心问题可以概括为一句话：如何让一个在开发机上验证通过的 AI 模型，安全、可追溯、可回滚地到达成百上千台 Jetson 设备，并在设备上稳定运行。这不是单纯的“模型转换”问题，也不是单纯的“OTA 推送”问题，而是版本治理与交付链路的系统工程。
一、边缘 AI 交付的真实痛点
先看一个典型场景。团队在 x86 工作站上用 PyTorch 训练了一个 YOLO 检测模型，导出 ONNX 后，在 Jetson Orin NX 上使用 TensorRT 8.5 构建了 FP16 引擎，验证 mAP 达标。随后，运维同学把 model.plan 和应用程序打包，通过 OTA 推送到现场 200 台设备。一周后，部分设备上报推理失败。排查发现：这些设备仍停留在 JetPack 5.0（TensorRT 8.2），而引擎是在 TensorRT 8.5 上构建的，反序列化直接报错；另有一批设备虽然 JetPack 版本正确，但显存只有 8GB，而引擎按 16GB 显存优化，运行中触发 OOM。
这个例子暴露了边缘模型交付的四个典型问题：
- 版本维度多且相互耦合：L4T、CUDA、cuDNN、TensorRT、DeepStream、驱动、容器镜像、模型权重、应用配置，任意两者不匹配都可能失败。
- 构建环境与运行环境不一致：TensorRT 引擎与构建时的 GPU 架构、TensorRT 版本、精度模式强绑定，不能跨版本、跨架构随意复制。
- 设备状态不可见：现场设备是否在线、剩余存储、当前版本、上次升级结果，往往缺少统一台账。
- 升级失败代价高：边缘设备无人值守，升级中断可能导致业务停摆，必须支持 A/B 分区、断点续传和自动回滚。
二、OTA 交付目标：不只是“推下去”
面向 Jetson 的 OTA 交付，目标不是把文件传到设备，而是建立一条可验证、可回滚、可审计的交付链。具体包括：
- 可构建：在受控环境中生成与目标设备匹配的 TensorRT 引擎或模型产物，记录构建参数。
- 可标识：每个模型、引擎、应用包都有唯一版本号和元数据，能回答“这台设备跑的是哪个版本”。
- 可分发：支持增量、断点续传、带宽受限和弱网环境下的可靠传输。
- 可验证：升级前后能校验完整性、版本兼容性和推理功能。
- 可回滚：升级失败或指标异常时，能自动或手动恢复到上一稳定版本。
- 可观测：设备上报版本、健康状态、推理时延和异常日志，形成闭环。
三、课程整体路线
本课程围绕“模型版本治理 + OTA 交付”两条主线展开，整体分为五个阶段：
- 基础与版本体系：厘清 JetPack/L4T、CUDA、TensorRT、模型格式之间的关系，建立版本矩阵思维。
- 模型构建与产物管理：从训练产物到 ONNX，再到 TensorRT 引擎，掌握构建参数、精度模式和产物命名规范。
- 版本治理机制：设计模型仓库、版本元数据、兼容性校验和灰度策略。
- OTA 交付实现：实现设备端升级代理、A/B 分区、断点续传、签名校验和回滚逻辑。
- 实战项目与排障：以一个完整的边缘视觉项目为载体，完成从模型构建到批量 OTA 的全链路交付，并处理典型故障。
下图展示了本课程的核心交付链路与版本治理对象之间的关系。它把“模型构建—版本登记—OTA 分发—设备端验证—回滚”串成一条可观察的链路，同时标出每个环节最容易出错的版本耦合点。
四、实战项目说明
课程配套一个贯穿始终的实战项目：“面向 Jetson Orin NX 的产线缺陷检测模型 OTA 交付”。项目设定如下（以下参数为教学示例，用于说明方法，不代表真实实测结果）：
| 项目要素 | 示例设定 |
|---|---|
| 目标设备 | Jetson Orin NX 16GB，JetPack 5.1.2（L4T 35.4.1） |
| 模型任务 | 缺陷检测，输入 640×640，输出类别 4 类 |
| 模型格式 | PyTorch → ONNX → TensorRT FP16 引擎 |
| 交付方式 | OTA 包 + 设备端升级代理 + A/B 分区 |
| 版本标识 | 模型版本 defect-v1.3.0，引擎哈希 sha256:... |
| 验收指标 | 推理时延 ≤ 25ms，mAP 下降 ≤ 1%，显存占用 ≤ 4GB |
在项目中，你会实际完成以下工作：在受控环境中构建 TensorRT 引擎并记录构建参数；为模型产物生成版本元数据和校验和；搭建一个轻量模型仓库；编写设备端升级代理，实现下载、校验、切换分区和自检；模拟弱网和断电场景，验证断点续传与回滚；最后通过设备上报数据判断升级是否成功。整个过程会反复遇到版本兼容问题，而解决这些问题的过程，正是本课程要训练的核心能力。
五、学习本课程后应具备的能力
- 能说清 Jetson 上各版本组件之间的关系，并建立版本兼容矩阵。
- 能独立完成从模型到 TensorRT 引擎的构建，并规范记录构建参数。
- 能设计模型版本命名、元数据和仓库结构，支持追溯与灰度。
- 能实现或配置设备端 OTA 升级代理，支持校验、A/B 分区和回滚。
- 能通过设备上报指标判断升级结果，并定位常见版本错配故障。
接下来的章节会从版本体系讲起，逐步进入构建、治理、分发和排障。你不需要一开始就记住所有版本号，但需要建立一种意识：在边缘 AI 交付中，版本不是附属信息，而是交付物的一部分。