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

2、环境准备：Jetson设备型号对比（Xavier、Orin等）、JetPack版本选择、系统烧录与基础配置

在正式进入Docker部署之前，我们必须先完成硬件选型与系统环境搭建。Jetson系列设备并非通用ARM开发板，其硬件架构、GPU算力、内存带宽和JetPack软件栈的差异，直接决定了容器化方案中镜像架构（arm64/aarch64）、CUDA运行时版本、设备映射方式以及性能调优参数。本章将围绕设备型号对比、JetPack版本选择、系统烧录与基础配置三个核心环节展开，帮助读者建立一套可复用的环境准备方法论。

上图展示了Jetson环境准备的整体决策链路。从硬件选型到软件栈匹配，再到系统烧录与基础配置，每个环节环环相扣。下面我们将逐一深入剖析。

2.1 Jetson设备型号对比：从Xavier到Orin的选型逻辑

核心原理：Jetson系列设备的核心差异在于GPU架构、CUDA核心数量、内存带宽和功耗预算。这些硬件参数直接决定了容器内AI推理任务的吞吐量、延迟和能效比。Xavier系列基于Volta架构，支持Tensor Core，但算力相对有限；Orin系列升级为Ampere架构，引入了更高效的第二代Tensor Core，并大幅提升了内存带宽。

型号	GPU架构	CUDA核心	内存带宽	算力(FP16)	功耗范围	典型场景
Xavier NX	Volta	384	102.4 GB/s	21 TOPS	10-20W	轻量级边缘推理
AGX Xavier	Volta	512	137 GB/s	32 TOPS	10-30W	中等负载机器人
Orin NX 16GB	Ampere	1024	102.4 GB/s	100 TOPS	10-25W	多路视觉SLAM
AGX Orin 64GB	Ampere	2048	204.8 GB/s	275 TOPS	15-60W	大模型推理、自动驾驶
Orin Nano 8GB	Ampere	1024	68.2 GB/s	40 TOPS	7-15W	入门级AI原型验证

判断方法：选型时需考虑三个维度：模型复杂度（参数量、计算量）、实时性要求（帧率、延迟上限）、功耗约束（电池供电或固定电源）。例如，若需在容器内运行YOLOv8s进行实时检测（30 FPS以上），Orin NX 16GB是底线；若涉及Transformer类模型，则建议AGX Orin 64GB。

经验提醒：不要只看TOPS数值。实际部署中，内存带宽往往成为瓶颈。Orin NX 16GB与Xavier NX带宽相近，但算力翻倍，说明Orin架构对计算密度优化更好。若模型是内存密集型（如大分辨率图像处理），优先选择带宽更高的型号。

2.2 JetPack版本选择：与Docker镜像的兼容性矩阵

核心原理：JetPack是NVIDIA为Jetson提供的完整SDK，包含Ubuntu系统、CUDA、cuDNN、TensorRT、OpenCV等组件。JetPack版本决定了宿主机内核版本、驱动版本和CUDA运行时，而Docker容器内的镜像必须与宿主机驱动版本兼容。NVIDIA官方提供了nvcr.io/nvidia/l4t-*系列镜像，其标签与JetPack版本严格对应。

判断方法：选择JetPack版本时，需确认以下三点：

硬件支持范围：Orin系列仅支持JetPack 5.1及以上；Xavier系列支持JetPack 4.x~5.x。
CUDA版本需求：若你的模型依赖CUDA 11.x特性，选择JetPack 5.x；若需要CUDA 12.x，则必须使用JetPack 6.x。
Docker镜像标签：检查nvcr.io/nvidia/l4t-jetpack:r35.2.1等标签，确保与宿主机JetPack版本一致。

# 查看当前JetPack版本
cat /etc/nv_tegra_release
# 输出示例：R35.2.1，对应JetPack 5.1.1

# 查看CUDA版本
nvcc --version
# 输出示例：Cuda compilation tools, release 11.4, V11.4.152

风险提示：JetPack 6.x目前仅支持Orin系列，且部分旧版Docker镜像（基于JetPack 4.x构建）无法直接运行。若需兼容旧镜像，建议在JetPack 5.x上使用--runtime nvidia配合LD_LIBRARY_PATH环境变量解决。

2.3 系统烧录与基础配置：从SDK Manager到命令行

操作流程：系统烧录有两种主流方式：SDK Manager图形化工具（适用于Ubuntu主机）和命令行手动烧录（适用于CI/CD或远程环境）。

SDK Manager方式：

将Jetson设备进入Recovery模式（按住Recovery键，再按Reset键）。
用USB Type-C线连接Jetson与Ubuntu主机。
打开SDK Manager，选择目标JetPack版本，勾选“Host Machine”和“Target Device”。
等待烧录完成，系统自动重启。

命令行方式（以Orin NX为例）：

# 下载BSP包
wget https://developer.nvidia.com/downloads/embedded/l4t/r35.2.1_release_v1.0/jetson_linux_r35.2.1_aarch64.tbz2
# 解压并进入目录
tar -xjf jetson_linux_r35.2.1_aarch64.tbz2
cd Linux_for_Tegra
# 烧录到Orin NX（需先进入Recovery模式）
sudo ./flash.sh jetson-orin-nx-devkit mmcblk0p1

基础配置清单：烧录完成后，需进行以下配置以确保Docker环境稳定：

配置项	命令/操作	说明
电源模式	`sudo nvpmodel -m 0`	0为最大性能模式，15W/25W/40W可选
CPU/GPU频率	`sudo jetson_clocks`	锁定最高频率，避免降频影响测试
Docker安装	`sudo apt install docker.io`	安装后需配置nvidia-container-runtime
存储扩展	挂载NVMe SSD	Docker默认存储在SD卡，建议迁移至SSD
Swap空间	`sudo fallocate -l 8G /swapfile`	防止内存不足导致容器OOM

2.4 实战案例：基于Orin NX的Docker环境搭建与验证

案例背景：某机器人创业公司需要在一台Orin NX 16GB设备上部署多模态感知模型（YOLOv8 + ResNet50），要求容器化部署，并支持热更新模型版本。初始现象是：直接运行docker run nvcr.io/nvidia/l4t-pytorch:r35.2.1后，容器内无法调用GPU。

分析过程：通过docker info检查发现，默认Docker未配置NVIDIA Runtime。进一步查看/etc/docker/daemon.json，发现缺少nvidia-container-runtime配置。同时，nvidia-smi在宿主机正常，但容器内执行报错NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver。

解决步骤：

# 1. 安装nvidia-container-runtime
sudo apt install nvidia-container-runtime

# 2. 配置daemon.json
sudo tee /etc/docker/daemon.json <<EOF
{
  "runtimes": {
    "nvidia": {
      "path": "nvidia-container-runtime",
      "runtimeArgs": []
    }
  }
}
EOF

# 3. 重启Docker
sudo systemctl restart docker

# 4. 验证GPU映射
docker run --rm --runtime nvidia -e NVIDIA_VISIBLE_DEVICES=all nvcr.io/nvidia/l4t-base:r35.2.1 nvidia-smi

结果对比：配置前，容器内无法识别GPU设备；配置后，nvidia-smi正常输出，且YOLOv8推理速度从CPU模式的2.1 FPS提升至GPU模式的38 FPS。风险与代价：升级Docker版本可能导致Runtime兼容性问题，需锁定Docker版本并定期测试。

  复盘经验：Jetson的Docker部署核心在于“设备映射”而非“驱动安装”。宿主机驱动已包含在JetPack中，容器只需通过--runtime nvidia和NVIDIA_VISIBLE_DEVICES环境变量访问GPU节点。此外，/dev/nvhost-*设备节点（如nvhost-ctrl、nvhost-gpu）必须映射到容器，否则部分硬件加速功能（如编解码）不可用。

2.5 常见误区与总结

误区一：认为所有Jetson型号的Docker镜像通用。实际上，Xavier和Orin的镜像标签不同，混用会导致CUDA版本不匹配。
误区二：忽略电源模式。默认的nvpmodel可能是低功耗模式，导致容器内推理性能下降50%以上。
误区三：将Docker数据目录放在SD卡。SD卡I/O性能差，建议迁移至NVMe SSD，否则容器启动和模型加载时间会显著增加。
误区四：忘记设置--shm-size。Jetson默认共享内存较小，多进程数据加载时容易OOM，建议设置为--shm-size=2g。

总结而言，Jetson环境准备是一个“硬件-软件-配置”三层联动的系统工程。选型时以模型需求和功耗预算为锚点，JetPack版本以CUDA兼容性为约束，烧录与配置则以Docker Runtime可用性为验收标准。只有将这三层打通，后续的容器化部署才能发挥Jetson的真实算力。