选对镜像：避开驱动冲突的第一道坎

刚拿到 DevCloud 账号时，最容易踩的坑就是“盲目追新”。很多开发者习惯性地拉取最新的 ROCm 镜像，结果发现宿主机驱动版本与容器内不匹配，导致 rocm-smi 命令直接报错，甚至无法识别 GPU。在 AMD 生态中，宿主机的内核模块与容器内的用户态库版本必须严格对应，这一点比 NVIDIA 生态更为敏感。

在 DevCloud 平台上，最稳妥的方案是直接使用控制台提供的“预置开发镜像”。这些镜像通常已经通过了平台方的兼容性测试，内置了与当前节点驱动完美匹配的 ROCm 7.x 环境。创建实例时，务必在镜像市场筛选带有"ROCm 7.x"且标注为“推荐”或“稳定版”标签的选项。如果必须自定义 Dockerfile，请务必先通过 cat /etc/os-release 确认宿主机基础环境，并严格锁定 rocm-dev 的版本号，不要使用 latest 标签。这一步看似简单，却能节省后续数小时的排查时间。

启动后的“体检”：编写设备可见性诊断脚本

容器启动成功并不代表万事大吉，第一步必须是验证硬件是否真正“就位”。不要只依赖 nvidia-smi 那种图形化输出（AMD 对应的是 rocm-smi），在自动化脚本或 CI/CD 流程中，我们需要更程序化的检查方式。

我习惯在容器入口写一个简单的 Python 诊断脚本，利用 torch 和 hip 接口快速摸底。以下这段代码可以直接复用，它能帮你确认设备数量、显存大小以及是否支持 BF16 等关键特性：

import torch
import sys

def check_rocm_health():
    if not torch.cuda.is_available():
        # 在 ROCm 环境下，torch 依然使用 cuda 作为后端别名
        print("❌ 错误：未检测到可用的 ROCm 设备，请检查 HIP_VISIBLE_DEVICES 环境变量")
        return False
    
    device_count = torch.cuda.device_count()
    print(f"✅ 检测到 {device_count} 个加速卡")
    
    for i in range(device_count):
        props = torch.cuda.get_device_properties(i)
        free_mem = torch.cuda.mem_get_info(i)[0] / 1024**3
        total_mem = props.total_memory / 1024**3
        
        print(f"--- 卡 {i}: {props.name} ---")
        print(f"   显存总量：{total_mem:.2f} GB")
        print(f"   可用显存：{free_mem:.2f} GB")
        
        # 检查 BF16 支持，这对大模型推理至关重要
        if props.major >= 9: 
            print("   ✅ 支持 BF16 加速")
        else:
            print("   ⚠️ 需确认是否开启 FP16 兼容模式")
            
    return True

if __name__ == "__main__":
    if not check_rocm_health():
        sys.exit(1)
    print("🎉 环境健康检查通过，准备启动服务")

将这段脚本保存为 health_check.py 并在容器内运行。如果看到红色的错误提示，第一时间检查启动参数中的 --device 映射或环境变量 HIP_VISIBLE_DEVICES 是否被错误限制。

vLLM 配置实战：块表参数与常见报错

环境验证无误后，就可以部署 vLLM 了。在 ROCm 7.x 上运行 vLLM，最让人头疼的往往是显存管理相关的报错，尤其是 Block Table 分配失败。这是因为 vLLM 的 PagedAttention 机制需要预先划分显存块，而不同型号的 Instinct GPU 显存拓扑结构不同，默认参数未必最优。

常见的报错信息类似 RuntimeError: CUDA out of memory（注意：ROCm 下报错信息有时仍沿用 CUDA 字样）或者 Assertion failed: block table size mismatch。这通常是因为 gpu-memory-utilization 设置过高，留给 KV Cache 的空间不足，或者是 max-num-batched-tokens 设定超出了物理显存承载能力。

针对 MI300 系列等大显存卡片，建议显存利用率控制在 0.9 左右，预留一部分给操作系统和上下文切换。下面是一个经过实测的启动命令模板，专门针对 ROCm 7.x 进行了参数调优：

export HIP_VISIBLE_DEVICES=0

python -m vllm.entrypoints.api_server \
    --model meta-llama/Llama-3-8B-Instruct \
    --host 0.0.0.0 \
    --port 8000 \
    --dtype bfloat16 \
    --gpu-memory-utilization 0.90 \
    --max-num-batched-tokens 8192 \
    --max-num-seqs 256 \
    --block-size 16 \
    --enforce-eager False \
    --disable-custom-all-reduce

这里有几个关键点：--dtype bfloat16 能充分利用 Instinct GPU 的 Tensor Core 性能；--block-size 16 是在显存碎片化和命中率之间的一个平衡值，若遇到长文本场景可尝试调整为 32；--disable-custom-all-reduce 在单卡或特定多卡拓扑下能避免某些集合通信库的兼容性崩溃。如果在启动时遇到 hipblaslt 相关的底层错误，尝试添加 --num-scheduler-steps 1 来简化调度逻辑。

网络挂载与显存分配的“深坑”

完成了服务启动，最后一步往往是加载模型权重。在 DevCloud 上，模型文件通常存放在共享存储（如 NFS 或对象存储挂载点）中。很多开发者在这里遇到了“隐形”问题：容器内能看到挂载目录，但读取大文件时速度极慢，甚至导致进程假死。

这通常是网络文件系统的小文件读取策略问题。解决方案是在挂载时增加 rsize 和 wsize 参数，或者在加载模型前，先将权重文件复制到容器本地的临时高速存储（如 /tmp 或内存盘）中。对于 7B 以上的模型，虽然复制需要几分钟，但能换来推理时稳定的 I/O 吞吐，避免因为网络抖动导致的首字延迟飙升。

另外，如果在多卡环境下遇到显存分配不均，部分卡显存爆满而其他卡空闲，请检查 NCCL_DEBUG=INFO 的输出日志。ROCm 7.x 对 RCCL 通信库进行了更新，有时需要手动指定 NCCL_SOCKET_IFNAME 来绑定正确的网卡接口，确保卡间通信走的是高速互联通道而非缓慢的以太网。

当你在终端看到 Uvicorn running on http://0.0.0.0:8000 且没有任何报错堆栈时，恭喜你已经跨过了最艰难的适配期。此时发送一个简单的 curl 请求，如果能在秒级内收到流畅的回复，这套基于 DevCloud + ROCm 7.x + vLLM 的推理链路就算真正跑通了。接下来的工作，就是根据实际业务流量，微调并发参数与量化策略了。

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