编译器选型与用户组权限：迁移的第一步

从 NVIDIA CUDA 生态迁移到 AMD ROCm 平台，很多开发者最容易在“起步阶段”栽跟头。大家习惯了 pip install torch 一键搞定，但在 AMD Instinct GPU 上，操作系统层面的地基如果不牢，后续所有操作都会建立在沙堆之上。

首先，操作系统强烈建议使用 Ubuntu 22.04 LTS。这是目前 ROCm 7.x 支持最完善、社区验证最多的发行版。安装完系统后，第一件事不是装驱动，而是配置用户权限。ROCm 驱动需要直接访问 /dev/kfd 和 /dev/dri 设备节点，默认情况下普通用户无权读取。必须执行以下命令将当前用户加入 video 和 render 用户组：

sudo usermod -aG video,render $USER

注意：执行完这条命令后，必须重启系统才能生效。很多教程漏掉这一步，导致后续 rocm-smi 报错或 PyTorch 无法识别显卡，让人白白浪费几小时排查代码。

重启后，真正的“拦路虎”是编译器版本。ROCm 7.x 对工具链极其挑剔。Ubuntu 22.04 默认可能携带较新的 GCC（如 GCC 12+），这往往会导致编译 PyTorch 时出现难以理解的链接错误。经过多次实战验证，GCC 11 或 Clang 15 是最稳妥的选择。你可以使用 update-alternatives 进行切换：

sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-11 100
gcc --version  # 确认输出为 gcc-11

同时，确保 CMake 版本在 3.20 以上。这一步看似枯燥，却能规避掉后续 80% 因底层工具链不兼容导致的“玄学”报错。

源码编译核心：PYTORCH_ROCM_ARCH 避坑指南

环境准备就绪后，千万不要急着去装预编译的 PyTorch 包。虽然官方提供了 Wheel 包，但在生产环境中，为了获得针对特定显卡架构的最佳算子支持，源码编译是必经之路。这里有一个极易踩坑的核心参数：PYTORCH_ROCM_ARCH。

AMD 的不同显卡架构代码差异巨大，例如 MI250 对应 gfx90a，MI300 对应 gfx942。如果在编译时未指定该变量，或者指定的架构代码与实际硬件不符，编译过程可能看似成功，但运行时会直接抛出 illegal instruction（非法指令）错误，且没有任何友好的提示。

在激活 Conda 虚拟环境并安装好 ninja、wheel、hipblaslt 等构建依赖后，务必先导出正确的架构变量：

# 根据实际显卡型号填写，多卡混合环境可用分号分隔
export PYTORCH_ROCM_ARCH="gfx90a;gfx942" 
export MAX_JOBS=32  # 利用多核 CPU 加速编译
export HIP_PATH=/opt/rocm

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

git clone --recursive https://github.com/pytorch/pytorch.git
cd pytorch
python setup.py install

PyTorch 编译完成后，再安装 vLLM。由于 vLLM 强依赖 Triton 编译器，需确保其版本与当前的 PyTorch ROCm 后端匹配。安装时建议加上 --no-build-isolation 以复用当前环境的依赖：

pip install vllm --no-build-isolation

最后，运行 python -c "import torch; print(torch.cuda.is_available())" 进行验证。在 ROCm 环境下，PyTorch 通常兼容此接口，若返回 True 则说明后端识别正常。

显存碎片化根源分析与 Block Size 调优

理论部署完成后，真正的挑战才刚开始。很多开发者在加载大参数模型（如 70B）时，明明计算过显存总量足够（例如显卡 128GB，模型+KV Cache 预估 110GB），服务却在启动瞬间崩溃，日志直指 OOM（内存溢出）。

排查发现，罪魁祸首往往是显存碎片化。vLLM 引入的 PagedAttention 技术虽然极大地提升了显存利用率，但在 AMD 驱动层面，对非连续内存块的分配策略较为敏感。当 block_size 的默认值（通常为 16）与实际业务场景的序列长度分布不匹配时，会产生大量无法利用的细小显存碎片，导致实际可用显存远低于理论值。

解决方案是手动调整 --block-size 参数。经过实测，将 block size 从默认的 16 调整为 32 或 64，能显著减少碎片率，使显存利用率曲线变得平滑。以下是经过调优后的稳定启动命令：

vllm serve /path/to/model \
  --host 0.0.0.0 \
  --port 8000 \
  --gpu-memory-utilization 0.92 \
  --block-size 32 \
  --quantization fp8 \
  --tensor-parallel-size 2

这里有两个关键细节值得注意：

• --gpu-memory-utilization：建议设为 0.92 而非激进的 0.95。留出 8% 的余量给系统开销和驱动缓冲，能有效防止因瞬时峰值导致的崩溃。
• 量化加速：如果模型支持，开启 fp8 量化不仅减少显存占用，还能在 Instinct GPU 上获得显著的推理提速。ROCm 7.x 对 FP8 算子的支持已相当成熟，是提升性价比的首选方案。

调整完 block size 并启用量化后，原本因碎片化而无法加载的模型通常能顺利拉起。对于正在从 NVIDIA 转投 AMD 的朋友，遇到显存问题不要只盯着总容量看，细粒度的内存管理参数往往是破局的关键。这套流程跑通后，后续的并发测试和 API 对接自然水到渠成。

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