驱动升级流程与回滚点
驱动升级的稳妥流程是：记录当前版本 → 停掉 GPU 任务 → 升级 → 重启 → 验证设备状态与容器透传 → 再逐步恢复服务。集群环境里逐台滚动升级比一次全升安全，一旦某台出现问题，还有健康实例可参照对比。
基本信息
| 升级前 | 记录当前版本号、停止 GPU 任务、留存旧版安装包 |
|---|---|
| 升级方式 | 按发行版仓库安装指定版本，避免被自动升到不兼容版本 |
| 生效方式 | 通常需要重启主机才能加载新驱动 |
| 升级后验证 | 核对版本、容器透传、跑冒烟请求 |
| 回滚准备 | 保留旧版本安装包或节点镜像 |
典型使用场景
- 修复已知驱动缺陷：官方发布修复版本后安排升级
- 新硬件接入：新卡或新特性需要更高的驱动版本
- 安全修复：驱动层漏洞需要及时打补丁
- 集群滚动升级：逐台操作，控制影响面
- 升级前兼容核对：确认驱动与容器运行时、推理框架的组合被支持
升级前后检查清单
升级前后检查清单
nvidia-smi | head -4 # 升级前记录版本，务必留档
sudo apt update && sudo apt install --only-upgrade <驱动包名>
sudo reboot # 驱动加载通常需要重启
nvidia-smi | head -4 # 升级后核对版本号
# 容器透传验证：确认容器内也能看到卡
docker run --rm --gpus all <测试镜像> nvidia-smi阶段与失败应对
| 阶段 | 动作 | 失败应对 |
|---|---|---|
| 升级前 | 记录版本、停任务、留存安装包 | 随时可退回旧版本 |
| 升级中 | 安装指定版本并重启 | 重启异常时准备回滚 |
| 升级后 | 核对版本与容器透传 | 透传失败查容器运行时配置 |
| 恢复阶段 | 单台冒烟通过后再推广 | 全量前保留一台旧版本节点 |
集群里逐台滚动升级比一次全升安全：先升一台跑满一天再推广，能把驱动相关的隐性回归暴露在小范围内。
驱动与容器运行时、推理框架之间存在版本对应关系：升级前先核对目标组合是否被官方支持，避免升完发现框架起不来。