环境基石：从权限到架构验证

在 AMD Instinct GPU 上跑通 vLLM，最让人头疼的往往不是模型本身，而是那些“静默失败”的环境配置。很多开发者在 DevCloud 上拿到实例后，急于安装框架，却忽略了操作系统层面的基础权限，导致后续驱动无法调用硬件。我们通常选择 Ubuntu 22.04 LTS 作为底座，因为它对 ROCm 7.x 的内核支持最为成熟稳定。

登录实例后的第一件事，是配置用户权限。ROCm 驱动运行依赖于特定的设备节点访问权，默认情况下普通用户是没有权限的。你必须执行以下命令，将当前用户加入 video 和 render 用户组：

sudo usermod -aG video,render $USER

这一步至关重要，但常被遗漏。执行完后必须重启系统（sudo reboot），否则新的组权限不会生效。很多“驱动安装成功但无法识别显卡”的诡异问题，根源就在于此。重启后，你可以用 groups $USER 确认自己是否已在这两个组中。

接下来是驱动验证。不要直接跳过这一步去装 PyTorch，否则运行时遇到"illegal instruction"错误再回头查驱动，会浪费大量时间。首先运行 rocm-smi，如果能看到清晰的表格列出 GPU 的温度、功耗和显存使用率，说明内核态驱动工作正常。紧接着，执行 rocminfo 获取详细的硬件架构信息，重点关注输出中的 Name: gfx90a 或 gfx942 等架构代码。记下这个代码，它在下一步编译 PyTorch 时是必填项。如果系统识别到的架构代码与你预期的 Instinct 型号不符，说明驱动层仍有问题，切勿强行继续。

核心组件编译：避开架构陷阱

虽然 PyTorch 提供了预编译的 ROCm 版本，但在生产环境或追求极致性能时，源码编译往往是必经之路，尤其是为了适配最新的算子优化。这里有一个极易踩坑的核心点：环境变量设置。

在激活 Conda 虚拟环境后，编译 PyTorch 前必须导出架构变量：

export PYTORCH_ROCM_ARCH="gfx90a" # 替换为你刚才 rocminfo 查到的实际代码

如果忽略这一步，编译出的二进制文件将无法在当前硬件上运行，报错时往往没有任何友好提示，直接崩溃。同时，建议使用 GCC 11 或 Clang 15 作为编译器，版本过高或过低都可能引发链接错误。安装构建依赖（如 ninja, wheel）后，使用以下命令加速编译：

MAX_JOBS=$(nproc) pip install .

PyTorch 安装完毕后，用 python -c "import torch; print(torch.cuda.is_available())" 快速验证。在 ROCm 环境下，PyTorch 通常兼容此接口，若返回 True，则说明后端识别成功。

随后是 vLLM 的安装。vLLM 对 Triton 编译器有强依赖，必须确保安装的 Triton 版本与当前 PyTorch ROCm 后端严格匹配。在执行 pip install vllm 之前，需显式导出 HIP_PATH 指向 ROCm 安装目录（通常为 /opt/rocm），并设置 MAX_JOBS 利用多核 CPU 加速构建：

export HIP_PATH=/opt/rocm
export MAX_JOBS=8
pip install vllm --no-build-isolation

加上 --no-build-isolation 参数可以减少环境隔离带来的依赖冲突。编译完成后，再次确认环境无误，即可进入服务启动阶段。

关键启动参数：性能与稳定的平衡术

大模型推理的核心瓶颈在于显存管理。vLLM 引入的 PagedAttention 技术虽大幅提升了利用率，但在 AMD 平台上仍需精细调优。启动服务时，以下几个参数决定了你的服务是“丝滑流畅”还是“频繁 OOM"。

首先是 --gpu-memory-utilization。这是控制 vLLM 占用显存比例的关键参数。建议将其设置为 0.90 至 0.92 之间，而非激进的 0.95。预留少量显存给系统开销和驱动缓冲，能有效防止因瞬时峰值导致的 OOM（内存溢出）崩溃。对于显存较大的 MI300X 等卡片，可以适当放宽，但务必留有余地。

其次是 --max-model-len 和 --max-num-seqs。这两个参数直接影响并发能力和延迟。--max-model-len 限制了单个请求的最大上下文长度。如果你的业务主要是短文本对话，将此值设得过大（如默认的 32k）会无谓地占用 KV Cache 空间，降低并发数。根据实际业务场景截断该值，能显著释放显存用于批处理更多请求。

--max-num-seqs 则控制了单个批次中处理的序列数量。在高并发场景下，若发现吞吐量随并发度增加而非线性增长甚至下降，可能是显存带宽饱和或上下文切换开销过大。此时尝试调整此参数，限制单批次序列数量，往往能找到性能拐点。

针对 ROCm 后端特有的 --enforce-eager 模式，这是一个排查神器。当遇到算子不支持导致服务启动失败或运行时报错时，启用该模式（--enforce-eager）虽会牺牲部分性能（关闭了部分图优化），但能提高兼容性，便于定位具体是哪个算子出了问题。在生产环境稳定运行后，可尝试关闭它以换取更高吞吐。

实战配置清单与基准测试

为了帮助大家快速上手，这里整理了一份针对不同显存大小 Instinct 卡的推荐配置清单（以 Llama 3 8B 为例）：

GPU 型号	显存大小	–gpu-memory-utilization	–max-model-len	–max-num-seqs	备注
MI250X	128GB	0.90	8192	256	适合高并发短文本
MI300X	192GB	0.92	16384	512	可支持更长上下文
MI210	64GB	0.85	4096	128	需严格控制显存

配置好后，如何验证效果？vLLM 内置了强大的基准测试工具 benchmark_serving.py。它可以模拟不同并发程度的用户请求，统计首字延迟（TTFT）、每秒请求数（RPS）和每秒令牌数（TPS）等关键指标。

以下是一个典型的调用示例，模拟 100 个请求，请求速率为每秒 10 个：

python benchmarks/benchmark_serving.py \
    --backend vllm \
    --dataset-name sharegpt \
    --request-rate 10 \
    --num-prompts 100 \
    --model meta-llama/Meta-Llama-3-8B-Instruct

通过调整 --request-rate，我们可以观察系统在不同负载下的表现。在 AMD Instinct GPU 上，理想的 TPS 数值应接近理论峰值的一定比例。如果发现 TTFT 过高，可能需要检查模型加载策略或网络带宽；若 TPS 随并发增加急剧下降，则可能是显存带宽成为瓶颈，或是调度算法未能有效利用多卡资源。记录这些数据，形成基线报告，为后续的优化提供量化依据。

最后，保持环境的纯净至关重要。建议使用 Conda 隔离项目依赖，并在安装前彻底清理旧的缓存文件。通过上述步骤，你应该已经在 AMD Instinct GPU 上成功跑通了 Llama 3 模型的推理全流程。这套最小可行产品（MVP）路径不仅适用于本地测试，也为后续探索多卡并行、高性能监控等高级特性打下了坚实基础。

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