2. Jetson平台与模型部署基础

在 Jetson 上部署一个模型，真正决定“能不能跑、跑多快、跑多久”的，往往不是模型本身，而是它下面那一整套软件栈的版本是否匹配。Jetson 的软件体系可以理解为一条自底向上的依赖链：最底层是 L4T（Linux for Tegra），它提供针对 Tegra SoC 的 Linux 内核、引导固件、驱动与根文件系统；在 L4T 之上是 JetPack SDK，它把 L4T、CUDA、cuDNN、TensorRT、VPI、多媒体 API 等打包成一个可刷写的整体；再往上才是 CUDA 运行时、TensorRT 推理引擎，以及最终由 TensorRT 加载执行的模型。理解这条链的版本对应关系，是后续做模型版本治理与 OTA 交付的前提。

一、核心组件的层级与版本绑定关系

Jetson 各组件并非彼此独立升级，而是存在严格的“配套”关系。以 Jetson Orin 系列常用的 JetPack 5.1.2 为例，它对应的 L4T 版本是 35.4.1，CUDA 为 11.4，cuDNN 为 8.6，TensorRT 为 8.5.2。如果单独把 TensorRT 升到 8.6，而 L4T 仍是 35.4.1，就可能出现 CUDA 运行时符号不匹配、插件加载失败等问题。因此在实际工程中，通常以 JetPack 版本号作为整个软件栈的“锚点”，其余组件版本由它决定。

下表给出一个示例性的版本对应关系，用于说明这种绑定结构（具体数值以 NVIDIA 官方发布说明为准，此处仅作教学示例）：

JetPackL4TCUDAcuDNNTensorRT适用平台
5.1.235.4.111.48.68.5.2Orin / Xavier
6.036.312.28.98.6.2Orin
4.6.432.7.410.28.28.2.1Xavier / Nano

可以看到，JetPack 6.0 把 CUDA 从 11.x 提升到 12.x，TensorRT 也随之进入 8.6 分支。这意味着一个在 JetPack 5.1.2 上用 TensorRT 8.5 构建并序列化出来的 .plan 引擎文件，通常不能直接在 JetPack 6.0 上加载，因为 TensorRT 的序列化格式与内部算子实现会随版本变化。这是模型版本治理中必须记录“构建环境”的根本原因。

Jetson 软件栈层级与模型运行形态 应用层 业务程序 / 推理服务 / 模型文件（.onnx、.plan、.engine） 推理运行时层 TensorRT 8.5.2（GPU 执行） + DLA（Orin/Xavier 上的固定功能加速器） 计算库层 CUDA 11.4 运行时 + cuDNN 8.6 + VPI（视觉加速） 系统平台层 L4T 35.4.1（内核、驱动、固件、根文件系统） 硬件层 Jetson Orin / Xavier / Nano（GPU、DLA、CPU、内存） JetPack 5.1.2 版本锚点 L4T 35.4.1 CUDA 11.4 cuDNN 8.6 TensorRT 8.5.2 VPI 2.3 DLA 可用 模型运行形态说明： ① ONNX 模型 → TensorRT 解析构建 → 序列化为 .plan 引擎（与 TensorRT 版本强绑定） ② 引擎可在 GPU 上执行，也可将部分层卸载到 DLA，降低 GPU 占用与功耗 ③ 同一模型在不同 JetPack 版本上需重新构建引擎，不能直接复用

二、模型在边缘设备上的运行形态

在 Jetson 上，模型通常不会以原始训练框架格式直接运行。典型路径是：训练侧导出 ONNX，部署侧用 TensorRT 的 trtexec 或 Python API 解析 ONNX，做层融合、精度校准、内核选择，最终序列化成一个 .plan 文件。这个 .plan 就是边缘设备上真正加载的“运行形态”。它内部已经固化了目标平台的 SM 架构、TensorRT 版本、精度模式（FP32/FP16/INT8）以及 DLA 卸载策略。

以 Orin 为例，DLA（Deep Learning Accelerator）是独立于 GPU 的固定功能推理加速器。把卷积、池化等层卸载到 DLA，可以显著降低 GPU 占用，让 GPU 同时处理其他任务。但 DLA 对算子类型和精度有严格限制，例如某些动态 shape 或自定义插件无法在 DLA 上执行。因此构建引擎时通常需要显式指定 --useDLACore=0 并配合 --allowGPUFallback，让不支持的层回退到 GPU。

# 示例：在 Jetson Orin 上构建 TensorRT 引擎（教学示例）
trtexec --onnx=model.onnx \
        --saveEngine=model_fp16.plan \
        --fp16 \
        --useDLACore=0 \
        --allowGPUFallback \
        --workspace=2048

# 运行引擎并查看性能
trtexec --loadEngine=model_fp16.plan --iterations=100 --avgRuns=10

执行后，trtexec 会输出吞吐量、延迟、各层耗时以及 DLA 与 GPU 的层分配情况。如果发现大量层回退到 GPU，说明 DLA 利用率不足，可能需要调整模型结构或精度模式。这些输出正是判断“模型是否以预期形态运行”的直接依据。

三、版本治理视角下的关键记录项

从模型版本治理与 OTA 交付的角度看，一个可部署的模型包至少应记录以下信息：构建时使用的 JetPack/L4T 版本、TensorRT 版本、CUDA 版本、精度模式、DLA 配置、输入输出张量形状与数据类型、以及引擎文件的哈希值。缺少任何一项，都可能导致在另一台设备上加载失败或性能不达预期。

在 OTA 场景中，建议把“模型引擎 + 构建环境元数据”作为一个整体版本单元进行管理。设备端在加载前先校验元数据中的 L4T 与 TensorRT 版本是否与当前系统匹配，不匹配则拒绝加载并上报，而不是等到推理时报错。
不要假设同一 JetPack 大版本下的所有小版本都完全兼容。例如 L4T 35.4.1 与 35.3.1 虽然同属 JetPack 5.x，但内核与驱动版本不同，某些依赖底层多媒体接口的模型可能出现行为差异。OTA 前应在目标版本上重新验证。

总结来说，Jetson 上的模型部署不是“把模型拷进去”这么简单，而是要把模型编译成与目标软件栈严格匹配的引擎形态，并在版本治理中完整记录构建上下文。只有把 L4T、CUDA、TensorRT、DLA 这条链的版本关系理清楚，后续的模型版本管理、灰度发布与 OTA 回滚才有可靠的基线。

← 上一章 📖 返回目录 下一章 →