📚 课程目录第2章环境搭建

2、环境搭建：NVIDIA边缘设备（Jetson系列）硬件架构、JetPack SDK安装、TensorRT-LLM源码编译与容器部署

在边缘端部署生成式AI模型，与云端最大的差异在于资源边界与异构计算单元的协同方式。Jetson系列设备并非一台“小电脑”，而是一套以GPU为中心、融合CPU、DLA（深度学习加速器）、PVA（视觉加速器）与专用编解码引擎的异构计算平台。本章将围绕硬件架构认知、JetPack SDK环境构建、TensorRT-LLM源码编译以及容器化部署四个核心环节展开，帮助读者建立从“看懂板卡”到“跑通大模型”的完整工程链路。

2.1 Jetson硬件架构：异构计算的核心原理

Jetson Orin系列采用了与数据中心GPU不同的设计哲学——统一内存架构（Unified Memory）。CPU与GPU共享同一物理内存池，无需PCIe传输数据，这极大降低了小批量推理的延迟。以AGX Orin为例，其内部集成了2048个CUDA核心的Ampere架构GPU、12核ARM Cortex-A78AE CPU、两个DLA引擎以及一个PVA引擎。在运行TensorRT-LLM时，GPU负责矩阵乘法和注意力机制计算，DLA可以卸载部分卷积类操作，而CPU则承担tokenizer预处理、采样策略和后处理逻辑。

理解硬件架构的关键在于内存带宽与功耗墙的平衡。LPDDR5内存虽然带宽可达204.8GB/s（AGX Orin），但相比数据中心HBM的TB/s级带宽仍有数量级差距。这意味着在边缘端部署大模型时，权重复用比计算吞吐更值得关注。TensorRT-LLM的INT4/INT8量化、KV Cache优化、以及inflight batching等特性，本质上都是在有限内存带宽下最大化生成速度。

硬件资源	作用	TensorRT-LLM中的角色
GPU (Ampere)	通用并行计算	执行GEMM、Attention、MLP等核心算子
DLA	固定功能深度学习加速	可卸载部分量化卷积层（当前版本支持有限）
CPU (Cortex-A78AE)	通用控制与预处理	运行Python前端、tokenizer、采样循环
NVENC/NVDEC	视频编解码	多模态模型中的视觉输入处理
统一内存	CPU/GPU共享数据	消除PCIe拷贝，但需管理内存分配策略

功耗与散热风险：Jetson设备在运行LLM推理时，GPU会持续高负载运行。Orin Nano在7W模式下性能大幅缩水，建议使用15W模式并配合主动散热。若设备过热（>85°C），GPU会自动降频，导致推理延迟陡增。部署时务必监控 tegrastats 输出。

2.2 JetPack SDK安装：从烧录到验证

JetPack是NVIDIA为Jetson平台提供的完整SDK，包含Ubuntu系统、内核驱动、CUDA、cuDNN、TensorRT以及多媒体API。安装JetPack有两种主流方式：SDK Manager（主机端图形化工具）和命令行烧录（适用于无显示器环境）。对于批量部署场景，推荐使用后者。

# 在x86主机上下载JetPack 6.0 (L4T 36.3)
# 进入Linux_for_Tegra目录后执行：
sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
  --external-device nvme0n1p1 \
  -c tools/kernel_flash/flash_l4t_nvme.xml \
  -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" \
  --showlogs \
  jetson-agx-orin-devkit nvme0n1p1

烧录完成后，首次启动需进行基础配置。验证环境是否就绪，应依次检查以下内容：

系统版本：cat /etc/nv_tegra_release 确认L4T版本
CUDA可用性：nvcc --version 与 nvidia-smi（Jetson上输出与x86不同）
TensorRT版本：dpkg -l | grep TensorRT
性能模式：sudo nvpmodel -m 0 切换到最大性能模式

经验提醒：JetPack 6.0开始，NVIDIA将TensorRT-LLM作为独立组件提供，不再预装在系统镜像中。这意味着即使JetPack安装成功，仍需单独编译或拉取TensorRT-LLM容器。建议直接使用NVIDIA官方发布的 nvcr.io/nvidia/tensorrt-llm:jetpack6.0 容器镜像，避免从源码编译的复杂性。

2.3 TensorRT-LLM源码编译：从源码构建的完整流程

虽然官方容器镜像可以省去编译步骤，但在以下场景仍需源码编译：需要定制算子、需要修改C++运行时、需要适配特定模型架构、或需要调试底层行为。源码编译的核心挑战在于依赖版本匹配与交叉编译环境。

# 在Jetson设备上直接编译（推荐，避免交叉编译工具链问题）
git clone https://github.com/NVIDIA/TensorRT-LLM.git
cd TensorRT-LLM
git checkout v0.10.0  # 选择与JetPack 6.0匹配的版本

# 安装依赖
python3 -m pip install -r requirements.txt
python3 scripts/setup.py --cuda 12.2 --tensorrt 8.6

# 编译（使用全部核心，约需40-60分钟）
mkdir -p build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_CUDA_ARCHITECTURES=87  # Orin系列为sm_87
make -j$(nproc)

编译过程中最常见的错误是CUDA架构不匹配。Jetson Orin的GPU架构是sm_87（Ampere），而x86服务器常用的sm_80/sm_86不适用。若使用交叉编译，还需设置 CMAKE_SYSTEM_PROCESSOR=aarch64 和对应的工具链文件。另一个高频问题是内存不足——编译时峰值内存可达8GB以上，Orin Nano 8GB版本建议增加ZRAM或交叉编译。

案例：Orin Nano 8GB编译失败排查

现象：编译进行到约70%时进程被OOM Killer终止。

分析：通过 dmesg | grep -i oom 确认是内存耗尽。Orin Nano 8GB在编译大型C++项目时，链接阶段需要大量内存。

解决：① 增加ZRAM：sudo zramctl -s 4G /dev/zram0；② 限制并行度：make -j2；③ 关闭桌面环境释放内存。

结果：编译时间从50分钟延长至90分钟，但成功完成。

复盘：边缘设备编译大型项目时，内存管理比CPU核心数更关键。建议优先使用官方容器，源码编译仅用于二次开发场景。

2.4 容器部署：Docker与NVIDIA Container Runtime

容器化是边缘AI部署的最佳实践。NVIDIA为Jetson提供了专用的容器运行时，使得容器内可以直接访问GPU、DLA等硬件加速器。与x86环境不同，Jetson上不能直接运行 nvidia-docker，而需要使用 nvidia-container-runtime 的JetPack版本。

# 安装容器运行时
sudo apt-get install nvidia-container-runtime
sudo systemctl restart docker

# 拉取TensorRT-LLM官方镜像（约4.5GB）
docker pull nvcr.io/nvidia/tensorrt-llm:jetpack6.0

# 运行容器并挂载模型目录
docker run --rm -it --runtime nvidia \
  --network host \
  -v /home/user/models:/models \
  nvcr.io/nvidia/tensorrt-llm:jetpack6.0 \
  python3 examples/llama/run_llama.py \
  --model_dir /models/llama-7b-int4 \
  --max_output_len 128

容器部署的核心优势在于环境隔离与可复现性。但需要注意，Jetson的容器与宿主机共享内核，因此内核驱动版本必须严格匹配。若宿主机JetPack版本与容器要求不一致，会出现CUDA初始化失败或TensorRT版本冲突。建议在容器内使用 nvidia-smi 验证GPU可见性，并检查 /usr/lib/aarch64-linux-gnu/tegra 下的库文件是否挂载正确。

部署方式	优点	缺点	适用场景
源码编译	完全可控、可定制	耗时长、依赖复杂	算子开发、框架调试
官方容器	开箱即用、版本匹配	镜像体积大、定制受限	快速原型、生产部署
自建容器	精简体积、集成自有代码	需维护Dockerfile	特定业务逻辑封装

关键风险：Jetson的Docker容器无法使用 --gpus all 参数（该参数仅支持x86的NVIDIA Container Toolkit）。必须使用 --runtime nvidia 并确保 /etc/docker/daemon.json 中配置了正确的运行时路径。若容器内无法识别GPU，检查 ldconfig -p | grep cuda 是否输出了Jetson特有的库路径。

2.5 环境验证与性能基线测试

环境搭建完成后，必须进行系统性的验证测试，而不仅仅是确认“能跑通”。建议建立一套标准化的性能基线，用于后续模型优化效果的对比。基线测试应包含以下维度：

GPU频率稳定性：运行 sudo tegrastats 观察10分钟内的GPU频率波动
内存带宽实测：使用 bandwidthTest 工具验证实际带宽是否接近理论值
LLM推理延迟：使用TensorRT-LLM自带的benchmark脚本，记录首延迟（TTFT）和后续延迟（TPOT）
功耗曲线：通过 sudo jetson_clocks 锁定最大频率后，测量稳态功耗

# 运行TensorRT-LLM内置benchmark
cd /opt/TensorRT-LLM/build
./benchmarks/gptManagerBenchmark \
  --model_dir /models/llama-7b-int4 \
  --engine_dir /models/llama-7b-int4/engine \
  --batch_size 1 \
  --max_input_len 512 \
  --max_output_len 128 \
  --num_runs 20

一个健康的Jetson环境，其TTFT应小于500ms（7B INT4模型），TPOT应小于50ms/。若TPOT超过100ms，说明内存带宽已接近瓶颈，应考虑减小batch size或使用更激进的量化方案。同时，建议将测试结果记录为JSON文件，纳入CI/CD流程，以便每次环境变更后自动回归。

实战建议：在Jetson上部署LLM服务时，务必设置 CUDA_MODULE_LOADING=LAZY 环境变量，这可以显著减少启动时间（从数秒降至数百毫秒）。同时，使用 torch.cuda.set_per_process_memory_fraction(0.9) 限制PyTorch内存占用，避免与TensorRT-LLM的KV Cache争抢内存。

环境搭建是整个边缘生成式AI课程的地基。硬件架构决定了性能上限，JetPack提供了软件栈基础，TensorRT-LLM编译与容器部署则是将模型高效落地的关键路径。在实际项目中，建议遵循“先容器后编译、先量化后调优”的原则，以最小成本验证可行性，再逐步深入底层优化。下一阶段的学习将聚焦于模型转换与量化技术，届时本环境将作为所有实验的基准平台。