为什么放弃容器，选择手搓源码？

在 AMD Instinct GPU 上跑大模型，官方 Docker 镜像确实能解决 80% 的问题，但对于需要深度定制算子、调试底层性能或者身处内网隔离环境的进阶玩家来说，容器往往显得“黑盒”且不够灵活。最近为了在本地集群复现一些最新的量化实验，我不得不放弃“即插即用”的幻想，硬着头皮从源码编译 PyTorch 和 vLLM。

这一路踩坑不少，尤其是 ROCm 生态对架构参数的敏感性，稍有不慎就会报出令人头大的 illegal instruction。如果你也正准备在裸金属服务器上构建一套完全可控的推理栈，这份基于 ROCm 7.x 的实战记录或许能帮你省下几个通宵。

地基：工具链与架构识别的生死线

编译失败，十有八九是环境没洗干净。ROCm 7.x 对编译器版本相当挑剔，我在 Ubuntu 22.04 上验证过，GCC 11 或 Clang 15 是最稳妥的选择。系统默认的 GCC 12/13 偶尔会在链接阶段抛出奇怪的符号错误，建议通过 update-alternatives 显式切换：

sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-11 100
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-11 100

比编译器更致命的是架构参数。AMD 的 GPU 不像 NVIDIA 那样用简单的算力等级（如 sm_80）区分，而是依赖具体的 GFX 架构代码。编译前必须运行 rocminfo 确认你的硬件代号：

• MI250/MI250X 对应 gfx90a
• MI300X 对应 gfx942
• MI210 对应 gfx908

如果这一步搞错，后续编译出的二进制文件在运行时一定会崩溃。确认无误后，将这个代码导出为环境变量，这是整个编译过程的“通关密钥”：

export PYTORCH_ROCM_ARCH=gfx942
# 同时确保 HIP 路径被识别
export HIP_PATH=/opt/rocm

别忘了将当前用户加入 video 和 render 组，并重启系统，否则驱动权限问题会让你在第一步就卡住。

深水区：PyTorch 与 Triton 的依赖博弈

PyTorch 的源码编译是重头戏。虽然可以直接 pip install torch，但为了启用最新的 hipBLASLt 优化和支持特定算子，源码编译是必经之路。

创建一个干净的 Conda 环境后，先安装基础构建依赖：

pip install ninja wheel cmake git

克隆 PyTorch 仓库时，记得加上 --recursive 拉取子模块。在執行 python setup.py install 之前，有几个关键变量必须设置：

export USE_ROCM=1
export MAX_JOBS=$(nproc)  # 利用多核加速编译
export CMAKE_ARGS="-DUSE_ROCM=1"

最大的坑在于 Triton。 vLLM 强依赖 Triton 进行算子融合，而 Triton 对 PyTorch 版本极其敏感。不要直接 pip install triton，务必使用与当前 PyTorch 分支匹配的 Triton 源码进行编译，或者寻找社区预编译的兼容 wheel。我在一次尝试中直接安装了最新版 Triton，结果导致 vLLM 启动时提示 kernel not found，最后不得不回退到与 PyTorch 2.4 对应的 Triton 版本才解决。

编译完成后，用一行代码快速验身：

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

看到 True 和对应的 ROCm 版本号，才算过了第一关。

跨越链接陷阱：LD_LIBRARY_PATH 的修复艺术

轮到 vLLM 登场了。执行 pip install vllm 时，如果之前没设置好 PYTORCH_ROCM_ARCH，这里会再次报错。即便架构正确，还常遇到链接器找不到 HIP 库的问题，表现为 ImportError: libhipblas.so.2: cannot open shared object file。

这是因为动态链接库路径未生效。最彻底的解决方法是在 ~/.bashrc 中永久追加：

export LD_LIBRARY_PATH=/opt/rocm/lib:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/opt/rocm/hipblaslt/lib:$LD_LIBRARY_PATH

如果是临时测试，也可以在启动命令前加上 LD_PRELOAD 强制加载。此外，vLLM 编译过程中会调用 HIP 编译器生成自定义算子，确保 hipcc 在 $PATH 中可用至关重要。如果遇到 nvcc 相关的报错（是的，有时候脚本里还残留着 CUDA 的检查逻辑），可能需要手动修改 setup.py 中的检测逻辑，强制指定后端为 ROCm。

最后一公里：显存调优与服务启动

一切编译通过后，真正的挑战转为显存管理。vLLM 的核心优势 PagedAttention 在 AMD 卡上同样有效，但需要精细配置 --gpu-memory-utilization。

MI300X 拥有 192GB 显存，但默认情况下 vLLM 可能只占用 90%。对于大并发场景，我们可以激进一点推到 0.95，但要预留几 GB 给系统开销，防止 OOM。启动命令示例：

vllm serve /models/Llama-3-70B-Instruct \
    --host 0.0.0.0 \
    --port 8000 \
    --dtype bfloat16 \
    --gpu-memory-utilization 0.95 \
    --block-size 16 \
    --tensor-parallel-size 2

这里 --block-size 16 是针对长上下文场景的优化，较小的块尺寸能减少显存碎片，提升 KV Cache 的利用率。如果模型支持 FP8，还可以加上 --quantization fp8，在 MI300X 上能带来显著的吞吐提升。

当终端打印出 Uvicorn running on http://0.0.0.0:8000 时，那种成就感是无与伦比的。这不仅意味着你拥有了一个可运行的服务，更意味着你完全掌控了从驱动到应用栈的每一行代码。虽然手搓源码过程痛苦，但当你在生产环境中需要微调某个算子或排查深层性能瓶颈时，这份掌控力就是最大的底气。

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