Misc. bug: VRAM does not allocate with ROCm 7.14 on gfx1201

快速结论：在 gfx1201（Radeon AI Pro 9700 XT / R9700）多卡机器上，用 ROCm 后端跑 llama.cpp 时模型权重全部落在系统内存，VRAM 几乎不占用，导致推理极慢；但 Vulkan 后端分配正常。优先排查 ROCm 运行环境（安装方式、容器 vs 本地、/opt/rocm 是否残留）以及后端是否真的启用了 GPU 显存分配。

适用环境：Linux（Debian Testing / Debian 13+backports，内核 7.1.x）；llama.cpp 构建版本 86 (b77d646) 与官方 ROCm 构建 10361/10481；ROCm 7.14.0（通过 uv 安装）、ROCm 7.12、7.11、10.1.0 tarball，及容器内 ROCm 7.2.1；GPU 为 8x RADEON AI Pro 9700 XT（gfx1201）；Vulkan 使用系统包。

最快修复方案：暂无确认的一步修复方案。Issue 中报告者已验证：使用官方 ROCm 容器（容器内 ROCm 7.2.1）时表现正常，而本地 uv/ROCm tarball 安装在 7.14、10.1.0、7.12、7.11 上均复现。可优先尝试改用官方 ROCm 容器或官方 llama.cpp ROCm 构建产物来对照定位。

注意事项：报告者回滚 ROCm 到 7.12/7.11 后问题依旧，说明不一定只由 ROCm 版本引起；另一名 R9700 双卡用户在 Proxmox 虚拟化 + P2P 环境下、用最新 commit 构建的容器可以正常占用 VRAM，说明该问题可能与特定系统环境/显卡拓扑有关，尚未确认根因。

问题场景

用户在 Linux + ROCm 环境下运行 llama-bench、llama-cli 或 llama-server，加载 Qwen3.x-27B GGUF 模型并尝试用 -ngl 999 / -ngl all 将层全部放到 8 张 gfx1201 显卡上。用 nvtop 观察发现：ROCm 后端只在 CPU 侧分配内存，GPU 显存完全不被占用，推理速度非常慢；但执行确实发生在 GPU 上。切换到 Vulkan 后端时，VRAM 按预期被分配，性能也正常。首批复现命令为：llama-bench -m Qwen3.6-27B-UD-Q8_K_XL.gguf -ctk bf16 -ctv bf16 -ngl 999 -lm none -fa on -sm layer -dev $(set ROCm{0..7}; IFS=/; echo "$*")。

报错原文

Misc. bug: VRAM does not allocate with ROCm 7.14 on gfx1201

llama-cli --version
version: 86 (b77d646)
built with Clang 23.0.0 for Linux x86_64

# 现象：ROCm 后端只分配 CPU 内存，VRAM 无占用
# nvtop 观察到：RAM all on CPU, none on GPUs
# Vulkan backend allocates VRAM as expected
# 构建选项尝试过（无差异）：
GGML_HIP_GRAPHS=on
GGML_HIP_MMQ_MFMA=on
GGML_HIP_VMM=off
GGML_HIP_RCCL=off
GGML_HIP_ROCWMMA_FATTN=on

# 官方 ROCm 构建产物同样复现：
version: 10361 14e78ddef

# 容器内设备可正常列出（但报告中本地仍异常）：
Available devices:
  ROCm0: AMD Radeon Graphics (32624 MiB, 32386 MiB free)
  ...
  ROCm7: AMD Radeon Graphics (32624 MiB, 32352 MiB free)

原因分析

目前 Issue 未给出确认的根因，且标签为 bug-unconfirmed。可能原因包括：

本地 ROCm 安装（uv 安装的 7.14，以及 7.11/7.12/10.1.0 tarball）与 gfx1201 的显存分配路径不兼容，导致 llama.cpp 的 HIP 后端没有真正落到 VRAM，而是走系统内存；
与 ROCm 运行环境有关，而非内核版本：报告者已测试不同内核（Debian stable backport 7.0、Debian Testing 7.1.3）且容器内 ROCm 7.2.1 表现正常，说明问题更可能出现在本地 ROCm SDK/驱动配置层；
残留或冲突的 /opt/rocm、旧构建目录可能影响链接结果（报告者已清理后仍复现，但这类残留仍是排查方向）；
多卡拓扑（6@16x、2@8x PCIe4）与 P2P/VMM 配置可能参与其中；另一名 Proxmox 虚拟化 + P2P 用户未复现，说明环境差异可能是关键变量。

涉及 GGML_HIP_VMM、GGML_HIP_GRAPHS、GGML_HIP_MMQ_MFMA 等构建选项的排列组合在本 Issue 中均报告“无明显差异”，不能据此断定是某个单一选项导致。

环境排查

确认 ROCm 安装方式：是 uv 安装、tarball 安装，还是使用官方 ROCm 容器（容器内已知为 7.2.1）。
确认 ROCm 版本：本地是否 7.14 / 7.12 / 7.11 / 10.1.0，容器内是否为 7.2.1。
确认 llama.cpp 版本与构建方式：如 version: 86 (b77d646)、官方 ROCm 构建 10361 14e78ddef、容器内 10481 25ae3a9b3 等。
确认操作系统与内核：如 Debian Testing、Debian 13 + backports、内核 7.1.x。
确认 GPU：8x RADEON AI Pro 9700 XT（gfx1201），以及 PCIe 拓扑（6@16x、2@8x PCIe4）。
确认是否清理了旧构建目录和 /opt/rocm 残留。
确认 CPU 内存容量（如 256GB ECC DDR4）和 nvtop 观察到的显存占用情况。
对比 Vulkan 后端是否正常分配 VRAM，用作 ROCm 是否走错路径的对照。

解决步骤

先用 Vulkan 后端做对照，确认模型、量化格式和 -ngl 参数本身没有问题（Issue 中 Vulkan 可正常占用 VRAM）。
用 nvtop 分别观察 RAM 和每张 GPU 的 VRAM 占用，记录 ROCm 与 Vulkan 的差异。
可优先尝试：改用官方 ROCm 容器运行 llama.cpp，容器内 ROCm 为 7.2.1，报告者在该环境下表现正常。
若坚持本地安装，彻底清理旧构建目录和 /opt/rocm 后重新安装 ROCm，再重新构建 llama.cpp，避免残留库被链接。
在本地 ROCm 与官方容器之间做 A/B 对照：同一模型、同一命令、同一 -ngl/-dev 参数，观察 VRAM 是否被分配。
如果本地 ROCm 多版本（7.14 / 10.1.0 / 7.12 / 7.11）都复现，记录各版本现象并附日志，向 Issue 反馈，以帮助确认是否与 gfx1201 的驱动或运行时有关。
若在虚拟化（如 Proxmox）或 P2P 环境中，可参考另一位 R9700 双卡用户的经验：使用最新 commit 构建的容器可正常工作，验证是否与虚拟化/P2P 拓扑有关。

验证方法

运行 llama-cli 或 llama-bench 加载同一 GGUF 模型，保持 -ngl 等参数不变，用 nvtop 或 rocm-smi 观察显存占用：若 VRAM 被正常分配、CPU 内存不再独占模型权重，且生成速度明显提升，则说明问题已缓解。也可先运行 llama-server --list-devices 确认 ROCm0–ROCm7 均能被识别，再运行推理验证显存分配行为。