概要
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 になる。原因は2つある。(1) 射影されたすべての o_proj/down_proj 更新がコミット前に updates リストに計算されるため、編集対象の全 writer の完全なコピーが GPU 上に一度に保持される。(2) LogicalParameterTransaction.commit が各ロールバックスナップショットを parameter.data.detach().clone() として GPU 上に保存するため、呼び出しが返るまで元の writer がすべて常駐し続ける。回避策: 一度に適用するのではなく、レイヤーをチャンクに分けて介入を適用する。たとえば、layers=[...] を使って4レイヤーずつのグループで繰り返し呼び出す。これなら 24GB カードに余裕で収まるが、編集全体にわたる all-or-nothing のロールバック契約は失われることに注意（各チャンクは独立してコミットされる）。検討中の長期的な修正: ロールバックスナップショットを CPU（または設定可能なデバイス）に保持するか、all-or-nothing ロールバックを維持しながらターゲットごとに計算とコミットを行い、射影されたコピーが一度に1つだけ存在するようにする。
トラブル対応失敗したUIモデルのリロードによって部分的なモデルや古いセッション状態が残ったり、GPUメモリ制限がバイパスされたりする問題を修正する方法
この問題はPR #246で修正されています。その修正を含むリリースにアップデートしてください。app.py内のすべての直接的なUI読み込み/再読み込み（チャットの遅延再読み込み、load_bench_into_chatでのセッション切り替え、A/B比較、実行後のチャット再読み込みを含む）は、obliteratus/ui_model_load.py内の1つのガード付き読み込みパスを通るようになりました。読み込みのセットアップはガード付きセクション内に移動されたため、ローダーが失敗した場合、古い状態を残す代わりに、部分的なモデルとセッション状態を完全にクリーンアップします。UIの再読み込みも、CLI/pipelineパスと同じ共有の読み込み許可関数とメモリ境界を使用するため、pipelineが拒否する読み込みをUIが受け入れることを防ぎます。古いバージョンでは、読み込みに失敗した後にUIプロセスを再起動し、厳密なメモリ許可が必要な場合はCLI/pipelineパスを使用してください。