适用于谁，以及哪些真的能用
一张跑在 Linux 上的 Radeon 显卡，用 llama.cpp 跑 GGUF。开始前先明确两点。消费级 Radeon 的 ROCm 以 Linux 为主：llama.cpp 文档里也有 Windows 上的 HIP 构建方法，但下面的 HSA_OVERRIDE_GFX_VERSION 变通办法在 Windows 上无效，所以不在 AMD 官方支持列表里的显卡，在 Windows 上通常更适合用 Vulkan 后端。另外可选格式比 NVIDIA 窄 —— GGUF 可用，vLLM 也有官方 ROCm 构建可用于 AWQ/GPTQ 服务（限 RX 7700 XT 及以上、RX 9000 系列，不含 RX 6000 和 7600 XT），但 EXL2 是 CUDA 独占，再怎么配 ROCm 也没用。
Best reports: RX 7900 XTX / XT (gfx1100), W7900
Works: RX 7800 XT / 7700 XT (gfx1101), RX 6800 XT / 6900 XT (gfx1030)
Patchy: RX 6700 XT (gfx1031), older Polaris
Not supported: integrated Radeon graphics前置条件
按你的发行版从 AMD 仓库安装 ROCm 6.1 或更新版本（llama.cpp 的 HIP 构建会拒绝更旧的版本），然后把用户加入 render 和 video 组，并重新登录。忘记加组是最典型的第一个坑：rocminfo 报告找不到设备，而后面每一步看起来都像编译问题，其实是权限问题。现在先确认显卡的 gfx 目标，编译时要用。
sudo usermod -aG render,video $USER # then log out and back in
rocminfo | grep -i gfx # e.g. gfx1100 for RX 7900 XTX
rocm-smi # card, VRAM, temperature用 HIP 后端编译 llama.cpp
编译开关是 GGML_HIP=ON。旧的 LLAMA_HIPBLAS 名称已被移除，而且不像 LLAMA_CUDA 那样会被转发到新名字 —— 用旧名字会得到一个编译顺利、能运行、但纯 CPU 的构建。CMake 唯一的提示是配置末尾的一行，把它列在 “Manually-specified variables were not used by the project” 之下，很容易一滚而过。同时把 GPU_TARGETS 设为你的 gfx 目标，确保内核为你的卡编译（旧名 AMDGPU_TARGETS 仍会被转发；两个都不设则为机器里所有 GPU 编译）。按 llama.cpp 构建文档的做法，用 HIPCXX 指向 ROCm 自带的 clang —— 把 hipcc 当编译器仍然可用，但 CMake 现在会警告这是旧做法。
git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
HIPCXX="$(hipconfig -l)/clang" HIP_PATH="$(hipconfig -R)" \
cmake -S . -B build \
-DGGML_HIP=ON \
-DGPU_TARGETS=gfx1100 \
-DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j$(nproc)如果你的卡不在官方支持列表里
ROCm 对于官方未支持的 gfx 目标会直接拒绝初始化，哪怕架构上和某个受支持型号很接近。HSA_OVERRIDE_GFX_VERSION 让运行时把它当作最接近的受支持目标：RDNA3 用 11.0.0，RDNA2 用 10.3.0。这是绕过手段而非受支持配置 —— 用的人很多，但在部分内核上也可能出现结果错误或卡死，采信前请先验证输出。
# RDNA2 card reporting gfx1031, treated as gfx1030
export HSA_OVERRIDE_GFX_VERSION=10.3.0
# RDNA3
# export HSA_OVERRIDE_GFX_VERSION=11.0.0启动服务并确认 GPU 已被使用
除非你确实想把服务开放到局域网，否则绑定 127.0.0.1 —— llama-server 自身没有任何鉴权。启动时日志会打印使用的后端和卸载到 GPU 的层数；确认的依据是这一行，而不是“它能回答”。退回 CPU 的 HIP 构建照样能出 token，只是很慢。模型加载期间 rocm-smi 应能看到显存被占用。
./build/bin/llama-server \
-m ./models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
-ngl 99 -c 8192 --host 127.0.0.1 --port 8080
# In the startup log, look for the ROCm device line and:
# load_tensors: offloaded 33/33 layers to GPU
rocm-smi --showmemuse为你的显卡挑模型
24GB 的 RX 7900 XTX 在“能装下什么”这件事上与 RTX 3090／4090 属于同一档：显存算术不关心是哪家的卡，只关心显存多大、KV 缓存多大。直接在显存计算器里选你的 Radeon（列表里有）来算，而不是照搬 NVIDIA 的建议。不能照搬的是吞吐：本站的 tok/s 数据在 NVIDIA 硬件上实测，不能用来预测 ROCm 上的表现。
常见问题
rocminfo 找不到设备：要么是用户组没加，要么是内核模块没加载 —— 用 dmesg 查 amdgpu。加载时报 hipErrorNoBinaryForGpu：编译时没有包含你的 gfx 目标；用正确的 GPU_TARGETS 重新编译，或设置 HSA_OVERRIDE_GFX_VERSION。能编译但跑在 CPU 上：几乎都是用了旧的 LLAMA_HIPBLAS 开关，CMake 只把它列为未使用变量、其余一概忽略 —— 看启动日志里的后端那一行。设置 override 后卡死或输出乱码：override 本就不是受支持路径；先降低上下文或换一个量化档位，再去怀疑模型本身。
下一步
下方链接的模型就是本指南所围绕的那几个。在计算器里选好你的 Radeon 再打开其中任意一个，就能看到它实际能撑住多长的上下文。
常见问题
Radeon 上跑 llama.cpp，该用 ROCm 还是 Vulkan？
在 Linux 上、且显卡在 AMD 官方支持列表里时，ROCm（也就是本指南的 HIP 构建）是文档给出的路径。Vulkan 是完全不需要安装 ROCm 的后备方案：编译时用 -DGGML_VULKAN=ON 代替 GGML_HIP。在 Windows 上、显卡又不在 AMD 列表里时，它是更好的选择，因为 llama.cpp 的构建文档写明 HSA_OVERRIDE_GFX_VERSION 在 Windows 上不受支持。如果你只是想在 Windows 上跑模型、不想自己编译 llama.cpp，Ollama 的 Windows 版会自己处理 Radeon 显卡：RX 7600 到 7900 系列走 ROCm，其他型号走 Vulkan。本站没有在 Radeon 上实测过任何一个后端，所以不下“谁更快”的结论 —— 用同一个模型和上下文在你的卡上两个都跑一遍再比较。
Radeon 能跑 AWQ、GPTQ 或 EXL2 模型吗？
AWQ 和 GPTQ 可以，但只能通过 vLLM 的 ROCm 构建，而且只限 vLLM 列出的显卡：RX 7700 XT、7800 XT、7900 系列，以及 RX 9000 系列。RX 6000 系列和 RX 7600 XT 不在列表里，这些卡请走 llama.cpp + GGUF。EXL2 需要 CUDA，任何 Radeon 都跑不了，况且它的运行时 ExLlamaV2 已经归档。本站的显卡页面和显存计算器用的是同一条规则，只会推荐你的卡能加载的格式。
24GB 的 RX 7900 XTX 和 16GB 的 Radeon 能装下的模型差多少？
在 4K 上下文下，本索引 90 个模型中有 72 个能宽裕地放进 RX 7900 XTX，而 16GB 的 RX 7800 XT 或 RX 9070 XT 是 56 个。差距在 30B 这一档。Qwen3 30B-A3B 的 Q4_K_M 在 8K 上下文下约 20.2 GB —— 占 7900 XTX 的 84%，属于宽裕 —— 而 16GB 卡放不下。GPT-OSS 20B 的 MXFP4 在 8K 上下文下约 12.9 GB，两种卡都能跑。以上只是显存数字；本站没有 Radeon 上的速度实测。
这篇指南用到了什么
- 格式
- GGUF
- 对应推荐
- 24GB 能跑的最好的本地大模型
接下来
看看 🔴 Radeon RX 7900 XTX 还能跑哪些模型反向查询 —— 24GB、8192 上下文，按质量排序本文涉及的模型
它真的跑起来了吗？
复制命令并不等于它能用，所以站内只在这里问一次。除了你的这个回答之外，不收集任何东西。