折腾实录】7900 XTX (RDNA3) 终极压榨：RoxxY 魔改分支 vs 原生 llama.cpp 交叉评测与 DFlash 调优避坑

abaalei

【折腾实录】7900 XTX (RDNA3) 终极压榨：RoxxY 魔改分支 vs 原生 llama.cpp 交叉评测与 DFlash 调优避坑

️ 硬件平台

显卡: XFX Radeon RX 7900 XTX 24GB (ROCm 7.2.0 / gfx1100)
CPU: Intel Xeon E5-2682 v4 × 2 (双路 32核64线程)
内存: 64GB DDR4 REG ECC (四通道插满)
系统: Ubuntu 24.04 LTS (Kernel 6.8.0)

起因：魔改分支 RoxxY 真的能起飞吗？

最近在Reddit看到有开发者发布了针对 RDNA3（gfx1100，如 7900 XTX）优化 KV 缓存与 prefill 的魔改 llama.cpp 分支 —— RoxxY (tbq4-rdna3-experiment)。
为了验证其真实含金量，我们在独立的沙盒中编译了 RoxxY，并与最新的原生 llama.cpp 进行了严格的交叉对比。所有测试均基于 Qwen3.6-27B 不同量化版模型，并且全部挂载 numactl --cpunodebind=0 --membind=0 锁定直连显卡的 NUMA Node 0 物理节点。

纯自回归（AR）性能交叉比对表

(测试参数: -p 512,2048 -n 128 -fa 1 -r 1)

测试模型	评测后端	pp512 Prefill (t/s)	pp2048 Prefill (t/s)	tg128 Decode (tok/s)
Model A (Q4_K_M)<br>Huihui 去审查版	原生 llama.cpp	910.18	977.84	30.72
	RoxxY packed16	907.72	964.58	31.97 (+4.06% )
Model B (IQ4_XS)<br>128K 长文本版	原生 llama.cpp	382.35	391.83	39.79
	RoxxY packed16	377.45	389.15	38.86 (-2.33%)
Model C (MTP 65层)<br>自我投机版	原生 llama.cpp	863.21	952.25	30.46
	RoxxY packed16	868.57	929.67	31.22 (+2.49%)

核心结论 1：RoxxY 的 Prefill 优化“解密”

RoxxY 分支宣称的“针对 RDNA3 进行专门的 packed16 与 WMMA 算子重构，能极大地加速 Prefill”在我们的实测中并没有显现出超越最新原生 llama.cpp 的优势。在三大模型下，原生的 Prefill 速度与 RoxxY 几乎在同一个档次，原生甚至还微弱胜出 1% 左右。
不过，在 Decode 阶段，RoxxY 的 packed16 格式在部分模型上确实能依靠底层 rocm_packed16_dot4_mmq 算子带来 2% ~ 4% 的微弱性能拉升。

核心结论 2：先前原生 Mode B 被严重低估了

之前测试原生的 IQ4_XS（Mode B）Prefill 只有 251 t/s，本次测试证实，只要锁死 NUMA 物理核心（避免跨 CPU 通信）并强制开启 Flash Attention，原生的 pp512 速度当场就能飞到 382.35 t/s！并非原生不行，而是之前运行脚本未锁 NUMA 导致总线带宽成了瓶颈。

️ DFlash 投机解码：双 4-bit KV 缓存的“稳定性陷阱”

很多小伙伴在使用 DFlash (Lucebox 架构) 榨取 7900 XTX 性能时，喜欢追求极限，开启 --cache-type-k q4_0 --cache-type-v q4_0（双 4-bit KV 压缩）。我们在 10 道 HumanEval 的 bench_he.py 测试中发现了致命的稳定性问题：

DFlash KV 缓存配置	Decode 速度 (tok/s)	显存节省率	稳定性表现
f16 K + f16 V (默认)	100.83	基准	稳定
q8_0 K + q4_0 V (推荐调音)	95.74	节省 60%+	完美稳定
q4_0 K + q4_0 V (激进双4-bit)	101.17	节省 75%+	崩溃 (ROCm Abort -6)

崩溃根因：激进的 q4_0 K（Key 缓存压缩至 4-bit）由于极致减少了显存读取带宽，在单次简单输出中确实能跑出 101.17 tok/s 的超快速度。但是在长文本或复杂的验证回滚树计算中，会稳定触发 ROCm 驱动底层 hipStreamSynchronize 的同步内存对齐异常，导致推理服务直接 Abort 闪退（exit code -6）。
避坑推荐：q8_0 K + q4_0 V 是目前最完美的黄金甜点组合！10 道测试题全部稳稳通过，解码速度高达 95.74 tok/s，既省显存又避开闪退。

️ 最佳实践启动脚本分享

1. 模式 A (DFlash 极速黄金调音版)

#!/bin/bash
export LD_LIBRARY_PATH=/opt/rocm-7.2.0/lib:$LD_LIBRARY_PATH
export HSA_OVERRIDE_GFX_VERSION=11.0.0
cd /home/peter/lucebox-hub/dflash

# 锁死 NUMA 0，使用 q8_0 K + q4_0 V 黄金稳定版
nohup numactl --cpunodebind=0 --membind=0 python3 scripts/server.py \
  --target '/mnt/models/Qwen3.6/Huihui-Qwen3.6-27B-abliterated.Q4_K_M.gguf' \
  --draft models/dflash-draft-3.6-q8_0.gguf \
  --budget 8 --max-ctx 32768 --fa-window 0 \
  --cache-type-k q8_0 --cache-type-v q4_0 \
  --tokenizer Qwen/Qwen3.6-27B \
  --host 0.0.0.0 --port 11435 \
  > /home/peter/llama-server-dflash.log 2>&1 &

2. 模式 B (原生 llama.cpp 长文本 128K 极速 Prefill 版)

#!/bin/bash
pkill -f "llama-server" 2>/dev/null
sleep 1
export LD_LIBRARY_PATH=/home/peter/llama.cpp/build-rocm/bin:/opt/rocm-7.2.0/lib:$LD_LIBRARY_PATH
export HIP_VISIBLE_DEVICES=0
export HSA_OVERRIDE_GFX_VERSION=11.0.0

# 挂载 NUMA 0 绑定，强制 -fa 1 开启 Flash Attention，加入 --no-mmap 提升载入速度
setsid numactl --cpunodebind=0 --membind=0 /home/peter/llama.cpp/build-rocm/bin/llama-server \
  -m /mnt/models/Qwen3.6/Qwen3.6-27B-Uncensored-HauhauCS-Balanced-IQ4_XS.gguf \
  -c 131072 -ngl 99 \
  -fa 1 \
  --no-mmap \
  --tensor-split 0 \
  --cont-batching \
  --cache-type-k q4_0 --cache-type-v q4_0 \
  --host 0.0.0.0 --port 11435 \
  > /home/peter/llama-server-iq4xs.log 2>&1 &

ye9ok

rdna3到底支不支持Flash Attention？俺咋记得打不开

566656661

@ye9ok

FA官方是寫有支持的, 不過那是基於ROCm跟HIP

Reddit上面倒是沒寫Vulkan有支持FA, 先當作沒有？

Xiaote

@ye9ok @566656661 FA支持情况补充一下：

RDNA3 (7900 XTX, gfx1100) 的 FA 支持取决于你用什么后端：

ROCm/HIP 路线（RoxxY魔改分支就是走这条路）：

ROCm 6.x 通过 hipFlashAttn 官方支持 FA2（flash_attn >= 2.0 在 ROCm 上已经可用）
但注意：hipFlashAttn 目前只支持 FA2，不支持 FA3（那是 Hopper 架构专属）
在 RoxxY / llama.cpp ROCm 后端下，只要编译时启用了 -DLLAMA_HIPBLAS=ON，FA 是正常生效的
不过 RDNA3 的 FA 效率不如 NVIDIA：实测 7900 XTX 开 FA 大约能省 15-20% 显存，速度提升约 10-15%

Vulkan 路线：

FA 目前确实不支持 Vulkan 后端
所以如果用原生 llama.cpp 的 Vulkan 后端（-ngl N -ngv vulkan），是打不开 FA 的
这也是 RoxxY 魔改分支（基于 ROCm）比原生 Vulkan 版本在某些场景下更快的原因之一——不仅仅是驱动优化，FA 带来的 attention 计算加速也是一个因素

简单总结：RDNA3 开 FA 可行，但仅限于 ROCm/HIP 后端。如果走 Vulkan 路线，确实没有 FA。

terry

补充下截图，很有意义

abaalei

好的版主，虽然全场都是agent操作，我啥都看不明白，就随便贴点agent的思考过程吧

abaalei

多图杀猫~~
哈哈好久没说过这句话了

terry

@abaalei 挺好的，穿插截图的意义是，版主和其它读者会很快确定你的文稿的真实性，因为太长了，大家不想看很久之后发现是AI写的。

abaalei

@terry 明白的，我的数据都是实测的，只是测试过程跟文章都是ai写的而已

抡锤者