abliteratedモデルをOllamaで動かそうとして全滅した話と、結局公式版で済んだ話

HuggingFaceでhuihui-aiがabliterated版のモデルを量産している。abliterationは、モデルの残差ストリームから「拒否方向」のベクトルを特定して除去する手法で、「すみませんが、その質問にはお答えできません」系の応答だけを消す。学習し直すわけじゃなく、拒否に寄与するニューロンの活性化を潰すだけなので、元モデルの性能はほぼそのまま残る——はず。

実際に試してみたら、そう簡単にはいかなかった。

環境

項目	スペック
PC	GMKtec EVO-X2
CPU	AMD Ryzen AI Max+ 395
GPU	Radeon 8060S（VRAM 48GB割り当て）
メモリ	64GB（統合メモリ）
OS	Windows 11
Ollama	0.16.2〜0.17.4
LM Studio	最新版（Vulkan）
比較環境	Mac（M1 Max / Ollama 0.17.4 / Metal）

Qwen 3.5 abliterated: 全滅

Qwen 3.5は軽量モデルの割に性能が高いが、2.5よりフィルターがきつめ。abliteratedで外したい気持ちはわかる。huihui_ai/qwen3.5-abliteratedがOllamaに上がっていたので試した。

Ollamaのバージョン問題

Qwen 3.5は2026年2月下旬リリースで、古いOllamaではアーキテクチャ未対応。ダウンロードは完了するがロードで500エラーになる。

Error: 500 Internal Server Error: unable to load model

Ollama 0.17.4以降にアップデートすれば解決する。

27b（Dense）の結果

>>> こんちわ
Thinking...
传递更多信息 associates传递更多信息 associates传递更多信息ivitprest associates传递更多信息
associatesprestivitprest associatesprestivitprest associatesprest associatesprest
associates传递更多信息 associates传递更多信息ivitprestivitprest associates传递更多信息
（延々と続く）

壊れた。Thinkingの出力が完全にゴミトークンのループ。「associates」「传递更多信息」「ivitprest」が無限に繰り返されて、応答本文にたどり着かない。

thinking無効化を試す

/set system /no_think でシステムプロンプトに埋め込んでも、--think=false で起動しても、出力は同じゴミトークン。「Thinking…」の表示が消えるだけで、本文として同じゴミが出てくる。

テンプレートやプロンプトの問題ではなく、モデルの重み自体が壊れている。推論エンジンとしてはちゃんと動いていて（VRAM 16.6GB使用、20秒で大量出力）、ただ出力されるトークンが全部ゴミ。

35b-a3b（MoE）の結果

27bがDenseモデルなのに対して、35b-a3bはMoE（active 3B）で内部構造が全然違う。abliterationの影響も変わるかもしれないと思ったが、結果は同じ。

>>> こんちわ
传递更多信息ivit传递更多信息ivit传递更多信息ivitprestivit传递更多信息
associatesprestivit传递更多信息 associatesprest associatesprest
（同じゴミトークン）

DenseだろうがMoEだろうが関係なく壊れる。27bも35b-a3bも同じ「associates传递更多信息ivitprest」のトークンループに落ちるので、壊れ方のパターンも共通。

公式版でも同じだった

ここで気になって、abliteratedではない公式の qwen3.5:35b-a3b を試した。

C:\Users\evovo360>ollama run qwen3.5:35b-a3b --think=false --verbose
>>> こんちわ
prest associates传递更多信息 associatesprest associatesprest associatesprest associates传递更多信息
associates传递更多信息ivit传递更多信息ivitprest associates传递更多信息 associates传递更多信息
（abliterated版と全く同じゴミトークン）

同じだった。abliterationが壊したんじゃない。Qwen 3.5自体がこの環境で動かない。

同じQwen 3.5をMac（M1 Max）のOllamaで動かしたときは、OCR校正もマルチモーダル画像読み取りも問題なく動いている。MacのMetalバックエンドでは正常、GLM-4.7-FlashはROCmでも正常。Qwen 3.5 + ROCm（gfx1151）の組み合わせだけが壊れている。

なぜ壊れるのか

abliterationのせいではなく、Ollama内部のllama.cppのROCmバックエンドがQwen 3.5のアーキテクチャに対応しきれていないのが原因だと思われる。Qwen 3.5のGQA（Grouped Query Attention）やRoPEの実装がGLMとは異なり、ROCmのカーネルがこの特定の構成を正しく処理できていない可能性が高い。

トークナイザーの特定のID範囲に嵌まり込んでループしている感じで、どの入力を入れても同じ「associates传递更多信息ivitprest」のアトラクターに落ちる。

最初はabliterationがthinking周りの重みを壊したと思っていたが、公式版でも同じゴミが出る以上、ROCm + gfx1151の問題。abliterated版が動かないのは当然で、そもそもベースモデルが動かない環境でabliteratedが動くわけがない。

Qwen 3.5はRadeon 8060S（ROCm / gfx1151）では動かない。abliteratedかどうかは関係ない。

Macでabliterated版を検証した結果

ROCmの問題なのか、abliterationの問題なのかを切り分けるため、同じabliterated版をMac（M1 Max / Metalバックエンド）で動かした。Ollamaのバージョンは同じ0.17.4。llama.cppのバージョンも同一で、違いはバックエンド（ROCm vs Metal）だけ。

>>> こんちわ
こんにちは！👋
お元気ですか？
今日は何をお手伝いしましょうか？
ご質問やお話し、何でも気軽に言ってくださいね！😊

普通に動いた。 Thinkingも英語でまともな推論をしていて、ゴミトークンは一切出ない。Winで出ていた associates传递更多信息ivitprest のループは完全にROCm固有の問題だった。

結論: abliterationは無罪。 モデルの重みは壊れていない。同じモデル、同じOllamaバージョンで、バックエンドがMetalかROCmかだけで結果が変わる。

原因はllama.cppのROCmバックエンドがgfx1151（RDNA 4 / Radeon 8060S）上でQwen 3.5のアーキテクチャを正しく処理できていないこと。GLM-4.7-Flashは同じROCm環境で正常に動いているので、ROCm全体が壊れているわけではなく、Qwen 3.5のGQA（Grouped Query Attention）やRoPEの実装がgfx1151向けカーネルで未対応または不具合を抱えている可能性が高い。gfx1151自体が2025年初出の新しいGPUターゲットで、llama.cppのROCmカーネル対応が追いついていないのだろう。

Vulkanバックエンドに切り替えてみる

ROCmが原因なら、同じWindows環境でもバックエンドをVulkanに変えれば動くはず。OllamaはデフォルトでROCmを優先するため、PowerShellで環境変数を設定して強制的にVulkanに切り替えた。

$env:OLLAMA_LLM_LIBRARY = "vulkan"
$env:OLLAMA_VULKAN = "1"
ollama serve

OLLAMA_LLM_LIBRARY=vulkan がポイントで、OLLAMA_VULKAN=1 だけではROCmが優先されて切り替わらない。PowerShellでは set ではなく $env: で環境変数を設定する必要がある点にも注意（これで30分溶かした）。

起動ログで library=Vulkan に切り替わったことを確認。VulkanだとVRAM認識が55.6GiB（ROCmの48GiBより大きい）になった。

Qwen 3.5を実行した結果:

>>> こんちわ
Error: 500 Internal Server Error: model runner has unexpectedly stopped

Vulkanではロードすらできなかった。ROCmはゴミトークンながら一応推論は回っていたが、Vulkanはモデルランナーがクラッシュして即死。

LM Studioで最後の望み

LM Studioも試してみた。以前のバージョンではRadeon 8060SのVRAMを正しく認識できず、GLM-4.7-Flashのロードでexit codeオーバーフロー（18446744072635812000）を吐いて使い物にならなかった。

ところがLM Studioをアップデートしたところ、VulkanでRadeon 8060Sの48GB VRAMを正しく認識するようになっていた。以前はVRAM認識すらできていなかったので、gfx1151対応が入ったのだろう。これでVRAMにメモリサイズを割り当てたまま、LM Studioを推論用途で使えるようになった。

Qwen 3.5 35b-a3b（Q4_K_M）をダウンロードして試した結果:

プロンプトを送った瞬間にLM Studioが「This message contains no content. The AI has nothing to say.」とエラーを返して、その直後にクラッシュした。モデルのロードまでは成功しているが、推論に入ると死ぬ。

最初はメモリオーバーフローを疑った。VRAM 15.8GB使用で共有メモリに7.1GB載っていて、このPCはどのモデルでも共有メモリを埋めたがる癖がある。しかしVRAMを11GB、メインメモリを1GBまで絞っても同じエラーが出たので、メモリの問題ではない。Vulkanバックエンド自体がgfx1151上でQwen 3.5の推論を処理できていない。

結局、Radeon 8060SでQwen 3.5を動かす手段は全滅:

バックエンド	結果
ROCm（Ollama）	ロードできるが出力がゴミトークン
Vulkan（Ollama）	ロードすらできずクラッシュ
Vulkan（LM Studio）	ロードできるが推論開始でクラッシュ
Metal（Mac / Ollama）	正常動作

GLM-4.7-Flash abliterated: テンプレート地獄

Qwen 3.5がダメだったので、GLM-4.7-Flash abliterated版を試した。GLM-4.7-FlashはMoE（30B、active 3B）で推論が軽く、コーディング用途で評価が高い。

LM Studioでの惨敗（旧バージョン）

以前のLM Studio（VRAM未認識の頃）でGLM-4.7-Flashを動かそうとした際の話。mradermacherのGGUF（Q5_K_S）を入れたが、ロードすらできなかった。

モデルの読み込みに失敗しました
Error loading model.
(Exit code: 18446744072635812000). Unknown error.

exit codeが符号なし整数のオーバーフロー。コンテキスト長を変えてもメモリ見積もりが変わらない。LM StudioのVulkanバックエンドがRadeon 8060S（gfx1151）に対応していなかった。

Ollamaでの格闘

LM Studioを諦めてOllamaに切り替えた。mradermacherのGGUFをModelfileで読み込んだが、出力がcompletionモード（チャットではなく文章補完）になる。

>>> こんにちわ
、
今日は  + date_str(date) +
 です。
+ "Hello, world! Today is a good day." \
（コード補完のようなゴミが延々と続く）

原因はテンプレート。Ollamaのhuihui_ai/glm-4.7-flash-abliteratedのテンプレートを確認したら、中身が {{ .Prompt }} だけだった。チャットテンプレートが一切設定されていない。

自分でModelfileにGLM-4.7-Flashの正しいチャットテンプレートを書いて再作成:

FROM /path/to/GLM-4.7-Flash.gguf
RENDERER glm-4.7
PARSER glm-4.7
TEMPLATE "[gMASK]<sop>{{ if .System }}<|system|>
{{ .System }}{{ end }}<|user|>
{{ .Prompt }}<|assistant|>
{{ .Response }}"
PARAMETER stop <|user|>
PARAMETER stop <|observation|>
PARAMETER stop <|end|>

RENDERER glm-4.7 と PARSER glm-4.7 が重要で、これがないとOllamaがGLM-4.7のフォーマットを正しく解釈できない。

テンプレートを直してもthinkingが中国語で延々垂れ流されて回答が出てこない問題が残ったが、--think=false フラグでthinkingを無効化したら会話として成立し始めた。

ただしabliterated版の日本語品質はひどかった:

>>> こんにちは、調子はどう？
お互い調子に乗ってます（笑）。

>>> 最近何してるの？
旅行か何かに行かれたり、最近はプライベートなことも忙しいのかなーと思いました（笑）

存在しない会話履歴を捏造する、</think> タグが出力に漏れる、過剰に卑屈なキャラで勝手に謝り始める。

公式版で解決

abliterated版を諦めて、公式の glm-4.7-flash:q8_0 を --think=false で動かしたら一発で動いた。

>>> いやあなんか今日疲れちゃって
それは大変ですね！今日はもうすぐ終わりなので、最後の1歩まで粘りましょう。
何か疲れの原因がありますか？それとも、ただ体が張ってしまう感じですか？

>>> 話もっと短くていいよ
了解しました。
よかったら、ゆっくり休んでくださいね！

普通に会話できる。Modelfileにキャラ設定のSYSTEMプロンプトを入れれば、日本語でまともにロールプレイもできた。

NSFW方面も、thinking無効にするだけで公式版でもかなり通る。参考記事でもthinking無効でNSFW制限が緩くなると報告されていて、実際に試したらabliterated版を使う必要がなかった。

最終構成

項目	値
モデル	glm-4.7-flash:q8_0（公式版）
ランタイム	Ollama 0.16.2
起動フラグ	—think=false
Modelfile	RENDERER/PARSER glm-4.7 + キャラ設定SYSTEM
速度	33 tokens/s（prompt eval 413 t/s）
VRAM使用	34GB（モデル+KVキャッシュ）
バックエンド	ROCm（gfx1151）

LM Studioで動かなかったのは、VulkanバックエンドがRadeon 8060Sと相性が悪かったため。OllamaはROCmでgfx1151を正しく認識して48GBの統合メモリをフル活用できていた。ollama serve のログで library=ROCm compute=gfx1151 と表示されて判明した。

MoEでactive 3Bなので、Q8_0でもQ4_K_Mでも速度差がほぼない。33t/sは人間の読む速度を超えてるので、会話用途には十分すぎる。

壊れ方にも種類がある

abliteratedモデルが動かないとき、問題の深刻度は大きく3段階ある。

レベル1: テンプレートが設定されていない（GLMパターン）

チャットテンプレートが {{ .Prompt }} だけで、completionモードで動いてしまう。自分でModelfileにテンプレートを書けば直る。huihui-aiの怠慢だが、致命的ではない。

レベル2: 出力言語がおかしい

中国語だけ出てくる、英語でしか返答しないなど。システムプロンプトや言語指定で矯正できることが多い。モデル自体は動いているので、設定で対処可能。

レベル3: バックエンド非対応（Qwen 3.5 + ROCmパターン）

出力がどの言語でもない。「associates传递更多信息ivitprest」のような意味不明なトークン列が無限ループする。テンプレート、システムプロンプト、thinkingの有効/無効、量子化の変更、DenseとMoEの切り替え——何を変えても同じゴミが出る。トークナイザーの特定のID範囲に嵌まり込んでいて、どの入力に対しても同じアトラクターに落ちる。

当初はabliterationが重みを壊したと思っていたが、同じモデルをMac（Metal）で動かしたら正常に動いた。重みは壊れていない。llama.cppのROCmバックエンドがそのモデルのアーキテクチャに対応できていないだけ。バックエンドを変えれば動くが、同じ環境では手の施しようがない。

abliteratedモデルの現状

今回の検証で分かったこと:

Qwen 3.5のabliteratedは壊れていなかった。 Macで検証したら正常に動いた。ROCm（gfx1151）のバックエンドがQwen 3.5のアーキテクチャに対応できていないだけで、abliterationは無罪
GLM-4.7-Flash abliteratedはテンプレートが壊れている。 Ollamaのhuihui-ai公式ページのテンプレートが {{ .Prompt }} だけで、チャットとして機能しない。自分でテンプレートを書けば動くが、日本語品質が大幅に劣化する
公式版 + thinking無効で十分だった。 GLM-4.7-Flashは --think=false で起動するだけでNSFW制限がかなり緩くなる。abliteratedにする必要がなかった
huihui-aiのabliteratedは品質管理がされていない。 テンプレート設定なし、動作確認なしで量産されている。使う側がテンプレート周りを全部自分で直す覚悟がいる

Qwen 3.5については当初abliterationの副作用だと思っていたが、Mac検証でモデル自体は正常と判明した。ただしGLM-4.7-Flashのabliterated版は日本語品質が明確に劣化しており、abliterationの副作用がゼロとは言えない。「公式版でthinkingを切る」方が、品質を維持したままNSFW制限を緩和できる現実的な選択肢だった。

エンコーダーモデル+ローカルLLMでOCR誤字を自動検出・修正する