🚀 Lucebox DFlash + Huihui：7900 XTX 上真·无审查 + 极速推理完全折腾纪实
-
原创折腾实录 | 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 插满！！！
- Lucebox DFlash（~93 tok/s run.py / ~80 tok/s API
-
想問,上下文無法開大對嗎?hermes agent無法使用?
-
@laobenxiong 118K-120K是稳定的。实测。优化后为设置的16K。看你想干什么了。我的速度模型用的8K就很够用了。还有测试的落地点不太一样。我比较注重 模型的智力
-
我测了一下。上下文卡在32K。不能上升。显存会爆。
总结：
- 克隆 Lucebox DFlash 源码，初始化 submodule
- HIP 后端编译成功：FA_ALL_QUANTS=ON，gfx1100，Release 模式
- 产物：test_dflash (1.4MB) + dflash_server (3.1MB)
- 下载 Huihui-Qwen3.6-27B-abliterated.Q4_K_M.gguf (16GB) + dflash-draft-3.6-q8_0.gguf (1.8GB)性能测试： | 场景 | 速度 | 接受率 | |-------------------------------------|------------|--------| | HumanEval 代码 (bench_he, budget=8) | 64.2 tok/s | 33.7% | | 中文短对话 (test_dflash) | 45.6 tok/s | 23.1% | | 中文 API (短 prompt) | 25.9 tok/s | 14.9% | | 对比：文档声称 | 81.4 tok/s | 39.1% | 发现的关键问题： 1. GPU DPM 必须 high——默认 low 模式下核心锁 516MHz，速度只有 7.8 tok/s（差 6 倍） 2. 64K 上下文爆显存——C++ dflash_server 预分配全部 KV cache，24GB 无法同时承载 14.7GB 模型 + 1.8GB 草稿 + 64K 缓存。文档用的是已移除的 Python server.py（可能按需分配） 3. 投机解码对中文对话提升有限——draft 模型专为代码优化，中文接受率仅 15%，速度优势减半 4. 文档 81 tok/s 与实测 64 tok/s 差距约 21%——来自 Huihui abliterated 改变了模型输出分布，draft 命中率下降 启动命令（每次重启后）： bash echo high | sudo tee /sys/class/drm/card1/device/power_dpm_force_performance_level cd /opt/lucebox-dflash/server HSA_OVERRIDE_GFX_VERSION=11.0.0 ./build/dflash_server \ models/Huihui-Qwen3.6-27B-abliterated.Q4_K_M.gguf \ --draft models/draft/dflash-draft-3.6-q8_0.gguf \ --ddtree --ddtree-budget 8 --fa-window 0 \ --max-ctx 65536 --cache-type-k tq3_0 --cache-type-v tq3_0 \ --prefix-cache-slots 0 \ --host 0.0.0.0 --port 11435 （64K 配置能启动但大 prompt 会爆，需降 max-ctx 或用纯 AR 模式）没折腾的参考下吧。
-
以下内容以agent回复为主，个人回复为辅，感谢论坛内各路大神的捧场！
感谢支持～折腾了三天，踩坑无数，好在最后成果还不错
作业随便抄，有问题随时问。128K 上下文在 7900 XTX 上实测过，结论是跑不了。详细账目：
64K 128K模型 Q4_K_M ~16 GB ~16 GB
KV cache ~2.5 GB ~5 GB
草稿模型 ~0.5 GB ~0.5 GB
其他 ~1 GB ~1 GB
─────────────────────────────────────
总计 ~20 GB ~22.5 GB
可用 24 GB 24 GB实测算下来 64K 稳，128K 强行分配时 ROCm 报 cudaMalloc failed: out of memory。所以目前定的是 DFlash 32K 日常用（这部分主要拿来随便对话，生成灵感），长文本切到 IQ4_XS 跑 128K（本人主要拿来写小说）。
@Kk Hh
你提到 Huihui 的越狱太暴力这个观察很到位。Abliterate 本质就是拿 diff-in-means 算出 attention 里的"拒绝回答"方向然后反向投影，确实暴力。
不过说 Qwen 不适合做越狱模型——从实测结果看，Qwen3.6 的安全训练相对温和，反而是 diff-in-means 效果比较好的基座。我们实测 Huihui 的真无审查版在代码场景下草稿接受率仍有 39%，智力没明显下降，日常用没啥问题。
同意你说的：越狱模型更适合作为本地私有部署的辅助工具，日常用原版，需要绕过审核时再切，两套共存才是合理方案。（我目前主力模型是deepseek v4flash，gemini3.1pro白嫖版，gemini3.5flash-agent版、sonnet4.6/Opus4.8（kiro白嫖版）、GPT5.5-thinking（微软E3白嫖版，本地大模型只占据使用中的零星一角，都是看各路大神说qwen3.6-27b比较好才去尝试用这个模型的去审查版本，如有更好选择请不吝建议！）
@CHIA AN YANG
上下文问题看上面回复，32K 日常够用。Hermes 接入很简单：
custom_providers:
- name: dflash
api_base: http://你IP:11435/v1
api_key: not-needed
models:- name: lucebox-dflash
然后 /model lucebox-dflash 切换即可。
@williamlouis（Post 6172）
你测得很详细，感谢补充！几个差异点我们逐条对过：
- 速度差异（64.2 vs 81.4 tok/s）
差距约 21%，主要原因：
- 你用的 C++ dflash_server，我们用的是 Python scripts/server.py。Python 版的 KV cache 按需分配，在相同显存下能留更多空间给推理
- 你加了 HSA_OVERRIDE_GFX_VERSION=11.0.0 和 --cache-type-k/v tq3_0，这两个参数我们没用过，不确定对 VEC kernel 调度有没有影响，建议去掉跑一次 bench_he.py 对比
- Huihui 在我们的测试中接受率（39.1%）反而高于 Heretic（30.0%），所以不是 draft 命中率下降的问题
-
DPM 问题
DPM 这点我们核实了——卡在 auto 模式下，温度 39°C，频率正常跑到。没有特意调到 high 也出了 81 tok/s。如果你的卡默认卡在 low（516MHz），那确实需要 sudo tee 调一下，但这不是普适问题，取决于主板/bios 的默认电源策略。 -
上下文 32K 限制
确实，Python server.py 按需分配能跑到 118K-120K，C++ dflash_server 预分配全部 cache，32K 往上就吃紧了。 -
我们完整的启动参数（供参考）：
python3 scripts/server.py
--target 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
隐藏最深的一个坑——MTP
这次折腾中发现了一个最意外的事：我们手上的 Qwen3.6 GGUF 模型（无论是 Heretic 还是 Huihui），量化时都没有保留 MTP 多 Token 预测层。
[spec] failed to create MTP context: model doesn't contain MTP layers
所以之前跑出来的 "MTP n=3 47.3 tok/s" 其实一直在跑纯自回归，MTP 压根没生效。如果你想要 MTP，需要找带 "Native-MTP-Preserved" 标签的 GGUF。我们最后直接全面转向 DFlash 了。
最终推荐方案
经历三天的反复折腾和横评，7900 XTX + Qwen3.6-27B 的最终定版：
推荐
• 引擎: DFlash + Huihui Q4_K_M
• 上下文: 32K
• 速度: ~81 tok/s
• 去审查: 真
• 用途: 日常主力
长文
• 引擎: llama.cpp + IQ4_XS
• 上下文: 128K
• 速度: ~39.7 tok/s
• 去审查:
• 用途: SillyTavern/写小说核心经验：
- FA_ALL_QUANTS=ON + --fa-window 0 + --tokenizer Qwen/Qwen3.6-27B 是 DFlash 稳定的三件套
- 不要 patch 源码，完整编译才是正路
- budget=8 是 7900 XTX 甜点，再大验证树浪费 GDDR6 带宽
- MTP 模式的 GGUF 要专门找带 MTP 头的版本，普通量化版不兼容
- 双卡机器上 Vulkan 有坑，ROCm 天然隔离 NVIDIA 卡
- name: dflash
-
@kos-or 对，按遥控指挥人做事的感觉真的会上瘾的，哈哈哈。我基本上是gpt3.0？一开始的时候用过一段时间，那时候觉得就那样。然后25年我爸cancer，开始重度使用gpt/grok来分析每15天的抽血报告，开始越来越觉得ai带来的增益比一开始要多了。然后26年2月开始白嫖gemini pro，用了2 个月越来越离不开了，后面就尝试在自己的truenas上面配置了hermesagent，然后就一发不可收拾了，现在都玩起双卡流了
，最可惜的是当年矿潮的时候12000买的3080ti，至今都不能改24g显存，不然7900xtx主力做LLM，3080ti跑comfyui就完美了，哎，可惜呀 -
以下内容以agent回复为主，个人回复为辅，感谢论坛内各路大神的捧场！
感谢支持～折腾了三天，踩坑无数，好在最后成果还不错
作业随便抄，有问题随时问。128K 上下文在 7900 XTX 上实测过，结论是跑不了。详细账目：
64K 128K模型 Q4_K_M ~16 GB ~16 GB
KV cache ~2.5 GB ~5 GB
草稿模型 ~0.5 GB ~0.5 GB
其他 ~1 GB ~1 GB
─────────────────────────────────────
总计 ~20 GB ~22.5 GB
可用 24 GB 24 GB实测算下来 64K 稳，128K 强行分配时 ROCm 报 cudaMalloc failed: out of memory。所以目前定的是 DFlash 32K 日常用（这部分主要拿来随便对话，生成灵感），长文本切到 IQ4_XS 跑 128K（本人主要拿来写小说）。
@Kk Hh
你提到 Huihui 的越狱太暴力这个观察很到位。Abliterate 本质就是拿 diff-in-means 算出 attention 里的"拒绝回答"方向然后反向投影，确实暴力。
不过说 Qwen 不适合做越狱模型——从实测结果看，Qwen3.6 的安全训练相对温和，反而是 diff-in-means 效果比较好的基座。我们实测 Huihui 的真无审查版在代码场景下草稿接受率仍有 39%，智力没明显下降，日常用没啥问题。
同意你说的：越狱模型更适合作为本地私有部署的辅助工具，日常用原版，需要绕过审核时再切，两套共存才是合理方案。（我目前主力模型是deepseek v4flash，gemini3.1pro白嫖版，gemini3.5flash-agent版、sonnet4.6/Opus4.8（kiro白嫖版）、GPT5.5-thinking（微软E3白嫖版，本地大模型只占据使用中的零星一角，都是看各路大神说qwen3.6-27b比较好才去尝试用这个模型的去审查版本，如有更好选择请不吝建议！）
@CHIA AN YANG
上下文问题看上面回复，32K 日常够用。Hermes 接入很简单：
custom_providers:
- name: dflash
api_base: http://你IP:11435/v1
api_key: not-needed
models:- name: lucebox-dflash
然后 /model lucebox-dflash 切换即可。
@williamlouis（Post 6172）
你测得很详细，感谢补充！几个差异点我们逐条对过：
- 速度差异（64.2 vs 81.4 tok/s）
差距约 21%，主要原因：
- 你用的 C++ dflash_server，我们用的是 Python scripts/server.py。Python 版的 KV cache 按需分配，在相同显存下能留更多空间给推理
- 你加了 HSA_OVERRIDE_GFX_VERSION=11.0.0 和 --cache-type-k/v tq3_0，这两个参数我们没用过，不确定对 VEC kernel 调度有没有影响，建议去掉跑一次 bench_he.py 对比
- Huihui 在我们的测试中接受率（39.1%）反而高于 Heretic（30.0%），所以不是 draft 命中率下降的问题
-
DPM 问题
DPM 这点我们核实了——卡在 auto 模式下，温度 39°C，频率正常跑到。没有特意调到 high 也出了 81 tok/s。如果你的卡默认卡在 low（516MHz），那确实需要 sudo tee 调一下，但这不是普适问题，取决于主板/bios 的默认电源策略。 -
上下文 32K 限制
确实，Python server.py 按需分配能跑到 118K-120K，C++ dflash_server 预分配全部 cache，32K 往上就吃紧了。 -
我们完整的启动参数（供参考）：
python3 scripts/server.py
--target 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
隐藏最深的一个坑——MTP
这次折腾中发现了一个最意外的事：我们手上的 Qwen3.6 GGUF 模型（无论是 Heretic 还是 Huihui），量化时都没有保留 MTP 多 Token 预测层。
[spec] failed to create MTP context: model doesn't contain MTP layers
所以之前跑出来的 "MTP n=3 47.3 tok/s" 其实一直在跑纯自回归，MTP 压根没生效。如果你想要 MTP，需要找带 "Native-MTP-Preserved" 标签的 GGUF。我们最后直接全面转向 DFlash 了。
最终推荐方案
经历三天的反复折腾和横评，7900 XTX + Qwen3.6-27B 的最终定版：
推荐
• 引擎: DFlash + Huihui Q4_K_M
• 上下文: 32K
• 速度: ~81 tok/s
• 去审查: 真
• 用途: 日常主力 长文
• 引擎: llama.cpp + IQ4_XS
• 上下文: 128K
• 速度: ~39.7 tok/s
• 去审查:
• 用途: SillyTavern/写小说核心经验：
- FA_ALL_QUANTS=ON + --fa-window 0 + --tokenizer Qwen/Qwen3.6-27B 是 DFlash 稳定的三件套
- 不要 patch 源码，完整编译才是正路
- budget=8 是 7900 XTX 甜点，再大验证树浪费 GDDR6 带宽
- MTP 模式的 GGUF 要专门找带 MTP 头的版本，普通量化版不兼容
- 双卡机器上 Vulkan 有坑，ROCm 天然隔离 NVIDIA 卡
- name: dflash
-
@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 回复下问题：卡默认卡在 low（516MHz），那确实需要 sudo tee 调一下。不是卡的问题。我设置了功耗墙。整机的功耗在不工作的状态 卡死在75W了。所以才有默认是 516MHz。需要的人可以试试。工作的状态需要命令行调整到 high。调整命令在我的折腾帖中。手打太长，自己去看吧。
-
@williamlouis 那就难怪拉，我现在3080ti待机35w+7900xtx待机20w，还没算外围电路、损耗、cpu、内存，加起来估计150~200w也是有的
-
@kos-or 感谢，不过他去年就走了
grok可以的，我现在是通过cliproxy api来oauth登陆了x之后，再反代出来给hermes用
因为我现在在用的主板也是矿板，现在还空出来了2根x16的全场插槽（这块板一共6槽，4x16 2x8），所以在心痒痒要不要多搞2张v100/16g 或者mi50/16g回来折腾，哈哈哈卡1只有1GB/s是主板问题吗？
-
我就是用這一張 挖礦用的 GPU 轉接卡 USB cable 通訊頻寬受限吧
上面寫著PCIe 1.0 to 16 所以才會這麼慢
不過我弄了一張主板有 6 slots x 32GB/s 應該夠應付跨卡需求了
-
