环境准备：避开依赖冲突的“第一道坎”

在 AMD 平台上手搓 vLLM 推理服务，最让人头疼的往往不是模型本身，而是那层层叠叠的编译依赖。很多开发者卡在第一步，就是因为直接照搬了 NVIDIA 平台的教程，结果在 ROCm 环境下碰了一鼻子灰。要想稳稳地跑起来，咱们得先从“地基”打起。

首先，操作系统建议锁定在 Ubuntu 22.04 LTS 或更新版本，内核太旧会导致驱动调度异常。安装好 ROCm 7.x 驱动后，别急着装 Python 包，先用 rocminfo 确认一下显卡架构代码（比如 MI300X 对应的是 gfx942），这个代码后面编译时要用到，填错了直接报 "illegal instruction"。

接下来是工具链。ROCm 7.x 对编译器版本比较挑剔，GCC 11 或 Clang 15 是比较稳妥的选择。如果你系统默认的是 GCC 12+，记得用 update-alternatives 切换一下，否则后续编译 PyTorch 时可能会遇到奇怪的链接错误。另外，ninja 构建工具必不可少，它比传统的 make 快得多，能显著缩短源码编译的等待时间。务必通过 pip install ninja wheel 提前备好，别让编译过程因为缺包而中断。

强烈建议使用 Conda 创建独立的虚拟环境。这不仅是为了隔离依赖，更是为了方便“重来”。在 AI 工程实践中，环境搞崩是常态，有个干净的重置按钮能省掉大量重装系统的时间。

源码编译实战：PyTorch 与 Triton 的适配细节

有了干净的环境，重头戏来了：源码编译。虽然 PyTorch 官方提供了预编译的 ROCm 版本，但为了获得对新算子的最佳支持以及避免版本错配，从源码编译往往是进阶用户的必经之路。

编译 PyTorch 前，最关键的一步是设置环境变量。你必须明确告诉编译器目标架构是什么：

export PYTORCH_ROCM_ARCH=gfx942
export MAX_JOBS=16  # 根据你的 CPU 核心数调整，加速编译

如果不设 PYTORCH_ROCM_ARCH，编译出的二进制文件可能无法在当前硬件上运行。接着，克隆 PyTorch 仓库并进入目录，执行安装命令：

git clone --recursive https://github.com/pytorch/pytorch.git
cd pytorch
pip install .

这个过程可能需要半小时甚至更久，期间请保持网络通畅，因为它需要下载大量子模块。

PyTorch 搞定后，轮到 vLLM 的依赖——Triton。这里有个常见的坑：Triton 的版本必须与 PyTorch 严格匹配。在 ROCm 7.x 环境下，建议直接使用 vLLM 推荐的特定 commit 版本，或者在安装 vLLM 时让它自动解决依赖。如果手动安装 Triton，务必检查其是否开启了 ROCm 后端支持，否则后续 vLLM 编译会找不到 HIP 内核。

最后编译 vLLM 本身。同样需要指定 HIP 路径和架构：

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

加上 --no-build-isolation 可以让 pip 使用当前环境中已安装的依赖，避免它重新下载一套不兼容的版本。如果编译过程中报错提示找不到 hipblaslt，请检查 LD_LIBRARY_PATH 是否包含了 /opt/rocm/lib。

显存优化与服务启动：从 block_size 到生产模板

编译完成不代表结束，如何配置才能让大模型跑得稳、跑得快，才是见功夫的地方。vLLM 的核心优势在于 PagedAttention，但在 AMD 卡上，显存碎片化管理需要更精细的参数调优。

最关键的参数是 --block-size。它决定了 KV Cache 内存块的大小。默认值通常是 16，但在某些长序列场景下，较小的 block size 会导致管理开销过大，而较大的 block size 又可能造成内部碎片。对于显存充裕的 MI300X，可以尝试调整为 32 或 64，观察显存利用率的变化。同时，--gpu-memory-utilization 建议设置在 0.90 到 0.92 之间，留出一点余量给系统开销，防止因瞬时峰值导致 OOM（显存溢出）崩溃。

下面是一个经过验证的启动命令模板，适用于单卡或多卡环境：

vllm serve meta-llama/Llama-3-8B-Instruct \
    --host 0.0.0.0 \
    --port 8000 \
    --tensor-parallel-size 1 \
    --block-size 32 \
    --gpu-memory-utilization 0.92 \
    --dtype bfloat16 \
    --max-model-len 8192

如果是多卡并行，只需修改 --tensor-parallel-size 为显卡数量即可。vLLM 会自动通过 RCCL（ROCm 版的 NCCL）进行卡间通信。启动后，密切观察日志中的 "KV Cache" 初始化信息，确保没有报错。

测试环节不要只用简单的 curl，建议使用 vLLM 自带的 benchmark_serving.py 脚本模拟真实并发流量。重点关注 TTFT（首字延迟）和 Token/s 指标。如果发现并发升高后吞吐量反而下降，可能是显存带宽饱和，此时可以适当减小 --max-num-seqs 来寻找平衡点。

折腾完这一套流程，你会发现虽然步骤繁琐，但每一步都踩在实处。亲手编译过的服务，排查问题时心里更有底，性能调优也更能有的放矢。这种掌控感，是直接使用黑盒 Docker 镜像无法比拟的。

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