개요
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
FAQ (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")은 디바이스에서 residual-writer 가중치의 약 3배까지 피크가 치솟아, 모델 자체는 올라가는데도 24GB 환경에서 7B bf16 모델이 OOM됩니다. 원인은 두 가지입니다: (1) 커밋이 이루어지기 전에 모든 투영된 o_proj/down_proj 업데이트가 updates 리스트에 먼저 계산되므로, 편집 대상인 모든 writer의 전체 복사본이 GPU에 한꺼번에 올라갑니다; (2) LogicalParameterTransaction.commit이 각 롤백 스냅샷을 GPU에 parameter.data.detach().clone()으로 저장하므로, 호출이 반환될 때까지 모든 원본 writer가 GPU에 상주합니다. 우회 방법: 한 번에 전부 적용하는 대신 레이어 청크 단위로 나누어 intervention을 적용하세요. 예를 들어 layers=[...]를 사용해 4개 레이어씩 묶어 반복 호출합니다. 이렇게 하면 24GB 카드에서도 여유롭게 동작하지만, 전체 편집에 대한 all-or-nothing 롤백 계약은 포기하게 된다는 점에 유의하세요(각 청크가 독립적으로 커밋됩니다). 검토 중인 장기적 수정 방안: 롤백 스냅샷을 CPU(또는 설정 가능한 디바이스)에 보관하거나, 타깃별로 compute-and-commit을 수행해 한 번에 하나의 투영 복사본만 존재하도록 하면서 all-or-nothing 롤백은 유지하는 방식입니다.
문제 해결UI 모델 리로드 실패로 인해 부분적인 모델/stale 세션 상태가 남거나 GPU 메모리 제한을 우회하는 문제를 해결하는 방법?
이 문제는 PR #246에서 수정되었습니다. 해당 수정이 포함된 릴리스로 업데이트하세요. app.py의 모든 직접 UI 로드/리로드(채팅 lazy reload, load_bench_into_chat에서의 세션 전환, A/B 비교, 실행 후 채팅 리로드 포함)는 이제 obliteratus/ui_model_load.py의 하나의 보호된 로드 경로를 통해 이루어집니다. 로드 설정이 보호된 섹션 내부로 이동했으므로, 로더가 실패할 경우 오래된 상태를 남기는 대신 부분적인 모델 및 세션 상태를 완전히 정리합니다. UI 리로드도 CLI/pipeline 경로와 동일한 공유 load-admission 함수와 메모리 한계를 사용하므로, UI가 파이프라인에서 거부될 로드를 수락하는 것을 방지합니다. 이전 버전에서는 로드 실패 후 UI 프로세스를 재시작하고, 엄격한 메모리 admission이 필요한 경우 CLI/pipeline 경로를 사용하세요.