实例创建与镜像选择的“第一公里”

对于初次接触 AMD GPU 的开发者来说，在 DevCloud 上迈出第一步时，最容易踩的坑往往不是代码写错了，而是环境选错了。很多习惯 NVIDIA 生态的朋友会下意识地寻找“最新”的 Docker 镜像，认为版本越新功能越强。但在 AMD ROCm 的世界里，宿主机内核驱动与容器内用户态库的版本必须严格对应，这种耦合度比想象中更敏感。一旦容器内的 ROCm 版本高于宿主机驱动支持的范围，rocm-smi 命令会直接报错，甚至导致 GPU 设备完全不可见。

在 DevCloud 控制台创建实例时，最稳妥的策略是放弃“自定义构建”，直接使用平台提供的预置开发镜像。在镜像市场筛选时，务必认准带有"ROCm 7.x"标签且标记为“推荐”或“稳定版”的选项。这些镜像已经过平台方的兼容性测试，内置的 rocm-dev 包与底层硬件驱动完美匹配。如果你必须使用自定义 Dockerfile，请务必先通过 cat /etc/os-release 确认宿主机基础环境，并严格锁定 rocm-dev 的具体版本号，严禁使用 latest 标签。这一步看似繁琐，实则是为了避开后续数小时的驱动冲突排查，是跑通服务的前提。

编写脚本进行硬件“体检”

容器启动成功并不代表万事大吉，很多时候界面能登录，但 GPU 并没有真正“就位”。不要只依赖命令行工具的输出，在自动化流程或正式部署前，我们需要一种更程序化的方式来确认硬件状态。我习惯在容器入口编写一个简单的 Python 诊断脚本，利用 PyTorch 接口快速摸底，确认设备数量、显存大小以及关键的 BF16（Brain Floating Point 16）支持情况。

以下这段代码可以直接复用，它能帮你快速识别环境是否健康：

import torch
import sys

def check_rocm_health():
    # 在 ROCm 环境下，PyTorch 依然使用 cuda 作为后端别名
    if not torch.cuda.is_available():
        print("❌ 错误：未检测到可用的 ROCm 设备")
        print("请检查 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.90 左右，预留一部分给操作系统和上下文切换，切忌贪心设为 0.95 以上。

下面是一个经过实测的启动命令模板，专门针对 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 来简化调度逻辑，往往能奇效般地解决问题。

验证首个推理接口

当你在终端看到 Uvicorn running on http://0.0.0.0:8000 且没有任何报错堆栈时，恭喜你已经跨过了最艰难的适配期。此时，服务已经处于待命状态，我们可以通过标准的 HTTP 请求来验证它是否真的“活”着。

打开一个新的终端窗口，使用 curl 发送一个简单的测试请求：

curl http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-3-8B-Instruct",
    "prompt": "Hello, please introduce yourself.",
    "max_tokens": 50
  }'

如果能在秒级内收到流畅的 JSON 回复，且内容逻辑通顺，这套基于 DevCloud + ROCm 7.x + vLLM 的推理链路就算真正跑通了。从选择正确的预置镜像，到编写脚本确认 BF16 支持，再到精细调整 block-size 与显存利用率，每一个环节都是确保服务稳定运行的基石。现在，你可以基于这个"Hello World"级的推理接口，进一步探索量化策略、多卡并行或更复杂的业务集成了。

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