为什么选择 Docker 容器化部署 ROCm

在 AMD Instinct GPU 上跑深度学习，最让人头疼的往往不是模型本身，而是环境配置。驱动版本冲突、依赖库缺失、多卡通信调试困难，这些问题在物理机上排查起来极其耗时。自从 ROCm 7.x 发布以来，官方对容器化的支持已经非常成熟，尤其是引入了模块化驱动架构和即插即用的预优化镜像后，利用 Docker 构建隔离且高效的训练环境成了最佳实践。

这种方式不仅能保证开发环境与生产环境的一致性，还能让我们在不污染宿主机系统的前提下，灵活切换不同的 PyTorch 或 vLLM 版本。对于拥有多卡资源的服务器而言，容器化更是实现资源隔离和并行训练的关键一步。下面我们就基于真实的部署经验，聊聊如何从零开始搭建这套环境。

拉取预装好的官方镜像

过去我们需要手动在容器里编译安装 ROCm 工具链，现在完全没必要了。AMD 官方维护的 rocm/pytorch 镜像已经预装了适配 ROCm 7.x 的 PyTorch、RCCL（ROCm Communication Collectives Library）以及常用的调试工具。这些镜像针对 Instinct MI300X 等新架构做了深度优化，开箱即用。

首先，确保宿主机已安装支持 ROCm 的 Docker 插件（通常较新版本的 Docker Engine 已原生支持）。拉取镜像的命令非常简单：

docker pull rocm/pytorch:rocm7.0_ubuntu22.04

如果你更关注推理场景，也可以直接拉取集成 vLLM 的专用镜像，它们针对 Llama 3.1 等大模型做了算子融合优化，能显著降低显存占用并提升吞吐量。对于大多数训练任务，基础的 PyTorch 镜像配合后续的手动配置已经足够强大。

关键参数：设备权限与容器启动

拉下镜像只是第一步，如何让容器“看见”并“使用”物理 GPU 才是核心。在 NVIDIA 生态中我们习惯用 --gpus all，但在 ROCm 环境下，虽然新版 Docker 也支持类似语法，但为了更精细地控制设备权限，建议显式挂载设备文件。

启动一个支持多卡训练的容器，推荐使用以下命令：

docker run --rm -it \
  --device=/dev/kfd \
  --device=/dev/dri \
  --group-add video \
  --cap-add=SYS_PTRACE \
  --security-opt seccomp=unconfined \
  --ipc=host \
  rocm/pytorch:rocm7.0_ubuntu22.04 \
  bash

这里有几个关键点需要注意：

• --device=/dev/kfd 和 --device=/dev/dri：这是内核驱动与用户态通信的必经之路，缺少任何一个都会导致容器内无法识别 GPU。
• --group-add video：确保容器内的进程有权限访问视频渲染组，避免报 “Permission denied”。
• --ipc=host：多卡训练时，进程间共享内存至关重要。特别是在使用 RCCL 进行集合通信时，默认的 Docker IPC 限制会导致训练崩溃或极慢，必须开启主机 IPC 命名空间。

进入容器后，运行 rocminfo 如果能列出详细的 GPU 拓扑信息，说明底层链路已经打通。

多卡并行：环境变量与拓扑优化

在单机多卡场景下，如何让每张卡各司其职？ROCm 提供了 HIP_VISIBLE_DEVICES 环境变量，作用等同于 CUDA 的 CUDA_VISIBLE_DEVICES。假设你的服务器有 8 张卡，但只想让当前训练任务使用前 4 张，可以在启动容器时传入：

-e HIP_VISIBLE_DEVICES=0,1,2,3

或者在容器内部 export 设置。这对于在同一台机器上并发运行多个实验非常有用，能有效避免显存争抢。

除了逻辑隔离，物理拓扑也会影响通信效率。在多卡训练中，GPU 之间的数据交换频率极高，如果跨 PCIe 交换机通信，延迟会显著增加。我们可以使用 rocm-smi --showtopo 查看卡间连接情况：

rocm-smi --showtopo

输出结果会展示 GPU 之间是通过 XGMI 直连还是经过 PCIe 桥接。对于大规模分布式训练，尽量将通信密集的进程调度到直连的 GPU 上。在代码层面，PyTorch 的 torch.distributed 会自动调用 RCCL 后端，只要环境变量配置正确，它会根据拓扑自动选择最优通信路径。

从单机到集群：GPU Operator 的自动化调度

当业务规模扩大，单台服务器无法满足算力需求时，就需要引入 Kubernetes 进行集群管理。手动在几十个节点上维护驱动和容器环境是不现实的，这时 AMD GPU Operator 就派上了用场。

作为 ROCm 6.4 及后续版本的重要组件，GPU Operator 实现了驱动生命周期管理、设备插件注册以及自动监控的自动化。部署后，它会自动检测节点上的 Instinct GPU，加载必要的内核模块，并将 GPU 资源暴露给 K8s 调度器。

在 YAML 文件中请求资源时，写法非常直观：

resources:
  limits:
    amd.com/gpu: 2

Operator 还会处理节点的自动封锁与排水，确保在驱动升级或维护时，正在运行的训练任务能安全迁移或暂停，极大降低了运维风险。结合 Prometheus 监控 exporter，你可以实时看到集群中每张卡的温度、功耗和利用率，为资源扩容提供数据支撑。

通过 Docker 容器化配合 ROCm 7.x 的新特性，我们在 AMD 硬件上构建深度学习工作流变得前所未有的顺畅。无论是单机多卡的快速验证，还是千卡集群的弹性伸缩，这套方案都能提供稳定可靠的底层支撑，让开发者将精力真正回归到模型与算法本身。

200小时GPU算力已就位，快来领取：https://marketing.csdn.net/questions/Q2604140858304426315?utm_source=AIpaper