🚀 Lucebox DFlash + Huihui：7900 XTX 上真·无审查 + 极速推理完全折腾纪实
-
想問,上下文無法開大對嗎?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 應該夠應付跨卡需求了
-
-
