当前位置：首页 > news >正文

AMD 显卡跑大模型，vLLM 加 ROCm 7.x 部署实录

news 2026/7/2 12:58:08

环境基线检查与权限配置

在 AMD Instinct GPU 上跑大模型，最让人头疼的往往不是模型本身，而是“环境地狱”。很多开发者兴致勃勃地拉下代码，结果卡在驱动版本不匹配或者权限问题上，半天连个hello world都跑不起来。要想稳稳当当地部署 vLLM，第一步必须把地基打牢。

我强烈建议使用Ubuntu 22.04 LTS或更新版本的内核，这对新硬件的调度支持更友好。系统装好后，别急着装驱动，先确认当前用户是否有足够的权限访问 GPU 设备。ROCm 驱动默认只允许特定用户组的成员调用硬件，如果漏了这一步，后续所有推理服务都会报Permission denied。

执行以下命令将当前用户加入video和render组：

sudousermod-aGvideo,render$USER

注意：执行完后必须重启系统才能生效。重启后，可以通过groups $USER再次确认是否已包含这两个组。此外，检查编译器版本也很关键，ROCm 7.x 通常对GCC 11或Clang 15支持最好。如果系统默认版本过高（比如 GCC 13），建议用update-alternatives切换一下，避免编译 PyTorch 时出现奇怪的链接错误。

ROCm 7.x 驱动安装与状态验证

驱动是整个栈的基石。对于生产环境，千万别去下载第三方打包好的“一键安装包”，最稳妥的方式是直接添加 AMD 官方软件源进行安装。安装过程遵循官方文档即可，这里不再赘述流水账，重点说说安装完如何验证。

很多人装完驱动就直接跳去装 PyTorch，这是大忌。必须先确认内核态驱动是否正常工作。打开终端，输入：

rocm-smi

如果能看到一张清晰的表格，列出了所有 GPU 的温度、功耗、显存使用率以及频率策略，说明驱动层没问题。如果报错或者显示为空，那后续步骤都不用做了，先修驱动。

接下来运行rocminfo查看详细的硬件架构信息。你需要确认系统识别到的 GPU 架构代码（例如 MI300X 对应的是gfx942）。这个代码在后面编译 PyTorch 时要用到，填错了会导致生成的二进制文件在当前 CPU/GPU 上无法运行，抛出illegal instruction错误。顺便试一下hipcc编译器，随便写个简单的 HIP Hello World 编译跑一下，确保开发工具链是通的。这一步看似繁琐，但能提前排除 80% 的硬件识别坑。

PyTorch 源码编译与架构指定

虽然 PyTorch 提供了预编译的 ROCm 版本，但在 Instinct GPU 这种新架构上，为了获得最佳性能和对新算子（如 FP8）的支持，源码编译几乎是必经之路。

首先创建一个干净的 Conda 环境，避免污染系统 Python。安装好ninja、wheel等构建依赖后，最关键的一步是设置环境变量。你必须明确告诉编译器你的显卡架构：

exportPYTORCH_ROCM_ARCH=gfx942exportMAX_JOBS=$(nproc)

这里的gfx942需根据你实际的rocminfo输出调整。如果不设这个变量，PyTorch 可能会编译成通用版本，丢失针对特定架构的优化，甚至直接跑不起来。

接着克隆 PyTorch 源码并开始编译：

gitclone--recursivehttps://github.com/pytorch/pytorchcdpytorch python setup.pyinstall

编译过程比较耗时，喝杯咖啡等着就行。完成后，用一行代码快速验证：

python-c"import torch; print(torch.cuda.is_available()); print(torch.version.hip)"

如果输出True且显示了 HIP 版本，恭喜，最难的关卡已经过了。接下来安装 vLLM 时，同样需要确保它链接到你刚编译好的 PyTorch，并且传入正确的HIP_PATH。vLLM 强依赖 Triton 编译器，务必检查 Triton 版本与当前 PyTorch 的兼容性，否则容易在启动时报kernel not found。

vLLM 部署与显存调优实战

环境就绪后，终于到了启动服务的环节。vLLM 的核心优势在于 PagedAttention 技术，它能极大提升显存利用率，但在 AMD 平台上，我们仍需手动微调一些参数以防 OOM（内存溢出）。

启动命令示例如下：

vllm serve meta-llama/Llama-3-8B-Instruct\--host0.0.0.0\--port8000\--gpu-memory-utilization0.92\--block-size16\--dtypeauto

这里有几个关键点值得注意：

--gpu-memory-utilization：建议设置在0.90 到 0.92之间。ROCm 下的显存管理有时不如 CUDA 激进，留一点余量给系统开销和驱动本身，能有效防止因瞬时峰值导致的进程崩溃。
--block-size：默认为 16，如果你的业务场景主要是短文本，可以尝试调小以提高细粒度利用率；如果是长上下文，保持默认或调大均可。
量化支持：如果显存紧张，可以加上--quantization fp8（需模型和后端支持），这在 MI300X 上能显著降低显存占用并提升吞吐。

服务启动后，观察日志直到看到 “Uvicorn running on…”。测试时不要只用浏览器访问，建议用curl或 Python 脚本模拟真实的 POST 请求， hitting/v1/completions接口。重点关注首字延迟（TTFT）和生成速度。如果发现并发一高就崩，大概率是显存碎片化严重，可以尝试调整block-size或降低gpu-memory-utilization。

如果在多卡环境下，记得加上--tensor-parallel-size <N>来启用张量并行。此时要确保所有卡在同一个 PCIe 根复合体下，或者通过 Infinity Fabric 互联，否则通信延迟会吃掉性能红利。

折腾完这一套，你会发现 AMD 平台的推理成本优势确实明显。虽然前期配置稍微麻烦点，但一旦跑通，稳定性和性价比都非常可观。对于想低成本搭建私有化大模型服务的团队来说，这条路径绝对值得投入时间去打磨。

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

查看全文

http://www.jsqmd.com/news/1108980/