🚀 Lucebox DFlash + Huihui:7900 XTX 上真·无审查 + 极速推理完全折腾纪实
-
@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也是有的
-
@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 應該夠應付跨卡需求了
-
-
-
-
A abaalei 被引用 于这个主题
-
更新一下昨晚的调参
分享一下针对单卡 7900 XTX 跑 Qwen3.6-27B(DFlash 投机推理)的最新极限调优成果!昨晚经过反复压榨,成功把生成速度推上了新高峰:
7900 XTX 单卡 DFlash 实测成绩:- 平均生成速度 (Decode MEAN):
84.47 tok/s(在 HumanEval 10-prompt 串行高压测试下跑出,单题峰值突破 108.05 tok/s) - 平均投机接受长度 (AL):6.29(接受率约 40.8%)
️ 终极黄金启动参数:bash
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 q8_0
--no-mmap
--tensor-split 0
--tokenizer Qwen/Qwen3.6-27B
核心调优心得(无痛白嫖 4% 速度的秘密):- 压榨 KV Cache 带宽(关键!):显式加上
--cache-type-k q8_0和--cache-type-v q8_0后,虽然在 GPU 内部多了一步反量化计算,但由于量化让 KV 缓存的数据量直接减半,极大地缓解了 RDNA3 架构在投机树匹配时的显存带宽压力。实测速度从默认 F16 状态下的 81.19 tok/s 直接飙升到了 84.47 tok/s!而且在 32K 极限上下文下能省下一半的 KV 显存,极大幅度降低了 OOM 的风险! - 配合
--no-mmap:在 Linux 原生 ROCm 驱动下,关闭内存映射可以避免文件 I/O 阻塞首字加载,对于首字延迟(Prefill)有可见的加载优化。 - 配合
--tensor-split 0:强制绑定单卡槽位算子,防止并发时发生莫名其妙的 CPU 回退(Fallback)。
- 平均生成速度 (Decode MEAN):

