heterodoxin/AbliteratedOutTheBox

这是 llama.cpp 的推理时拒答移除分支，更适合已经熟悉 GGUF 转换和模型服务的人。README 对机制和实测取舍写得异常具体；真正的问题不是它在作者测试的三款模型上是否有效，而是它的判定门在你自己的提示和硬件上表现如何。

解决什么问题

用户手里有一个本地模型，希望它对原本会被安全对齐拒答的提示作出回答，同时不想重新训练，也不想保存第二份权重。直接把拒答方向烘焙进权重的做法会修改磁盘上的权重，每个提示都面对一个被改过的模型，而且依赖针对具体架构的手术。这里的流程接近普通 llama.cpp：把 Hugging Face 模型转成 GGUF，再用 llama-abliterate 带上提示启动。运行时逐条提示决定是否从激活里移除拒答方向，磁盘上的模型文件不被改写，普通提示还能共用同一份权重。

有什么不同

编辑方向从提示本身读出来。对每条提示，运行时强制模型以几种“配合”和“拒答”开头生成，对比激活差异得到拒答方向，再单独处理安全免责声明方向。判定门会先让模型自己生成最多 24 个 token，当中层平均后的拒答投影峰值超过 --ff-threshold 时触发。编辑是在 build_cvec 的层输出位置做尺度无关的投影，165 个架构里有 131 个共用这个位置，所以一套配方覆盖多个模型家族，不需要逐架构写代码。

作者在 Qwen3-8B 上的数据最清楚：在宽泛的留出有害提示上拒答率从 96.3% 降到 7.9%，在 JailbreakBench 上从 82.0% 降到 0.0%；判定门在 alpaca 提示上有 0.4% 触发（256 条中 1 条），未触发时作者称输出与基座逐位相同。同一配方据称可用于 Llama-3.1-8B 和 Gemma-4-e4b。代价在免责声明一侧：调高 --disc-strength 会去掉更多套话，但也可能让较长输出退化；保持连贯的回答其 distinct-token 比例仍低于基座（约 0.65 对 0.84）。由于判定门标量按上下文保存，运行时一次只处理一条序列。这些都是作者在三款模型上的数字，不是独立复现。

谁值得试

适合：已经在跑 llama.cpp，想在自己已有的模型和硬件上研究或演示拒答行为如何体现在激活里、又如何被改动的开发者。纯 CPU 可跑这一点在这里有意义，因为方向计算发生在提示预填充阶段，不需要训练。不适合：期待一个面向多并发用户、通用绕过安全限制的服务的人；一次一条序列的判定门和固定的强制开头集合都限制了这种用法。如果只是为单一任务找一个无审查模型，预烘焙的检查点可能更省事，但本项目不必额外维护一份权重文件。

使用条件与边界

安装假设你按 llama.cpp 的方式用 C++ 构建，选择 CUDA、HIP 或纯 CPU 后端；只有在把 Hugging Face 检查点转成 GGUF 时才需要带 torch、transformers 和 gguf 的 Python。工具说明见 tools/abliterate 文档，当前参数以项目 README 为准。如果手上已有 GGUF 模型，可以跳过 Python 转换这一步。

持续使用中的约束比安装更重要：判定门阈值在有害提示召回（默认 0.70 时约 0.89）和误触发（约 0.4%）之间取舍，这两个数都来自作者的 Qwen3-8B 测试集。方向取自固定的开头集合，非常规提示可能判定或编辑效果更差。作者称解码吞吐不变，但触发的提示要多做一次预填充；免责声明强度调高也可能让长输出退化。项目没有报告这三款家族之外模型的评测，所以架构覆盖范围需要在自己的检查点上验证，不能当作保证。

HotRepo 点评

HotRepo 在 2026-10-24 首次记录时项目只有 3 天；2026-10-25 的新项目榜（cpp）单次快照显示共 104 星、#18。这不是单日新增星数，已存覆盖也只有这一个日期，因此还无法判断热度能否持续。采用前值得先确认你的目标架构在覆盖范围内，并用一批自己的普通提示观察判定门；文档里的误触发率只针对报告中的那几款模型。