4. IGX软件栈全景

IGX平台并不是“一块带GPU的工控机”这么简单，它是一套从固件、操作系统、驱动、运行时到领域SDK的完整分层软件栈。理解这套栈的关键，不是记住六个名字，而是搞清楚：谁依赖谁、谁为谁提供能力、谁决定兼容性边界。一旦把层次关系理顺，后续做镜像定制、容器部署、版本升级和故障定位时，就不会在“到底该动哪一层”上反复试错。

一、从下到上的六层职责

IGX软件栈可以按“越靠下越稳定、越靠上越贴近业务”的原则划分为六层。最底层是CUDA-X，它不是一个单一库，而是CUDA之上的一整套加速库集合，包括cuDNN、TensorRT的底层算子依赖、cuBLAS、NPP、CUDA Math Library等。CUDA-X为上层提供GPU并行计算与数学加速能力，是整条栈的算力基座。

其上是TensorRT，负责把训练好的模型做图优化、层融合、精度校准（FP32/FP16/INT8）并生成针对具体GPU架构的推理引擎（.plan）。TensorRT不负责视频解码，也不负责多路调度，它只解决“单模型如何跑得最快”这一问题。

DeepStream建立在TensorRT与多媒体框架之上，负责视频流接入、解码、批处理、推理调度、跟踪、编码与输出。它面向的是“多路视频+AI分析”的流水线场景，典型输入是RTSP、CSI摄像头或文件，输出是带元数据的结构化结果。

Holoscan SDK是面向低延迟传感器与实时AI的流式处理框架，强调端到端确定性延迟，适合机器人、医疗影像、工业检测等需要“传感器到执行”闭环的场景。它与DeepStream并非替代关系：DeepStream偏视频分析流水线，Holoscan偏低延迟多模态数据流，两者可以共存于同一IGX设备。

IGX OS是NVIDIA为IGX定制的操作系统层，基于Ubuntu LTS，集成了实时内核补丁（PREEMPT_RT）、安全启动、OTA更新、设备树与板级支持包（BSP）。它向下管理硬件与驱动，向上为JetPack组件和容器运行时提供稳定基础。

最上层是JetPack，它是一组组件的集合概念：包含CUDA、cuDNN、TensorRT、DeepStream、VPI、多媒体API等，并给出经过验证的版本组合。JetPack的版本号实际上定义了“这一整套栈的兼容性快照”。

二、版本兼容性：为什么不能随意混搭

这套栈最容易被忽视、也最容易出问题的就是版本兼容性。核心规则是：JetPack版本决定CUDA、cuDNN、TensorRT、DeepStream的可用组合。例如JetPack 6.x对应CUDA 12.x、TensorRT 8.6/10.x、DeepStream 7.x，而IGX OS的BSP版本又必须与JetPack匹配。如果强行把为JetPack 5编译的TensorRT引擎拿到JetPack 6上运行，通常会因为GPU架构或算子版本不匹配而加载失败。

更隐蔽的是TensorRT引擎的架构绑定：.plan文件在构建时就绑定了目标GPU的计算能力（如Orin为8.7）。同一台IGX设备上跨JetPack大版本升级后，旧引擎必须重新构建，不能直接复用。这一点在OTA升级规划中必须提前考虑。

三、实际部署中的分层操作示例

假设我们要在一台IGX Orin上部署一个多路视频缺陷检测应用，合理的分层操作顺序如下。首先确认基础版本：

# 查看当前 IGX OS 与 JetPack 版本
cat /etc/nv_tegra_release
# 输出示例：R36 (release), REVISION: 3.0  → 对应 JetPack 6.0

# 查看 CUDA 与 TensorRT 版本
nvcc --version
dpkg -l | grep tensorrt
# 示例：TensorRT 8.6.2，CUDA 12.2

确认版本后，在开发主机上构建TensorRT引擎。注意引擎必须在目标架构上构建，或使用与目标一致的GPU环境：

trtexec --onnx=defect.onnx \
        --saveEngine=defect_fp16.plan \
        --fp16 \
        --workspace=2048 \
        --minShapes=input:1x3x640x640 \
        --optShapes=input:4x3x640x640 \
        --maxShapes=input:8x3x640x640

这里用动态shape覆盖1到8路批处理，FP16精度在Orin上通常能获得约2倍于FP32的吞吐，而精度损失在缺陷检测任务中一般可接受——但必须用验证集实测确认，不能凭经验假设。构建完成后，把.plan交给DeepStream或Holoscan加载。若走DeepStream，配置文件中的关键项是：

[primary-gie]
enable=1
plugin-type=0
config-file-path=config_infer_primary.txt
# config_infer_primary.txt 中指定：
# onnx-file 或 model-engine-file=defect_fp16.plan
# batch-size=4
# precision-mode=2   # FP16

运行后通过nvidia-smi dmon或DeepStream的FPS日志观察实际吞吐。判断是否达标的依据不是“跑起来了”，而是：单路延迟是否满足产线节拍、GPU利用率是否留有裕量、INT8/FP16切换后漏检率是否仍在阈值内。如果FPS远低于预期，优先检查是否误用了FP32引擎、批处理是否被拆散、解码是否成为瓶颈，而不是先怀疑模型本身。

四、各层该由谁维护

从工程管理角度，建议明确分层维护责任：IGX OS与JetPack由平台/系统团队统一管理，通过NVIDIA官方源升级，不手工替换驱动；TensorRT引擎由算法团队在CI中随模型版本重新构建并归档，引擎文件与模型版本一一对应；DeepStream/Holoscan应用由应用团队以容器方式交付，容器基础镜像固定到具体JetPack版本标签。这样当出现问题时，可以快速定位是平台层、引擎层还是应用层的变化导致。

把六层职责和版本锁定关系理清之后，IGX上的开发就不再是“碰运气式地装环境”，而变成一条可复现、可升级、可回退的工程链路。后续无论是做容器化部署还是OTA升级，都可以在这张分层图上找到对应的操作位置和影响范围。