Qwen3.6-35B-A3B脱獄版のローカルデプロイ：無検閲GGUF、llama.cpp、安全境界

零度ブログは最近、ローカルモデル Qwen3.6-35B-A3B Uncensored HauhauCS Aggressive を紹介しました。原文ではこれを「脱獄版」「無検閲」のオープンモデルと呼び、GGUF量子化ファイル、llama.cppの起動方法、Agent連携の考え方を示しています。

この種のモデルは注目に値しますが、冷静に理解する必要があります。重要なのは単に制限が少ないことではなく、ローカルAIに必要な複数の能力がまとまっていることです。

MoE構成の35B級モデル。
GGUF量子化によりコンシューマーGPUでも動かせる。
llama.cpp経由でOpenAI API互換インターフェースを提供できる。
mmproj によりマルチモーダル視覚入力を扱える。
HermesやOpenClawなどのローカルAgentツールに接続できる。

ローカルモデルに関心があるなら、「脱獄」という言葉よりも、ローカルモデルが「チャットできる」段階から「ツールに接続し、画像を理解し、Agentのバックエンドになる」段階へ進んでいる点を見るべきです。

このモデルとは

原文で紹介されているモデル名は次の通りです。

1

Qwen3.6-35B-A3B Uncensored HauhauCS Aggressive

名前からいくつかの情報が読み取れます。

Qwen3.6：Qwen系列をベースにしたモデル。
35B：総パラメータ規模は約35B。
A3B：推論時のアクティブパラメータは約3Bで、MoE的な設計。
Uncensored / Aggressive：安全制限が少ない、またはより攻めた調整のバージョン。
GGUF：llama.cppなどのローカル推論ツール向け量子化形式。

注意すべき点は、Uncensored が「より信頼できる」という意味ではないことです。通常は拒否が少ない一方で、制約の少ない内容、未検証の内容、リスクのある内容を出しやすくなります。技術研究には使えますが、公開サービス、本番環境、無人運用に直接つなぐべきではありません。

なぜ35Bモデルがローカルで動くのか

35B と聞くと、サーバーや高性能な複数GPUが必要だと思いがちです。原文で強調されている鍵は、このモデルがMoE構成である点です。

MoEは簡単に言えば、総パラメータは大きいものの、毎回の推論ですべてを使うわけではなく、一部の専門家だけをアクティブにします。原文では実行時に約3Bパラメータをアクティブにするとされており、一定の量子化を行えば、従来のdense 35Bモデルより速度やVRAM負荷を下げられます。

さらにGGUF量子化により、コンシューマーGPUでも動かせる可能性があります。原文では最小量子化版は約11GBで、6GB/8GB VRAMでも試せるが、少なくとも8GB VRAMを推奨するとされています。

現実的には次のように考えるのがよいです。

6GB VRAM：低ビット量子化で試せるが、コンテキストと速度への期待は下げる。
8GB VRAM：入門テスト向き。小さめの量子化を選ぶ。
16GB VRAM：より余裕があり、長いコンテキストやGPU offloadに向く。
24GB VRAM：Q4_K_M、Q4_K_Pのような高品質量子化に向く。

ローカルモデルが使いやすいかどうかは、起動できるかだけでは決まりません。コンテキスト長、生成速度、VRAM余裕、KV cache、マルチモーダルの有無、並行性、実タスクの種類が影響します。

量子化の選び方

原文の推奨はおおよそ次の通りです。

Q4_K_P：RTX 4090など24GB VRAM向き。
Q4_K_M：安定性と品質寄り。
IQ4_NL：高圧縮と品質維持のバランス。
IQ2_M：6GB/8GB VRAM向け。

これは品質とリソース消費のトレードオフです。

Q4系は品質が安定しやすいがVRAM消費が大きい。
IQ2 / IQ3系は軽いが、回答品質、長文安定性、細部の能力が落ちる可能性がある。
Agent呼び出しやローカルAPIを試すだけなら、低量子化でまず流れを通せる。
コード作成、画像理解、複雑推論を長時間使うなら、高品質量子化を選びたい。

「起動できる」ことと「長期的に使える」ことは別です。

llama.cppでのデプロイ

原文では llama.cpp が推奨されています。Windows、Linux、macOSに対応し、NVIDIA CUDA、AMD、Intel、Vulkan、CPUなど複数バックエンドに対応しているためです。

典型的な起動方法は次のようになります。

1
2
3
4
5
6
7
8
9


llama-server.exe ^
  -m "モデルパス.gguf" ^
  --mmproj "mmproj.gguf" ^
  -ngl 999 ^
  -c 131072 ^
  -n 8192 ^
  --host 127.0.0.1 ^
  --port 8080 ^
  --jinja

主なパラメータは次の通りです。

-m：メインモデルのGGUFファイルパス。
--mmproj：マルチモーダル投影ファイル。視覚入力に必要。
-ngl：可能な限りGPUへレイヤーをoffloadする。
-c：コンテキスト長。大きいほどメモリとVRAMを使う。
-n：1回の生成token上限。
--host 127.0.0.1：ローカルだけで待ち受ける。公開するより安全。
--port 8080：ローカルAPIのポート。
--jinja：新しいQwenモデルでは正しいチャットテンプレートに重要。ないと形式崩れ、繰り返し、日本語や中国語の異常が起きる可能性がある。

最も踏みやすい罠はコンテキスト長です。-c 131072 は魅力的に見えますが、長いコンテキストはKV cacheを大きく増やします。低VRAM環境では小さめから始め、段階的に増やす方が安全です。

マルチモーダル機能

原文では、このバージョンは画像、スクリーンショット、OCR、複雑なUI、コード画像を分析できるとされています。

llama.cppでは、マルチモーダル利用には通常、メインモデルと対応する mmproj ファイルが必要です。--mmproj を正しく読み込まないと、画像アップロードが使えなかったり、モデルが画像を正しく理解できなかったりします。

ローカルマルチモーダルの用途は次の通りです。

UIスクリーンショットの分析。
画像内テキストのOCR。
コード画像やエラー画像の読解。
ローカルAgentへの視覚入力。
クラウドに上げずにプライベート画像を処理する。

ただし視覚理解は厳密なOCRではなく、唯一の事実源にもなりません。請求書、契約書、証明書、医療画像など高リスクな内容では、人間の確認が必要です。

OpenAI API互換インターフェース

llama.cppの llama-server はOpenAI APIに似たローカルインターフェースを提供できます。原文のbase URLは次の通りです。

1

http://127.0.0.1:8080/v1

これにより、OpenAI-compatible providerをカスタム設定できるツールは、リクエストをローカルモデルへ送れます。API keyはクライアントが厳密に検証しない限り、任意のプレースホルダーでよい場合があります。

この能力には大きな意味があります。

クラウドAPI keyが不要。
token課金がない。
データをローカルに残せる。
ローカルAgent、コーディング支援、チャットフロントエンドに接続できる。
OpenAI APIのローカル代替バックエンドとして実験できる。

ただしローカルAPIをそのまま外部公開してはいけません。モデルがローカルにあっても、APIをLANやインターネットに開くと、悪用され、リソースを使い切られたり、意図しない内容を生成されたりする可能性があります。

HermesやOpenClawと接続する意味

原文では、このローカルモデルをHermesやOpenClawに接続してこそ価値が出るとされています。

つまり、モデル自体は推論コアにすぎません。Agentツールがそれを実タスクにつなぎます。

コードを書く。
ツールを呼ぶ。
ファイルを読む。
画像を分析する。
Web検索を行う。
複数ステップのタスクを実行する。
長いコンテキストのワークフローを維持する。

ローカルモデルをチャットだけに使う価値は限定的です。安定したAgentバックエンドになれば、ローカルAIワークステーションに近づきます。

ただし、無検閲モデルをAgentに接続する場合は特に慎重であるべきです。Agentがファイルを操作し、コマンドを実行し、Webページを訪問し、ツールを呼ぶなら、モデル出力は現実の操作になります。モデルの制限が少ないほど、外側の権限制御、人間の確認、監査ログが重要になります。

無検閲モデルの安全境界

この種のモデルの売り文句は、拒否が少ないことです。しかし拒否が少ないほどリスクも大きくなります。

注意すべき点：

違法、危険、誤解を招く内容を出しやすい可能性がある。
安全境界を自分から示さない可能性がある。
高リスクな話題で過信した助言を出す可能性がある。
プロンプト誘導で不適切なタスクに向かう可能性がある。
公開利用には向かない。

より安全な使い方：

ローカルまたは制御されたLAN内だけで試す。
高権限ツールに接続しない。
削除、支払い、投稿、一括送信など不可逆操作を自動実行させない。
Agentツールにファイル、コマンド、ネットワーク、ブラウザの権限境界を設定する。
高リスク出力は人間が確認する。

自由なモデルほど、外側のシステム制約が必要です。

誰に向いているか

この種のモデルが向いているのは次のような人です。

ローカルLLMデプロイを研究したい。
8GB以上のVRAMがあり、GGUFとllama.cppを調整する気がある。
ローカルモデルをOpenAI-compatibleクライアントに接続したい。
ローカルマルチモーダル、スクリーンショット分析、Agentバックエンドに関心がある。
一部のプライベートデータをオフラインで処理したい。

向いていないのは次のような場面です。

パラメータ調整をしたくない初心者。
安定した本番SLAが必要なサービス。
セキュリティとコンプライアンス要件が高いチーム。
厳密な事実信頼性が必要な業務フロー。
外部ユーザーに直接公開したい場合。

まとめ

Qwen3.6-35B-A3B Uncensored HauhauCS Aggressive のようなモデルは、ローカルAIの能力境界が急速に広がっていることを示しています。コンシューマーGPUで大きなモデルを動かし、GGUF量子化で導入しやすくなり、llama.cppでOpenAI互換APIを持ち、マルチモーダルとAgentツールによりチャットからタスク実行へ進んでいます。

ただし、これを単なる脱獄モデルとして理解すべきではありません。より重要なのは、ローカルAIが組み合わせ可能なインフラになりつつあることです。モデル、推論エンジン、APIサーバー、フロントエンド、Agentツール、権限制御が一緒に体験を決めます。

試すなら、低リスクなローカルテストから始めるべきです。適切な量子化を選び、コンテキスト長を抑え、--jinja と --mmproj が正しいことを確認し、その後クライアントにつなぎます。安定してからAgentワークフローを検討するのがよいです。

参考資料：

零度ブログ原文：https://www.freedidi.com/24284.html
llama.cpp GitHub：https://github.com/ggml-org/llama.cpp