R9700 32GB 跑 Qwen3.8-27B：llama.cpp Vulkan + MTP 实测与踩坑记录
-
最近在一张 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。
:::
-
最近在一张 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。
:::
@PhoenixRise2026 谢谢分享， 请问电脑内存的大小和速度影响大么？
-
如果模型能基本完整放进显存，内存速度影响通常不大，Decode 阶段主要还是看显卡和显存带宽。
内存容量更重要一些，主要影响模型加载、系统文件缓存、Prompt Cache，以及显存不够时的 CPU offload。内存太小会导致加载困难、频繁换页，甚至直接 OOM。
如果模型需要大量 CPU/GPU 混合推理，那内存带宽就会明显重要起来，情况会不一样。
-
，
T terry 固定了此主题
-
@exllm 谢谢提醒，补一个q8_0的测试结果
-
@phoenixrise2026
我也是 R9700，但是CPU是AMD Ryzen 9700X，Mesa RADV Vulkan升级到26.1.7后，llama-bench测试Qwen3.8-27B-UD-Q4_K_XL，prefill比25.2.X版本有明显提升，decode比ROCm快。prompt size Vulkan 旧驱动 25.2.8 Vulkan 新驱动 26.1.7 ROCm pp512 881.8 1014.2 (+15.0%) 1206.5 pp2048 870.1 1004.4(+15.4%) 1182.2 pp8192 825.7 953.2 (+15.4%) 1124.1 tg128 28.16 28.41 (+0.9%) 26.43 另外好奇的是，你的4080s 32GB是魔改卡吗？为什么不是涡轮散热器？
