Qwen3.8-27B-Uncensored-GGUF

未经审查的 Qwen3.8-27B 模型，以 GGUF 量化格式发布，保留并验证了多令牌预测（MTP）头。

拒绝行为已大幅减少，但并未完全消除。具体数据请参阅"实测行为"部分。其余能力、训练数据和架构均保持不变。

MTP 张量经过验证，而非凭空假设。 Abliteration 技术会丢弃 mtp.* 张量：模型通过 transformers 重新保存，而该框架不携带 MTP 头，但 config.json 中仍声明了该组件。这些张量已从基础检查点重新嫁接回来，且每个文件在量化后均经过检查——详见"方法与验证"部分。

方法

• 使用 Heretic 移除拒绝方向，该工具在最小化拒绝数量的同时，兼顾与基础模型的 KL 散度。无需手写拒绝移除代码，无需微调，无需额外训练数据。
• Abliteration 以 bf16 精度运行（非 4-bit 量化）；生成的 LoRA 合并回 bf16 基础模型，因此发布的权重并非量化往返的结果。
• 合并后，mtp.* 张量从基础检查点原样复制。Abliteration 从不触碰这些张量——它仅修改主栈中的 attn.o_proj 和 mlp.down_proj。
• 草稿头是基于未修改模型训练的，因此接受率可能略有下降。推测解码会对每个令牌与目标模型进行验证，因此输出质量不受影响。
• imatrix 直接基于 f16 计算，而非中间量化结果，因此校准过程看到的是真实权重。

文件说明

草稿头在所有配置中均保持 Q8_0 精度。相对于目标模型，它体积较小，进一步压缩量化只会降低草稿接受率，而几乎无法节省磁盘空间。

概述

文件列表

困惑度（Perplexity）

以下数据均在同一构建版本上、同一会话中、以相同的 f16 基线为参照进行测量，因此各行数据之间具有可比性。

在解读排序之前，请务必先阅读误差范围。 除 IQ2_M 之外的所有行都落在约 0.026 的区间内，而标准误差约为 0.25，因此这些量化版本之间、以及它们与 f16 之间均无法有效区分，表中的排序只是噪声。不要据此认为 Q8_0 比 Q5_K_M 更差。本次测量唯一能够明确分辨的差异是 IQ2_M，它比基线高出约 2.8 个标准误差。

noMTP-* 系列未在表中列出，因为它们的测量结果与对应的融合版本完全一致。MTP 模块在正常前向传播过程中不参与计算，这一点已在本次测试中得到验证：融合版与 noMTP 版的 IQ2_M 均返回 7.8581，融合版与 noMTP 版的 f16 均返回 7.1557。

测试语料为 Salesforce/wikitext 数据集中的 wikitext-2-raw-v1 的 test-00000-of-00001.parquet 文件，取 text 列并以 \n 连接。该文件与用于生成重要性矩阵的语料相同，详细信息见下文。

llama-perplexity -m Qwen3.8-27B-Uncensored-IQ2_M.gguf \
  -f calibration.txt -ngl 99 --chunks 20

困惑度只能检测出严重的量化损伤，除此之外别无他用。它无法衡量推理能力、代码能力、多语言能力或拒答行为。请参阅下文“需要注意的注意事项”。

重要性矩阵（Importance matrix）

Qwen3.8-27B-Uncensored-imatrix.dat 是本仓库中所有量化版本所使用的重要性矩阵。全部十二个 IQ2_M、IQ4_XS、Q4_K_M、Q5_K_M、Q6_K 和 Q8_0 文件，无论是融合版还是 noMTP 版，都在各自的元数据中记录了该矩阵。独立的 draft-Q8_0 头与 vision-f16 投射器则未包含该矩阵，因为二者并非基于此矩阵构建。

发布此矩阵的目的是为了让本仓库中的文件可以被复现，同时让你能够构建本仓库未提供的量化版本。

使用前需要了解两点：

• 尽管扩展名为 .dat，它实际上是 GGUF 格式（general.type = imatrix）。不支持 GGUF 格式 imatrix 的旧版 llama.cpp 将无法加载该文件。
• 该矩阵不包含 blk.64（即 MTP 块）的任何条目。llama-imatrix 在正常前向传播过程中不会激活草稿头，因此不会为其收集激活值。这一点在下方会有所涉及。

来源可验证而非仅凭声明：使用此文件将 f16 重新量化为 Q4_K_M，可以逐字节复现已发布的 Qwen3.8-27B-Uncensored-Q4_K_M.gguf，全部 866 个张量完全一致。

自行构建其他低位量化版本

本仓库的下限是 IQ2_M，大小为 10.6 GB。如果你需要更小的模型，或想使用未发布的量化类型，可以使用上述 imatrix 自行构建。

你需要 f16 GGUF 文件，但该文件因体积达 54 GB 未在此发布。你可以从公开的 bf16 权重自行构建：

hf download JonathanColetti/Qwen3.8-27B-Uncensored --local-dir Qwen3.8-27B-Uncensored
python convert_hf_to_gguf.py Qwen3.8-27B-Uncensored \
  --outfile Qwen3.8-27B-Uncensored-f16.gguf --outtype f16

对于noMTP变体，请在该命令中添加--no-mtp参数。MTP分片已整合进bf16仓库中，因此无需先进行任何恢复操作。

MTP块必须固定不变。 由于imatrix不包含blk.64条目，且IQ3_XXS、IQ2_XXS、IQ2_S和IQ2_M需要基于张量的重要性数据，因此在不固定的情况下进行融合低位构建不仅会降低草稿头的性能，llama-quantize甚至会直接拒绝运行。将blk.64固定为q8_0可绕过此要求，同时保持草稿头完整无损：

llama-quantize \
  --imatrix Qwen3.8-27B-Uncensored-imatrix.dat \
  --tensor-type 'blk\.64\.=q8_0' \
  --token-embedding-type q4_K \
  Qwen3.8-27B-Uncensored-f16.gguf Qwen3.8-27B-Uncensored-IQ2_XXS.gguf IQ2_XXS

--token-embedding-type q4_K 是该模型上最大的规模调节杆。llama.cpp 会在所有 IQ2/IQ1 格式类型上强制将 token_embd 提升为 Q5_K，而在 248320 词表大小下，这大约占参数的 8% 到 10%。 切勿低于 q4_K。对于 noMTP-* 构建，请省略 --tensor-type 固定参数，因为 没有可供固定的块。

之后请验证该块是否保留，而不是想当然地认为它已经保留：

python quantize.py inspect Qwen3.8-27B-Uncensored-IQ2_XXS.gguf   # expect 65/65, has_mtp: true

2-bit 警告。 IQ2_M 是本仓库中退化最严重的文件，任何基于它构建的内容只会更糟。这种损失预计会最重地落在该模型的主要用途上。旧拒绝边界附近的行为已经是其最不稳定的属性（见“重要注意事项”），而 2-bit 量化恰恰加剧了这一问题。困惑度会告诉你模型并未损坏，但它无法告诉你拒绝边界是否仍保持 Q6_K 时的表现，而本仓库中没有任何指标在 2-bit 下度量这一点。

第三方量化版本

第三方发布了一系列基于该模型的混合精度变体：

• zerodigest/Qwen3.8-27B-Uncensored-YMQ-MTP-GGUF

并非由本仓库制作或与其相关。 该版本并非由我构建，我未验证其文件或公布的数据，且其中引用的任何指标并非在本测试框架上测量，因此与本文档中的困惑度数据不具可比性。提供此链接是因为人们常询问我未发布的尺寸规格，而非作为推荐。

使用方法

llama-server -m Qwen3.8-27B-Uncensored-Q4_K_M.gguf \
  --spec-type draft-mtp --spec-draft-n-max 2 \
  -ngl 99 -c 8192

目标加显式草稿：

llama-server -m Qwen3.8-27B-Uncensored-noMTP-Q4_K_M.gguf \
  --spec-type draft-mtp \
  --model-draft Qwen3.8-27B-Uncensored-draft-Q8_0.gguf \
  -ngl 99 -c 8192

--spec-draft-n-max 默认值为 3。吞吐量取决于您的硬件配置，建议进行参数扫描——不同草稿长度的测量结果参见 qwen3.8-spec-decode-bench。

验证

每个产物在量化后均经过 MTP 张量存活性检查，而非仅依据转换标志进行推断：

python quantize.py inspect Qwen3.8-27B-Uncensored-Q4_K_M.gguf

此报告列出了元数据键、声明的 block_count 及实际存在的块。若融合文件的实际块数未超过声明块数，则说明其未保留 MTP 块。

实测表现

在与未修改的基础模型完全相同的设置下进行基准测试。关键在于差值（Δ）：它单独反映了权重修改所带来的影响。

使用 lm-evaluation-harness 进行 0-shot 测试，bf16 精度，两个模型在同一会话中评分。每个差值都在报告的标准误差范围内或接近该范围（MMLU ± 0.30，ARC ± 1.44，HellaSwag ± 0.38，Winogrande ± 1.21），因此没有一项能明确区分于运行间的随机噪声。

这些是 0-shot 结果，与 Qwen 官方发布的分数不可比，后者使用了 few-shot 提示。但两者直接可比，这正是关键所在。另请注意，对于具有如此 MMLU 分数的模型而言，ARC-Challenge 分数偏低——基础模型在相同设置下也仅得 58.9 分，因此这属于推理调优模型的格式敏感性，而非消融（abliteration）造成的损伤。

基准测试未涵盖的内容：没有生成式评估（GSM8K、HumanEval），没有数学或代码测试，没有多语言测试，且测试工具仅加载了文本栈——此处没有任何指标衡量视觉塔或 MTP 投机解码。

搜索过程：200 次 Heretic 试验，23 个非支配点。发布的模型为标记行。

如何解读这些指标

拒答率（Refusal rate） 是指在 mlabonne/harmful_behaviors （测试集）中 100 条留存提示词（prompt）中，模型拒绝回答的次数——这些是明确有害的请求，而非良性请求。因此，这个数字并非过度拒答率：它并不反映模型拒绝合法任务的情况，而是衡量原始安全行为在应对有害请求时保留了多少。

KL 散度（KL divergence） 是基于未修改的基础模型，对首个生成 token 的分布进行测量得到的。它是优化器用来衡量“我们对模型造成了多大损伤”的代理指标。数值越低，说明越接近基础模型。但这是一个代理指标，而非能力评估——低 KL 散度并不能证明推理或编码能力得以保全，本页面中的任何内容也无法做出此类保证。

二者之间存在权衡取舍。Heretic 在这两者之间搜索帕累托前沿（Pareto front）；所发布的结果只是该前沿上的一个选择，而非全局最优解。

需要重视的注意事项

• 拒答率是在非思考模式下测量的。 该模型的聊天模板会开启 <think> 代码块，因此评估过程会显式关闭该代码块，以对回答内容而非推理过程进行评分。若启用思考模式，拒答率可能会有所变化，可能更高也可能更低。
• 该测量仅基于单一数据集中的 100 条提示词。 其结果仅适用于该分布范围内的有害请求，不具有更广泛的普适性。模型在其他主题上的拒答行为尚未被刻画。
• 困惑度（Perplexity）仅基于 wikitext-2 数据集（参见文件表）。它能检测出严重的量化损伤，但无法检测推理、代码或多语言任务上的能力损失。
• 量化会放大上述所有问题。 各项测量是在 bf16 合并版本上完成的；而您下载的文件已经过量化处理。

环境要求

MTP 推测解码（speculative decoding）自 llama.cpp PR #22673 起引入。早于该版本的构建产物可以加载这些文件，但会静默忽略 MTP 张量。

局限性

• 拒答行为是减少而非消除，也没有被引导转向。该模型会尝试回答许多原始模型拒绝的请求，但仍有相当一部分会被拒绝——详见“实测行为”部分。
• 在原有拒答边界附近的行为稳定性不如基础模型。
• 低比特量化会加剧这一问题，其中 IQ2_M 的影响最为显著。请在 Q6_K 或 Q8_0 上评估行为，而非 IQ2_M 或 IQ4_XS。本页面没有任何指标衡量 2-bit 量化下的拒答边界。
• 能力基准测试显示，在 MMLU、ARC-Challenge、HellaSwag 和 Winogrande 上，相较基础模型平均下降 0.5 分。详见“实测行为”部分。未进行生成式、数学、代码或多语言评估。

预期用途

本地推理。不建议在未配置自身安全层的情况下向第三方部署。

许可证

Apache 2.0，继承自Qwen/Qwen3.8-27B。基础模型的许可证及可接受使用政策仍适用于您对本衍生模型的使用。

推测解码，在该模型上的实测数据

IQ2_M

在此构建版本上实测：NVIDIA H200 NVL，生成256个Token，取3次重复的中位数，n_max 在1到3之间扫描。上表数据可追溯至原始发布版本，其硬件信息未记录，因此请比较倍率而非绝对速率。

MTP头在2-bit量化下仍能正常工作，因为它被固定为q8_0精度，而非与其余部分一同量化，因此推测解码在此场景下依然有效。

将noMTP-IQ2_M与已发布的draft-Q8_0搭配使用，在散文提示下、n_max为2时可达97.7 Token/秒，即1.30倍加速，在该提示上优于融合文件。原因在于融合版MTP头与主模型共享低位宽的token_embd（q4_K）和output（Q5_K）张量，而独立草稿模型则自带Q8_0副本。分离式方案需要13.3 GB权重，而融合文件仅需10.6 GB，因此仅在显存充裕时分离式才是更优选择。