1. 课程导入与全景认知

在医疗影像、工业质检、机器人等边缘场景中，AI 模型一旦进入量产阶段，问题就不再是"模型能不能跑通"，而是"同一台设备在三年后、在十万台设备上，是否还能跑出与今天一致的结果"。NVIDIA IGX 正是为这类需求设计的边缘 AI 计算平台：它在硬件层面提供工业级可靠性、功能安全（FuSa）支持与长期供货承诺，在软件层面提供 Holoscan 传感器处理框架、IGX OS 与容器化运行时，并通过与 NVIDIA AI Enterprise、Triton、TensorRT 等工具链的配合，把"模型"变成"可交付、可追溯、可回滚的产品组件"。

本课程围绕两条主线展开：模型版本治理与量产部署。前者解决"我部署的到底是哪个模型、它从哪来、能不能复现"；后者解决"如何把经过验证的模型安全、可控、可批量地推送到边缘设备，并在出问题时快速收敛"。二者在 IGX 平台上并非独立，而是通过 OTA 更新通道、容器镜像仓库、设备身份与签名验证机制耦合在一起。

为什么边缘 AI 的版本治理比云端更难

云端模型更新可以随时灰度、随时回滚，因为算力与网络是集中且充裕的。边缘设备则相反：设备分散在客户现场，网络可能间歇可用，算力受限，且一旦模型行为异常，可能直接影响产线停机或医疗诊断。更棘手的是，边缘设备的软件栈是"分层"的——底层是 IGX OS 与驱动，中间是 CUDA/TensorRT 运行时与容器运行时，上层才是模型与业务应用。任何一层版本变化，都可能改变最终推理结果。

举一个具体的教学示例（以下参数为合理假设，用于说明方法而非实测结果）：某工业质检设备使用 IGX Orin 32GB 模组，模型为基于 ResNet-50 的缺陷分类网络，输入 640×480 灰度图，TensorRT 以 FP16 精度构建引擎。若把 TensorRT 从 8.5 升级到 8.6，即使模型权重文件（.onnx 或 .plan）完全不变，由于算子融合策略与内核选择可能变化，同一张图片的输出置信度也可能出现 0.5%~2% 的偏移。对于阈值设在 0.5 的二分类判断，这种偏移足以让一批原本判为"合格"的样本翻转为"不合格"。因此，版本治理的对象绝不只是模型文件，而是模型 + 推理引擎 + 运行时 + 系统镜像这一整条推理链。

IGX 平台在版本治理中的角色

IGX 平台提供了几个关键能力来支撑上述治理：其一，IGX OS 采用不可变根文件系统与 A/B 分区更新，系统级更新失败可自动回退；其二，支持安全启动与镜像签名，确保设备只运行经过授权的软件；其三，通过容器化部署，把模型与依赖打包成 OCI 镜像，使"版本"成为可寻址、可校验的镜像摘要（digest）。这意味着，一次量产部署的"版本标识"可以精确到镜像 digest，而不是模糊的"v2.3 模型"。

下图展示了从模型训练到边缘设备量产的版本治理全景：左侧是模型与引擎的构建与登记，中间是版本元数据与签名，右侧是设备侧的拉取、校验、运行与回滚路径。

量产部署的核心挑战

从工程实践看，量产部署的挑战集中在四个方面。第一是一致性：同一版本镜像在不同批次设备上必须产生相同推理结果，这要求固定 TensorRT 构建参数、固定 CUDA 版本、固定输入预处理逻辑。第二是可观测性：设备上线后，需要持续采集推理延迟、置信度分布、内存占用等指标，才能判断模型是否"退化"。第三是可回滚性：任何更新都必须能在不拆机、不到现场的前提下回退，IGX 的 A/B 分区与容器双版本机制正是为此设计。第四是合规性：医疗与工业场景往往要求保留完整的版本变更记录，包括谁、何时、把哪个 digest 部署到了哪些设备。

课程目标与学习路径

本课程的目标是让学员能够独立完成一条从模型到量产设备的治理链路。具体包括：理解 IGX 平台的软硬件分层与版本边界；掌握模型版本命名、元数据登记与镜像摘要管理的方法；能够设计灰度发布与回滚策略；能够使用 IGX 提供的工具链完成容器化打包、签名与 OTA 更新；能够建立推理结果的可观测性并据此判断版本是否可继续放量。

学习路径按"认知—构建—治理—部署—运维"推进：先建立 IGX 平台与版本治理的全景认知，再进入模型构建与引擎优化，随后学习版本仓库与元数据管理，接着完成量产部署与 OTA 实操，最后落到运行监控、异常诊断与回滚复盘。每一阶段都会围绕真实对象展开，例如具体的镜像标签规则、TensorRT 构建参数、设备组划分方式与回滚触发条件，而不是停留在概念层面。

需要特别强调的是，版本治理不是一次性的项目动作，而是贯穿设备全生命周期的持续过程。模型会迭代、系统会升级、客户需求会变化，只有把版本关系、部署记录与运行指标三者绑定在一起，才能在出现问题时快速定位是"模型变了"、"引擎变了"还是"数据变了"。这也是本课程后续所有章节的共同基础。