1. Jetson平台与容器化概览

Jetson 是 NVIDIA 面向边缘 AI 与嵌入式场景的 SoC 计算平台。它与桌面 GPU 最大的不同在于：CPU、GPU、内存控制器、视频编解码器、ISP、DLA 等模块被集成在同一颗芯片上，并通过统一内存架构共享物理内存。这意味着 CPU 与 GPU 之间不需要通过 PCIe 拷贝数据，TensorRT 推理时可以直接引用同一块内存地址，从而显著降低延迟与功耗。理解这一点，是理解后续容器化部署为何要特别关注设备节点、内存与算力分配的前提。

Jetson 系列硬件架构与代际差异

当前主流 Jetson 模块可分为三条产品线：面向入门与量产的 Orin Nano / Orin NX，面向中高端机器人的 AGX Orin，以及更早的 Xavier 与 Nano 系列。以 AGX Orin 64GB 为例，其 GPU 为 2048 核 Ampere 架构，含 64 个 Tensor Core，CPU 为 12 核 Arm Cortex-A78AE，AI 算力约 275 TOPS（INT8，含 DLA 与 GPU 合计）。Orin Nano 8GB 则提供约 40 TOPS，GPU 为 1024 核 Ampere，CPU 为 6 核 A78AE。这些数字决定了同一模型在不同模块上的批处理大小、分辨率与帧率上限。

除算力外，还需关注三类硬件资源：一是内存带宽，Orin 系列约 102–204 GB/s，直接决定大模型权重加载与多路视频解码的吞吐；二是编解码能力，例如 Orin Nano 支持 1 路 4K60 解码，而 AGX Orin 可支持多路 4K；三是接口，包括 CSI 摄像头通道数、PCIe 通道、USB 与 40-pin 扩展头。容器化部署时，这些资源往往以设备节点或挂载路径的形式暴露给容器，因此必须先在宿主机上确认硬件拓扑。

JetPack SDK 的组成与 L4T、Ubuntu 的关系

JetPack 是 NVIDIA 为 Jetson 提供的官方 SDK 集合，它并不是一个操作系统，而是一套“BSP + 运行时 + 开发工具”的打包。其核心层次如下：最底层是 L4T（Linux for Tegra），即 NVIDIA 基于 Ubuntu 定制的板级支持包，包含内核、U-Boot、设备树、GPU 驱动、CUDA 驱动与固件；L4T 之上是 Ubuntu 根文件系统，提供 apt、systemd、网络与用户空间；再之上是 CUDA、cuDNN、TensorRT、VisionWorks、DeepStream 等加速库；最上层是 JetPack 安装器与 SDK Manager，用于刷机与组件安装。

因此，L4T 与 Ubuntu 的关系可以概括为：L4T 决定了“这块板子能跑什么内核与驱动”，Ubuntu 决定了“用户空间长什么样”。例如 JetPack 6.x 对应 L4T 36.x，底层为 Ubuntu 22.04；JetPack 5.x 对应 L4T 35.x，底层为 Ubuntu 20.04。容器镜像的标签通常也按 L4T 版本对齐，如 nvcr.io/nvidia/l4t-base:r36.2.0。若宿主机是 L4T 36.2，却拉取 r35 的镜像，CUDA 驱动与用户态库版本不匹配，常见结果是 CUDA error: insufficient driver version 或 TensorRT 初始化失败。

容器化部署的价值与典型场景

在 Jetson 上使用容器，核心价值有四点。第一是环境隔离：TensorRT、CUDA、OpenCV 的版本组合非常敏感，把应用与依赖封进镜像后，换板子或换批次时不必重装系统。第二是可复现：镜像标签固定了 L4T 与库版本，团队可以做到“同一镜像在 Orin Nano 与 AGX Orin 上行为一致”。第三是交付效率：OTA 升级时只需替换镜像，而不是重刷整机。第四是资源约束：通过 --cpus、--memory 与 --device 可以限制单个容器的算力与设备访问，便于多应用共存。

典型场景包括：多路视频分析（DeepStream 容器 + CSI 摄像头设备映射）、机器人感知（ROS 2 容器 + 串口与 CAN 设备）、模型服务（TensorRT 推理容器 + 共享内存）、以及边缘训练/微调（PyTorch 容器 + 挂载数据集）。这些场景的共同点是都需要访问宿主机上的特定设备或库，因此容器启动参数不是“随便跑跑”，而是与硬件拓扑强相关。

从硬件到容器的关键映射

上图展示了从硬件到容器的三层关系。左侧是物理资源，中间是 JetPack 软件栈，右侧是容器层。容器并不直接“看到”硬件，而是通过运行时把宿主机的设备节点、驱动库和共享内存映射进去。因此，一个典型的 TensorRT 容器启动命令会包含以下要素：

docker run --rm -it \
  --runtime nvidia \
  --network host \
  --device /dev/video0 \
  --device /dev/nvhost-ctrl \
  -v /tmp/.X11-unix:/tmp/.X11-unix \
  --shm-size=1g \
  nvcr.io/nvidia/l4t-tensorrt:r36.2.0 \
  /bin/bash

其中 --runtime nvidia 负责注入 CUDA 驱动与设备节点，--device 用于摄像头或编解码设备，--shm-size 影响多进程推理时的共享内存上限。若省略 --runtime nvidia，容器内执行 nvidia-smi 或 TensorRT 初始化会直接失败。若 L4T 版本与镜像标签不一致，则可能在加载 libcuda.so 时报版本错误。这些判断依据，是后续章节排查容器故障的基础。

版本对齐与选型建议

实际项目中，建议先确定三件事：目标模块型号、JetPack 版本、以及是否需要 DeepStream 或 ROS 2。若使用 Orin Nano 8GB 做单路 1080p 检测，JetPack 6.0 + L4T 36.3 + TensorRT 8.6 是较稳妥的组合；若使用 AGX Orin 64GB 做多路 4K 分析，则需确认 DeepStream 版本与 TensorRT 的兼容矩阵。容器镜像优先选择 NVIDIA NGC 上的 l4t-* 系列，再在其上叠加业务代码，而不是从零构建基础镜像。这样既能保证驱动兼容，又能减少镜像体积与构建时间。

总结来看，Jetson 容器化部署的本质，是在“统一内存 + 专用设备节点 + 版本强绑定”的硬件与软件约束下，把应用及其依赖封装成可迁移、可复现的镜像。理解 L4T 与 Ubuntu 的分层、JetPack 的组成，以及容器如何映射设备与库，是后续所有部署、调试与运维工作的起点。