为什么选择容器化部署 ROCm

在本地或云端搭建 AMD GPU 推理环境时，最让人头疼的往往不是模型本身，而是那套复杂的“环境依赖地狱”。ROCm 栈对宿主机内核版本、驱动版本以及编译器工具链有着极其严苛的要求。一旦宿主机升级了内核，或者不同项目需要不同版本的 PyTorch 和 vLLM，整个开发环境就可能瞬间崩塌。

这时候，Docker 容器的价值就凸显出来了。通过将 ROCm 7.x 运行时、PyTorch 框架以及 vLLM 推理引擎全部封装在镜像中，我们可以实现“一次构建，到处运行”。这不仅彻底解耦了应用与宿主机驱动的强绑定关系，还让多租户环境下的资源隔离变得轻而易举。对于需要在 Kubernetes 集群中调度 AMD Instinct GPU 的团队来说，容器化更是实现自动化运维和高可用性的基石。

构建专属的 ROCm 7.x 推理镜像

要打造一个稳定的推理环境，第一步是编写高质量的 Dockerfile。我们不需要从零开始安装驱动，而是应该基于官方提供的 ROCm 基础镜像进行扩展。这样既能保证底层 HIP 库的兼容性，又能大幅减少构建时间。

以下是一个针对 vLLM 推理服务优化的 Dockerfile 示例，它涵盖了基础环境设置、关键环境变量注入以及依赖安装的核心逻辑：

FROM rocm/pytorch:rocm6.2_ubuntu22.04_py3.10_pytorch_2.5.1

# 设置环境变量，确保 ROCm 路径被正确识别
ENV PATH=/opt/rocm/bin:$PATH
ENV LD_LIBRARY_PATH=/opt/rocm/lib:$LD_LIBRARY_PATH
ENV HSA_OVERRIDE_GFX_VERSION=9.4.2

# 安装系统级依赖，避免编译时缺少头文件
RUN apt-get update && apt-get install -y \
    ninja-build \
    git \
    vim \
    && rm -rf /var/lib/apt/lists/*

# 安装 vLLM 及其依赖
# 注意：生产环境建议指定具体版本号以保证稳定性
RUN pip install --no-cache-dir vllm==0.5.4 triton==2.2.0

# 设置工作目录
WORKDIR /workspace

# 暴露默认服务端口
EXPOSE 8000

CMD ["vllm", "serve", "/models/llama-3-8b", "--host", "0.0.0.0", "--port", "8000"]

在这个文件中，有几个细节值得注意。首先，HSA_OVERRIDE_GFX_VERSION 是关键，特别是在使用较新的 MI300 系列显卡时，显式指定架构版本（如 9.4.2）可以避免因自动检测失败导致的“非法指令”错误。其次，我们选择了 Ubuntu 22.04 作为基底，这是目前 ROCm 生态支持最完善的发行版。最后，通过 pip install 直接安装预编译好的 vLLM 包，能规避大部分源码编译带来的链接错误。

解决驱动兼容性与设备映射

很多初学者在运行容器时会遇到"GPU 不可见”的问题，这通常是因为启动容器时没有正确传递设备权限。与 NVIDIA 的 --gpus all 参数不同，AMD GPU 的容器化部署需要更精细的设备映射配置。

在 Docker 命令行中，我们需要使用 --device 标志将宿主的渲染设备映射到容器内部。一个标准的启动命令如下所示：

docker run --rm -it \
  --device=/dev/kfd \
  --device=/dev/dri \
  --group-add video \
  --ipc=host \
  --shm-size 16G \
  -p 8000:8000 \
  -v /data/models:/models \
  my-rocm-vllm-image

这里 /dev/kfd 是 AMD GPU 的内核固件驱动接口，而 /dev/dri 则包含了 Direct Rendering Infrastructure 设备节点。--group-add video 确保容器内的用户有权限访问这些硬件资源。--ipc=host 和较大的 --shm-size 则是为了应对大模型推理过程中频繁的进程间通信和共享内存需求，防止因共享内存不足导致的服务崩溃。

通过这种方式，无论宿主机的具体驱动小版本如何变化，只要内核模块加载正常，容器内的应用就能稳定调用 GPU 算力，真正实现了环境与底层的解耦。

Kubernetes 集群中的多租户调度

当业务规模扩大到集群级别时，手动管理 Docker 容器显然不再可行。在 Kubernetes (K8s) 中调度 AMD GPU 资源，需要借助 k8s-device-plugin 来暴露硬件资源给调度器。

部署 Device Plugin 后，AMD GPU 会以 amd.com/gpu 的资源形式出现在节点状态中。在多租户场景下，安全性与隔离性是首要考量。我们可以通过 K8s 的 ResourceQuota 和 LimitRange 来限制每个命名空间可使用的 GPU 数量，防止单个任务耗尽集群资源。

此外，利用 Pod 的 securityContext 可以进一步提升安全性。例如，禁止容器以特权模式运行，并只挂载必要的配置文件卷。对于需要高性能互联的多卡推理任务，还可以配合拓扑感知调度插件，确保同一 Pod 内的多个容器被调度到同一台物理机的不同 GPU 上，从而利用高速的 Infinity Fabric 互联带宽，降低张量并行通信延迟。

在实际生产中，我们还建议为推理服务配置健康检查探针（Liveness/Readiness Probes），结合 Prometheus 监控 GPU 显存和温度指标，一旦检测到异常立即自动重启或迁移 Pod，确保服务的高可用性。

容器化不仅简化了 ROCm 环境的部署流程，更为大规模集群管理提供了标准化的交付单元。当你还在为环境配置焦头烂额时，或许可以直接利用现成的云算力快速验证想法。

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