📚 课程目录第2章环境准备

2、环境准备：搭建Jetson开发环境，安装JetPack SDK、CUDA、cuDNN、TensorRT以及Python深度学习库

Jetson平台的部署优化工作，本质上是在受限的功耗与散热预算内，最大化AI推理的吞吐量与能效比。在动手编写任何模型代码之前，一个干净、版本匹配、可复现的开发环境是后续所有性能调优工作的基石。本章将系统讲解如何在Jetson设备上从零搭建完整的深度学习部署环境，重点解决JetPack SDK、CUDA、cuDNN、TensorRT以及Python库之间的版本耦合问题，并给出针对图像分类任务的实战配置建议。

上图展示了Jetson部署环境的分层架构。从底层硬件到顶层应用，每一层都依赖下一层提供的接口与算力。在实际部署中，最常见的环境问题并非某个库无法安装，而是各库之间的版本不兼容导致运行时崩溃。因此，本章的核心思路是：以JetPack SDK为版本锚点，统一CUDA/cuDNN/TensorRT的版本基线，再基于该基线安装Python依赖。

2.1 核心原理：JetPack SDK的版本耦合机制

JetPack SDK是NVIDIA为Jetson平台提供的完整软件开发套件，它并非一个单独的安装包，而是一个包含操作系统(L4T)、CUDA、cuDNN、TensorRT、多媒体API、开发者工具等组件的集合。理解JetPack的版本耦合机制是环境搭建的第一课。

JetPack的每个版本都对应一个特定的L4T (Linux for Tegra) 内核版本，而CUDA、cuDNN、TensorRT的版本又必须与L4T版本严格匹配。例如，JetPack 5.1.1对应L4T 35.4.1，内置CUDA 11.4、cuDNN 8.6、TensorRT 8.5.2。如果用户手动将CUDA升级到12.x，会导致cuDNN和TensorRT无法加载，因为它们的二进制文件是针对CUDA 11.4编译的。

  版本匹配的核心原则：不要单独升级CUDA或cuDNN。Jetson平台的驱动、CUDA运行时、cuDNN库和TensorRT引擎是作为一个整体由NVIDIA测试验证的。任何脱离JetPack基线的单独升级都可能破坏这个生态平衡。

对于图像分类任务，我们通常使用PyTorch作为训练框架，训练完成后将模型导出为ONNX或直接使用TensorRT进行推理。PyTorch的Jetson版本（由NVIDIA官方维护）同样与JetPack版本绑定。例如，JetPack 5.x对应PyTorch 1.13/2.0的Jetson预编译版，这些版本已经针对Jetson的GPU架构（如Orin的Ampere架构）进行了优化。

2.2 操作流程：从SDK Manager到Python环境验证

搭建Jetson开发环境的标准流程分为三个阶段：系统烧录、SDK组件安装、Python环境配置。以下以Jetson Orin Nano 8GB + JetPack 5.1.2为例，给出完整操作步骤。

阶段一：系统烧录与初始配置

下载SDK Manager：在宿主机（Ubuntu 18.04/20.04/22.04 x86_64）上安装NVIDIA SDK Manager，登录NVIDIA开发者账号。
连接设备：将Jetson设备通过USB-C线连接宿主机，并确保Jetson处于恢复模式（按住Recovery键再按Reset键）。
烧录系统：在SDK Manager中选择目标设备型号和JetPack版本，选择"Host Machine"和"Target Device"组件，点击安装。此过程会向Jetson的eMMC或NVMe SSD写入L4T系统镜像。
完成初始设置：烧录完成后，Jetson会自动重启，进入Ubuntu初始化界面，设置用户名、密码、时区等。

阶段二：验证SDK组件

系统启动后，打开终端，依次验证各核心组件是否安装成功：

# 检查L4T版本
cat /etc/nv_tegra_release

# 检查CUDA版本
/usr/local/cuda/bin/nvcc --version

# 检查cuDNN版本
dpkg -l | grep cudnn

# 检查TensorRT版本
dpkg -l | grep TensorRT
# 或
/usr/src/tensorrt/bin/trtexec --version

如果输出显示版本号与JetPack 5.1.2的预期版本一致（CUDA 11.4、cuDNN 8.6、TensorRT 8.5.2），则系统软件层安装成功。

阶段三：Python深度学习库安装

Jetson的Python环境与x86_64服务器有显著差异。由于ARM架构和特定的CUDA版本，不能直接使用pip install torch从PyPI安装，必须使用NVIDIA提供的Jetson专用wheel包。

# 安装系统依赖
sudo apt update
sudo apt install -y python3-pip libopenblas-dev libopenmpi-dev

# 安装PyTorch (Jetson专用版本)
# 从NVIDIA官方论坛获取下载链接
wget https://developer.download.nvidia.com/compute/redist/jp/v512/pytorch/torch-2.0.0+nv23.05-cp38-cp38-linux_aarch64.whl
pip3 install torch-2.0.0+nv23.05-cp38-cp38-linux_aarch64.whl

# 安装torchvision (需与PyTorch版本匹配)
sudo apt install -y libjpeg-dev zlib1g-dev
git clone --branch v0.15.1 https://github.com/pytorch/vision torchvision
cd torchvision
python3 setup.py install

# 安装其他常用库
pip3 install numpy onnx onnxruntime-gpu pillow

重要提醒：不要使用pip3 install torch从PyPI安装，因为PyPI上的torch是x86_64架构的，无法在ARM上运行。同样，不要使用pip3 install torchvision，因为其依赖的torch版本不匹配。所有Jetson专用包必须从NVIDIA官方源或GitHub的Jetson分支获取。

2.3 案例拆解：图像分类模型的环境验证与Batch设置预检

为了验证环境是否真正就绪，我们以一个ResNet-18图像分类模型为例，进行环境验证和Batch Size预检。这个案例的目标是：确认PyTorch能调用GPU、TensorRT能完成模型转换，并初步评估不同Batch Size下的显存占用。

背景与约束：Jetson Orin Nano 8GB，JetPack 5.1.2，PyTorch 2.0.0，TensorRT 8.5.2。设备功耗模式设置为15W（最大性能）。

初始验证脚本：

import torch
import torchvision.models as models

# 验证GPU可用性
print("CUDA available:", torch.cuda.is_available())
print("GPU name:", torch.cuda.get_device_name(0))

# 创建ResNet-18模型并移至GPU
model = models.resnet18(pretrained=True).cuda().eval()
print("Model loaded on GPU")

# 测试不同Batch Size的显存占用
for batch_size in [1, 4, 8, 16]:
    dummy_input = torch.randn(batch_size, 3, 224, 224).cuda()
    with torch.no_grad():
        output = model(dummy_input)
    allocated = torch.cuda.memory_allocated() / 1024**2
    print(f"Batch Size {batch_size}: 显存占用 {allocated:.1f} MB")
    del dummy_input, output
    torch.cuda.empty_cache()

执行结果与分析：

Batch Size	显存占用 (MB)	推理耗时 (ms)	结论
1	512	8.2	适合实时单帧推理
4	1024	12.5	吞吐量提升明显
8	1792	18.9	显存占用接近50%
16	3328	32.4	显存占用过高，有OOM风险

关键发现：Batch Size从1增加到8时，吞吐量（图像数/秒）提升了约2.3倍，但显存占用增长了3.5倍。当Batch Size达到16时，显存占用已接近4GB，考虑到TensorRT引擎转换和后续可能的多模型加载，这个设置风险较高。因此，对于该设备，Batch Size 8是性能和显存之间的较优平衡点。

TensorRT转换预检：

# 使用trtexec工具验证ONNX模型能否成功转换
/usr/src/tensorrt/bin/trtexec --onnx=resnet18.onnx --saveEngine=resnet18.trt --fp16

# 输出关键信息
# [I] Engine built in 12.3456 sec
# [I] Binding names: input, output
# [I] Binding dimensions: input (1x3x224x224), output (1x1000)

如果trtexec能成功生成TensorRT引擎文件，说明ONNX导出和TensorRT环境均正常。此案例验证了从PyTorch到TensorRT的完整链路，为后续章节的模型优化奠定了基础。

2.4 常见误区与总结复盘

在Jetson环境搭建过程中，开发者常陷入以下误区，导致后续部署反复返工：

误区一：盲目升级CUDA版本。很多开发者习惯在x86_64服务器上使用最新CUDA，但在Jetson上，CUDA版本由JetPack锁定。升级CUDA会导致cuDNN和TensorRT无法加载，甚至系统驱动崩溃。
误区二：使用pip直接安装PyTorch。PyPI上的PyTorch是x86_64版本，在Jetson上安装会报"Exec format error"或"No matching distribution"。必须使用NVIDIA提供的aarch64 wheel包。
误区三：忽略swap空间配置。Jetson设备内存有限（Orin Nano 8GB），在编译torchvision或运行大型模型时容易内存不足。建议配置至少4GB的zram或swap文件。
误区四：不检查TensorRT版本兼容性。TensorRT的ONNX解析器对ONNX算子版本有要求。如果ONNX模型使用了较新的算子，而TensorRT版本过旧，会导致转换失败。

经验总结：环境搭建的核心是"版本锁定"。建议在项目开始时，记录完整的版本清单（JetPack版本、CUDA版本、PyTorch版本、TensorRT版本），并编写一个环境验证脚本，每次部署前自动检查版本一致性。此外，建议将Jetson的存储升级为NVMe SSD，因为eMMC的读写速度会显著影响模型加载和数据集读取时间。

最后，务必在完成环境搭建后，运行一次完整的图像分类推理测试（包括图像预处理、模型推理、后处理），确保整个数据链路畅通。只有环境验证通过，后续的模型轻量化、Batch Size优化和TensorRT加速才有意义。