AMD 本地大模型部署实战：ROCm 环境修复与 Vulkan/HIP 性能基准测试

随着大语言模型（LLM）的爆发，本地部署大模型已成为开发者、研究人员和 AI 爱好者的刚需。虽然 NVIDIA 凭借 CUDA 生态长期占据主导地位，但 AMD 凭借其极高的性价比（如消费级显卡和二手计算卡 MI50/MI250）以及 ROCm（Radeon Open Compute）生态的不断完善，正成为越来越多人的替代选择。

然而，在 AMD 平台上部署本地大模型并非“开箱即用”。ROCm 环境配置复杂、老旧或未完全支持的硬件存在兼容性陷阱、不同计算后端（如 Vulkan 与 HIP）性能差异显著等问题，劝退了不少尝试者。本文将结合一线实战经验，深入探讨如何修复 ROCm 环境、进行底层调优，并科学对比不同后端的性能，帮助你真正榨干 AMD GPU 的每一滴算力。

跨越硬件鸿沟：ROCm 环境修复与底层配置

在 AMD GPU 上运行本地 LLM，最常见的痛点就是“系统识别不到 GPU”或“性能严重缩水”。这通常是由底层硬件配置和软件环境映射不当引起的。

物理层与系统层调优

对于使用服务器计算卡（如 AMD MI50）或特定消费级显卡的用户，BIOS 设置往往是被忽视的重灾区。例如，MI50 仅支持 PCIe Gen3，若主板插槽默认协商为 Gen4 或启用了 ASPM（Active State Power Management，活动状态电源管理），会导致 PCIe 链路在高负载下反复重训练，甚至导致 ROCm 无法读取 GPU 状态。此外，必须禁用 CSM（Compatibility Support Module，兼容性支持模块），否则 UEFI 兼容模式会阻碍 ROCm 内核驱动的正常加载。在系统层面，建议使用 Ubuntu 22.04 LTS（内核 5.15.x），并彻底禁用 Nouveau 开源驱动，以避免与 amdgpu 驱动发生冲突。

架构覆盖与环境修复

对于未被 ROCm 官方白名单直接支持的 GPU（如基于 Vega 20 架构的 gfx906），我们需要通过环境变量 HSA_OVERRIDE_GFX_VERSION 来“欺骗” ROCm 运行时，使其将当前 GPU 映射为受支持的架构版本。手动查找 PCI ID 并配置 Shell 环境变量既繁琐又容易出错。

为此，社区开发者推出了 ROCmFix 这样的零依赖开源工具。它能够直接读取系统硬件信息（Windows 注册表或 Linux 的 lspci），自动匹配正确的 HSA_OVERRIDE_GFX_VERSION，并一键更新 PowerShell、Bash、Zsh 等 Shell 配置文件。

# 手动配置环境变量示例（以 gfx906 架构为例）
export HSA_OVERRIDE_GFX_VERSION=9.0.6
export HIP_VISIBLE_DEVICES=0

# 验证 ROCm 是否正确识别 GPU
rocm-smi

编译与运行优化：榨干 AMD GPU 的每一滴算力

配置好基础环境后，若想在推理速度上取得突破，直接使用预编译的二进制文件往往不够，我们需要针对特定 GPU 架构进行源码编译和深度调优。

定制化编译 llama.cpp

以目前最流行的本地推理框架 llama.cpp 为例，开启 HIP（Heterogeneous-compute Interface for Portability，异构计算可移植接口）支持并指定目标架构，可以大幅提升计算效率。同时，开启 GGML_HIP_GRAPHS 可以利用 HIP Graphs 技术减少内核启动开销。

# 针对 gfx906 架构编译 llama.cpp
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build \
  -DGGML_HIP=ON \
  -DGGML_HIP_GRAPHS=ON \
  -DAMDGPU_TARGETS=gfx906 \
  -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j$(nproc)

高级环境变量调优

在运行推理服务时，合理配置 ROCm 和 HIP 的高级环境变量，能够显著优化显存访问和计算单元调度。例如，HSA_FORCE_FINE_GRAIN_PCIE=1 可以强制使用细粒度 PCIe 内存访问，加速多卡或大模型分片时的数据传输；AMD_DIRECT_DISPATCH=1 能够减少 GPU 任务调度的延迟；而 GPU_MAX_HW_QUEUES=8 则有助于提升 MoE（混合专家模型）等高并发场景下的吞吐量。

# 推理性能调优环境变量组合
export HSA_FORCE_FINE_GRAIN_PCIE=1
export AMD_DIRECT_DISPATCH=1
export GPU_MAX_HW_QUEUES=8
export HSA_ENABLE_SDMA=1
export HIP_FORCE_DEV_KERNARG=1

# 启动推理服务
./build/bin/llama-server -m your_model.gguf --host 0.0.0.0 --port 8080

性能对决：Vulkan 与 HIP/ROCm 基准测试实战

在 Ollama、LM Studio 等本地 LLM 部署工具中，用户常常面临一个选择：使用 Vulkan 后端还是 HIP/ROCm 后端？Vulkan 是一种跨平台的图形和计算 API，兼容性极佳，几乎能在所有 AMD 显卡上开箱即用；而 HIP 是 AMD 专属的计算接口，能够直接调用 RDNA/CDNA 架构的底层特性，性能上限更高，但配置门槛也更高。

科学的基准测试方法论

为了客观评估两者的 Token 吞吐量（Tokens per second），不能仅凭单次运行的直觉，必须引入科学的基准测试方法。社区工具 InferBench 提供了一套自动化测试流程，其核心设计包括：

预热机制（Warm-up passes）：在正式计时前运行几次推理，让 GPU 显存分配和内核编译达到稳定状态。
中位数统计（Median of N runs）：执行多次推理并取中位数，有效过滤掉系统后台任务或显存垃圾回收带来的偶发性性能波动。
冷启动 VRAM 卸载：在每次测试周期之间彻底卸载显存，确保前一次测试的显存残留不会影响后续结果。

测试结论与场景建议

通过大量实测发现，在较新的 RDNA 3 架构（如 RX 7900 XTX）上，HIP/ROCm 后端的 Token 生成速度通常比 Vulkan 高出 15% 到 30%，尤其是在处理长上下文和大 Batch Size 时优势明显。然而，Vulkan 后端在 Prompt 处理（Prefill）阶段的表现有时更为稳定，且无需折腾复杂的驱动环境。

对于追求极致推理速度、需要部署 70B 及以上大模型（如参考 AMD 官方 MLPerf Inference v6.1 基准测试中的 Llama 2 70B 场景）的生产环境，强烈建议深度调优 HIP/ROCm 后端；而对于日常轻量级对话、快速验证模型效果，或者使用未被 ROCm 完美支持的老旧显卡，Vulkan 后端则是更省心的选择。

总结与展望

在 AMD 平台上部署本地大模型，是一场从底层硬件 BIOS 设置到上层软件环境调优的系统工程。通过修复 ROCm 环境（如使用 ROCmFix 和 BIOS 调优）、针对特定架构进行源码编译与高级环境变量配置，我们能够打破官方白名单的限制，充分释放 AMD GPU 的算力。同时，借助 InferBench 等科学测试工具，我们可以清晰地界定 Vulkan 与 HIP/ROCm 的性能边界，为不同应用场景选择最合适的后端。

展望未来，AMD ROCm 生态正在经历快速迭代。官方对消费级显卡的支持日益完善，社区涌现出的开源工具也在不断降低部署门槛。随着 HIP 生态的繁荣和类似 MLPerf 等工业级基准测试的推动，AMD 有望在 AI 推理市场打破垄断，为开发者提供更具性价比、更透明可控的本地大模型部署方案。

参考来源：

AMD ROCm Blogs: Reproducing AMD MLPerf Inference v6.1 Submission Results
Xanpavle (Lemmy/GitHub): ROCmFix & InferBench 开源工具介绍
CSDN 博客: Linux下用AMD MI50+ROCm跑Ollama大模型推理实战指南
GitHub Gist (xmesaj2): Proxmox TheRock nightly ROCm instructions for LXC passthrough (MI50/gfx906)

编程手札