环境筑基：从 DevCloud 到驱动验证

很多开发者在尝试 AMD GPU 部署大模型时，往往还没开始写代码就倒在了环境配置上。尤其是面对 ROCm 生态，版本依赖的细微差别都可能导致编译失败。我的实践是从干净的 Ubuntu 22.04 LTS 系统开始，这是目前 ROCm 7.x 支持最稳定的底座。

在动手安装任何深度学习框架前，必须先打通硬件层。将当前用户加入 video 和 render 组是基础操作，执行 sudo usermod -aG video,render $USER 后务必重启，否则后续驱动无法调用显卡资源。重启后，不要急着装 PyTorch，先用 rocm-smi 命令“点名”。如果终端能清晰列出所有 GPU 的温度、功耗和显存占用，说明内核态驱动工作正常。这一步看似简单，却能提前排除 80% 的硬件识别问题。对于云端的 DevCloud 实例，建议直接选用官方预制的 ROCm 7.x 镜像，避免手动添加软件源时引入不兼容的内核模块。

确认硬件就绪后，工具链的版本检查至关重要。ROCm 7.x 对编译器比较挑剔，GCC 11 或 Clang 15 是比较稳妥的选择。使用 gcc --version 确认版本，若系统默认版本过高，可通过 update-alternatives 切换。此外，CMake 需保持在 3.20 以上，Git 最好更新到最新版以支持大仓库的浅克隆。Python 环境方面，强烈建议使用 Conda 创建独立虚拟环境，这能有效隔离系统包，防止后续安装出现依赖冲突。

源码编译：避开依赖陷阱的关键步骤

虽然 PyTorch 提供了预编译的 ROCm 版本，但在生产环境中，为了获得最佳性能和对新算子的完整支持，源码编译往往是必经之路。这也是最容易踩坑的环节。

在激活 Conda 环境后，首先安装构建依赖，包括 ninja、wheel 以及特定版本的 hipblaslt 库。最关键的一步是设置环境变量 PYTORCH_ROCM_ARCH，必须明确指定为你的显卡架构代码（如 gfx90a 或 gfx942）。如果忽略这一步，编译出的二进制文件可能在运行时抛出"illegal instruction"错误，导致服务直接崩溃。

编译 PyTorch 时，建议使用 MAX_JOBS 环境变量利用多核 CPU 加速过程。待 PyTorch 安装完毕，通过 python -c "import torch; print(torch.cuda.is_available())" 进行快速验证（ROCm 环境下通常兼容此接口）。随后进行 vLLM 的编译，vLLM 对 Triton 编译器有强依赖，需确保安装的 Triton 版本与当前 PyTorch 版本严格匹配。在执行 pip install vllm 时，同样需要传入正确的 HIP_PATH 和架构参数，确保其内部的 HIP 内核能被正确编译和优化。如果在链接阶段报错找不到 HIP 库，通常是 LD_LIBRARY_PATH 未包含 ROCm 的 lib 目录，需在 .bashrc 中永久导出该路径。

显存调优：防止 OOM 的核心策略

大模型推理最核心的瓶颈在于显存。vLLM 引入的 PagedAttention 技术极大提升了显存利用率，但在 AMD 平台上仍需精细配置，否则极易发生 OOM（内存溢出）崩溃。

启动服务前，需根据模型参数量估算显存需求。除了模型权重本身，还要预留足够的空间用于 KV Cache。通过 --gpu-memory-utilization 参数可以控制 vLLM 占用显存的比例，建议设置为 0.9 到 0.95 之间，留出少量余量给系统开销。针对显存碎片化问题，可以启用 --block-size 参数调整内存块大小。较小的 block size 能提高细粒度利用率，但可能增加管理开销；较大的 block size 则相反，需根据实际业务场景的序列长度分布进行权衡。

若模型支持，开启 --quantization 选项使用 FP8 或 INT8 量化，不仅能减少显存占用，还能显著提升推理速度。在 ROCm 环境下，需确认量化算子是否已被后端完全支持，必要时需在代码层面 fallback 到高精度计算以保证稳定性。对于多卡场景，通过 --tensor-parallel-size 指定 GPU 数量时，还需注意进程绑核设置，避免多个 GPU 进程争抢同一个 CPU 核心资源。

服务验证与生产级监控

当所有依赖和配置就绪后，使用 vllm serve 命令启动服务，监听 0.0.0.0:8000 以便局域网访问。启动过程中，密切观察日志输出，确认模型权重加载进度以及 KV Cache 的初始化情况。一旦看到"Uvicorn running on…"字样，说明服务已成功拉起。

测试环节不能仅凭感觉，需构造标准的 HTTP 请求进行验证。可以利用以下 Python 脚本模拟真实流量，重点关注首字延迟（TTFT）和吞吐量：

import requests
import json

url = "http://localhost:8000/v1/completions"
payload = {
    "model": "your-model-name",
    "prompt": "Hello, how are you?",
    "max_tokens": 100
}

response = requests.post(url, json=payload)
print(json.dumps(response.json(), indent=2))

如果在测试中发现连接被重置或超时，大概率是显存不足导致进程崩溃，或者是防火墙规则阻挡了端口访问。进入生产环境后，可观测性是稳定运行的保障。除了常规的系统监控，必须重点监控 GPU 指标。部署 Prometheus + Grafana 栈，利用 ROCm 导出的 exporter 采集显卡温度、功耗及显存使用率。建议设置合理的告警阈值，例如当显存使用率超过 95% 持续一分钟时触发告警，预防 OOM crash。同时将 vLLM 的标准输出重定向到结构化日志系统，定期复盘请求耗时与 Token 生成数量，识别长尾延迟请求的特征，确保服务长期稳定运行。

🎁 开发者“神装”补给站｜CSDN 6 月宠粉专属福利
工欲善其事，必先利其器。为了帮大家扫清 AI 实践的障碍，CSDN AI 开发者计划，在文末为大家准备了一份「AI 开发者能量包」！