换到新的 GPU 云实例后，程序能启动不代表环境已兼容：可能出现框架识别不到设备、算子报错，或任务运行速度明显变化。GPU云实例迁移时驱动与框架版本兼容检查，重点不是把所有版本都升级到最新，而是确认五层依赖能够共同工作，并保留回退依据。
先核对硬件与驱动：框架支持这张卡吗
第一项是 GPU 型号及计算能力。不同显卡的架构和计算能力会影响框架及其算子是否提供相应支持。迁移前记录旧实例的 GPU 型号、驱动版本与设备数量，再对照新实例的产品说明及所用框架版本的支持范围；不要只凭显存容量相近，就判断两张卡可直接替换。
第二项是驱动与 CUDA 运行时。NVIDIA 驱动负责与设备交互，CUDA Toolkit 则提供编译器和开发库；很多预编译框架包会携带所需的 CUDA 运行时组件。因此，宿主机未必需要安装与框架完全相同的 Toolkit 版本，但驱动必须满足该运行时的最低要求。具体边界应查对应版本的 NVIDIA CUDA 兼容文档及云平台说明，不能把“版本号相同”当作唯一标准。
再核对软件栈：框架包和底层库是否配套
框架构建版本
第三项是 PyTorch、TensorFlow 或 JAX 的具体发行版本及构建类型。同一框架版本可能分别提供 CPU 版、不同 CUDA 运行时构建，或针对不同平台的包。迁移时记下包版本、安装来源和构建信息；到新实例后确认实际安装的是 GPU 构建，并用框架自身的设备查询方式验证能否识别显卡。只比较“框架都是 PyTorch”不足以判断兼容。
加速库与通信组件
第四项是 cuDNN、NCCL 等依赖。cuDNN 影响常见深度学习算子的执行，NCCL 常用于 NVIDIA 多卡通信；它们可能由框架依赖间接提供，也可能来自系统或容器。若环境中同时存在多个来源，动态库加载顺序变化就可能引起报错。应以框架发行说明和容器镜像文档为准，避免把旧实例中的库文件直接复制到新系统。
最后核对系统环境，并按步骤验收
第五项是操作系统、内核、容器运行时和安装方式。主机驱动通常由云平台提供或管理，容器里的 CUDA 用户态组件则由镜像决定；容器不能替代宿主机驱动。若从虚拟机迁到容器，或更换 Linux 发行版，还要确认设备是否正确映射、容器运行时能否访问 GPU，以及所用驱动是否受平台支持。
- 留档：记录旧实例的 GPU 型号、驱动、框架及依赖版本、操作系统和镜像来源，并保存安装清单。
- 查矩阵：按目标 GPU 和框架构建版本，核对驱动最低要求、CUDA 运行时及相关库的支持关系；云平台未公开的项目应向平台文档或支持渠道确认。
- 先做小规模迁移：在目标实例安装同一应用环境，检查系统是否识别设备，再让框架执行设备查询和一个代表性算子。
- 验收真实负载：运行可重复的小批任务，检查日志中的驱动、运行时与库加载信息，并与旧环境比较结果正确性、显存占用和耗时。速度变化不必然代表版本不兼容，还应排查实例规格和数据输入差异。
- 保留回退路径：兼容性未确认前不要同时升级框架、驱动和应用依赖；保存旧镜像或环境定义，发现故障时逐层定位。
GPU云实例迁移时驱动与框架版本兼容检查，最终应形成一张可复核的版本清单和一组通过的验收任务。这样能区分驱动不满足要求、框架构建不匹配与容器配置错误，而不是迁移后再靠反复换版本试错。
常见问题
驱动版本越新越好吗？
不一定。新驱动可能支持更多运行时，但仍要符合云平台和应用环境的支持范围；稳定复现比盲目升级更重要。
宿主机和容器里的 CUDA 版本必须一致吗？
不一定。容器通常提供用户态运行时，宿主机提供驱动；关键是驱动满足容器运行时的要求，且容器能访问设备。
迁移后能识别显卡，是否就算通过？
不算。还应运行应用实际使用的算子或通信任务，并核对结果、日志及资源表现。
可以直接复制旧实例的驱动和库文件吗？
不建议。驱动通常与宿主机内核和平台管理方式相关，手工复制库文件也可能造成加载冲突，应使用目标平台支持的安装方式。
