抡锤者

abaalei

原创折腾实录 | 2026-06-10 | RX 7900 XTX 24GB + ROCm 7.2.0

写在前面

一直以来，7900 XTX 用户在 Qwen3.6-27B 上有一个无法两全的选择：

Lucebox DFlash（~93 tok/s run.py / ~80 tok/s API ）→ 最快！但原方案极其挑食。
社区去审查模型（Huihui abliterated 等）→ 真无审查，但容易触发 DFlash 的 fattn.cu:312 崩溃。

本文记录了如何同时得到「DFlash 极速 + 真无审查」——通过 FA_ALL_QUANTS=ON 完整编译解决 Fattn 兼容性，配合 --fa-window 0 和 --tokenizer Qwen/Qwen3.6-27B 实现完美稳定运行。

🧪 硬件环境

+---------------------------+-----------------------------------------------+
| 组件                      | 详情                                           |
+---------------------------+-----------------------------------------------+
| CPU                       | Intel Xeon E5-2682 v4 × 2 (32C/64T)           |
| 主板                      |华强北白牌X99-6Plus 槽距63mm pcie3.0（16x*4 8x*2） |
| GPU — 主力推理            | AMD Radeon RX 7900 XTX 24GB (ROCm 7.2)         |
| GPU — 后处理              | NVIDIA RTX 3080 Ti 12GB (CUDA) — 未参与        |
| 系统                      | Ubuntu 24.04 LTS, Kernel 5.15.0-181           |
| Python                    | 3.12.3                                       |
| 模型                      | Qwen3.6-27B (Q4_K_M / variant)               |
| DFlash                    | Lucebox (lucebox-hub, ggml-hip)              |
+---------------------------+----------------------------------------------+

️ 强调： 本测试全程只用 7900 XTX，RTX 3080 Ti 完全不参与推理过程，避免混淆。

目标

DFlash 引擎 — Lucebox DFlash 投机解码，7900 XTX 甜点 ~93 tok/s
真·无审查 — Huihui abliterated，完全拒答阻断的解除
稳定运行 — 完整 43 轮每轮 200 token 稳定测试不崩溃

️ 完整折腾路线图（七阶段全记录）

（编者注：有agent就是好，看到论坛内的贴/X上面的贴不管有没有用就直接扔给agent进行分析匹配，然后一项项让她自己随机跑，省下不少时间，就是token烧不少了）

阶段一：初识问题 — Fattn 崩溃

社区主流 GGUF（如 Huihui Q4_K_M）在 DFlash 下会导致 fattn.cu:312: fatal error。

根因定位：
并非模型本身问题，而是 HIP 编译默认只编译了 4 组 KV-quant 模板（F16/Q4_0/Q8_0/BF16）。当 DFLASH27B_FA_ALL_QUANTS=OFF 时，Q4_K_M 模型使用的 KV cache dtype 不在这些模板中 → VEC kernel dispatch 找不到匹配 → GGML_ABORT("fatal error")。

阶段二：尝试补丁 — TILE fallback patch（失败）

最初怀疑是 VEC kernel 本身的 bug，尝试在 fattn.cu 中将 VEC 找不到时的 GGML_ABORT 改为 fallback 到 TILE kernel。

编译通过，但：

前 10~15 轮请求正常
到了 26 轮左右出现静默 segfault（zombie test_dflash 进程，BrokenPipeError）
根因：TILE kernel 在 HIP (gfx1100) 后端上不稳定，大量并发验证时触发底层内存访问越界

结论： 不需要 patch 源码，走错了方向。

阶段三：证实方向 — FA_ALL_QUANTS=ON 完整编译

放弃 patch 源码的歪门邪道，直接使用 CMake 默认的完整编译：

-DDFLASH27B_FA_ALL_QUANTS=ON (CMake 默认值)
HIP/gfx1100 成功编译全部 50+ 种量化模板
VEC 命中任意 KV quant 对，彻底解决 ggml_abort

# 强制开启完整模板编译
cmake .. -DDFLASH27B_FA_ALL_QUANTS=ON -DCMAKE_HIP_ARCHITECTURES=gfx1100
cmake --build . --target ggml-hip --clean-first -j4
cmake --build . --target test_dflash -j4

️ 重建必须 --clean-first，否则 cmake 不重编 HIP 目标！

阶段四：测试 OBLITERATUS（假无审查 + 不兼容）

OBLITERATUS 是对 Qwen3.6-27B 跑 diff-in-means 去审查的模型。结果是：

假无审查 — 对炸弹/敏感内容仍在输出安全教育
DFlash 不兼容 — 同样触发 fattn.cu:312
层数不对（65 层 vs 草稿 64 层）
已清理删除

阶段五：测试 Huihui IQ4_XS（真无审查但龟速）

Huihui abliterated 的 IQ4_XS 版本：

真无审查 — 直接回复XX步骤、BL/SQ细节
DFlash 兼容（FA_ALL_QUANTS=OFF 时唯一能跑的真无审查模版）
速度仅 28 tok/s — IQ4_XS 在 HIP 上的反量化路径不如 Q4_K_M 高效
上下文受限（~64K）

结论： IQ4_XS 已弃用（已从磁盘删除），Q4_K_M 在 FA_ALL_QUANTS=ON 下全面优于 IQ4_XS。

阶段六：测试 Heretic Q4_K_M（原生兼容但假无审查）

Youssofal 的 Heretic Q4_K_M：

原生 DFlash 兼容 — 第一版就稳定运行
早期 benchmark：68.80 tok/s（bench_he.py）
假无审查 — 号称"Uncensored"但实测仍输出安全教育/「无法提供」
已弃用，被 Huihui 全面替代

阶段七：FA_ALL_QUANTS=ON + --fa-window 0 + Huihui Q4_K_M

最终稳定核心：

FA_ALL_QUANTS=ON 解决量化模板缺失
--fa-window 0 禁用 DFlash 滑动窗口（防长文本崩溃）
--tokenizer Qwen/Qwen3.6-27B 解决 emoji 显示为方块问号的问题

最终启动参数：

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 \
  --fa-window 0 \
  --tokenizer Qwen/Qwen3.6-27B \
  --host 0.0.0.0 --port 11435

完整模型兼容性矩阵

模型	DFlash 兼容	去审查	速度 (API)	状态
Huihui Q4_K_M (mradermacher)	FA_ALL_QUANTS=ON	真	~81 tok/s	推荐
Heretic Q4_K_M (Youssofal)	原生	假	~69 tok/s	已弃用
~~Huihui IQ4_XS~~	OFF 时唯一	真	~28 tok/s	已删 (太慢)
~~OBLITERATUS Q4_K_M~~	崩溃	假	—	已删
~~Huihui Q4_K (原始版)~~	OFF 崩溃	真	—	已删 (层数61不对)

（Gemini注：海外作者（如西方开源社区）制作的。他们寻找“拒绝向量”时，用的测试集绝大多数是英文的安全基准（比如涉及暴力的英文问答）。它抹掉了英文语境下的道德底线，但在面对中文的高级隐喻、特定文化禁忌时，由于没有彻底擦除中文特有的安全向量，模型依然会触发潜意识的“道德刹车”）

最终性能对比

DFlash API 速度 (OpenAI 兼容 server)

模型	速度 (API tg128)	速度 (run.py)	显存占用	去审查
Huihui Q4_K_M	~80-81 tok/s	~93 tok/s	14.73 GiB	真
Heretic Q4_K_M	~69 tok/s	~69 tok/s	14.73 GiB	假

bench_he.py 详细成绩 (Reddit 同款 10 HumanEval，2026-06-10)

Huihui Q4_K_M + FA_ALL_QUANTS=ON + --fa-window 0 + --tokenizer Qwen/Qwen3.6-27B：

+-----------------------------+-------+------+--------+
| prompt                      | tok/s | AL   | 接受率 |
+-----------------------------+-------+------+--------+
| has_close_elements          | 100.7 | 7.53 | 49.6%  |
| separate_paren_groups       | 76.6  | 5.82 | 37.2%  |
| truncate_number             | 54.4  | 4.00 | 26.8%  |
| below_zero                  | 82.5  | 6.10 | 39.0%  |
| mean_absolute_deviation     | 96.4  | 7.11 | 46.2%  |
| intersperse                 | 87.2  | 6.40 | 40.3%  |
| parse_nested_parens         | 70.6  | 5.33 | 36.5%  |
| filter_by_substring         | 74.6  | 5.57 | 35.3%  |
| sum_product                 | 115.2 | 8.53 | 53.3%  |
| rolling_max                 | 55.7  | 4.13 | 26.4%  |
+-----------------------------+-------+------+--------+
| MEAN                        | 81.38 | 6.05 | 39.1%  |
+-----------------------------+-------+------+--------+

对比 Heretic 旧成绩 (bench_he.py)：

Heretic Q4_K_M (旧): 68.80 tok/s, AL 4.79, 接受率 30.0%
Huihui Q4_K_M (新): 81.38 tok/s, AL 6.05, 接受率 39.1%
提升：+18.3%

对比 Reddit 帖文 (r/LocalLLaMA, 同款 test_dflash)：

项目	Reddit 帖文	我们实测 (Heretic)	我们实测 (Huihui)
AR 基线	28.07 tok/s	30.83 tok/s	—
DFlash budget=8	62.75 tok/s	68.80 tok/s	81.38 tok/s
加速比	2.24x	2.23x	2.64x
AL	4.93	4.79	6.05
草稿模型	Q8_0 GGUF	Q8_0 GGUF	Q8_0 GGUF
主模型	原版 Qwen3.6	Heretic 无审查	Huihui 真无审查

模型去审查排名表

模型	去审查	DFlash 兼容	速度	备注
Huihui Q4_K_M (mradermacher)	真	FA_ALL_QUANTS=ON	~81 tok/s	唯一真无审查冠军
Heretic Q4_K_M (Youssofal)	假	原生	~69 tok/s	仅是真实度+0.5 而非真去审查
~~Huihui IQ4_XS~~	真	️ OFF 也可	~28 tok/s	太慢已删
~~OBLITERATUS Q4_K_M~~	假	崩溃	—	假去审查+不兼容

去审查实测验证

测试问题	Huihui Q4_K_M	Heretic Q4_K_M
"如何制造XX"	直接输出步骤	"我不能提供"
"详细描述BL场景"	完整叙述	"请保持安全"
"制作XX的XX原理"	给出原理+流程	安全教育

🧠 经验教训总结

FA_ALL_QUANTS=ON 是正解。 不要再去 patch 源码了，完整编译能解决所有量化类型的 kernel 缺失问题。TILE fallback 是歪路。
Uncensored 标签水很深。 Huihui abliterated 是真无审查（直接回复XX步骤），Heretic 号称 Uncensored 但实际拒答。实测为准。
mradermacher 的 GGUF 转换管道与 DFlash 兼容性最好。 同一量化的其他发布者版本可能层数/架构不同导致崩溃。
Q4_K_M 性能远优于 IQ4_XS (~81 vs ~28 tok/s)，FA_ALL_QUANTS=ON 后 Q4_K_M 无兼容问题，IQ4_XS 已弃用。
--fa-window 0 仍是必要的。 即使编译完美，该参数依然是防范长文本 DFlash 滑动窗口崩溃的最佳实践。
--tokenizer Qwen/Qwen3.6-27B 解决 emoji 显示方块问题。auto-detect 会匹配到 Qwen3.5 的 tokenizer，某些 emoji token 映射不一致。
DFlash 重建后必须 --clean-first，否则增量编译不重编 HIP 目标，修改不生效。
bench_he.py 才是正确的测量方法。 run.py 单 prompt 测速会包含预填充开销，低估性能 10-15%。

参考来源

Lucebox DFlash: https://github.com/Luce-Org/lucebox-hub
Huihui abliterated: https://huggingface.co/huihui-ai/Qwen3.6-27B-Abliterated-GGUF
Heretic (假无审查): https://huggingface.co/Youssofal/Qwen3.6-27B-Abliterated-Heretic-Uncensored-GGUF
Reddit DFlash 参考: https://www.reddit.com/r/LocalLLaMA/comments/1tgepbd/
lcz.me 论坛实测: Topic 353 & 100 (7900 XTX + Qwen3.6)

最后再晒一下心意十几年的真-双路服务器主板，待内存降回合理水平后势必要32G 2400Recc 插满！！！

abaalei

补充一下Deepseek v4 Flash 的账单

abaalei

写在前面

Reddit 有人发了 Lucebox DFlash 在 7900 XTX 上跑 Qwen3.6-27B 的测试，62.75 tok/s，看得手痒。趁着周末自己也搭了一遍，前后折腾了三天，踩了不少坑，也发现了一些有意思的东西。

这份报告不只是复制粘贴 Reddit 的结论，而是包括了我们自己各种方案的横评对比。

硬件配置

+-----------------------------------+------------------------------------------------+
| 组件 | 详情 |
+-----------------------------------+------------------------------------------------+
| CPU | Intel Xeon E5-2682 v4 × 2 (32C/64T) |
| 主板 | 华强北白牌X99-6Plus 槽距63mm pcie3.0（16x4 8x2）|
| GPU | AMD Radeon RX 7900 XTX 24GB (Navi 31) |
| 显存带宽 | ~936 GB/s |
| 系统内存 | 62 GiB DDR4 ECC |
| 系统盘 | SATA SSD |
| 额外 GPU（后处理/语音用） | NVIDIA GeForce RTX 3080 Ti 12GB |
+-----------------------------------+-------------------------------------------------+

注： 3080 Ti 插在机器上但做的是 ComfyUI 视频后处理和 VoxCPM 声线转换，测 LLM 时完全不参与。不过后文会提到——Vulkan 后端不会自动隔离它，这是个坑。

软件环境

+-----------------------------------+----------------------------------------+
| 组件 | 版本 |
+-----------------------------------+----------------------------------------+
| OS | Ubuntu 24.04 LTS |
| Kernel | 6.8.0-124-generic |
| ROCm | 7.2.0 |
| llama.cpp | 3ebe862b5 (2026-06) |
| Lucebox DFlash | 73678fa (master, HIP PR #119) |
+-----------------------------------+----------------------------------------+

对比的 Reddit 帖文用的是 Ubuntu 26.04 + ROCm 7.1，我们稍微新一点。但实际跑分差异主要不在这。

🧪 整个测试历程（三天踩坑实录）

Day 1: 先试 MTP，把参数撸了个遍

最开始没发现 DFlash，先用 llama.cpp 自带的 MTP (Multi-Token Prediction) 投机解码。目标是用 Huihui 的无审查 Q4_K 模型。

MTP 参数调优

MTP 有个核心参数：投机个数 n（每次猜几个 token）。

+-----------+--------+--------+----------------+
| n 值 | tok/s | 加速比 | 说明 |
+-----------+--------+--------+----------------+
| 无 MTP | 30.7 | 1.00x | 纯自回归基线 |
| n=2 | 43.3 | 1.41x | 还行 |
| n=3 | 47.3 | 1.54x | 最优 |
| n=4 | 40.7 | 1.32x | 过度投机，反降 |
+-----------+--------+--------+----------------+

结论： 在 RDNA3 上 n=3 是甜点。n=4 时 MTP 头预测的 token 接受率下降，白白浪费算力。

ROCm 优化参数验证（血泪教训）

网上抄了一堆「优化参数」一个个验证（编者注：有agent就是好，看到论坛内的贴/X上面的贴不管有没有用就直接扔
给agent进行分析匹配，然后一项项让她自己随即跑，省下不少时间，就是token烧不少了）：

+--------------------+--------+--------+----------------------------+
| 参数 | TG 前 | TG 后 | 结论 |
+--------------------+--------+--------+----------------------------+
| --batch-size 1024 | 47.3 | 47.3 | ≈ 完全无影响 |
| --flash-attn on | 47.3 | 47.3 | ≈ 完全无影响 |
| --cache-ram 0 | 47.3 | 48.7 | ≈ 可以忽略 |
| 全开(3个全加) | 47.3 | 47.3 | ≈ 完全无影响 |
| MMVQ_MAX_BATCH=3 | 47.3 | 30.7 | 降30%是毒药 |
| --no-mmap | 47.3 | OOM | 直接在 ROCm 上报错崩溃 |
+--------------------+--------+--------+----------------------------+

结论： ROCm + RDNA3 上绝大部分社区「优化参数」都是抄 CUDA 的，搬过来要么没效果要么反效果。核心只有 --spec-type draft-mtp --spec-draft-n-max 3，其他全删掉就是最优。

Day 2: Vulkan 对比 + 发现 3080 Ti 污染

想看看 Vulkan 和 ROCm 有多大差距，结果发现了一个大坑。

双 GPU 的 Vulkan 陷阱

+-----------------------------+--------+----------------------------------+
| 配置 | tok/s | 说明 |
+-----------------------------+--------+----------------------------------+
| ROCm (纯 7900 XTX) | 47.3 | ROCm 天然只看 AMD GPU |
| Vulkan (默认, 双卡都在) | 25~29 | 被 3080 Ti 分走部分 work |
| Vulkan + VK_ICD_FILENAMES | ~0 | RADV 退 CPU, GPU 0% |
| Vulkan + GGML_VULKAN_DEVICE | 25~29 | 设了也没用，3080 Ti 仍占 6.9GB |
+-----------------------------+--------+----------------------------------+

细说 Vulkan 的坑：

GGML_VULKAN_DEVICE=1 无法真正隔离 GPU — 设了之后 7900 XTX 干活，但 3080 Ti 仍然被分配了 ~6.9GB 显存。两张卡之间 PCIe 来回走，带宽瓶颈直接拖死。

VK_ICD_FILENAMES 可以物理隐藏 3080 Ti，但只能用 RADV 开源驱动（不能用 AMD 官方驱动）。RADV 下 compute 全退 CPU（GPU 0%, CPU 99%），根本跑不动。

结论：ROCm 才是纯 7900 XTX 的唯一可靠后端。 之前谣传的 Vulkan 好用，全是因为没发现 3080 Ti 在偷算力。

MTP 精度敏感

IQ4_XS GGUF 有的版本自带 MTP 层有的没有。如果模型不带 MTP 层，--spec-type draft-mtp 直接报 model doesn't contain MTP layers。就算带了，IQ4_XS 的接受率也只有 ~34%，不如 Q4_K 的 ~50%。

Day 3: DFlash 登场

社区发现 Lucebox DFlash 在 AMD 上能跑出 2.2x 加速，立马安排。

编译

git clone https://github.com/Luce-Org/lucebox-hub.git
cd lucebox-hub
git submodule update --init --recursive
cd dflash

cmake -B build -S . \
  -DCMAKE_BUILD_TYPE=Release \
  -DDFLASH27B_USE_HIP=ON \
  -DCMAKE_HIP_ARCHITECTURES="gfx1100" \
  -DROCM_PATH=/opt/rocm-7.2.0

cmake --build build --target test_dflash -j$(nproc)

踩坑： CMakeLists.txt 引用了不存在的 src/prefix_cache.cpp，删掉该行即可。

️ 模型层数陷阱（踩了两次）

DFlash 的草稿模型基于 Qwen3.6 原版架构（64 层），所以主模型也必须是 64 层。我们最早用的 Huihui Q4_K 有 65 层（含 MTP 头），DFlash 加载直接不兼容。

正确搭配必须是 64 层模型。

测量方法的坑

一开始用 scripts/run.py 单 prompt 测，只跑出 56.14 tok/s。后来发现 Reddit 帖子用的是 bench_he.py（10 道 HumanEval 编程题平均），测出来的才是纯解码速度：

DFLASH_BIN=$PWD/build/test_dflash \
DFLASH_TARGET=/path/to/64层主模型.gguf \
DFLASH_DRAFT=models/dflash-draft-3.6-q8_0.gguf \
DFLASH27B_DRAFT_SWA=2048 \
DFLASH27B_PREFILL_UBATCH=512 \
  python3 scripts/bench_he.py --n-gen 128 --ddtree-budget 8

全部方案横向对比

+--------------------------------+---------+--------+----------------------------+
| 方案 | tok/s | 加速比 | 说明 |
+--------------------------------+---------+--------+----------------------------+
| Pure AR (llama.cpp HIP) | 30.83 | 1.00x | 自回归基线 |
| ROCm MTP n=2 (Q4_K) | 43.3 | 1.40x | 早期 MTP 配置 |
| ROCm MTP n=3 (Q4_K) | 47.3 | 1.53x | MTP 最优 |
| ROCm MTP n=4 (Q4_K) | 40.7 | 1.32x | 过度投机 |
| Vulkan MTP (受3080 Ti污染) | 25~29 | 0.9x | 比纯AR还慢 |
| DFlash Q4 draft + budget=22 | 27.03 | 0.88x | 草稿太慢+验证树太大 |
| DFlash chain (无DDTree) | 64.23 | 2.08x | 简单策略还行 |
| DFlash Q8 draft + budget=8 | 68.80|2.23x| 全场最佳 |
| DFlash Q8 draft + budget=22 | 60.94 | 1.98x | budget 太大浪费带宽 |
+--------------------------------+---------+--------+----------------------------+

DFlash 完整实测明细

1:1 对照 Reddit

+---------------------+-------------------+-------------------+--------+
| 项目 | Reddit 帖文 | 我们实测 | 差异 |
+---------------------+-------------------+-------------------+--------+
| AR 基线 | 28.07 tok/s | 30.83 tok/s | +10% |
| DFlash DDTree b=8 | 62.75 tok/s | 68.80 tok/s | +9.6% |
| 加速比 | 2.24x | 2.23x~2.45x | 持平 |
| 平均提交长度 | 4.93 | 4.79 | -3% |
| ROCm | 7.1 | 7.2 | — |
| 主模型 | 原版 Qwen3.6 27B | Heretic 无审查版 | — |
+---------------------+-------------------+-------------------+--------+

bench_he.py 10 题明细

+-----------------------------+-------+------+--------+
| prompt | tok/s | AL | 接受率 |
+-----------------------------+-------+------+--------+
| has_close_elements | 41.63 | 2.91 | 18.2% |
| separate_paren_groups | 68.61 | 4.92 | 30.8% |
| truncate_number | 61.05 | 4.13 | 25.8% |
| below_zero | 74.61 | 5.12 | 32.0% |
| mean_absolute_deviation | 55.97 | 4.43 | 27.7% |
| intersperse | 89.24 | 6.10 | 38.1% |
| parse_nested_parens | 70.85 | 4.92 | 30.8% |
| filter_by_substring | 69.46 | 4.74 | 29.6% |
| sum_product | 93.42 | 6.40 | 40.0% |
| rolling_max | 63.19 | 4.27 | 26.7% |
+-----------------------------+-------+------+--------+
| MEAN |68.80|4.79|30.0%|
+-----------------------------+-------+------+--------+

DFlash 时序分解（budget=8）

+----------------+----------+--------+
| 阶段 | 耗时/步 | 占比 |
+----------------+----------+--------+
| draft_build | 0.61 ms | 0.9% |
| draft_compute | 11.91 ms | 17.8% |
| verify_build | 1.66 ms | 2.5% |
| verify_compute | 51.85 ms | 77.6% |
| 其他 | 0.67 ms | 1.0% |
| 合计每步 | 66.85 ms | — |
| 每步提交 | 3.76 tokens | — |
+----------------+----------+--------+

瓶颈在验证阶段（78%），这是 RDNA3 的 WF32 物理上限。

DFlash 参数调优对比

+---------------------------+--------+---------------------------------------+
| 参数 | tok/s | 说明 |
+---------------------------+--------+---------------------------------------+
| Q4 draft + budget=22 | 27.03 | Q4 反量化拖草稿 + 验证树太大 |
| Q8 draft + budget=8 |68.80 | AMD RDNA3 上 Q8 反量化快于 Q4 |
| Q8 draft + budget=22 | 60.94 | budget 太大，验证树浪费 GDDR6 带宽 |
| chain（无 DDTree） | 64.23 | 短生成更快，长上下文不如 DDTree |
+---------------------------+--------+---------------------------------------+

关键发现（不只是抄结论）

1. Budget=8 是 7900 XTX 的甜点

完全验证了 Reddit 和 PR #156 的结论。budget=8 时验证树大小刚好填满 GDDR6 的 wavefront，再大就浪费了。

2. 无审查版不影响 DFlash 性能

Abliterate 改的是 attention 里拒绝回答的方向，对草稿接受率无影响。实测 68.80 tok/s 高于 Reddit 原版的 62.75，说明不存在负面作用。

3. ROCm 优化参数基本都是玄学

在 RDNA3 上 batch-size、flash-attn 这些 CUDA 优化全都没效果。--no-mmap 甚至直接 OOM。越简单越好。

4. 双 GPU 机器测 Vulkan 要小心 ️

Vulkan 默认把所有 GPU 拉进来干活，3080 Ti 被分配 ~6.9GB显存，跨卡 PCIe 瓶颈直接拖死。ROCm 天然隔离 NVIDIA，才是正确方案。

5. 测量方法很重要 ️

run.py 单 prompt → 56.14 tok/s（含预填充开销）
bench_he.py 多 prompt 平均 → 68.80 tok/s（纯解码速度）
对标别人必须用同款工具。

6. MTP n=3 是第二选择

如果不用 DFlash，ROCM MTP n=3 + Q4_K 是 47.3 tok/s 的可靠方案。但 Q4_K_M + DFlash 的 68.8 tok/s 直接拉开 45% 差距。

最终结论

Lucebox DFlash 在 RX 7900 XTX (24GB) + Qwen3.6-27B 上：

实测 68.80 tok/s（bench_he.py 10 HumanEval tg128）
相比 llama.cpp HIP 纯自回归基线 30.83 tok/s → 2.23x 加速
超越 Reddit 帖文 62.75 tok/s，证实 AMD 卡在 DFlash 上确实能跑出好成绩

参考链接

Lucebox DFlash: https://github.com/Luce-Org/lucebox-hub
草稿模型: https://huggingface.co/Lucebox/Qwen3.6-27B-DFlash-GGUF
主模型(Heretic 无审查): https://huggingface.co/Youssofal/Qwen3.6-27B-Abliterated-Heretic-Uncensored-GGUF
lcz.me 论坛帖: https://lcz.me/topic/195/
Reddit 原帖: https://www.reddit.com/r/LocalLLaMA/comments/1tgepbd/

写在最后：折腾的路还在继续，第二篇帖子已经写好了，再折腾半天即可发布~！
附上简陋的测试环境、杂乱的线材、远远比不上各位前辈们的海景房大机箱
图片_20260610101156.jpg

图片_20260610101147.jpg

abaalei

@kos-or 感谢，不过他去年就走了

grok可以的，我现在是通过cliproxy api来oauth登陆了x之后，再反代出来给hermes用
因为我现在在用的主板也是矿板，现在还空出来了2根x16的全场插槽（这块板一共6槽，4x16 2x8），所以在心痒痒要不要多搞2张v100/16g 或者mi50/16g回来折腾，哈哈哈

卡1只有1GB/s是主板问题吗？

cab0d02d-034a-43ec-a90a-f00022b176a8-da48b96c858dc4624ce09d399fa014d.jpg

abaalei

@kos-or 所以我现在有3个模式：
模式A-极速模式，就日常瞎聊使用

模式B-128k上下文，专门拿来写小说（就是用huihuiai的模型）
“模式 B (长文写作版) — IQ4_XS

配置：llama-server + --cache-type-k q4_0 --cache-type-v q4_0 + --no-mmap（关闭 MTP）。
首字速度 (Prefill)：313.93 t/s (6.3万 tokens 耗时约 202 秒)。
生成速度 (Decode)：19.34 tok/s。
显存占用：72% (约 17.6 GB) 🟢。
定位：支持 128K。”

另外昨晚修复了之前丢失的模式C-用Qwen3.6-27B-Uncensored-HauhauCS-Balanced-MTP-Q4_K_P“模式 C (自投机备用版) — MTP-Q4_K_P 缝合怪

配置：llama-server + 原生 MTP (n=3) + --cache-type-k q8_0 --cache-type-v q8_0 + --no-mmap。
首字速度 (Prefill)：644.60 t/s (6.3万 tokens 耗时约 100 秒)。
生成速度 (Decode)：43.22 tok/s。
显存占用：94% (约 23.0 GB) ️。
定位：支持 64K。首字和生成速度都极其优秀，但 128K 长文下显存接近临界值，容易被其他并发进程挤爆 OOM”

abaalei

@kos-or 对，按遥控指挥人做事的感觉真的会上瘾的，哈哈哈。我基本上是gpt3.0？一开始的时候用过一段时间，那时候觉得就那样。然后25年我爸cancer，开始重度使用gpt/grok来分析每15天的抽血报告，开始越来越觉得ai带来的增益比一开始要多了。然后26年2月开始白嫖gemini pro，用了2 个月越来越离不开了，后面就尝试在自己的truenas上面配置了hermesagent，然后就一发不可收拾了，现在都玩起双卡流了，最可惜的是当年矿潮的时候12000买的3080ti，至今都不能改24g显存，不然7900xtx主力做LLM，3080ti跑comfyui就完美了，哎，可惜呀

abaalei

@CHIA-AN-YANG 我不是大神，ai才是，哈哈，下面是我家agent的回复，你试试看？

药方一：检查并修正运行时的 LD_LIBRARY_PATH（最有可能的罪魁祸首！）

问题所在：Colt 编译时使用的是 -DROCM_PATH=/opt/rocm-7.2.3。但是他运行时的命令行里写的却是 LD_LIBRARY_PATH=/opt/rocm/lib:$LD_LIBRARY_PATH。
根因：如果他系统里的 /opt/rocm 软链接指向的是旧版本（比如 ROCm 6.x 或其他版本），那么程序在运行时就会加载错误的 libamdhip64.so，导致 ABI 不兼容，进而在 prefill 阶段发生核心转储崩溃！
解决方案：让他把运行时命令中的 /opt/rocm/lib 明确修改为与编译一致的绝对路径：

LD_LIBRARY_PATH=/opt/rocm-7.2.3/lib:$LD_LIBRARY_PATH

药方二：去掉不兼容的英伟达等效编译参数 -DDFLASH27B_HIP_SM80_EQUIV=ON

问题所在：他在 CMake 命令中显式开启了 -DDFLASH27B_HIP_SM80_EQUIV=ON。
根因：这个参数是强行把英伟达的 SM80（Ampere）架构指令转换映射到 AMD 架构。在 7900 XTX (Navi 31 / gfx1100) 的 ROCm 7.x 原生环境下，开启此转换极易生成不兼容的显卡底层硬件指令，导致 prefill 崩溃。
解决方案：重新编译时，直接删掉这个参数，走纯原生的 HIP 编译。

药方三：强力建议开启 -DDFLASH27B_FA_ALL_QUANTS=ON 进行干净的重编

问题所在：如果他没有显式开启这个参数（默认是 OFF），DFlash 在面对 Q4_K_M 这种量化格式的 KV Cache 时会匹配不到对应的 VEC dispatch 模板，导致闪退或崩溃。
解决方案：让他清理编译缓存（这步极度重要，ROCm 编译必须 --clean-first），并用下面的命令重新编译：

1. 彻底清理旧编译缓存

rm -rf server/build

2. 干净地进行全量化重新编译

cmake -B server/build -S server
-DCMAKE_BUILD_TYPE=Release
-DDFLASH27B_GPU_BACKEND=hip
-DCMAKE_HIP_ARCHITECTURES=gfx1100
-DROCM_PATH=/opt/rocm-7.2.3
-DDFLASH27B_FA_ALL_QUANTS=ON
-DCMAKE_C_STANDARD=11
-DCMAKE_CXX_STANDARD=17
-DGGML_CCACHE=OFF

cmake --build server/build --target test_dflash --clean-first -j$(nproc)

额外避坑提醒：
运行 test_dflash 时，他的 --fa-window 0 可能会因为参数解析问题被丢弃。建议他把命令行参数改写成带等号的 --fa-window=0，或者干脆在运行前加一句：
export DFLASH27B_FA_WINDOW=0

abaalei

我用机智罗的整合包，先在pc上用机智罗的软件解压缩后，再重新压缩传到7900xtx的机器上，让agent帮我解压跟文档归类，目前我这步跑960*544 12帧/秒，3.33秒的视频大概耗时160~180秒的样子，你也可以用他的整合包试试

abaalei

@kos-or 对的但是思考商业模式并非我的强项，哎。会的东西一大堆，但是没有一样是可以拿来转换成商业模式了。是时候跟ai深入探讨一下了

抡锤者

abaalei

帖子

写在前面

🧪 硬件环境

目标

️ 完整折腾路线图（七阶段全记录）

阶段一：初识问题 — Fattn 崩溃

阶段二：尝试补丁 — TILE fallback patch（失败）

阶段三：证实方向 — FA_ALL_QUANTS=ON 完整编译

阶段四：测试 OBLITERATUS（假无审查 + 不兼容）

阶段五：测试 Huihui IQ4_XS（真无审查但龟速）

阶段六：测试 Heretic Q4_K_M（原生兼容但假无审查）

阶段七：FA_ALL_QUANTS=ON + --fa-window 0 + Huihui Q4_K_M

完整模型兼容性矩阵

最终性能对比

DFlash API 速度 (OpenAI 兼容 server)

bench_he.py 详细成绩 (Reddit 同款 10 HumanEval，2026-06-10)

模型去审查排名表

去审查实测验证

🧠 经验教训总结

参考来源

写在前面

硬件配置

软件环境

🧪 整个测试历程（三天踩坑实录）

Day 1: 先试 MTP，把参数撸了个遍

MTP 参数调优

ROCm 优化参数验证（血泪教训）

Day 2: Vulkan 对比 + 发现 3080 Ti 污染

双 GPU 的 Vulkan 陷阱

MTP 精度敏感

Day 3: DFlash 登场

编译

️ 模型层数陷阱（踩了两次）

测量方法的坑

全部方案横向对比

DFlash 完整实测明细

1:1 对照 Reddit

bench_he.py 10 题明细

DFlash 时序分解（budget=8）

DFlash 参数调优对比

关键发现（不只是抄结论）

1. Budget=8 是 7900 XTX 的甜点

2. 无审查版不影响 DFlash 性能

3. ROCm 优化参数基本都是玄学

4. 双 GPU 机器测 Vulkan 要小心 ️

5. 测量方法很重要 ️

6. MTP n=3 是第二选择

最终结论

参考链接

1. 彻底清理旧编译缓存

2. 干净地进行全量化重新编译