3. IGX软件栈与JetPack基础
NVIDIA IGX平台面向工业与医疗边缘场景，其软件能力并非单一组件，而是由JetPack SDK统一封装的一整套“自底向上”的运行时栈。理解这套栈的关键，不是记住每个缩写的全称，而是搞清楚谁依赖谁、谁在什么位置、版本如何互相约束。一旦版本关系错位，典型表现是容器能启动但推理失败、摄像头能出图但DeepStream插件报错，或者Isaac ROS节点找不到CUDA运行时。
一、从硬件到应用的分层结构
IGX Orin模组本身提供GPU、CPU、DLA、PVA等异构算力，但要让这些算力被应用调用，需要一层层“翻译”。最底层是Linux for Tegra（L4T），它是NVIDIA为Tegra/Orin平台维护的Ubuntu衍生发行版，包含定制内核、设备树、GPU驱动、显示与多媒体驱动。L4T的版本号（如35.4.1、36.3）决定了内核ABI和驱动接口，是整条栈的“地基”。
在L4T之上是CUDA Toolkit，提供GPU通用计算运行时与编译器；cuDNN是CUDA之上的深度神经网络原语库，负责卷积、池化、归一化等算子的高效实现；TensorRT则进一步面向推理，做图层融合、精度校准（FP32/FP16/INT8）、内核自动调优，把训练好的模型编译成针对具体GPU的plan文件。三者构成“通用计算→算子库→推理优化”的递进关系。
再往上，DeepStream把TensorRT推理、视频解码、跟踪、消息代理串成一条视频分析流水线，适合多路RTSP/IP摄像头的实时检测；Isaac ROS则面向机器人感知与导航，提供视觉SLAM、位姿估计、图像处理等ROS 2节点，底层同样调用CUDA与TensorRT。二者是并列的应用框架，而非包含关系。
二、JetPack SDK：版本绑定的“总合同”
JetPack并不是一个可单独安装的软件，而是一份版本清单。它规定了某一时刻L4T、CUDA、cuDNN、TensorRT、DeepStream等组件的兼容组合。例如JetPack 5.1.2对应L4T 35.4.1、CUDA 11.4、TensorRT 8.5、DeepStream 6.2；JetPack 6.0对应L4T 36.3、CUDA 12.2、TensorRT 8.6/10.x、DeepStream 7.0。刷机时通过SDK Manager选择JetPack版本，实际就是一次性写入这套组合。
因此现场部署的第一条纪律是：先确定JetPack版本，再决定容器镜像和模型引擎版本。如果拿JetPack 5.1的TensorRT 8.5引擎去JetPack 6.0的TensorRT 10上加载，会直接报“serialized engine version mismatch”。正确做法是在目标设备上重新用trtexec或TensorRT API构建引擎，而不是跨版本拷贝plan文件。
三、容器化运行时：把版本差异关进镜像
IGX支持Docker与NVIDIA Container Toolkit。容器内通过--runtime=nvidia或--gpus all挂载GPU设备与驱动库，但CUDA驱动由宿主机L4T提供，容器只带用户态CUDA库。这意味着容器镜像的CUDA版本必须与宿主机驱动兼容。NVIDIA官方提供nvcr.io/nvidia/l4t-*系列基础镜像，其标签直接对应L4T版本，例如l4t-tensorrt:r35.4.1。
一个可复现的部署流程如下：
# 1. 确认宿主机JetPack与L4T版本
cat /etc/nv_tegra_release
# 输出示例：R35 (release), REVISION: 4.1
# 2. 拉取匹配的TensorRT容器
docker pull nvcr.io/nvidia/l4t-tensorrt:r35.4.1-devel
# 3. 启动容器并挂载工作目录与摄像头设备
docker run -it --rm --runtime nvidia --network host \
-v /home/nvidia/models:/models \
--device /dev/video0 \
nvcr.io/nvidia/l4t-tensorrt:r35.4.1-devel
# 4. 容器内验证TensorRT与CUDA
trtexec --version
nvcc --version若第4步中trtexec报找不到libnvinfer，通常说明镜像标签与宿主机L4T不匹配，或容器未正确挂载nvidia运行时。此时应回退到与/etc/nv_tegra_release完全一致的镜像标签。
四、版本兼容的排查顺序
现场遇到“推理失败”时，建议按自底向上的顺序排查，而不是直接改模型：
- L4T与JetPack：
cat /etc/nv_tegra_release确认R版本与REVISION； - CUDA驱动：
nvidia-smi或cat /proc/driver/nvidia/version查看驱动版本； - TensorRT：
dpkg -l | grep tensorrt确认库版本，与引擎构建版本比对； - DeepStream：
deepstream-app --version，并检查gst-inspect-1.0 nvinfer是否正常； - 容器：
docker inspect查看镜像标签与运行时配置。
trtexec能正常加载ONNX并构建引擎，但DeepStream的nvinfer插件报错，问题通常在DeepStream与TensorRT的版本匹配，而非CUDA本身。反之，若nvidia-smi都失败，则应先检查L4T驱动与容器运行时。五、Isaac ROS与DeepStream的选型边界
两者都依赖TensorRT，但定位不同。DeepStream面向多路视频结构化，强项是解码、批处理、跟踪和Kafka/MQTT消息输出，适合产线质检、周界安防；Isaac ROS面向机器人本体感知，强项是时间同步、TF变换、SLAM与导航，适合AGV/AMR。若项目既要多路摄像头分析又要机器人运动控制，常见做法是DeepStream做前端检测，通过ROS 2桥接把目标位姿送入Isaac ROS的导航栈，而不是强行用一套框架覆盖全部需求。
最后需要强调：JetPack的版本升级不是“打补丁”，而是整栈替换。升级前应记录当前L4T、CUDA、TensorRT、DeepStream版本，重新构建所有TensorRT引擎，并在容器镜像标签中同步更新。把版本关系当作部署的一部分来管理，才能避免“设备能开机、应用跑不起来”的典型现场问题。