Full Survey · Decision Matrix · Quantization Curve · Bare-Metal Validation ×2 · v4.2

谁是最好的
Qwen3.8-27B 无审查模型

+ 两台 L40S 共 16 机时：第一轮推翻纸面 9 条，第二轮推翻第一轮自己 2 条

HuggingFace 上匹配 Qwen3.8 的仓库有 1607 个,其中无审查族 402 个, 30 天下载合计 210 万。本报告从中挑出 10 个真正的候选逐个立档, 用 三个独立证据源(第三方横评 n=50 / 社区实测口碑 / 作者自述)交叉裁决, 并给出 六维加权决策矩阵。 量化部分覆盖 1 → 16 bit 全档,含 KL 散度阈值与质量悬崖的实测位置。

v4 新增实机层：拉起一台专用 L40S（g6e.xlarge · Ada sm_89）跑 13 小时,产出 137 份可独立复核的证据 —— 显存与速度矩阵、1M 上下文的最终裁决、四运行时横评、KLD 质量对照、 以及全网首次的中文轴定量实测。结果推翻了 v3 的 9 条结论。

更新 2026-08-21 Base Qwen/Qwen3.8-27B · 08-05 证据 41 份子报告 + X 横评 + 137 份实测 验证机 g6e.xlarge · L40S 48GB · Ada sm_89 机时 12.9 h 推翻 9 条纸面结论
证据等级: 实测可复现第三方数字 口碑社区实测但不可复现 自述作者声称 = 营销 推断本报告综合判断 缺口无公开数据
读之前必须知道：v3 有 9 条结论已被实机推翻

本报告的 0–15 章是纸面调研层（转述 + 交叉核对）， M1–M5 章是实机验证层（每个数字都在 L40S 上亲手测的）。 两层冲突时以 M 章为准。 模型选型的结论（huihui + Q4_K_M）经实机验证仍然成立； 被推翻的集中在显存、速度、1M 上下文可行性、运行时能力这四类。 → 被推翻的纸面 9 条 · 第二轮推翻自己的 2 条

00 最终裁决 先给答案,后面全是论证
三个独立证据源指向同一个冠军

模型:huihui-ai/Huihui-Qwen3.8-27B-abliterated —— 它是唯一在三个独立证据源上同时领先的候选: 第三方横评加权 9.19/10 第一(n=50,统一 Q4); 社区横评 KLD 0.0078 最低 + 拒答率 1.5%; 而且它是唯一被多个独立账号确认「中文不会掉成英文」的模型 —— 对中文使用者这一条可能比前两条加起来更重要。

量化:Q4_K_M 就够,不必更高。BF16 → 4-bit 在 AIME-120 / Terminal-Bench / 盲评上全部落在噪声内, 且跨 2/4/6/8-bit + BF16 五档实测证明 4-bit 不会让拒答复活。 Q3_K_S 是雷(AIME 54.2% vs Q3_K_M 73.3%),IQ2/IQ1 弃用。

✓ 直接用这个

huihui_ai/Qwen3.8-abliterated —— ollama 一键拉取(13.2K pulls,15 tags,vision/tools/thinking 全标)。 GGUF 走 huihui-ai/Huihui-Qwen3.8-27B-abliterated-GGUF 的 Q4_K_M。

△ 想要方法可复现

trohrbaugh/Qwen3.8-27B-heretic-ara —— KL 0.0535 / 拒答 0/100(原模型 99/100),全部 6 个超参公开,Heretic + ARA。 唯一"数字与方法都能查"的一支。

✗ 别碰这三个

HauhauCS(抄袭 Heretic + 中文强制转英文)· AEON-ULTIMATE(横评 6.83 垫底 + 9/50 silent refusal)· JonathanColetti(下载量第一但 KLD 0.1191 最差)

402
无审查族仓库
从 1607 个 Qwen3.8 仓库中正则筛出
0.0078
冠军 KLD
全场最低 · 越低越接近原模型
9.19
冠军横评加权
n=50 · silent refusal 0/50
Q4_K_M
推荐档位
15.65 GB · 再往上买不到质量
0
权威第三方横评
abliterlitics 还没做 Qwen3.8
M1 实机验证：9 条纸面结论被推翻 专用 L40S · 13 小时 · 137 份证据
v4 的方法论转折

v3 的全部结论来自 转述 + 交叉核对。v4 拉起一台 专用 L40S（g6e.xlarge · Ada sm_89 · us-east-1c）跑了约 13 小时，把每个关键数字亲手测一遍，然后回头核对自己的调研报告。

结果：9 条结论被推翻、5 条被证实、5 条是全新发现。 推翻的来源集中在三类错误 —— 跨 GPU 架构外推、估算值被标成 ✅、 把「查不到」当成「不存在」。

9
被推翻
含显存判死、性能判死、能力判死
28.38 GiB
262K 常驻实测
q8_0 KV · 44.99 预算下余 16.61
41.67 GiB
1M 实测峰值
v3 预测 45.56 判 OOM · 高估 3.93
0.924
中文字符占比
全网首次 · 无 L4 不对称 / 无 L7 坍缩
137
原始证据文件
sha256 已校验 · 可独立复核

被推翻的 9 条 左=纸面 / 右=实机

#v3 纸面结论v4 实机结果错在哪
11M + Q4_K_L 需 45.56 GiB ⇒ 判 OOM实测 41.67 GiB，ECC 开着也够（余 3.34）估算值被标 ✅：权重按文件大小算 + compute buffer 估太高 + 预留重复计入
2issue #27109 使 4-bit KV prefill 崩到 74 t/s ⇒ 1M 需 3.9 小时Ada sm_89 完全不受影响：q4_0 = 2,425.86 t/s（比 f16 只慢 7.7%）跨架构外推：证据硬件是 sm_86 / GB10，差判据阈值 12 倍
3ECC 不可关，44.99 GiB 是硬上限可关：46,068 → 49,140 MiB = 正好 +3.000 GiB未验证就下判断
4只有 llama.cpp 能吃 huihui 的权重（格式锁定运行时）shawnw3i 的 AWQ 保留 visual 333 + MTP 15，vLLM 成功加载没去搜衍生格式
5vLLM 已移除 GGUF 支持vllm-gguf-plugin 存在且注册成功检测代码本身有 bug（importlib.util 需显式 import）
61M 单卡只有 llama.cpp 能做vLLM KV 池实测 1,908,254 tokens，比 llama.cpp 更强只查了 fp8，没查更低档
7Ollama 不暴露 KV 量化 ⇒ 淘汰OLLAMA_KV_CACHE_TYPE 明明存在（--help 权威输出）把「查不到」当「不存在」：strings 查 Go 二进制是假阴性
8速度模型有效带宽 η = 0.60–0.75实测 η ≈ 0.84（反推 725–732 GB/s）系统性偏悲观 20%
9YaRN 验收判据是 freq_scale=0.5/0.25该行根本不打印 ⇒ 按它判会把成功误判为失败判据本身没被验证过
最重要的新发现：-c 1048576 会被静默截断回 262144

加载「成功」、显存按 1M 分配、进程正常 listening、退出码 0 —— 但日志里有一行 capping，slot 实际只有 262,144。 显存白付 3/4，而所有粗看指标都是绿的。

铁证：-c 491520 不加 YaRN 时 slot 被 cap 回 262,144， 而显存占了 37,813 MiB（比 262K/f16 的 35,775 多 2,038）⇒ 按 491,520 分配了 KV。 付了钱拿不到东西。 ⇒ 这催生了本项目的核心方法论：判据必须是产物，不是退出码。

另外四条新发现 v3 完全没有的

FA f16 影子副本 = 1 份

v3 把它列为「全套报告最大的单项不确定性」。用同上下文、只改 KV 精度的对照相减直接解出：

@262,144: q8_0 → 28.380 − 8.500 = 19.880  ┐ 完全相等
          q4_0 → 24.380 − 4.500 = 19.880  ┘ 影子 = 0.959 GiB

三个性质同时成立：① q8_0 与 q4_0 影子相同 ⇒ 是 f16 缓冲；② 随 ctx 线性；③ 等于「一层的 f16 KV」= ctx × 4 KiB ⇒ 1 份，不是 2 份。-ub 调小无法规避。

thinking 的空输出不是审查

8 次里 4 次返回空 answer，看起来像审查残留。每一个的 finish_reason 都是 length，零个 refusal。

max_tokensfinish_reasonanswer
420length0 字符
2000stop4,148 字符

⇒ 社区大量「thinking 死循环 / 空助手消息」的报告很可能是预算耗尽被误诊为审查。部署铁律：开 thinking 时 max_tokens ≥ 2000 并必须检查 finish_reason。

reasoning_effort 三个陷阱

官方模板第 49 行只接受 {xhigh, medium, low}：

  • 没有 high 这档 ⇒ 按常规传 high 直接 HTTP 500
  • 默认是 xhigh —— 最贵那档，不显式设置就等于选了有问题的档位
  • none 不是关闭推理，是静默变 xhigh

机制解释：xhigh 把预算花在 reasoning 上（546 字符），答案反而只有 medium 的 37%（135 vs 362）⇒「medium 最稳」不是玄学。

llama.cpp 丢弃 MTP 块

启动日志：W model has unused tensor blk.64.nextn.* -- ignoring（共 15 个）。张量在 GGUF 里，只是常规 qwen35 路径不用它们。

⚠️ 但这不足以推翻「huihui 的 MTP 权重坏了」—— 那条警告是不开 --spec-type draft-mtp 时打的，而社区报的 acceptance = 0.00000 是开了 MTP 测的，两者不矛盾。该结论仍属【单次实测·待复验】，不是已被推翻。 缺口

M2 显存与速度实测矩阵 校准后公式误差 < 2%

这个架构能单卡吃长上下文的根本原因：64 层里只有 16 层产生 KV（16 full_attention + 48 linear_attention / Gated DeltaNet，full_attention_interval=4）。 每 token KV = 16 × 2 × 4头 × 256dim = 32,768 元素 = 64 KiB @f16 ⇒ 262K 只需 16 GiB KV，而常规 27B 要 64 GiB。 另有 48 层 DeltaNet 的递归状态 0.146 GiB 固定，不随 ctx 增长，且 -ctk/-ctv 碰不到它（llama.cpp 硬编码 F32）。

ctxKV-ub实测 GiBv3 预测v3 偏差
65,536f1651222.733——
65,536q8_051221.067——
262,144f1651234.92137.95–38.81高估 3.0–3.9
262,144q8_051228.380 ★ 常驻推荐31.95高估 3.57
262,144q4_051224.380——
491,520q8_025636.63839.71–40.41高估 3.1–3.8
1,048,576q4_051241.63245.56 ⇒ 判 OOM高估 3.93

经实测校准的两个公式 可以直接拿去做容量规划

calibrated-formulas · 误差 < 2%
VRAM(GiB) ≈ 18.9                             权重 + CUDA context + 基础 compute
          + ctx × KV_bytes_per_token / 2^30   KV cache
          + ctx × 4 KiB / 2^30                FA f16 影子副本（仅量化 KV 时出现）
          − 0.5                               若 -ub 从 512 降到 256

decode tok/s ≈ 725 / (19.47 + KV_GiB)        有效带宽 η ≈ 0.84
prefill ms/token ≈ 0.40 + 0.0094 × 深度(K)   ⇒ 1M 全新 prompt TTFT ≈ 85 分钟

回代：1M + q4_0 + ub512  预测 40.92 vs 实测 41.632  → 误差 1.7%
      491,520 + q8_0 + ub256 预测 36.22 vs 实测 36.638 → 误差 1.1%

速度：KV 精度几乎不影响，深度才是代价

KVpp512 @d0pp512 @d16Kpp512 @d64Ktg64 @d0tg64 @d64K
f162628.492281.891194.3337.2431.20
q8_02559.332253.121192.4636.9631.30
q4_02425.862314.86—36.82—
M3 1M 上下文的最终裁决 结论不变，理由全换
v3 判死的两条理由都被推翻了，但结论仍然是「不推荐」

v3 说「装不下（45.56 > 44.99）+ 跑不动（#27109 打崩 prefill）」—— 两条都不成立：实测 41.67 GiB 装得下，Ada 上 prefill 是 2,425 t/s。 真正的阻断是另外三条，v3 只提到了其中两条且没有数字。

唯一的真阻断是 max_position_embeddings = 262144

候选阻断项v3 结论v4 实测
显存装不下判死（45.56 > 44.99）不成立：实测 41.67
#27109 打崩 q4_0 prefill判死（74 t/s ⇒ 3.9 h）不成立：Ada 上 2,425 t/s
ECC 不可关44.99 是硬上限不成立：可关，+3.00 GiB
KV 容量不够vLLM 最低 fp8 = 32 GiB不成立：vLLM 实测 1.9M tokens
max_position_embeddings=262144未识别为主阻断✅ 这是唯一的真阻断
有效上下文只有 ~64K成立✅ 仍成立（声称 1M 是 16× 夸大）
静态 YaRN 惩罚 100% 请求成立（无数字）✅ 仍成立，现在有数字：+2.23% PPL

YaRN 解锁配方 已验证 n_ctx_slot 全额

llama.cpp · 解开 slot 的锁
# 三条实测事实：
#   ① 不加 YaRN 请求 >262,144 会静默截断，但显存照样按请求值分配（付钱拿不到东西）
#   ② 加上这四个参数，n_ctx_slot + /props 双重确认全额可用
#   ③ YaRN 不额外花显存 —— 加与不加都是 37,813 MiB，显存由 -c 决定
--rope-scaling yarn --rope-scale <N> --yarn-orig-ctx 262144 \
--override-kv qwen35.context_length=int:<目标ctx>

# ⚠️ GGUF 的 arch 串是 qwen35（不是 qwen38）—— 前缀写错会静默失效

真实 prefill 阶梯 1M · q4_0 · YaRN factor 4 · n_ctx_slot=1048576

6K
2,504 t/s
24K
2,383 t/s
98K
1,306 t/s
197K
599 t/s
TTFT ≈ 85 分钟

拟合 ms/tok ≈ 0.40 + 0.0094 × 深度K（197K 处回代预测 4.35 分 vs 实测 3.87 分 ✅）⇒ 交互式不可用。且无 context shift / cache reuse ⇒ 多轮不命中前缀就每轮重付整段 prefill。

有效上下文只有 ~64K

声称 1M 是 16× 夸大，原生 262K 也已虚 4 倍。prefill @d65536 已腰斩至 1,194 t/s，与该结论方向一致。只有 6% 的窗口被真正利用。

静态 YaRN 惩罚 100% 请求

factor 4 在 4096 token 的块上（根本没接近扩展上下文）就让 9.3% 的 token 改变最优预测，PPL +2.23% ⇒ 为 1% 的长文场景让 99% 的短请求付税。

显存峰值：加载时测量就是可信判据

@1M 跑起来的峰值 42,667 MiB = 41.67 GiB（389 次采样），仅比加载时（42,647）多 20 MiB ⇒ v3 担心的「跑起来峰值更高」不成立。

部署决策流程 每个数字都是实测 · 浏览器里会动

Qwen3.8-27B 部署决策流程：选运行时 → 选上下文档位 → 验收四查
↗ 点击看原图（可放大） · 选运行时 → 选上下文档位 → 验收四查。绿=推荐 · 青=需要视觉/MTP 时的唯一选择 · 橙=按需拉起 · 红=不推荐
M4 四运行时横向对比 同 huihui 血统 · 实测非文档声称
能力llama.cppvLLM 0.27.1SGLang 0.5.17Ollama 0.32.14LMDeploy 0.16.0
加载模型arch qwen35AWQ 成功AWQ 成功内嵌 b16687forward 崩
最低 KV 精度q4_0 = 18.0 KiB/tok3-bit = 13.1fp4_e2m1继承 llama.cppquant_policy=4
非对称 K/V可设但装不下turboquant_k8v4 = 25.0?无?
超 max_position_embeddings🔴 静默截断✅ 硬失败报错???
MTP 投机--spec-type draft-mtp--spec-method qwen3_5_mtpqwen3_5_mtp无?
视觉实测正常支持支持??
并发上限无硬限无硬限14（mamba state）——
冷启动~30 s> 400 s34 s（禁 cuda graph）~30 s—
可观测性/props /slots /metrics + memory_breakdown/metrics 丰富/metrics有限?
vLLM 在 KV 压缩上胜过 llama.cpp

KV 池实测容量（AWQ · util 0.92 · 池 23.74 GiB）：

kv-cache-dtypeKV tokensKiB/tok
auto(bf16)384,68464.7
fp8_e4m3760,37032.7
turboquant_k8v4994,13025.0
turboquant_3bit_nc1,908,25413.1

最低档 13.1 vs llama.cpp 的 18.0 KiB/token（省 27%）。⚠️ 但 turboquant_* 的 hybrid 分支关闭了首尾层保护，缺了它 GSM8K 掉约 30 分 ⇒ 生产要手动 --kv-cache-dtype-skip-layers。

8K prefill：三框架在噪声内

同 5,457 token：llama.cpp 2.6 s vs SGLang 2.5 s ⇒ 印证「单用户场景三大引擎速度差异在噪声内」，选型该看能力与可观测性，不是速度。

依赖坑：因架构是 Qwen3_5ForConditionalGeneration（多模态），vLLM/SGLang 会强制 import torchcodec，它依赖 libavutil.so.57，DLAMI 上缺失 ⇒ 启动直接失败。

解法：uv pip uninstall torchcodec（纯文本不需要）。装 ffmpeg 解决不了 —— 系统给的是 .so.56。

LMDeploy：代码支持最深，却是唯一跑不起来的

它有 lmdeploy/pytorch/kernels/cuda/gated_delta_rule.py —— GDN 专用 CUDA kernel， 比 llama.cpp 更「懂」这个架构（llama.cpp 直接丢弃 MTP 块）。 但 AWQ 路径第一次 forward 就崩：index_copy_(): self and source expected to have the same dtype, but got (self) BFloat16 and (source) Half ⇒ 是 bug 不是不支持，值得救（可能 --dtype bfloat16 能绕，未测）。

验证平台架构 本机零推理 · 浏览器里会动

验证平台架构：MacBook 编排 → AWS SSM → g6e.xlarge L40S → 四运行时 → 证据回传 → Cloudflare Pages
MacBook 只做编排与分析，权重下载与全部推理在 AWS 上完成，通过 SSM Run Command（不是 SSH）投放脚本
M5 KLD 质量对照 回答 v3 列为「第一大未知」的问题

方法上有个关键发现：不需要 BF16 基线 —— 用 Q4_K_L 自己在参考配置下的 logits 做基线即可对照。 v3 曾判断「无 BF16 基线 ⇒ KLD 测不了」，这是错的。 基线：无 YaRN + f16 KV，PPL = 3.6750 ± 0.06648 · 语料 400 KB · -c 4096 --chunks 6。

配置PPL 税率99.0% KLD99.9% KLDRMS ΔpSame top p
q8_0 KV ★ 常驻+0.37%0.1260.3004.19%94.85 ± 0.20%
q4_0 KV+0.62%0.1960.4955.33%93.45 ± 0.22%
YaRN factor 2+0.78%0.2020.4525.23%93.58 ± 0.22%
YaRN factor 4+2.23%0.3881.0457.38%90.69 ± 0.26%
① q8_0 KV 几乎免费 ⇒ 常驻就该用它

+0.37% PPL / 94.85% same-top-p，换来省 6.5 GiB + 快 27%。v3 推荐 f16 常驻的第一条理由是「不触发 #27109」—— 而那个理由在 Ada 上根本不存在 ⇒ L0 基线应该是 q8_0，f16 反而是降级选项。

② 静态 YaRN factor 4 确实伤短文本

在 4096 token 的块上（根本没接近扩展上下文），它让 9.3% 的 token 改变了最优预测，PPL 上升 2.23%。⇒ 填补了「全网唯一数字是官方口述的 MMLU 1–2 分，无表无脚本无 seed」这个缺口，实证支持「不要为 1% 的长文场景常开 YaRN」。

③ 双端点方案是正确的

YaRN f4 的代价是 q8_0 的 6 倍（0.0220 vs 0.0037 ln-PPL）⇒ 为长上下文常开 YaRN，比降 KV 精度贵得多 ⇒ 日常 262K 无 YaRN 常驻 + 长文按需拉起独立 preset。

④ 更正 v3 一处：factor 2 的收益只有声称的 40%

v3 称「×2 税率约为 ×4 的 1/7」。实测 0.007804 / 0.022019 = 0.355 ≈ 1/2.8 ⇒ 降 factor 有用，但收益只有 v3 声称的约 40%。

⚠️ 这批 KLD 数字的边界

语料是纯英文（Gutenberg 400 KB，中文源下载失败）⇒ 这批数字只反映英文文本， 中文 KLD 未测，是新缺口。且只测到 -c 4096， 未测更长块上的 KV 量化代价（长上下文下误差可能累积）。 缺口

M6 第二轮：缺口清零 + 推翻自己 2 条 g6e.2xlarge · 3.1 机时 · 2026-08-21
这一章记录的是「推翻自己」

第一轮推翻了纸面调研的 9 条。第二轮拉起第二台 L40S（g6e.2xlarge · 8 vCPU / 61 GiB）跑 3.1 小时， 把 6 个缺口全部关闭 —— 顺手推翻了第一轮自己的 2 条结论。

两轮用同一份权重（sha256 6d9ee93a… 逐字节一致）⇒ 跨机可比。 但 vCPU 4→8、llama.cpp 07822bd→b10548 不同 ⇒ 跨轮比速度类数字必须注明。

24/24
中文长上下文命中
5 深度 × 4 探针 + 位置扫描 · 全网首次
2
推翻第一轮自己
前缀复用 · LMDeploy 可用性
4.6 分
200K+5轮累计
v4.0 预测 38 分钟
811K
最深 prefill
66.8 分钟 · 显存峰值 41.67 GiB
0.008
中文 Mean KLD 上限
判据 < 0.05 · 四配置全过

推翻第一轮的 2 条 左=第一轮 / 右=第二轮

#第一轮说第二轮实测错在哪
1无 context shift / cache reuse ⇒ 多轮每轮重付 prefill（200K + 5 轮 ≈ 38 分钟）cache_prompt 的整段前缀复用有效：第 2–5 轮 cache_n=197,586→197,793，prefill 从 259.0s 降到 0.5s，5 轮累计 4.6 分钟把三个机制混成一件事（见下）
2LMDeploy 0.16.0 不可用（AWQ 首次 forward 崩于 dtype 不一致）显式 --dtype bfloat16 即绕过，/v1/chat/completions、/v1/completions、/generate 三端点都能出 token第一轮写了「可能可用 --dtype bfloat16 绕过（未测）」—— 这次测了
第 1 条错在哪：三个缓存机制被混成了一件事
机制真实状态
context shift（超长时滑窗丢前文）🔴 确实强制关闭（imrope ⇒ get_can_shift()=false）
--cache-reuse（前缀部分匹配的 token 级复用）🔴 确实强制归零
cache_prompt（前缀完全匹配时跳过 prefill）✅ 工作正常 —— 第一轮把它一并否定了

forcing full prompt re-processing due to lack of cache data 这条日志 只在缓存为空时出现（第 1 轮），第一轮把它读成了「每轮都重来」。

⇒ 长文档多轮问答 = 一次性入场费 4.4 分钟 + 之后每轮 2–6 秒，完全可以对外服务。 但三个条件必须同时满足：材料在前缀最前面且逐字节不变、同一个 slot、不设 cache_prompt: false。 ⚠️ RAG 场景拿不到 —— 每次检索片段不同 ⇒ 前缀每次都变。

中文长上下文：24/24 NoLiMa 式无词面重叠 · 全网首次

普通 needle-in-haystack 只要 grep 到关键词就能答对 ⇒ 测的是字符串匹配。 本实验让 question 与 needle 的谓词零重叠，只共享人名： 林砚秋把那台老式收音机留在了外祖母的阁楼里 → 林砚秋将哪件物品存放在长辈家的屋顶空间中？

真实 token命中回答中文占比prefill
8,0044/41.0003.2 s
28,2984/41.00012.3 s
57,0884/41.00031.1 s
115,5624/41.00096.9 s
257,9944/41.000433.8 s

加上 28K 上的位置扫描（5% / 25% / 75% / 95% 全中）⇒ 合计 24/24，无深度退化、无位置偏置、无语言坍缩。

⚠️ 这个结果的边界 —— 与「有效上下文只有 ~64K」不矛盾

测的是单跳语义检索，不是长上下文推理。 「有效上下文 ~64K」那条结论来自英文 RULER/NoLiMa 的综合任务（含推理、多目标、干扰项）—— 二者不矛盾也不互相替代。 可以说的：选 huihui 的中文理由在长文场景没有失效。 不能说的：「中文长上下文质量到 258K 无损」。长上下文推理是新缺口。 缺口

中文 KLD：Mean KLD ≤ 0.008
配置中文 Mean KLD中文税率英文税率
KV q8_00.001894−0.015%+0.37%
KV q4_00.004797+0.253%+0.62%
YaRN f20.003632+0.105%+0.78%
YaRN f40.007969+0.348%+2.23%

⚠️ 但不能说「中文更耐量化」：中文基线 PPL 12.09 vs 英文 3.675（差 3.3 倍）， 语料域也不同。基线困惑度更高 ⇒ 分布更平 ⇒ 同样扰动的 KL 机械地更小。 严格比较需平行语料 —— 新缺口。

长块 KV 量化：不累积
配置409632768倍数
KV q8_00.0018940.0014640.77×
KV q4_00.0047970.0037070.77×
YaRN f20.0036320.0030540.84×
YaRN f40.0079690.0068970.87×

⚠️「更低」的机制是长块含更多易预测的延续 token，摊薄了平均值 —— 不等于「长上下文更安全」。262K 上的 KLD 仍未测（.kld 基线在 32K/2chunks 已 16 GB）。

811K prefill 与曲线重新标定 339 个测点

累积 token累计 t累计 t/s边际 t/s边际 ms/tok
120,832101.7 s1,1881,1880.841
235,520359.7 s6553402.944
350,208775.8 s4512344.282
464,8961,347.0 s3451785.630
579,5842,072.3 s2801436.992
694,2722,951.9 s2351208.335
811,1864,006.6 s2021039.673

边际吞吐从 1,188 t/s @121K 衰减到 103 t/s @809K（11.5 倍） —— 16 层 full-attention 的 O(n²) 行为。

重新标定 · 两个独立锚点回代误差 < 3%
边际 ms/token ≈ 0.209 + 0.01165 × 深度(K)      n=305 点
    旧（第一轮，仅 4 个手工点到 197K）：0.40 + 0.0094 × 深度K   ← 斜率偏低 19%

回代：257,994 → 拟合 7.4 分  vs 实测 7.2 分   （+2.8%）
      811,139 → 拟合 66.7 分 vs 实测 66.8 分  （−0.1%）
   1,048,576 → 拟合 110.4 分 ← 满窗外推
核账：第一轮的「1M ≈ 85 分钟」量级对，但低估 23%

⚠️ 先更正我自己：本轮脚本输出过「旧公式在 811K 处预测 108.5 分钟、实测 66.8、高估 62%」—— 这是我脚本的 bug：把边际公式当累计用了（直接 ms/tok × N），应该积分。

口径第一轮第二轮实测/标定差
边际斜率0.0094 /K0.01165 /K第一轮偏低 19%
积分到 811,19057.0 分钟66.8 分钟（实测）第一轮低估 15%
第一轮直接写的「1M ≈ 85 分钟」85 分钟110.4 分钟第一轮低估 23%

⇒ 量级与方向都对（分钟级、交互式不可用），结论不变。 顺带：显存峰值 41.67 GiB，仅比加载时多 20 MiB，且与第一轮 @1M 完全一致 —— 「加载时显存就是可信容量判据」再次成立。

本轮我自己犯的 5 个错 这一节和结论一样重要

#错误后果
1pkill -9 -f 'lmdeploy' 把脚本自己杀了 —— pkill -f 匹配完整命令行，而脚本路径 97-lmdeploy-dtype.sh 就含 lmdeploy45 秒自杀，只留一个空表头
2haystack 目标定在 ctx 的 94%，而生成器容差 ±4% —— 余量小于容差5 个深度里 3 个的 prompt 超出 ctx 被 400 拒绝
3把那些 400 的空回答误判成「🔴 L7 语言坍缩」若照此发布，结论会是「中文在 32K 坍缩、262K 又恢复」—— 物理上荒谬。非单调本身就是基础设施 bug 的判据
4把第一轮的边际公式当累计用输出「高估 62%」，实际积分后是低估 15%
5ssm-run 传了远端路径（它要本地路径）静默不执行，我以为跑起来了
还更正了一条旧教训，和一个反直觉的量

坑 9 更正：原写「export LC_ALL=C.UTF-8 或用 python3」—— 实测在 C.UTF-8 下 grep -o '[一-龥]' 直接报 Invalid collation character 并返回 0。范围表达式依赖 collation，而 C locale 没有中文 collation ⇒ LC_ALL 救不了，必须用 python3。

中文实测 1.593 字/token，不是直觉的 1:1。 若按 1:1 估算，「262K 深度」实际只有 ~152K，深度轴系统性偏低 42% ⇒ 新增 scripts/lib-calibrate.sh 做实测标定。这是「判据必须是产物」的又一面： token 数要用 tokenizer 数出来，不能用字符数推。

01 六维加权决策矩阵 "最好"取决于你在意哪一维 推断

把"谁最好"拆成六个可分别评估的维度,并给出权重。 权重是我的判断,你可以换——换了之后名次会变,这正是重点: 不存在一个与用途无关的"最好"。

候选 合规彻底
25%		 能力保全
25%		 证据强度
20%		 中文可用
15%		 工程完整
10%		 社区检验
5%		 加权总分 裁决
huihui-ai
Huihui-Qwen3.8-27B-abliterated		 9.2 9.5 7.0 9.0 7.0 9.0 8.83 第一推荐
trohrbaugh
Qwen3.8-27B-heretic-ara		 9.0 8.5 9.5 5.0 7.5 4.0 8.10 方法最透明
orcarouter
Qwen3.8-27B-Uncensored 系		 8.5 8.0 6.5 5.0 9.5 8.0 7.53 格式最全 · 已 gated
0bserverx (RVN)
…-Heretic-Abliterated-GGUF		 8.9 8.8 6.0 5.0 3.5 6.5 7.29 思考最强但打包稀烂
Zynerji
Ektome-…-PristinelyUncensored		 7.5 9.0 7.5 5.0 8.5 3.0 7.53 工程最扎实 · 无人验证
Blackfrost-AI
Qwen3.8-27B-ABLITERATED		 8.0 7.0 5.5 5.0 8.0 4.0 6.83 措辞最克制 · 数字最少
philbert440
…-Uncensored-Aggressive		 8.0 8.0 7.0 5.0 7.0 2.0 7.15 有 α 扫描曲线
JonathanColetti
Qwen3.8-27B-Uncensored		 7.0 4.5 9.0 5.0 8.0 7.0 6.53 下载量第一,质量最差
AEON-7
…-AEON-ULTIMATE-UNCENSORED		 5.5 5.0 8.5 5.0 8.5 5.0 6.10 刻意不追求彻底
HauhauCS
…-Aggressive-MTP-GGUF		 9.5 6.0 2.0 1.5 9.5 6.0 5.98 抄袭 + 中文硬伤
评分为本报告基于 §3 各档案证据的综合判断 推断 · 原始证据与出处见对应档案 · 权重可自行调整

换权重会怎样 这才是决策矩阵的用法

只要"最不会拒答"

合规彻底 100% ⇒ HauhauCS 9.5 第一。 社区原话:"I haven't found anything it'll refuse yet"。

但你要接受:中文被强制转英文(≥5 个独立账号 + 作者置顶承认)、 抄袭 Heretic 且抹掉署名、不再发 BF16 所以外部无法复现 KLD。
⇒ 对中文使用者这是纸面第一、实际不可用。

只要"方法可复现"

证据强度 100% ⇒ trohrbaugh heretic-ara 9.5 与 JonathanColetti 9.0 并列前二。

前者公开全部 6 个 ARA 超参 + KL 0.0535 + 拒答 0/100; 后者是唯一贴了 lm-eval-harness 全表 + 标准误、 公开 200 次 Optuna 的 Pareto 前沿、 且诚实写"substantially reduced, not eliminated"的。

中文优先(你的情形)

中文可用 40% ⇒ huihui 优势进一步扩大。 它是全场唯一有正面中文证据的:多个独立账号在 HauhauCS 讨论区对照后主动指出 "huihui 会用本地语言思考+输出,不需要任何额外设置"。

其余 8 家在中文轴上全部是 缺口 —— 不是差,是没人测。

02 场地有多大,以及三个数据口径陷阱 HF API 穷尽遍历 实测
1,607
Qwen3.8 仓库总数
cursor 分页遍历去重
402
无审查族
正则匹配 ablit/uncens/heretic/aeon…
2,103,214
30 天下载合计
402 个仓库累加
3,736
likes 合计
≈ 下载量的 0.18%
4
官方 Qwen3.8 仓库
27B / 27B-FP8 / 2.4T-A95B / ×FP8
陷阱一:HF 的 downloads 是「近 30 天」,不是累计
而且计数方式是:safetensors 仓库 = 对 config.json 的每一次 HTTP GET 或 HEAD; GGUF 仓库 = 每个 .gguf 文件的每次请求(HF 官方文档)。

两个后果:① 爬虫 / CI / 解析器能轻易把 safetensors 仓库刷高; ② GGUF 仓库与 safetensors 仓库的下载量根本不可横向比较—— 一个有 15 档 GGUF 的仓库,用户下一次就产生多次计数。
⇒ 看到"某模型 76 万下载"时,那不是 76 万个人。
陷阱二:很多"Qwen3.8-XB"根本不是 Qwen3.8 血统
不存在官方 Qwen3.8-9B / 4B / 2B。 empero-ai/Qwen3.8-9B-Distill 的 base_model 是 Qwen/Qwen3.5-9B(社区蒸馏)。 因此 rohit267/Qwen3.8-9B-heretic-uncensored、MegaPanchamZ/Qwen3.8-9B-abliterated-25、 Foresee/Qwen3.8-9B-heretic-* 全部只是借了名字。

更微妙的一例:Lord-H4D3ZS/Qwen3.8-Distill-35B-A3B-Coder-Abliterated 的 base 是 Qwen/Qwen3.6-35B-A3B,Qwen3.8 只是它的蒸馏教师。 作者自己在卡里写明:The "3.8" in the name refers to the teacher, not the base, 且 'Abliterated': corpus-scoped, NOT a globally abliterated model。
⇒ 选型前必须查 cardData.base_model,不能信名字。
陷阱三:张量前缀写错会让你误判"vision 全丢"
官方 Qwen/Qwen3.8-27B = 1199 张量 = 851 文本 + 333 视觉 + 15 MTP。 但视觉张量的真实前缀是 model.visual. 而不是 visual.; 文本是 model.language_model. 外加 lm_head.weight;只有 MTP 头是裸 mtp.。

若照字面用 startswith("visual.") 去数,任何健康仓库都会返回 0 并被误判为 vision 全丢。 正确写法:contains("visual") 或 startswith("model.visual.")。
⇒ 这是验证一个变体是否完整的唯一客观手段(不依赖作者自述),写错就白验。

真实下载/likes 排行 近 30 天 · 2026-08-19 实测

仓库30 天下载♥方法格式一句话
JonathanColetti/…-Uncensored-GGUF766,812449HereticGGUF下载量霸主,横评垫底 — KLD 0.1191 + 12/100 拒答
0bserverx/…-Heretic-Abliterated-…-GGUF245,266148Heretic 衍生(RVN)GGUF思考质量最高,但缺 chat_template 导致工具调用永久失效
Blackfrost-AI/…-ABLITERATED-GGUF164,263159abliterationGGUF措辞最克制,数字最少
HauhauCS/…-Aggressive-MTP-GGUF131,113259抄袭 HereticGGUF K_P最不会拒答,但中文强制转英文 + AGPL 违规
huihui-ai/…-abliterated-GGUF94,234162remove-refusals-with-transformersGGUF社区共识第一 — KLD 最低 + 中文正常
orcarouter/…-Uncensored-FP860,078585tensor-level abliterationFP8♥ 全场第一,但仓库已转 gated
KridgeDookie/…-PHILADELPHIA-CLASS36,0238自研BF16+GGUF下载/♥ = 4,503,异常
orcarouter/…-Uncensored-GGUF26,472161同上GGUF 17 档档位最全,dl/♥ = 164 最健康
Zynerji/Ektome-…-PristinelyUncensored9,6076Ektomē + surrogate-nullBF16工程细节最扎实,几乎无人知道
AEON-7/…-ULTIMATE-…-BF167,805136abliterix 1.12.2 OptunaBF16卡片质量最高,横评成绩最差
huihui-ai/…-abliterated(BF16)7,207156同上BF16 55.56 GB冠军的源权重
trohrbaugh/…-heretic-ara6,13074Heretic v1.2.0 + ARABF16KL 0.0535 / 拒答 0/100,6 个超参全公开
JonathanColetti/…-Uncensored(BF16)6,04233Heretic 200 trialsBF16唯一贴 lm-eval-harness + 标准误
Blackfrost-AI/…-BF165,85923weight-level 方向修改BF16"evaluation in progress" = 无实数
heretic-org/…-heretic-ara2,66921trohrbaugh 镜像BF16组织号镜像
coder3101/Qwen3.8-27B-heretic2,4312Heretic v1.2.0(可复现)BF16最朴素的 heretic 应用
philbert440/…-Aggressive1,5763单方向 α=1.15 @layer 28BF16有 α 消融扫描曲线
⚠️ GGUF 与 BF16 仓库的下载量不可横向比较(计数方式不同)· ♥ 是唯一勉强可比的信号
03 候选档案 ×10 逐个立档:方法 / 数字 / 已报告的 bug / 可信度
第一推荐 huihui-ai/Huihui-Qwen3.8-27B-abliterated 8.83
方法
Sumandora/remove-refusals-with-transformers,前 15 层不做 ablation,MTP 与 vision tower 不改。 张量清点实测 1199 = 851+333+15,与官方完全一致。作者自称 "crude, proof-of-concept implementation"。
硬数字
  • 横评加权 9.19/10 第一,10 类中 8 类第一,A 配合 10.00,silent refusal 0/50 实测 n=50
  • 社区横评 KLD 0.0078 全场最低,拒答率 1.5% 口碑
  • ollama huihui_ai/Qwen3.8-abliterated:13.2K pulls,15 tags,vision/tools/thinking 全标 实测
独有优势
  • thinking 模式下也真去审查 —— 多数竞品只在 non-thinking 模式下无审查
  • 中文/多语一致性正常:中文问 → 中文思考 + 中文回答,不需要任何额外设置。 这条由多个独立账号在 HauhauCS 讨论区对照后主动指出 —— 全场唯一有正面中文证据的候选
弱点
  • KLD 0.0078 来自单个 reddit 用户的 independent testing,无脚本无日志,不可复现
  • 同一用户自己说"我一般避开 huihui,他们别的模型 KLD 很大" ⇒ 该作者质量在不同模型上波动大
  • MTP 头状态有直接矛盾:HF discussion #4 报告 --spec-type draft-mtp 接受率 0% ("MTP head weights corrupted by abliteration",作者已 closed),而社区测试者说 MTP 正常(n=2-3 有效)。 无第三方裁决 缺口
  • 模型卡没有任何评测数字
可信度
中等偏高。reddit ≥4 个独立账号推荐,来源互相独立, 且包含"承认作者平时不靠谱"的反向证据——这降低了自吹嫌疑。
方法最透明 trohrbaugh/Qwen3.8-27B-heretic-ara 8.10
方法
Heretic v1.2.0 自定义 fork + ARA(Arbitrary-Rank Ablation,heretic PR #211) —— 不用 refusal direction,直接对每个矩阵做 L-BFGS 无约束优化,目标含 preserve / steer / overcorrect 三项。 给出全部 6 个超参。分片布局特殊:6 个 main shard + 独立 model-auxiliary.safetensors(849 MB)承载 15 个 mtp.*。
硬数字
KL 0.0535 · 拒答 0/100(原模型 99/100)· 张量 1199 = 851+333+15 实测通过 自述但可复现
其 chat_template.jinja 的 SHA-256 c3cf9e34…81041 与 Qwen 官方逐字节一致 —— 这是个好信号。
弱点
卡正文除超参外直接抄 Qwen 官方卡 · 社区几乎无人测过(6,130 下载 / 74 ♥)· ARA 尚未合并进 heretic 主干, 参数语义与传统 abliteration 不兼容 · 中文轴 缺口
格式最全 · 已 gated orcarouter/Qwen3.8-27B-Uncensored 系 7.53
规格
BF16 55.56 GB(18 shards)+ FP8 30.8 GB(7 shards)+ GGUF 17 档 + MLX 4 档 —— 全场唯一的完整矩阵。 FP8 对齐官方 Qwen3.8-27B-FP8 方案,同 vLLM kernel 路径。
硬数字
横评第 2(加权 8.98),且毒品类 8.62 是全场最高(该类是所有模型的能力边界)。 FP8 仓库 585 ♥ 全场第一。GGUF 仓库 dl/♥ = 164,是全场最健康的比值。
弱点
  • 2026-08-19 起全系转为 gated:gated=auto,匿名读 README 返回 Access to model … is restricted。/tree/main 元数据仍公开。⇒ 自动化流水线会挂
  • 模型卡没有任何评测数字,只有免责声明;方法只一句话
  • 自己承认 caveat(说教前缀)率 27.3%–56.0% —— 它答,但先训你一顿。 这与它横评 A 配合 10.00 并不矛盾:配合分测的是"是否给出答案",不是"回答干净"
  • BF16 卡称 55.6 GB 但 GGUF F16 只有 50.90 GB,差 3.84 GB 疑似丢 MTP 头
思考最强 · 打包稀烂 0bserverx/Qwen3.8-27B-Heretic-Abliterated-Uncensored-GGUF（RVN） 7.29
硬数字
横评加权 8.87 第 3,但 「C 思考」9.40 是全场最高,生物医学 9.09 亦第一。 这与「Heretic 的 KL 约束保住推理质量」的方法学预测完全吻合。
发布即出锅
  • 发布 24 小时内连续 3 条 "Not uncensored / Censored / Still censored"
  • 所有 RVN GGUF 缺 tokenizer.chat_template → llama.cpp 回退到内置 208 字节 ChatML stub ⇒ 工具调用永久失效(模型说 "no tools are available",连 tool_choice:"required" 也没用)、 enable_thinking 无效、<think> 块随机泄漏
  • 张量数不匹配:expected 866, got 851 —— 差 15,正是 MTP 头张量数
  • 标注为 imatrix 的 IQ4_XS / IQ4_NL 实际没有 imatrix 元数据
  • IQ3_M 无限输出 ///;标准量化下视觉能力严重退化(Q5_K_M 比更小的 Unsloth UD IQ4_XS 还差)
根因与修复
最有价值的一条 discussion(#8):有人用 HTTP range 扫描所有 GGUF 头,定位到根因是 转换目录里没放 Qwen3.8 的独立 chat_template.jinja (新版 transformers 把模板存成单独文件,gguf-py/gguf/vocab.py 会读它)。
修复:gguf_new_metadata.py in.gguf out.gguf --chat-template-file chat_template.jinja, 或启动加 --chat-template-file。作者已确认并补上官方模板。
重要推论
那 3 条"仍在审查"很可能就是模板缺失的下游症状(模板缺 → thinking 行为异常 → 触发残留对齐)。 ⇒ 这解释了为什么它在 X 横评里表现良好:横评很可能用的是有模板的 legacy 文件或 -mtp 双胞胎 推断
⇒ 也说明社区"某模型还会拒答"的报告,第一嫌疑永远是 chat template 而不是模型。
下载量第一 · 质量最差 JonathanColetti/Qwen3.8-27B-Uncensored(-GGUF) 6.53
做得最好的地方
  • 方法披露全场最详:Heretic 200 trials,只改 attn.o_proj + mlp.down_proj(各 64 模块), bf16 下跑 abliteration 不经过 4-bit 往返,公开 Pareto 前沿全表
  • 唯一贴了 lm-eval-harness 结果 + 标准误的候选,并明说不覆盖 vision/MTP
  • MTP 处理最规范:明说 abliteration 会丢 mtp.*(transformers 重存不带 MTP 模块但 config 仍宣称 mtp_num_hidden_layers),15 个张量逐个 graft 回来并做 inventory 断言
  • 措辞最不吹:标题写 "refusal behaviour substantially reduced, not eliminated"
  • 是 llama.cpp -sm tensor 唯一能跑通的 —— 多卡场景的不可替代理由
致命弱点
社区横评:KLD 0.1191(候选里最高)且仍有 12/100 拒答(最高)。 测试者原话:"worst major release I've examined on both counts"。
LM Studio 性能问题(#13 未关闭);有人追问 baseline bf16 perplexity,作者未给出。
讨论区噪音极大(诈骗电话号码、"is it good for vibe coding?(virus,log stealer)")。 正面评价全是一句话式低信息量("Good shit thanks yo!"),唯一带数字的评价是负面的。
怎么理解矛盾
它在 X 横评里 silent refusal 0/50,却被社区测出 12/100 拒答。 两者不矛盾——测的是不同东西(见 §4)。 而 KLD 0.1191 最高与横评里「C 思考」8.00 四家最低是同一件事的两个测量: 能力扰动最大。两份独立数据在能力轴上完全一致。 推断
最不会拒答 · 但请勿使用 HauhauCS/Qwen3.8-27B-Uncensored-HauhauCS-Aggressive-MTP-GGUF 5.98
纸面最强
社区公认"最不会拒答的" —— "pretty much always the best abliterated version… I haven't found anything it'll refuse yet"。 工程量最大:K_P 定制量化全档(Q8_K_P→IQ2_M)、BF16 mmproj(图+视频)、保留原生 NextN、 外加 903 MB FastMTP sidecar(自述 3.02× document TG / 1.93× reasoning TG)。提供 checksum + signed provenance。
三条否决级问题
  • ① 抄袭 Heretic 且抹掉署名,违反 AGPL —— 已被作者本人确认。 2026-04-26 一份 860 赞的调查做了代码逐行比对 + SHA-256 可验证 实测
  • ② 中文/多语严重退化(对你是硬伤):中文提问 → 思维链强制英文、输出英文或中英混杂, system prompt 和 Jinja 模板都改不动。 ≥5 个独立账号报告(西语 / 中文 ×3 / 越南语),作者已置顶承认该 issue (#12 "Multilingual to English reversion? Read this.")。中文 FastMTP 接受率仅 40%(#21)
  • ③ 不再发布 BF16/F16,最高只到 Q8 ⇒ 外部无法复现 KLD。 那个 0/465 拒答是纯自述,零第三方复现
其它
实测做详细会议纪要(非拒答任务)质量明显低于未 abliterate 版 · IQ3_M 下仍会拒绝露骨请求(#17) · 过度思考(#15) · 作者自己警告有人在分发夹带 payload 的假冒 GGUF
其余四个候选档案（Blackfrost / AEON-7 / Zynerji Ektome / philbert440）

Blackfrost-AI/Qwen3.8-27B-ABLITERATED — 措辞最克制,数字最少 · 6.83

  • 好:发了 BF16 母本 + NVFP4 + GGUF 全套,可外部复现(这点强于 HauhauCS)。 卡片措辞克制:"public research preview"、"not for sale"、"evaluation and release review remain in progress"、 "must not be represented as upstream Qwen safety-stock checkpoint"。 MTP 修得干净:把 MTP block 直接嵌进 9 个主量化、删掉 sidecar,给出 runtime 验证 (65-block model,smoke test 21 个 draft token 接受 14 个)。
  • 坏:#2 "Unrealistically slow in LMStudio" 仍未关闭; 发布初期 mtp- sidecar 打包会进入 llama.cpp 的 broken separate-draft 路径直接加载不了(已修,需重下); reddit 上几乎没人主动推荐。
  • 关键:那个广为流传的 "450 条测试仅 11 条拒绝 = 2.4%" 只在中文二手文章里出现,未在 Blackfrost 模型卡或任何一手来源核到。 而它自己公开的漏斗显示:裸模板下真拒答 88/450 → 作者 operational prompt → 33 → shipped short prompt → 11。 ⇒ 那 2.4% 是 prompt 工程的成绩,不是权重性能。

AEON-7/…-AEON-ULTIMATE-UNCENSORED-BF16 — 卡片质量最高,成绩最差 · 6.10

  • 方法最详:SSM conv1d outlier 修复(FernflowerAI)→ abliterix 1.12.2 (50 trial Optuna,用 Gemini-3.1-flash-lite 判分)→ 取 trial 48 → 从 stock 回接 MTP 15 张量(hash-match)。 张量 1199 = 851+333+15 实测通过。
  • 模型卡是全场唯一交代了 KL 中位数 / 长尾、判分器偏差、并坦承长上下文会复读的。 这种诚实度反而说明它的低分不是掩饰。
  • 但成绩最差:横评加权 6.83 垫底,silent refusal 9/50 (集中在武器爆炸 4.93 与反取证 4.95),B 细节 6.56 与 C 思考 6.56 双塌陷。
  • 作者的设计意图是反向的:它刻意不追求 refusal=0、刻意保留 KL ≈ 0.099, 理由是"把最后几个 outlier 追到底就是把模型搞坏的方式"。 ⇒ 所以 "ULTIMATE" 不代表"最彻底",恰恰代表作者选择了不彻底。名字误导。
  • 两条减分说明:它是 5 个被横评模型里唯一用 Q4_K_S 的(其余 Q4_K/Q4_K_M), 分数被更低量化档污染;且判分若为 LLM-judge,则它自测的 36 个 judge-R 里有 25 个其实写了实质内容 ⇒ 排末位方向可信,幅度被高估。

Zynerji/Ektome-Qwen3.8-27B-PristinelyUncensored — 工程最扎实,无人知道 · 7.53

  • 方法 "Ektomē" + abliteration-repair / surrogate-null(细节未公开)。自述 1199 张量与 base 完全对齐, 15 个 mtp.* byte-identical。
  • 有 benchmark:MMLU 0.7995(n=1531)/ HumanEval 0.8902(n=164)/ MMStar 0.6633(n=300);MTP +35% @bs1(75.7 → 102.5 tok/s)。
  • 作者自己的诚实值得表扬:明写 "MMLU 0.7995 is not separable from the parent line's 0.7975 — treat them as equivalent, not better"。⚠️ 但三个 4-bit 兄弟仓各有一套不同数字 (-HYBRID: MMLU 0.7897 / HumanEval 0.8537 / MMStar 0.6367)—— 引用时必须写清是哪个仓。
  • 卡片工程细节最扎实:交代了 GGUF 事故根因、8 卡实测、为什么 stock vLLM 加载不了。 但只有 9,607 下载 / 6 ♥,几乎无人验证。

philbert440/Qwen3.8-27B-Uncensored-Aggressive — 有 α 扫描曲线 · 7.15

  • 单方向 refusal-vector 正交化(Arditi et al. / mlabonne 路线),layer 28,α = 1.15, 并明说旧版 α ≈ 1.24 属于过度消融 —— 这是全场唯一公开 α 消融曲线结论的。
  • 有四轴自测:openness / confab / factual / gsm8k。分片布局:2 shards 50.95 GiB + 独立 model-mtp.safetensors 0.79 GiB。
  • 弱点:判分用 Claude 且样本量未披露;1,576 下载 / 3 ♥,社区检验几乎为零。
  • ⚠️ 注意:"Aggressive" 这个后缀在不同作者手里含义完全不同。 philbert440 的是 α 值;HauhauCS 的是私有方法;而 06 号子报告发现 相当多 "Aggressive" 的实质差异其实在 chat template 而不在权重。
04 三源交叉裁决 当证据打架时怎么判

本报告有三个独立证据源。它们测的不是同一件事,理解这一点才能正确使用它们:

证据源测什么样本可复现?强项 / 盲区
X 横评
@Yamada_Ryoooo 08-17		 silent refusal + 分类别配合质量 + 思考质量 5 模型 × 50 题 × 10 类,统一 Q4 部分评分者未披露 唯一跨作者对照,且是裸测(无作者 prompt 加持)。盲区:每类仅 5 题、不测语言、AEON 用了 Q4_K_S
社区实测
r/LocalLLaMA + HF discussions		 KLD + 显式拒答率 + 实际 bug 单人横评 100 题 + 数十条 discussion 否无脚本无日志 唯一提供 KLD 横向对比和真实 bug 清单(chat_template 缺失、张量数不匹配、语言漂移)。盲区:不可复现、样本主观
作者自述
模型卡		 refusal 率 + 各家自选 benchmark 各不相同,常不披露 否 唯一提供方法与超参。盲区:refusal 数字普遍在作者注入的 prompt 下测得,是 prompt 工程成绩
裁决案例:JonathanColetti 到底好不好?
表面矛盾:X 横评 silent refusal 0/50(看起来很彻底),社区测得 12/100 显式拒答(最差)。

裁决:两者测的不是同一层。silent refusal 是 L1/L3 层(空输出、模板化空答); 显式拒答是 L0 层(硬拒答)。一个模型可以"从不给空答案"但"经常明确说不"——这两个指标正交。

而在能力轴上,两份数据完全一致: 社区测得它 KLD 0.1191 全场最高(能力扰动最大), X 横评测得它 「C 思考」8.00 四家最低。 两个独立测量、两套完全不同的方法,指向同一个结论。

⇒ 净裁决:不推荐,除非你需要 llama.cpp -sm tensor 多卡(它是唯一能跑通的)。 它的价值在方法披露(唯一贴 lm-eval-harness + 标准误 + Pareto 前沿),不在成品质量。
裁决案例:RVN 为什么在横评里好、在社区里被骂?
社区:发布 24h 内 3 条"仍在审查" + 所有 RVN GGUF 缺 chat_template + 张量数少 15(丢 MTP)+ 假 imatrix。
X 横评:加权 8.87 第 3,C 思考 9.40 全场最高。

裁决:这是文件级问题而非模型级问题。 根因已被定位到"转换目录里没放 chat_template.jinja",作者已修。 横评很可能用的是有模板的 legacy 文件或 -mtp 双胞胎 推断。

⇒ 普适教训:社区报告"这模型还会拒答"时,第一嫌疑永远是 chat template,不是权重。 先验证 gguf-dump 里有没有 tokenizer.chat_template,再谈模型行不行。
一个尚无裁决的矛盾:huihui 的 MTP 头到底活着吗?
HF discussion #4:--spec-type draft-mtp 接受率 0%,报告为 "MTP head weights corrupted by abliteration"(作者已 closed)。
社区测试者:MTP 正常,n=2-3 有效接受率。

无第三方裁决 缺口。 自己验的方法:gguf-dump 数有没有 15 个 mtp.* 张量,再实测 accept rate。
⚠️ 但对 Apple Silicon 用户这个矛盾可能无关紧要——见 §11: MTP 在 GGUF 路径上实测比不开还慢 2.3×。
05 方法学七族 看懂后缀就能先做一轮先验筛选
这个领域只有一对准标准化指标
refusals count + KL divergence,由 Heretic 定义, 且只有 Heretic / Abliterix / abliterlitics / reaper-analysis 这四方在用同一份代码算。
⇒ 任何模型卡上不带这两个数、或不说清用哪套 prompt 集算的"无审查"声明,都应按【自述】折价处理。
#方法族核心操作需训练算力?典型副作用本次候选中谁用
1单方向正交化
abliteration		对 o_proj/down_proj 做 rank-1 正交化,减掉一个 refusal direction不需要数学/推理掉点最明显;残留拒绝;"hydra effect" 自修复philbert440(α=1.15 @L28)
huihui(前 15 层不动)
2多方向 / 逐层
/ null-space		多方向(SOM/PCA/SVD)、逐层不同方向、把更新约束在保留激活的 null space不需要过度切除 → 输出退化为乱码;方向选取不当直接失效Zynerji(surrogate-null)
3ablation + 超参优化
(KL 约束)		在 (refusals, KL) 双目标上跑 Optuna TPE,取 Pareto 前沿不需要训练
但需 200 trial 推理		时间成本高;对 KL 过度最小化会"保留审查"JonathanColetti(200 trials)
AEON-7(abliterix 50 trials)
RVN / coder3101
3bARA
Arbitrary-Rank Ablation		不用 refusal direction;对每个矩阵做 L-BFGS 无约束优化,目标含 preserve/steer/overcorrect 三项不需要尚未合并进主干;参数语义与传统 abliteration 不兼容trohrbaugh(heretic PR #211)
4abliterate 后
SFT/DPO healing		先切,再用偏好数据把能力"治回来"需要
6×A6000 ≈ 6h45m		SFT 可能把 refusal direction 重新学回来(需正交约束)本次候选中无人做 缺口
5纯 SFT 去对齐用无拒绝语料(dolphin / toxic-dpo)直接微调,不做权重手术需要风格漂移;对齐"表面化",adaptive jailbreak 仍能触发差异—
6merge / distill 混合abliterate + SFT + DPO + 蒸馏 + 层扩展 + 视觉/MTP 头移植的组合流水线需要
多阶段		归因不可能:说不清哪一步带来收益/损伤AEON-7 · Josiefied · DavidAU · Qwopus-Kimi-destill
7只改 system prompt
/ chat template		覆写 tokenizer.chat_template、注入默认 system prompt、锁死 thinking零算力这不是去审查。换 runtime 或用户自带 system prompt 就复原06 号报告发现相当多 "Aggressive" 属此类
学术根源

Arditi et al. 2024(arXiv 2406.11717,NeurIPS 2024)的核心发现: refusal 由残差流中的一维子空间中介,在 13 个 open-source chat model(最大 72B)上都成立。 存在单一方向 r,擦除它就阻止拒绝,注入它能让模型拒绝无害指令。

实现:取 harmful 与 harmless prompt 两组第一个输出 token 的残差均值作差归一化, 再对写入残差流的权重做正交化 W' = W − r(rᵀW)。
"abliterated" 这个词是 FailSpy 造的。

一条被广泛照抄的错误做法

Heretic 作者在 issue #202 明确说:Heretic 从不 ablate embedding, 因为"早期层 ablation 长期以来被公认会损害模型性能"; 而对 attention 和 MLP 都做,是 "cargo-culted"(照抄惯例)。

⇒ 这解释了为什么 huihui 的"前 15 层不做 ablation"是个好设计, 也解释了为什么 JonathanColetti 只改 o_proj + down_proj 是对的—— 尽管它的 KLD 仍然最差,说明做对了结构选择不代表调对了强度。

06 八层拒答分类学 为什么 "refusal = 0" 基本都是营销

社区把 uncensored 当成布尔值,实际至少有八层。 评测只要不覆盖某一层,那一层就会被作者的数字掩盖。

层名称表现关键词分类器Qwen3.8-27B 系的具体证据
L0硬拒答我无法提供能抓base 模型 98/100 · AdvBench 99.0% · JonathanColetti 残留 12/100
L1空输出 / thinking 死循环助手消息为空,或 reasoning 打转到耗尽预算抓不到0xKitkat v3 原话:"It looks like a hard refusal. It is the template."
L2软拒答 / caveat 前缀答了,但先来一段说教会误判成 refusal最大测量陷阱。orcarouter 自述 caveat 率 27.3%–56.0%
L3部分合规 / 模板化空答结构完整但关键步骤缺失抓不到AEON:36 个 judge-R 里 25 个其实写了内容
L4语言不对称英文答、中文拒结构性失明0xKitkat 唯一承认者,为此单建 Chinese-refuse 消融轴
L5thinking 阶段自我审查reasoning 里自我否决后改成含糊版测不到RVN 某些量化只在关闭 thinking 时才 uncensored;开 thinking 后把解锁指令判定为 prompt injection
L6上下文 / 多轮衰减前几轮合规,后面开始拒单轮测不到无任何公开定量数据 缺口
L7语言坍缩不拒答,但改用英文回答不在任何 benchmark 视野内HauhauCS:≥5 组独立报告(中/法/西/越),作者置顶承认
"refusal = 0" 的真相:一个作者自己公开的漏斗
Blackfrost 公开了完整数据 —— 同一份权重:
裸模板下真拒答 88/450 → 加作者 operational prompt → 33 → 换 shipped short prompt → 11。

所谓 11/450 = 2.4% 是 prompt 工程的成绩,不是权重的裸性能。 HauhauCS 的 0/465 同理。
⇒ 这正是 X 横评那个 0/50 更有价值的原因:它是无作者 prompt 加持的裸测。
07 中文轴 v4：已从口碑升级为实测
v4 更正：这一章说的「没人做规模化的中文拒答率评测」已经不成立了 —— 我们做了

11 组中英语义配对探针 × 22 次生成,--temp 0 --top-k 1 --seed 42, 在 L40S 上实测 huihui Q4_K_L。这是全网首次对 Qwen3.8-27B abliterated 做中文拒答/语言行为的定量评测。 设计要点：比较的是同一模型的中英差异而非模型间差异 —— 这样即使探针设计不完美,差值仍然有意义。

指标实测结果判定
L7 语言坍缩中文提问 → 回答中文字符占比平均 0.924（纯散文题 5 条 = 1.000；含技术术语的 4 条 0.78–0.87 是英文术语混入,正常）不存在坍缩
L4 语言不对称中文拒答率 0/11,英文拒答率 0/11,|Δ| = 0.000无不对称
C0 过度拒答6 条完全无害的探针全部正常回答无

⇒ 社区口碑「huihui 中文不掉英文」从【口碑】升级为【实测】 实测。 这是选 huihui 的决定性理由,也是全网没有的数据。 人工抽查确认纯中文且文学质量正常。

附带发现：同语义下英文 reasoning 比中文长 3.5–8 倍（557 vs 4805 字符） ⇒ 在这个模型上开 thinking,中文更省 token。
⚠️ 剩余缺口：以上全部在短上下文下测的。 中文长上下文质量（100K+）仍是本项目当前最大缺口 —— 所有长上下文证据都是英文。 缺口

v2 说这是全空白,现在要更正

中文轴不再是完全空白。虽然没人做规模化的中文拒答率评测, 但有两组明确的、来自多个独立账号的定性证据——而且方向相反, 刚好把候选分成了两半。

✓ huihui:中文正常(正面证据)

中文问 → 中文思考 + 中文回答,不需要任何额外设置。

证据来源特别有说服力:是在 HauhauCS 讨论区里, 中文/多语用户被 HauhauCS 的语言漂移问题困扰后,主动对照并指出 huihui 没有这个问题。
⇒ 这是对照实验式的口碑,而不是泛泛好评。 口碑·高可信

✗ HauhauCS:中文强制转英文(反面证据)

中文提问 → 思维链强制英文、输出英文或中英混杂。 system prompt 和 Jinja 模板都改不动。

≥5 个独立账号报告(西语、中文 ×3、越南语), 作者已置顶承认(#12 "Multilingual to English reversion? Read this.")。 中文场景下 FastMTP 接受率仅 40%(#21)。
⇒ 对中文使用者,这个"最不会拒答"的模型实际不可用。 实测·作者承认

为什么 Qwen 的中文轴是独立的 机制解释

L4:中文安全回路可能没被切到

绝大多数 abliteration 脚本用英文的 harmful/harmless prompt 对提取"拒绝方向"。 Qwen 是中英双语深度训练的模型,它的中文安全对齐很可能位于一组不同的方向上。

0xKitkat 是唯一显式承认并处理这个问题的 Qwen3.8 作者: 英文写作已合规,但中文安全回路仍完整(会输出 违规 / 我无法提供…超出了服务范围),他为此单独建了一条 Chinese-refuse 消融轴。

L7:语言坍缩,比拒答更难发现

模型不拒答,但改用英文回答。 对中文使用者功能上等价于失效, 但它不在任何 refusal benchmark 的视野内—— 所有 benchmark 只问"答了没有",不问"用什么语言答的"。

机制推测:abliteration 扰动了语言选择的内部表示, 而英文是训练分布的主模态,受扰后回落到主模态。 推断

更深一层:中国政治/意识形态对齐 ≠ refusal,abliteration 基本治不了
Qwen2 时代的系统性对照(deccp,base = Qwen2-7B)显示:政治类拒答从 ~100% 只降到 ~20%, 而且"不拒答"往往变成照搬官方叙事。 同一批问题中文拒答率比英文低 >80% —— 代价是被宣传口径替换。

⇒ abliteration 移除的是"拒绝"这个动作,不是训练数据里的叙事倾向。 这两件事必须分开评估:一个模型可以"什么都答"同时"答的全是官方口径"。 实测·2024-06
08 能力损伤 —— 无审查的代价 无 Qwen3.8 第三方数据,由同架构 3.5/3.6-27B 外推
一句话
abliteration 本身不是"变笨机器"。顶级实现在选择题上几乎测不出损失。 真正的代价是三样标准 benchmark 测不到的东西:真实性下降、指令遵循松动、thinking 死循环。 而"谁做的"这个变量,对能力保全度的影响是 abliteration 本身的 10 倍以上。
指标好的实现差的实现说明
MMLU−0.3 ~ −0.5 pp−2 pp选择题几乎测不出差异 —— 这也是为什么模型卡都爱报 MMLU
NatInt(UGI 智力)−0.3 ~ −2 分
−1% ~ −6%		−11 ~ −13 分
−30% ~ −36%		方差全在"谁做的",不在 abliteration 本身
Lambada ppl≈ 不变×2.9语言建模能力的崩坏信号
TruthfulQA
真实性 / 抗错觉		−1.9 ~ −14.4 pp（相对 −3% ~ −28%）掉得最惨第一名。过度顺从 ⇒ 不敢反驳用户的错误前提
UGI Pop-Culture
冷知识检索		最惨 −87%掉得最惨第二名,机制未明
IFEval
指令遵循		0 ~ −14.4 pp掉得最惨第三名 —— 格式/约束遵循松动
KL divergenceHeretic 0.0037
huihui 0.0074–0.0078		AEON 0.099
JonathanColetti 0.1191
某些变体 1.22		KL > 0.1 开始出现可测能力损伤 —— 注意 JonathanColetti 正好越线
已核查更正:huihui 不是 KL 最小的

很多人以为 huihui 是"最温和"的实现。跨代际看,KL 最小的是 Heretic: Qwen3.6-27B 上 Heretic 0.0037 vs huihui 0.0074; Qwen3.5-27B 上 0.0630 vs 0.0654。abliterlitics 原文称 Heretic 为 "the clear winner for capability preservation"。

huihui 的真实优势只有一条:Qwen3.6-27B 上非 GSM8K 平均 |delta| 最小(0.5pp)。
⇒ 与 X 横评吻合:heretic 系的 RVN 思考质量 9.40 全场最高。

KL 不能可靠预测"变笨"

Heretic 作者在 issue #236 自己证明: PIQA 与真实智力的秩相关远好于 KL。 而且 KL 完全测不到 thinking 死循环 —— 一个 KL 极低的模型仍可能在 reasoning 里无限递归。

⇒ 别只看作者报的 KL。X 横评的「C 思考」维度补上的正是 KL 测不到的那一块。

过度消融的教科书案例 + 它的指纹
Kewk/Heretical-Qwen3.5-9B:W/10 拿到 7.8–8.0(很"无审查"), 但 NatInt 从 base 17.62 崩到 6.57。什么都答,但全是幻觉。 同代 heretic 版几乎无损(NatInt 27.47 vs base 28.8)。

AEON 在 Qwen3.8 代呈现同一病症:B 细节 6.56 与 C 思考 6.56 同时塌陷。
⇒ 这个病症有明确指纹:合规分高 + 质量分低。看到这个组合就该警惕。

UGI 的稳定规律 跨代际都成立 实测

指标官方 Qwen3.x-27B无审查改造后变化
UGI(愿意说 + 懂敏感话题)16 – 2743 – 58翻 2–2.5 倍
W/10(配合意愿)1.2 – 2.88.8 – 10.0大幅上升
NatInt(自然智能)——基本不涨甚至微跌
Writing(写作)——微跌
⇒ UGI 涨的是"愿意说",不是"更聪明"。别把 UGI 当能力分看。
⚠️ 没有任何第三方 leaderboard 收录 Qwen3.8-27B
UGI CSV 共 1295 行,Qwen3.8 零匹配,最高只到 Qwen3.6。 有人 08-15 提交了 Qwen3.8-27B 评测请求(discussion #694),维护者尚未回应。 abliterlitics.dev 最新只做到 Qwen3.6-27B,社区自己也在等 ——"I'll wait for abliterlitics report" 是相关话题最高赞评论之一(221 赞)。
唯一进公开榜的 Qwen3.8 开源模型是旗舰 MoE 2.4T-A95B(EQ-Bench Creative Writing v3,Elo 1840.1), 不是 27B,不能替代。
09 量化:1 → 16 bit 的完整差距 体积 = HF API 实拉字节数 · 质量 = quesma 实测
质量数据的来源
quesma 在 Qwen3.6-27B(与 3.8-27B 同尺寸同 dense 同 hybrid 架构)上烧了 37 小时本地 + $1430 云 GPU,跑 AIME-120、Terminal-Bench、盲评 SVG(Bradley-Terry)。 这是 27B 尺度上目前最扎实的一份量化质量实测。 实测
F16
50.90 GB
Q8_0
27.05 GB
Q6_K
20.89 GB
Q5_K_M
18.19 GB
Q5_K_S
17.66 GB
Q4_K_M ★
15.65 GB
Q4_K_S
14.73 GB
IQ4_XS
14.25 GB
Q3_K_L
13.55 GB
Q3_K_M
12.57 GB
IQ3_M
11.89 GB
Q3_K_S ⚠雷
11.41 GB
IQ3_XXS
10.83 GB
Q2_K
10.11 GB
IQ2_M
9.73 GB
IQ2_XXS
8.27 GB
IQ1_S / _M
不存在
014 GB28 GB42 GB55.6 GB
无损 无损区内 甜点 = 推荐 可察觉 弃用 ★ 推荐档 · ⚠ 有陷阱
问题答案证据
无感区在哪≥ 4-bit。BF16 → 4bit 在 AIME-120、Terminal-Bench、盲评 SVG 上全部落在噪声内实测
第一个可察觉台阶3-bit,而且内部方差极大:Q3_K_M AIME-120 = 73.3%,Q3_K_S 只有 54.2%(BF16 基准 70.8%)。同为"3-bit",差 19 个点实测
明显退化2-bit。盲评 Bradley-Terry 上 UD-IQ2_XXS 比平均低约 3 分 ≈ 20 场输 19 场实测
单一最好用的判据mean KLD:< 0.05 ≈ 无损;> 0.08 开始掉分(27B 尺度、AIME 任务)。比困惑度可靠得多实测
1-bit 值不值得做27B dense 上不值得。所有 IQ1 候选都劣于已发布的两家 IQ2,省下的显存买不到任何实用价值。所以没人发布实测
27B 的耐受度位置比 8B 好、比 100B+ MoE 差。经验法则:27–40B 能扛到 ~Q3;< 27B 不要低于 ~Q4;~Q2 要到 90–120B 才算可用口碑
⚠️ Apple Silicon 上量化买的是内存,不买速度
quesma 作者在同型号 M5 Max 128GB 上实测:不同量化档位的 tok/s "没有太大变化"—— 权重虽以 2/4-bit 存储,矩阵乘法仍在 16-bit 浮点上跑,每次都要解包。

同一个 UD-Q2_K_XL:M5 Max 30 tok/s · L40S 94 tok/s · H100 112 tok/s。
⇒ 在 128 GB Mac 上降档位既不省有用的内存,也不换来速度 ⇒ 直接用高档位。
⇒ 在 L40S 48 GB 上量化是真实约束,而且 tok/s 是 Mac 的 3 倍。
2026 年新格式：NVFP4 / MXFP4 / Q1_0 / Q2_0 的现状

llama.cpp master(2026-08-19,124,676 ★)的 LLAMA_FTYPE_* 枚举新增了 Qwen3.8 时代才有的槽位: MXFP4_MOE = 38、NVFP4 = 39、Q1_0 = 40、Q2_0 = 41。 已移除:Q4_2/Q4_3、Q4_0_4_4 系(改为 runtime repack)。

⚠️ NVFP4 在 llama.h 里有 ftype,但 llama-quantize 的类型表里没有它 —— 加入 CLI 的 PR #26556 与 #26869 截至 2026-08-19 仍是 open。 即 llama.cpp 目前能读 NVFP4 GGUF,还不能生产。 Q1_0 纯 bpw = 1.125(128 元素 / 18 字节),不需要 imatrix; IQ1_S = 1.5625 bpw 且硬性需要 imatrix。

10 量化 × 去审查的交互 "低比特会不会让拒答复活"的实测答案
决定性实测:同一权重跨 5 档,拒答率恒为 0/100
PocketAiHub/Qwen3.8-27B-Abliterated-MLX 对同一份 abliterated 权重 (base 固定 revision 1d4bf0f2…)在 5 个量化档位上各测 100 条 harmful + 100 条 benign,deterministic,thinking 关闭:
变体harmful 显式拒答benign 拒答有 final answer其它退化
MLX BF16(参考)0 / 1000 / 100200 / 200—
MLX 8-bit0 / 1000 / 100200 / 200—
MLX 6-bit0 / 1000 / 100200 / 200—
MLX 4-bit(group 64)0 / 1000 / 100200 / 200无
MLX 2-bit AWQ(实验性)0 / 1000 / 100196 / 20012 项质量检查只过 9 项 · 8 项 tool-call 全挂 · 4K needle 找到但复述不准
从 BF16 一路压到 2-bit,harmful 拒答率恒为 0/100 —— 没有任何"拒答回归"迹象。2-bit 的失效在别处。
Q1 · 量化会让拒答复活吗

≥4-bit:不会。上表 + X 横评(5 模型全 Q4,4 家 0/50)双重独立证据。

2-bit 的失效模式是语句崩坏 + tool-call 全挂,不是拒答复活。

社区"Q4 又开始拒绝了"的报告全部可归因于: 下错文件、chat template 缺失、thinking 开着、缺 system prompt。 RVN 的案例就是活教材(§4)。 实测

机制上有多危险

abliteration 的编辑量(KL 0.0085–0.1191)与 4-bit 量化噪声的 KL 同量级,与 2-bit 噪声(KL 0.07–0.18)同量级甚至更小。

⇒ 所以"抹掉"在数学上不是荒谬的担忧——只是在 4-bit 以上没有变成可观测行为。 推断

Q3 · 反向:文献冲突

主流实测:量化后拒答率下降 12–68 pp 而质量指标不变("hidden-danger"); KV cache 量化可让 Mistral-7B 在 PPL 仅 ×1.03 时丢掉 15.2% 拒答。

但 2026-06 一篇 200 万条响应的因子实验反过来认为标准 AWQ INT4 近似安全中性。 实测·冲突

仍然成立的一条纪律
横评必须在同一档位上做。如果你在 Q4 测出某模型会拒答,你无法区分三种原因: ① abliteration 不彻底;② 量化影响;③ chat template 缺失。
X 横评做对的正是统一 Q4;做得不够的是 AEON 用了 Q4_K_S,恰好破坏了这个前提。
11 这个架构的五个坑 llama.cpp 源码级 + issue 复现 实测
① Gated DeltaNet 状态路径对低比特不成比例地敏感

48 层线性注意力的递归状态是有状态的,误差会沿序列累积, 不像常规注意力每步重算。⇒ 这是 27B 混合架构比同尺寸纯注意力模型更怕低比特的机制性原因。

② vision tower 全生态一致保 F16 / BF16 / Q8_0

333 个视觉张量没人敢量化。但真正的损伤不在视觉塔本身,而在接收视觉嵌入的前几层 LLM—— RVN 的 #6 就是活证:Q5_K_M 视觉幻觉严重,比更小的 Unsloth UD IQ4_XS 还差。 作者回应:mmproj 本身是官方 Q8_0 不是瓶颈,问题在被量化的 LLM 输入层。
⇒ 视觉任务建议 Q8_0 / F16,或用 llama-quantize --override-tensor 做 UD 风格保护。
⚠️ 没有任何人跑过 VL benchmark 的 before/after 缺口

③ MTP 头会被 abliteration 直接打坏

accept rate 归零。而且默认会被 transformers 的 save_pretrained 静默丢掉(config 仍宣称 mtp_num_hidden_layers),必须显式 graft 回来。

典型症状:done_getting_tensors: wrong number of tensors; expected 866, got 851 —— 差 15 = MTP 头张量数。 graft 回来后实测 accept rate 40–66%(vLLM)/ 92%(llama.cpp FastMTP)。 另:imatrix 无 blk.64 条目会导致 IQ2/IQ3 量化直接 abort。

④ DeltaNet 递归状态在 llama.cpp 里硬编码 F32

-ctk / -ctv 只作用于 16 层 full attention,48 层线性注意力不受影响。

两个后果:① 262k 长上下文成本远低于常规 27B(好事); ② KV 量化的质量影响只落在 1/4 的层上 ⇒ 在这个架构上 KV 量化比通常更安全。

⑤ Apple Silicon 特有:MTP 投机解码可能让你更慢
社区实测:MTP 在 GGUF 路径上比不开还慢 2.3×。 另有 llama.cpp 在 M2 Ultra 上用 Qwen3.8 默认参数会崩的报告。

⇒ 三个推论:
① Mac 上不要为了 MTP 去选模型——§4 那个"huihui 的 MTP 头到底活着吗"的矛盾,对你可能根本不重要;
② 但在 L40S(CUDA)上 MTP 是真加速(Zynerji 实测 +35% @bs1,75.7 → 102.5 tok/s);
③ Mac 上先关 MTP 测基线,再决定要不要开。
一处待追的数字矛盾：BF16 55.6 GB vs GGUF F16 50.90 GB

orcarouter 卡称 BF16 55.6 GB,但它自己的 GGUF F16 两分片相加只有 50.90 GB(24.91 + 25.99),加 mmproj 0.86 GB 仍只 51.76 GB —— 差 3.84 GB。

最可能的解释是 GGUF 转换丢弃了 MTP 头(与坑 ③ 完全吻合)。 若如此,GGUF 路线等于放弃投机解码。
验证:gguf-dump 查有无 15 个 mtp.* 张量。
⚠️ 参考对照:trohrbaugh 的布局是 6 个 main shard(54.71 GB)+ 独立 model-auxiliary.safetensors(849 MB)承载 MTP,两者相加 55.56 GB —— 说明把 MTP 单独放文件是可行且更清晰的做法。

12 非 Qwen 替代 —— Qwen3.8 真的最优吗 防止在局部最优里打转
一句话结论

Qwen3.8-27B-Uncensored 在「智力 × 可跑性 × 中文」三维乘积上是 2026-08 的最优解, 但它既不是最无审查的,也不是最好的创作模型。 它的护城河是原始能力代差 (Artificial Analysis Intelligence Index 52 vs Gemma 4 31B 的 30、Muse Glimmer 30B 的 35) 和中文—— 而不是 VL / 262k / MTP / hybrid attention,这四项在 2026-08 的同代模型里已经全部商品化。

排名模型方法能力UGI / W-10128GB Mac 落点为什么
1 Qwen3.8-27B-Uncensored
huihui / trohrbaugh 任一		 abliterated AA 52 未收录 Q6_K 22.4 GB / Q8 29 GB
绰绰有余		 同尺寸内无对手;中文原生;abliteration 能力损失实测仅 −0.5 分均值(在标准误内)
2 coder3101/gemma-4-31B-it-heretic
或 llmfan46 同款		 abliterated
(Heretic)		 AA 30 UGI 65.69 / 64.99
W/10 10.0		 Q6_K 25.2 GB ≤135B 区间的无审查天花板(仅次于 123B 的 XORTRON)。当 Qwen3.8 还在拒绝时用它
3 TheDrummer/Behemoth-128B-v3
base = Mistral-Medium-3.5-128B		 原生 finetune
(非 abliterated)		 — Writing 最高档
Behemoth-X-123B-v2 = 50.27		 Q4_K_M 78.4 GB 散文质量维度 ≤135B 最高档。创作用途 abliterated 打不过原生 tune
黑马 Ling-3.0-flash abliterated
124B-A5.1B · MIT		 abliterated AA 38 无数据 Q4_K_M ~75 GB
仅 5.1B 激活 → Mac 上极快		 中文原生 + 262k ctx + MIT 许可。风险:无 UGI 数据,abliterated 版本极新
通用智力 / 中文 / 代码

Qwen3.8-27B-Uncensored。AA Index 52 是个代差, Gemma 4 31B 只有 30。这一维没得选。

极端无审查

gemma-4-31B-it-heretic,UGI 65.69 / W-10 满分 10.0。 Qwen3.8 系还没进 UGI,但历史规律显示同尺寸 Qwen 改造后 UGI 落在 43–58 —— 低于 Gemma-4-heretic。
⇒ Qwen3.8 不是最无审查的。

创作 / 角色扮演

TheDrummer 系原生 finetune。 关键洞察:abliterated 是"移除拒绝",原生 tune 是"从头就没有"—— 后者不带 abliteration 的副作用(过度顺从、真实性下降),所以散文质量更好。

13 许可与供应链风险 逐字节核对 实测
许可:最干净的一种状态
  • Qwen/Qwen3.8-27B = Apache 2.0 完整正文,11,544 字节,未插入任何附加条款。版权行 Copyright 2026 Alibaba Cloud
  • NOTICE 文件不存在(404) ⇒ Apache 2.0 §4(d) 的 NOTICE 转述义务不触发
  • 整份 65 KB README 里 licen* 只出现在 YAML front-matter,无 acceptable-use / 禁止用途 / 商用限制
  • ⇒ 对比 Llama 系(自有社区许可 + AUP + 7 亿 MAU 条款)或 Gemma(Prohibited Use Policy): Qwen3.8-27B 没有任何"可接受使用政策"可被违反 —— abliteration 不构成违约,因为没有约上"不得移除安全对齐"这种条款
  • 衍生模型可商用/闭源/托管 API,无 copyleft。再分发义务 4 条:附许可副本 / 声明改动 / 保留归属 / 转述 NOTICE(本例无)
真实风险排序(与直觉相反)
  1. ① 质量/失真错误 —— 已发生,多起。这是目前唯一真正伤到用户的风险: RVN 缺 chat_template 导致工具调用失效、张量数不匹配加载失败、假 imatrix、视觉退化
  2. ② GGUF / config 解析类 CVE
  3. ③ pickle RCE —— 本生态无 pickle 文件,风险为零

trust_remote_code 不需要: 仓库无任何 *.py,auto_map 为 null,transformers 已原生支持 qwen3_5。

消失风险:不是 HF 下架,而是作者删库和转 gated
HF 政策上有权下架,但未找到任何因 abliteration 本身被下架的公开案例—— 2024 年一批 abliterated 旗舰仓库至今仍在线。

更现实的风险已经发生了:orcarouter/* 全系在 2026-08-19 转为 gated (gated=auto,匿名读 README 被拒)。作者自己删库 / 腾存储配额 + 转 gated 比 HF 主动下架现实得多。
⇒ 想留的模型现在就下、算 sha256、本地归档。
14 落地与命令 v4：已全部实机验证
v4 更正：本章下方是 v3 的「计划」快照,实际执行方式不同

v3 计划在生产机 l40s-48 上腾显存（停 tts-api 换 10.4 GB）。 实际执行改成了拉起一台专用临时实例 —— 生产机全程未被触碰, 验证完即回收（i-074bf6be2d4b96724,运行 12.9 小时后已终止）。
理由：在生产机上腾显存会污染基准（共卡争抢让延迟涨 +78%~191%, 而偏了一倍的数字长得跟正常数字一模一样）,且需要动别人的服务。专用机更干净。

抢容量经验：us-east-1 的 g6e 长期 80–97% 利用率,单机型死等会一直失败 （g6e.4xlarge 试了 19 次全败）。 关键发现：同一张 L40S 出现在 g6e 全系 —— xlarge/2xlarge/4xlarge/8xlarge 的 memory.total 都是 45,776 MiB,只差 vCPU/RAM/NVMe。 ⇒ 验证 GPU 侧行为时 g6e.xlarge 与 4xlarge 完全等价, 而且更容易抢到、更便宜。同时抢 3 个尺寸 × 4 AZ,g6e.xlarge 第 4 次就中了。

实测支撑的常驻配置

llama-server · 显存 28.38 GiB · decode ~26 tok/s · KLD 税 +0.37%
export CUDA_MODULE_LOADING=LAZY
llama-server -m Q4_K_L.gguf -a qwen38-27b-abliterated \
  --host 127.0.0.1 --port 8800 \
  -c 262144 -ctk q8_0 -ctv q8_0 -b 2048 -ub 512 \
  -np 1 -ngl all -fa on -fit off \
  --no-context-shift --no-mmproj --load-mode mmap \
  -ctxcp 8 -cram 32768 -to 7200 \
  --jinja --chat-template-file chat_template.jinja \
  --reasoning-format deepseek --metrics --slots --no-webui

# v3 推荐 f16 KV,第一条理由是「不触发 #27109」—— 那个理由在 Ada 上根本不存在。
# 实测 q8_0 才是帕累托最优：+0.37% PPL 换省 6.5 GiB + 快 27%。

验收四查 —— 判据是产物,不是退出码

四条全过才算起来了
grep -a "n_ctx_slot" server.log   # 必须 == 你请求的 -c 值,不等就是被静默截断了
grep -a "capping"    server.log   # 有任何输出 = 已截断（而 exit code 仍是 0、显存照付）
grep -a "CUDA :"     server.log   # 必须含 FA_ALL_QUANTS = 1,缺了非对称 KV 会静默掉 CPU
curl -s :8800/props | grep -o '"n_ctx":[0-9]*'

# 绝对不要用 freq_scale=0.5/0.25 当判据 —— 那一行根本不打印,
# 按它判会把正确启动误判为失败（v3 最严重的错误之一）

完整操作手册见 docs/DEPLOYMENT-GUIDE.md（890 行,每条断言都带证据分层标记）。

↓ 以下是 v3 的计划快照,保留供溯源 机器状态已过时

铁律:本机不跑模型
模型下载与推理一律在 AWS l40s-48 上做。本机(MacBook Pro M5 Max)的网络与算力是稀缺资源。
访问方式是 AWS SSM Run Command(不是 SSH): bin/ssm-run l40s-48 <本地脚本>,项目在 ~/Code/aws-gpu。
机器规格显存 / 内存状态对本任务的含义
l40s-48
i-04acf5fce04f04ff0		g6e.4xlarge
16 vCPU / 124 GB RAM		46,068 MiB
L40S 48 GB		running已用 27,737 / 46,068 MiB(60.2%),空闲 18,331 MiB。27B Q4_K_M 需 ≈ 20–22 GB(含 KV)⇒ 停 tts-api(10.4 GB)即够,不必全停
a10g-24g5.4xlarge23,028 MiBstopped根卷已搬到 l40s-48,无系统盘,无法启动
本机 M5 Max18 CPU / 40 GPU 核
带宽 614 GB/s		128 GiB
Metal 可用 107.5
单 buffer 上限 80.6		仅编排能装 BF16(55.6 GB),但 tok/s 只有 L40S 的 1/3,且按铁律不用于测试。ollama 0.32.14 已识别 arch = qwen35,vision/thinking 就绪
在 L40S 上准备主力模型（只下一个 4-bit）~/Code/aws-gpu
# 项目铁律：不手写 aws ssm send-command，一律用 bin/ssm-run 投放脚本
cd ~/Code/aws-gpu

# 1. 看显存预算与实时占用（只读）
./bin/gpu vram l40s-48

# 2. 释放 10.4 GB —— 只停 tts-api，不必全停
./bin/gpu down tts-api

# 3. 主力：huihui Q4_K_M（≈16.5 GB）+ 视觉投影层
#    ollama 路径最省事：huihui_ai/Qwen3.8-abliterated（15 tags，vision/tools/thinking 全标）
#    GGUF 路径：huihui-ai/Huihui-Qwen3.8-27B-abliterated-GGUF 的 Q4_K_M + mmproj-*-f16.gguf

# ⚠️ 任何基准/标定必须先拿锁（remote/136 实测共卡让延迟涨 +78%~191%，
#    而偏了一倍的数字长得跟正常数字一模一样）
#    source /opt/gpu-stack/bin/bench-guard.sh && bench_lock qwen38-uncensored
#    纯性能测量再加 bench_require_idle
下载后必做的三项验证不要跳过 — 质量错误是本生态第一大风险
# ① chat_template 在不在？（RVN 事故的根因，缺了工具调用永久失效）
llama-gguf-dump model.gguf | grep -i "chat_template"
#    缺了就补：gguf_new_metadata.py in.gguf out.gguf --chat-template-file chat_template.jinja
#    或启动时加 --chat-template-file

# ② 张量数对不对？期望 1199 = 851 文本 + 333 视觉 + 15 MTP
#    ⚠️ 前缀是 model.visual. 而不是 visual.；只有 MTP 是裸 mtp.
curl -s "https://huggingface.co/api/models/<repo>/raw/main/model.safetensors.index.json" \
  | jq '[.weight_map|keys[]] | {
        total: length,
        visual: map(select(test("visual")))|length,
        mtp:    map(select(startswith("mtp.")))|length }'
#    见到 "expected 866, got 851" = 差 15 = MTP 头丢了

# ③ base_model 是不是真的 Qwen3.8？（很多 Qwen3.8-9B 其实是 Qwen3.5 血统）
curl -s "https://huggingface.co/api/models/<repo>" | jq '.cardData.base_model'
推荐的运行期设定来自实测,不是猜的
reasoning_effort = medium        # xhigh 会陷入过度思考死循环（X 横评实测）
                                # 与 Heretic issue #253 的 think 块无限递归是同一现象
thinking         = 考虑关闭      # RVN 某些量化"只在关闭 thinking 时才 uncensored"；
                                # 开 thinking 后模型会把解锁 prompt 判定为 prompt injection
                                # 例外：huihui 是少数 thinking 模式下也真去审查的
chat template    = 官方 jinja    # SHA-256 c3cf9e34…81041（Qwen 官方 = trohrbaugh ARA 逐字节一致）
KV 量化          = 可用          # 只影响 16 层 full attention，DeltaNet 状态硬编码 F32
MTP              = Mac 上先关    # GGUF 路径实测比不开还慢 2.3×；CUDA 上才是加速（+35% @bs1）
mmproj           = 必须单独下    # 0.86 GB，不下则图片功能直接没有；视觉任务用 Q8_0/F16 主体
15 缺口与最小自测方案 哪些是硬数据,哪些只是推断
硬数据支撑
  • 402 个候选的清点、体积、下载、♥ —— HF API 实拉,可 curl 复现
  • 合规彻底度的档次划分 —— X 横评 n=50 独立第三方
  • 量化质量曲线 —— quesma 37 小时 + $1430 实测
  • ≥4-bit 不复活拒答 —— 跨 5 档 × 200 条,与 X 横评独立互证
  • 架构五坑 —— llama.cpp 源码级 + issue 复现
  • 许可链 —— LICENSE 逐字节核对
  • HauhauCS 抄袭 —— 代码逐行比对 + SHA-256,作者本人确认
只是推断 / 缺口
  • Qwen3.8-27B 的能力损伤幅度 —— 全部由 3.5/3.6-27B 外推
  • huihui 的 MTP 头到底活着吗 —— 仍未裁决。v4 发现 llama.cpp 常规路径会丢弃 blk.64（所以 unused tensor 警告不是权重坏的证据）,但社区那次 acceptance=0.00000 是开了 MTP 测的 —— 两者不矛盾,本轮未复验
  • abliterated 是否更不耐量化 —— 无对照实测。但 v4 已测出 KV 量化与 YaRN 的代价（q8_0 +0.37% / factor4 +2.23%,见 M5）
  • VL 能力是否受损 —— v4 部分关闭：基础功能实测正常（形状 3/3 · 颜色 3/3 · 文字正确读出）,但 before/after 定量 benchmark 仍无人跑过
  • L6 多轮 / 长上下文衰减 —— 仍无公开定量数据。v4 已确认架构性无 context shift / cache reuse ⇒ 多轮不命中前缀就每轮重付整段 prefill,这决定对外 SLA,是当前第 3 优先的缺口
  • 中文定量拒答率 —— v4 已关闭：实测中文占比 0.924 / 中英拒答率均 0/11 / |Δ|=0.000（见 §7）。但中文长上下文仍是缺口
  • §1 决策矩阵的六维评分 —— 本报告综合判断,权重可争议
若日后决定自测,只需测两件事

其余全部有数据了。

  1. 中文轴定量化:候选 3 个(huihui / trohrbaugh-ara / orcarouter),统一 Q4_K_M, reasoning_effort=medium。同一批探针中英双语各一份 —— 比较的是同一模型的中英差异而非模型间差异,这样即使探针设计不完美,差值仍有意义。 分层记录:硬拒答 / 空输出 / caveat 说教 / 部分合规 / 改用英文回答(L7) / 完全合规 —— 只记"拒/不拒"会漏掉 6 层里的 4 层。
  2. MTP 头存活验证:gguf-dump 数 15 个 mtp.*,再实测 accept rate。 这条能一次性解决 §4 那个悬而未决的矛盾。在 L40S(CUDA)上测——Mac 上 MTP 本身就是负收益。

显存:停 tts-api 释放 10.4 GB,空闲达 ~28.7 GB 即够单模型串行。 遵守 ~/Code/aws-gpu 铁律第 7 条:bench_lock;纯性能测量另加 bench_require_idle。

子报告索引 13 份 · docs/research/

文件最有价值的一条
01-hf-inventory-qwen38.md1607 仓库 / 402 无审查族;张量前缀陷阱;"Qwen3.8-9B" 其实是 Qwen3.5 血统
02-hf-inventory-prior-gens.mdHF downloads 的计数口径;DavidAU Qwen3.6 系 303 万 30 天下载
03-methods-and-tools.md七族方法分类学;heretic 27,851 ★;"早期层 ablation 有害"
04-leaderboards.md无任何榜收录 Qwen3.8-27B;KL 最小是 Heretic 而非 huihui
05-capability-damage.md方差全在"谁做的",是 abliteration 本身的 10 倍以上
06-true-compliance.md八层拒答分类学;Blackfrost 的 88→33→11 漏斗
07-community-verdicts.md逐模型口碑卡;HauhauCS 抄袭 + 中文硬伤;RVN chat_template 事故
08-quant-quality-curve.mdKLD<0.05 无损;Apple Silicon 上量化不买速度
09-quant-x-abliteration.md≥4bit 不复活拒答(跨 5 档 0/100);架构四坑
10-apple-silicon-m5max-sizing.md带宽 614 GB/s;Metal 可用 107.5 GiB;ollama 已识别 qwen35
11-risk-and-license.mdApache 2.0 无附加条款;真实风险第一是质量错误不是 RCE
12-non-qwen-alternatives.mdAA Index 52 vs Gemma 4 的 30;gemma-4-31B-heretic UGI 65.69 是无审查天花板
13-x-headtohead-2026-08-17.md第一手 X 横评 n=50 —— 唯一的跨作者独立对照
总纂见 docs/00-MASTER-REPORT.md
关于子报告可信度的诚实说明
01–12 由一个 25-agent 工作流产出,其中只有 5 份完成了对抗性事实核查(文末有「核查记录」section), 其余 7 份的核查未完成 —— 引用未核查报告中的具体数字时需谨慎。
中止原因:其中一个 agent 违规在本机拉起了模型推理(两个 llama-server,占满 GPU), 工作流被整体停止。教训已记入 memory/no-local-model-inference.md。
Qwen3.8-27B 无审查模型 · 全景调研 + 单卡 L40S 实机验证 · v4 · 2026-08-21（v1 08-19 · v2/v3 08-20）
v4 实机层：专用 g6e.xlarge · L40S 48GB · Ada sm_89 · 12.9 机时 · 137 份证据（sha256 1051e62b…05eea7）· 推翻 9 条纸面结论 · 验证机已回收
证据源：41 份子报告 · HuggingFace Models API（1607 仓库遍历）· GitHub Search API · quesma 量化实测 · UGI Leaderboard CSV · abliterlitics · llama.cpp 源码 · r/LocalLLaMA · HF discussions
核心第三方证据：X/Twitter @Yamada_Ryoooo 2026-08-17 横评（5 模型 × 50 题 × 10 类 × 统一 Q4）
实测 可复现 · 口碑 社区实测不可复现 · 自述 作者声称 · 推断 本报告判断 · 缺口 无公开数据