GPU 服务器容器环境怎么定版本基线：驱动、CUDA 与 NVIDIA Container Toolkit 的责任边界

GPU 容器环境最常见的误区，是把宿主机驱动、容器内 CUDA 运行时和 NVIDIA Container Toolkit 当成同一个版本。它们位于不同层，兼容关系和升级责任也不同；镜像能够启动，只能证明最基础的设备映射成立。

NVIDIA Container Toolkit 版本基线应同时记录宿主机操作系统、内核、GPU 驱动、Toolkit、容器运行时、编排组件和业务镜像。任何一层单独升级，都要验证设备发现、库加载、通信和业务结果。

先把五个软件层分开管理

宿主机负责 GPU 驱动与内核接口，Container Toolkit 负责把设备和所需运行能力交给容器，镜像携带用户态 CUDA 组件与应用依赖，容器运行时和编排平台再负责创建与调度。每一层都应有独立版本字段。

不要通过在容器中重复安装完整宿主机驱动来修复兼容问题。这样容易形成库来源混杂，升级后也无法判断实际加载了哪一套组件。

CUDA 兼容性按应用要求核对

业务镜像声明的 CUDA 与框架版本，需要满足 NVIDIA 公布的驱动兼容条件。不能只比较版本号大小，还要关注框架、通信库、扩展算子和操作系统支持范围。

同一宿主机运行多个镜像时，建立允许列表并记录测试状态。某个较新镜像可运行，不代表旧镜像或带自定义算子的镜像不会因库加载顺序出现差异。

基础验收不止检查 GPU 可见

容器内应验证设备数量、设备权限、GPU 计算、显存分配、监控指标和退出清理。多 GPU 场景还要验证 NVLink/NVSwitch 与 NCCL，跨节点任务再加入 RDMA 设备、网络命名空间和通信库。

宿主机测试正常而容器异常时，先比较设备映射、挂载库、运行时配置和安全策略；不要在没有证据时调整交换机或 GPU 固件。

编排平台要处理调度与隔离

Kubernetes 等平台还涉及设备插件、运行时类、节点标签、污点和资源健康。驱动升级后节点重新加入调度前，应确认资源上报、容器创建和监控链路均恢复。

使用 MIG 或多租户策略时，实例划分、资源名称和作业申请必须一致。容器层的资源隔离不能替代宿主机权限、网络和存储边界。

升级采用节点池滚动而非全量覆盖

先在隔离节点池安装目标驱动与 Toolkit，运行代表性镜像和通信测试，再分批迁移生产节点。每一批保留可回退镜像、驱动包、配置和验证结果。

升级完成后比较作业启动时间、失败率、GPU 利用、NCCL 和业务指标。只有软件包安装成功而没有业务回归，不能视为版本基线已经通过。