写在前面

一直以来，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 完全不参与推理过程，避免混淆。

目标

1. DFlash 引擎 — Lucebox DFlash 投机解码，7900 XTX 甜点 ~93 tok/s
2. 真·无审查 — Huihui abliterated，完全拒答阻断的解除
3. 稳定运行 — 完整 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)：

模型去审查排名表

排名	模型	去审查	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原理"	给出原理+流程	安全教育

🧠 经验教训总结

1. FA_ALL_QUANTS=ON 是正解。 不要再去 patch 源码了，完整编译能解决所有量化类型的 kernel 缺失问题。TILE fallback 是歪路。

2. Uncensored 标签水很深。 Huihui abliterated 是真无审查（直接回复XX步骤），Heretic 号称 Uncensored 但实际拒答。实测为准。

3. mradermacher 的 GGUF 转换管道与 DFlash 兼容性最好。 同一量化的其他发布者版本可能层数/架构不同导致崩溃。

4. Q4_K_M 性能远优于 IQ4_XS (~81 vs ~28 tok/s)，FA_ALL_QUANTS=ON 后 Q4_K_M 无兼容问题，IQ4_XS 已弃用。

5. --fa-window 0 仍是必要的。 即使编译完美，该参数依然是防范长文本 DFlash 滑动窗口崩溃的最佳实践。

6. --tokenizer Qwen/Qwen3.6-27B 解决 emoji 显示方块问题。auto-detect 会匹配到 Qwen3.5 的 tokenizer，某些 emoji token 映射不一致。

7. DFlash 重建后必须 --clean-first，否则增量编译不重编 HIP 目标，修改不生效。

8. 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 插满！！！