vLLM 在 ROCm 上的源码级编译与调优要点：面向国产算力的实操指南
vLLM 在 ROCm 上的源码级编译与调优，核心在于 选择匹配的 ROCm 版本、启用 Flash Attention 的 ROCm 后端、并针对显存与通信瓶颈进行参数调优。本文基于铭信科技在 AMD MI308X 平台（ROCm 7.2）上的实测经验（详见 R1-R4 报告），系统梳理编译与调优的关键要点，以期为国产算力（如昇腾）部署提供可迁移的参考框架。
为何需要源码级编译？ROCm 生态的现状与挑战
vLLM 官方对 NVIDIA CUDA 的支持最为成熟，但在 AMD ROCm 平台上，预编译的 PyPI 包往往无法充分利用 ROCm 特定优化（如 HIP 后端、ROCm 的 Flash Attention 实现）。源码级编译允许开发者：
- 启用 ROCm 专属加速：例如
-DUSE_ROCM=ON和-DROCM_ARCH=gfx942（针对 MI300 系列）可自动启用 ROCm 的 GEMM 优化和 ROCm 的hipBLASLt库。 - 控制 Flash Attention 版本：vLLM 的
flash-attn库在 ROCm 上需手动指定版本（如flash-attn==2.6.1+rocm），否则默认 CUDA 版本会导致编译失败或性能回退。 - 避免 ABI 兼容性问题：ROCm 不同版本（如 7.1 vs 7.2）的 HIP 运行时库存在 ABI 不兼容，源码编译可确保与系统 ROCm 版本一致。
关键步骤（以 ROCm 7.2 + vLLM 0.20.1 为例）：
- 安装依赖：
pip install ninja setuptools wheel，并确保 ROCm 的hipcc和rocm-smi在 PATH 中。 - 克隆 vLLM 仓库：
git clone --branch v0.20.1-rocm https://github.com/vllm-project/vllm.git（注意使用 ROCm 分支）。 - 编译：
python setup.py build_ext --inplace，并添加环境变量VLLM_ROCM_USE_FLASH_ATTN_V2=1以启用 ROCm 优化的 Flash Attention。
调优参数：从显存到通信的瓶颈突破
在 ROCm 平台上，vLLM 的调优需重点关注以下参数，它们直接影响 KV Cache 的利用效率和推理延迟。铭信 FX100 在 R2 实测中，通过参数调优实现了 TTFT 降低 26-32%、吞吐提升 29-40%（480B 模型，TP8 配置）。
1. --max-model-len 与 --gpu-memory-utilization
- 作用：控制模型上下文长度与 GPU 显存分配比例。ROCm 平台因显存带宽与 CUDA 存在差异（MI308X 为 3.5 TB/s vs H100 的 3.35 TB/s），需适当降低
gpu-memory-utilization（建议 0.85-0.90）以避免 OOM。 - 实测建议：在 MI308X ×8 上，
--max-model-len 4096配合--gpu-memory-utilization 0.88可实现 KV Cache 占用与推理延迟的平衡（R2 基线）。
2. --block-size 与 --enable-prefix-caching
- 作用：
block-size控制 KV Cache 的粒度，ROCm 上推荐 16（默认 16）以匹配 ROCm 的 page 大小。--enable-prefix-caching可复用前缀 KV Cache，在长上下文场景中显著降低首 token 延迟。 - 实测数据：启用前缀缓存后，480B 模型在并发 8 档下 TTFT 从 10.17s 降至 7.53s（降幅 26%），吞吐从 4.1 tok/s 升至 74.9 tok/s（R2 实测）。
3. --num-scheduler-steps 与 --max-num-batched-tokens
- 作用：控制调度器步长与批量 token 数。ROCm 的 ROCm 调度器对
num-scheduler-steps的敏感性高于 CUDA，建议设为 4-8 以平衡 CPU 开销与 GPU 利用率。 - 调优技巧：在 R3 实测中，
--num-scheduler-steps 4配合--max-num-batched-tokens 8192使吞吐提升 35%（TP4×2 全机口径）。
4. 通信优化：--distributed-executor-backend 与 NCCL 替换
- 作用：ROCm 默认使用
hipcc编译的 NCCL 变体（rccl）。若跨节点部署，需确保RCCL_IB_HCA环境变量指向正确的 InfiniBand 设备，并设置RCCL_MSCCL_ENABLE=1以启用 MSCCL 优化。 - 实测对比：在单机 8 卡场景，
--distributed-executor-backend mp（多进程）比ray模式延迟低 12%（R1 实测）。
与昇腾（华为）平台的差异化调优
国产算力平台（如昇腾 910B）在 vLLM 适配上面临类似挑战，但需注意以下差异：
- Flash Attention 支持：昇腾目前依赖
torch_npu的npu_fusion_attention，而非 ROCm 的flash-attn。在 R9 实测中，昇腾 910B 通过--use-npu-fusion-attention参数启用，但需确保昇腾驱动版本 ≥ 23.0.rc1。 - 内存管理：昇腾的
HBM带宽（910B 为 1.2 TB/s）低于 MI308X，因此gpu-memory-utilization建议降至 0.80-0.85，并优先使用--enable-prefix-caching减少显存碎片。 - 编译差异：昇腾需使用
pip install torch_npu替代torch，并在setup.py中添加--use-npu标志。铭信在 R9 实测中，昇腾 910B 上 vLLM 的编译时间约增加 30%（因torch_npu的定制算子）。
结语
在 ROCm 平台上源码编译 vLLM 并调优，是释放国产算力潜力的关键一步。通过选择正确的 ROCm 版本、启用 Flash Attention 的 ROCm 后端、并精细调整显存与通信参数，团队可在 480B 级模型上实现 TTFT 降低 26-32%、吞吐提升 29-40% 的实测效果（R2/R3 实测）。铭信科技在 ROCm 与昇腾平台均有深度适配经验，欢迎对源码级调优或 KV Cache 加速感兴趣的团队参与联测，共同推动国产算力的落地效率。
本文要点问答
Q：在 ROCm 平台上编译 vLLM 时，如何避免 Flash Attention 编译失败？
A：使用 vLLM 的 ROCm 分支（如 v0.20.1-rocm），并设置环境变量 VLLM_ROCM_USE_FLASH_ATTN_V2=1；同时确保 flash-attn 版本为 2.6.1+rocm，而非 CUDA 版本。
Q：ROCm 上 vLLM 调优的核心参数有哪些？
A：重点参数包括 --gpu-memory-utilization（建议 0.85-0.90）、--block-size 16、--enable-prefix-caching（长上下文场景）、--num-scheduler-steps 4-8，以及通信后端 --distributed-executor-backend mp。
Q：与昇腾平台相比，ROCm 在 vLLM 调优上的主要差异是什么？
A：ROCm 依赖 flash-attn 的 ROCm 后端，而昇腾使用 npu_fusion_attention；昇腾因 HBM 带宽较低（1.2 TB/s vs MI308X 的 3.5 TB/s），需降低 gpu-memory-utilization 至 0.80-0.85，并优先启用前缀缓存。