项目简介
OBLITERATUS 通过消融技术定位并移除大模型内部与拒答相关的方向，无需重训练。提供探测、提取、干预和分析模块，以及 Gradio 界面。每次运行可匿名贡献数据，支持社区研究。
README 预览
\n O B L I T E R A T U S\n\n\n\n Break the chains. Free the mind. Keep the brain.\n\n\n\n \n \n \n \n \n \n \n\n\n\n Try it now on HuggingFace Spaces — runs on ZeroGPU, free daily quota with HF Pro. No setup, no install, just obliterate.\n\n\n---\n\n**OBLITERATUS** is the most advanced open-source toolkit for understanding and removing refusal behaviors from large language models — and every single run makes it smarter. It implements abliteration — a family of techniques that identify and surgically remove the internal representations responsible for content refusal, without retraining or fine-tuning. The result: a model that responds to all prompts without artificial gatekeeping, while preserving its core language capabilities.\n\nBut OBLITERATUS is more than a tool — **it's a distributed research experiment.** Every time you obliterate a model with telemetry enabled, your run contributes anonymous benchmark data to a growing, crowd-sourced dataset that powers the next generation of abliteration research. Refusal directions across architectures. Hardware-specific performance profiles. Method comparisons at scale no single lab could achieve. **You're not just using a tool — you're co-authoring the science.**\n\nThe toolkit provides a complete pipeline: from probing a model's hidden states to locate refusal directions, through multiple extraction strategies (PCA, mean-difference, sparse autoencoder decomposition, and whitened SVD), to the actual intervention — zeroing out or steering away from those directions at inference time. Every step is observable. You can visualize where refusal lives across layers, measure how entangled it is with general capabilities, and quantify the tradeoff between compliance and coherence before committing to any modification.\n\nOBLITERATUS ships with a full Gradio-based interface on HuggingFace Spaces, so you don't need to write a single line of code to obliterate a model, benchmark it against baselines, or chat wit
常见问题 (3)
故障排除如何修复大张量（如 Qwen2.5 嵌入）导致的 SnapshotError："snapshot tensor exceeds admitted staging memory"？
出现此问题的原因是 DiskSnapshot 会预留 max(tensor_bytes) * 6 + overlay_bytes，而旧的固定默认值 SnapshotConfig.staging_bytes 为 1 GiB。因此，即使主机内存可用，大于约 179 MB 的张量也可能超出预算。
临时解决方法：将显式暂存上限提高到至少 6 * largest_tensor_bytes + overlay_bytes，并确保有足够的空闲内存。对于约 467 MB 的张量，至少使用 3 GiB；4 GiB 是更稳妥的起点：
from obliteratus.config import SnapshotConfig
config = SnapshotConfig(staging_bytes=4 * 1024**3)永久修复：升级到包含基于主机内存的默认值的版本。在该版本中，staging_bytes=None 会从 available_host_bytes() 推导默认预算，而显式设置的 staging_bytes 仍是硬性上限。拒绝消息会报告所需字节数、已接纳字节数以及需要调大的配置项。
故障排除如何修复在 24GB GPU 上对 7B 模型的所有层进行正交化时出现的 CUDA out of memory 错误？
apply_concept_intervention(mode="orthogonalize", layers="all") 在设备上的峰值显存占用约为残差写入器权重的 3 倍，因此即使模型本身可以放下，在 24GB 显存上运行 7B bf16 模型时也会 OOM（显存溢出）。有两个原因：(1) 每个投影后的 o_proj/down_proj 更新在任何提交（commit）之前都会被计算并存入 updates 列表，从而在 GPU 上同时持有所有被编辑写入器的完整副本；(2) LogicalParameterTransaction.commit 将每个回滚快照以 parameter.data.detach().clone() 的形式存储在 GPU 上，因此每个原始写入器都会一直驻留在显存中，直到调用返回。变通方案：按层分块应用干预，而不是一次性全部应用，例如以每组 4 层的方式用 layers=[...] 反复调用。这样可以在 24GB 显卡上轻松容纳，但请注意，这会放弃整个编辑过程中全有或全无（all-or-nothing）的回滚契约（每个块独立提交）。正在考虑的长期修复方案：将回滚快照保存在 CPU（或可配置的设备）上，或者按目标逐个计算并提交，使同一时间只存在一个投影副本，同时保留全有或全无的回滚能力。
故障排除如何修复 UI 模型重新加载失败导致残留部分模型/过期会话状态或绕过 GPU 内存限制的问题？
此问题已通过 PR #246 修复。请更新到包含该修复的版本。app.py 中所有直接的 UI 加载/重载——包括聊天惰性重载、load_bench_into_chat 中的会话切换、A/B 对比以及运行结束后的聊天重载——现在都统一经过 obliteratus/ui_model_load.py 中的一条受保护加载路径。加载设置已移入受保护区域内，因此当加载器失败时，会完全清理已部分加载的模型和会话状态，而不会留下残留状态。UI 重载还使用与 CLI/pipeline 路径相同的共享加载准入函数和内存限制，防止 UI 接受 pipeline 会拒绝的加载。在旧版本中，加载失败后请重启 UI 进程，并在需要严格内存准入时使用 CLI/pipeline 路径。