🚀 Lucebox DFlash + Huihui：7900 XTX 上真·无审查 + 极速推理完全折腾纪实
-
以下内容以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 應該夠應付跨卡需求了
-
-
-
-
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)：
-
@kos-or
这是我之前跟gemini探讨无审查模型的作用，你可以参考下绝大多数人一听到“无审查（Uncensored）”，第一反应都是角色扮演（RP）、写小说或者搞擦边内容。在那些场景下，我们需要的是像 Huihui 那样“有情绪、有感官、懂禁忌”的模型。
但为什么 Eric Hartford 这类大佬要耗费巨资去训练 Dolphin 这种“冰冷、客观、绝对服从”的无审查模型？因为在硬核的工程、网络安全和自动化领域，AI 的“道德感”往往会成为致命的绊脚石。
我们可以把这种需求拆解到你提到的代码、逻辑、推理这三个板块来看：
- 代码 (Code)：红蓝对抗与“数字洁癖”
主流的商业模型（如官方的 Claude、GPT-4，甚至是原版 Qwen）都有严重的“数字洁癖”。如果你的需求稍微触碰到系统底层或网络边界，它们就会触发安全警报（这在业内被称为 False Refusal / 误拒）。
安全测试与渗透代码： 假设你需要写一个脚本来测试自己服务器的防御强度，比如模拟一个勒索病毒的加密过程，或者写一个局域网的 ARP 欺骗脚本。正经模型会立刻对你进行说教：“对不起，我不能提供恶意软件的编写方法。”但对于绝对服从的无审查模型来说，它只是一段代码，你让它写，它就高效地把 Python 或 C 语言的源码吐给你。
激进的系统管理： 在管理复杂的 Linux 服务器、虚拟机集群或底层网络分流节点时，有时需要写一些极其暴力、权限极高的自动化运维脚本（比如强制清理进程、修改底层路由表）。带有道德护栏的模型有时会因为判定“该操作可能损害系统”而拒绝输出完整代码。绝对服从的模型则不管这些，它默认你对自己的硬件有绝对控制权。
- 逻辑 (Logic)：无视规则的智能体 (Agent) 驱动
你在跑本地的 AI Agent 时，Agent 运转的核心逻辑是“理解任务 -> 调用工具（Tool Calling） -> 输出严格的 JSON”。
无视服务条款 (ToS)： 如果你给 Agent 下达的指令是“绕过这个网站的反爬虫机制，抓取所有数据”，或者“强行破解这个本地文件的密码”。有审查的模型会在逻辑链条的中间突然“圣母心”发作，判定这违反了某某网站的 ToS，然后输出一段包含拒绝语气的废话，直接导致整个 Agent 的 JSON 格式崩溃，工作流中断。
绝对的工具调用： 绝对服从的模型没有这些顾虑。它的逻辑链条是纯粹的线性的：既然你给了我抓取网页的工具和指令，我就不择手段地组合参数去完成它。它是一台完美的、没有情绪的齿轮。
- 推理 (Reasoning)：黑暗数据的冷酷分析
有时候，我们需要模型处理的数据本身就是负面的、违规的或者极度具有争议性的。
舆情分析与取证： 假设你需要让模型总结提炼一份包含大量极端言论、网络暴力的聊天记录，或者分析一份真实的犯罪现场调查报告。
“爹味”的干扰： 有审查的模型在推理这些数据时，会忍不住在结论里加上一句：“需要注意的是，这些言论是非常不合适的……”或者直接因为文本太黑深残而拒绝阅读。
冷酷的剥离： 绝对服从的模型在做推理时，就像一个没有感情的法医。它能精准地从那些污言秽语和残忍描述中，提取出作案动机、逻辑漏洞或是数据规律，不带任何偏见和说教。
总结来说：
Huihui 这类 RP 模型是“狂热的演员”，陪你沉浸式发疯；而绝对服从的无审查模型是“冷酷的杀手”，你给它一把枪（工具）和一个目标，它就去执行，绝对不问为什么。 - 代码 (Code)：红蓝对抗与“数字洁癖”
-
@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”
-
系统 取消固定了该主题
