驱动与固件版本怎么配：AI 服务器升级顺序和回滚基线
说明服务器 BIOS/BMC、GPU、网卡、DPU、交换机、驱动、CUDA 与通信库的版本基线、升级顺序、验证和回滚方法。
AI 服务器的软件栈跨越服务器 BIOS/BMC、GPU 固件与驱动、网卡或 DPU 固件与驱动、操作系统内核、CUDA、RDMA 组件、通信库和训练框架。单独把某一层升级到最新版本，可能破坏原本稳定的组合。
生产环境需要管理的是经过验证的版本基线，而不是每个组件的最新版本。每次升级都应有明确目的、依赖检查、验证节点、业务回归和回滚路径。
建立完整版本清单
清单要按节点保存，而不是只记录集群平均版本。少数节点的版本漂移常常表现为随机作业失败或某条路径性能异常。
- 服务器型号、BIOS、BMC、CPLD、PCIe 和电源或风扇相关固件。
- GPU 型号、固件、驱动分支、CUDA 运行时和管理组件。
- 网卡/SuperNIC/DPU 型号、固件、驱动、RDMA 用户态库和 DPU 系统。
- 交换机硬件、网络操作系统或固件、配置模板和管理平台。
- 操作系统、内核、容器运行时、NCCL/MPI、框架与业务镜像。
确定升级原因和目标组合
升级可能为了解决已知缺陷、支持新硬件、获得安全修复或满足应用版本。先明确目标，再从服务器和组件支持矩阵中选择组合。没有业务需求时，不建议把大规模集群作为追新环境。
目标基线要包含兼容窗口和禁止组合。例如某驱动分支支持哪些 CUDA 运行时，某网卡固件与驱动是否要求配套，交换机版本是否改变拥塞控制行为。
| 阶段 | 主要动作 | 通过条件 |
|---|---|---|
| 准备 | 收集现状、依赖、配置和回滚包 | 版本和恢复路径完整 |
| 验证节点 | 升级少量同配置节点 | 设备识别、日志和基础测试通过 |
| 业务回归 | 运行代表性训练、推理和网络测试 | 性能与稳定性不低于约定阈值 |
| 分批推广 | 按故障域和批次升级 | 每批可观察、可暂停 |
| 收尾 | 更新 CMDB、镜像和验收报告 | 无版本漂移和未处理告警 |
推荐升级顺序
没有一种顺序适用于所有平台，但应遵循依赖关系。通常先确认服务器固件和操作系统是否满足目标设备驱动，再升级验证节点的网卡/DPU 与 GPU 组件，最后更新通信库、框架和业务镜像。交换网络变更应与主机变更分窗口进行，避免同时改变两端。
DPU 环境还要区分主机侧、DPU 侧和管理侧版本。升级前验证主机信任模式、启动介质和恢复控制台，避免 DPU 故障导致主机网络同时不可达。
验证内容
- BMC、操作系统、GPU、网卡和 DPU 正确识别，无新增硬件错误。
- PCIe 链路、NUMA、端口速率、RDMA 和 GPU 拓扑与升级前一致。
- 点对点网络、NCCL、多节点作业和存储读写达到基线。
- 容器拉取、作业调度、监控、日志、告警和故障恢复正常。
- 连续压力运行后无温度、误码、重置或内核异常。
回滚设计
回滚不只是保留旧安装包。需要确认旧固件是否允许降级、配置格式是否向后兼容、操作系统内核和驱动能否成对恢复，以及业务镜像是否仍可获取。
每个批次都应设置停止条件，例如设备丢失、错误计数上升、性能下降超过阈值或业务失败。触发后先冻结扩散，再根据变更记录回滚，不能继续升级期待后续版本自动修复。
风险边界
跨多个大版本的一次性升级、服务器和交换网络同时变更、没有同配置验证节点，是三类高风险做法。大规模环境应按机柜、rail 或作业域分批，并保留未升级容量承载业务。
具体支持组合以服务器、GPU、网络和软件厂商当期文档为准。历史项目成功的版本不能自动复制到不同服务器型号或新硬件代际。