最后这台机器上比较稳定、速度也比较理想的方案，是：

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. 目前的实测结果

其中 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。

当时大概是这个情况：

这里要特别说明：

这不是严格的同权重、同量化、同版本横向 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 工作流或者频繁 CPUGPU 数据交换时，老平台还是可能影响整体体验。

但如果只是单用户本地 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。

:::