最近在一张 AMD Radeon AI PRO R9700 32GB 上折腾 Qwen3.8-27B，前后试了 ROCm 下的 SGLang、vLLM，以及 llama.cpp 的 HIP / Vulkan 路线。
最后这台机器上比较稳定、速度也比较理想的方案，是：
llama.cpp + Mesa RADV Vulkan + Q4_K_M + MTP + 128K Context
先说结论：如果手里已经有 R9700，现阶段我更建议优先试 llama.cpp Vulkan。至少在我这套环境里，它比我之前折腾的 ROCm 路线省心得多。
下面的数据只代表这台机器、当前驱动和对应版本下的结果，不建议直接外推到所有 R9700 或所有模型。全程使用Gemini 3.7 flash 配置。
1. 测试环境
硬件大致如下：
- 华南金牌 X99-TF
- Xeon E5 v4 2697A
- 128GB DDR4
- AMD Radeon AI PRO R9700 32GB
- PCIe 3.0 x16
- 机器里同时还有一张 NVIDIA 4080s 32G
软件环境：
- Ubuntu 24.04
- Mesa 25.2.x / RADV Vulkan
- llama.cpp Vulkan 构建
- Qwen3.8-27B Q4_K_M
- 视觉模型使用对应的 F16 mmproj
BIOS 里开启：
- Above 4G Decoding
- Resizable BAR
2. 目前的实测结果
| 场景 | 实测 |
|---|---|
| 长文本 Prefill，约 2322 tokens | 730.89 t/s |
| 非思考模式，代码生成 | 53.10 t/s |
| 思考模式，数学证明 | 44.81 t/s |
| 视觉问答生成 | 35.80 t/s |
| 视觉问答 TTFT | 约 927 ms |
| Context | 128K |
| 运行时显存占用 | 约 20.3 GiB |
其中 53 t/s 并不是所有问题都能稳定达到。
Qwen3.8 的 MTP 对任务类型比较敏感。代码、JSON、工具调用这类下一 token 比较容易预测的任务，接受率高，速度会明显上去；开放式写作、视觉问答这类任务，接受率下降，速度也会跟着掉。
我这边两个比较典型的数据：
- 代码生成：MTP acceptance 约 68.7%，53.10 t/s
- 数学证明：MTP acceptance 约 54.9%，44.81 t/s
所以以后看别人贴 R9700 / Qwen3.8 的速度，最好先看他测的是什么题、有没有开 MTP，而不是只看一个 t/s。
3. 我现在用的关键参数
核心启动参数大概是下面这样：
export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.json
./llama-server \
--model /path/to/Qwen3.8-27B-Q4_K_M.gguf \
--mmproj /path/to/mmproj-Qwen3.8-27B-F16.gguf \
--ctx-size 131072 \
--cache-type-k q4_0 \
--cache-type-v q4_0 \
--n-gpu-layers 999 \
--no-mmap \
--spec-type draft-mtp \
--spec-draft-n-max 5 \
--cache-ram 32768 \
--flash-attn on \
--parallel 1 \
--jinja
几个我觉得比较关键的地方。
① 双显卡环境最好显式指定 Vulkan ICD
我的机器同时有 AMD 和 NVIDIA 卡。
如果直接让 Vulkan 自己探测，偶尔会碰到加载错 ICD 的问题。显式指定：
VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.json
之后省事很多。
如果是纯 AMD 单卡机器，未必需要这么做。
② 128K 下 KV Cache 用 q4_0
我现在是：
--cache-type-k q4_0
--cache-type-v q4_0
这样 128K Context 可以装下，整套运行时显存大约 20.3 GiB，还能留出十来 GB 余量。
如果 KV Cache 直接上高精度，32GB 显存会紧张很多。
③ MTP 我这里 n-max=5 比较合适
--spec-type draft-mtp
--spec-draft-n-max 5
我试过把步数继续往上加，但不是越大越快。
草稿猜错以后需要重新验证，步数过大反而可能拖慢整体 Decode。至少我这组测试里，5 是比较合适的点。
④ Prompt Cache 别留太小
长对话下，如果 --cache-ram 太小，日志里可能看到 cache skipping，后续请求又重新做 Prefill。
我最后给到：
--cache-ram 32768
这主要吃系统内存，不是显存。机器内存够的话可以适当放大。
4. ReBAR 值得检查
这是这次折腾里我觉得最值得单独说的一点。
最开始这台 X99 平台没有把 ReBAR 配好，长 Prompt 的 Prefill 大约在 450 t/s 左右。
BIOS 开启：
- Above 4G Decoding
- Resizable BAR
并确认系统里 R9700 的 BAR 映射正常后，同一套环境下长文本 Prefill 测到 730.89 t/s。
从这组结果看，提升大约 62%。
不过这里我更愿意把它理解成“这台机器上的实测现象”，而不是说所有 R9700 开 ReBAR 都一定能涨 60%。
老平台、PCIe 拓扑、驱动版本都可能影响结果。
如果 Prefill 明显偏慢，我建议先查 ReBAR，而不是一上来就怀疑模型或 llama.cpp。
5. Vulkan、SGLang、vLLM，我最后为什么留 Vulkan
我前面也折腾过 ROCm。
当时大概是这个情况：
| 路线 | 我这台机器上的情况 |
|---|---|
| SGLang / ROCm | 可以跑，但大上下文下 Decode 大约 11 t/s，空闲功耗表现也不理想 |
| vLLM / ROCm | 128K 需要继续调 KV Cache 和请求限制，当时 Decode 大约 7～8 t/s |
| llama.cpp HIP | 可以用，但我测试时稳定性和 MTP 表现不如 Vulkan |
| llama.cpp Vulkan | 当前最省事，MTP、Flash Attention、128K、mmproj 都能正常用 |
这里要特别说明：
这不是严格的同权重、同量化、同版本横向 benchmark。
SGLang / vLLM 当时使用的权重格式和运行条件并不完全一样，所以这些数字只能说明“我最后为什么选 Vulkan”，不能拿来证明 Vulkan 理论上一定比 ROCm 快多少。
后面 ROCm、vLLM、SGLang 对 RDNA4 的支持继续完善以后，结果完全可能变化。
6. 几个比较容易踩的坑
ReBAR 没开
表现：
- 长 Prompt Prefill 偏慢
- 视觉输入响应也可能不理想
先检查 BIOS 的 Above 4G Decoding 和 ReBAR。
用几十个 token 测 Prefill
短 Prompt 固定开销占比太高，数据没什么参考意义。
我现在至少用 2000 tokens 左右的输入来观察 Prefill。
MTP 步数一味往上加
n-max=8、10 不一定比 5 快。
接受率掉下来后，可能越调越慢。
128K 还坚持高精度 KV Cache
32GB 显存很容易被吃满。
如果目标就是单请求 128K，q4_0 KV Cache 是一个比较实用的取舍。
双卡机器不指定 Vulkan ICD
AMD + NVIDIA 混插时尤其值得注意。
遇到 Vulkan 启动异常，可以先确认实际加载的是不是 RADV。
7. 关于老 X99 / E5 v4 会不会拖后腿
这也是我一开始比较担心的。
从目前的监控看，Decode 阶段 GPU 利用率很高，CPU 占用并不高。至少在我这套单请求测试里，E5 v4 还没有表现成明显瓶颈。
这不代表 CPU 完全不重要。
高并发、大量预处理、复杂 Agent 工作流或者频繁 CPU
GPU 数据交换时，老平台还是可能影响整体体验。
但如果只是单用户本地 LLM 推理，我暂时没有因为 X99 去换平台的打算。
8. 目前还没测的东西
这篇主要是单实例、单请求测试。
还没有认真做：
--parallel 4之类的多并发压力测试- 128K 下长时间并发稳定性
- 接入Hermes的测试
- 不同 GGUF 量化之间的质量和速度对比
所以现在更适合把它看成一份 R9700 + llama.cpp Vulkan 的实机配置记录，不是完整 benchmark。
结论
如果是 R9700 32GB + Qwen3.8-27B，我目前会推荐：
Q4_K_M + llama.cpp Vulkan + MTP + q4_0 KV Cache
我这台机器上可以稳定跑 128K，上下文显存余量也比较充足；普通生成大约在 40～50 t/s，代码这类 MTP 接受率高的任务可以到 50 t/s 以上。
另外，如果 Prefill 明显低于预期，建议优先检查 Above 4G Decoding / ReBAR。
:::
