Hugging Face on KnightLiブログ

Gemma 4 E4B の脱獄版と公式通常版の違い

Sat, 18 Apr 2026 10:20:00 +0800

HauhauCS/Gemma-4-E4B-Uncensored-HauhauCS-Aggressive のようなモデルを見るときに一番重要なのは、これは Google が新しく出した別の Gemma 4 ではない という点です。公式の google/gemma-4-E4B-it をベースにした非公式派生版であり、主眼は「拒否応答を減らすこと」にあります。

つまり、通常版との本質的な差はモデル構造よりも アラインメント方針と応答スタイル にあります。

この派生版モデルカードが明示していること

Hugging Face のモデルカードでは、この HauhauCS 版について次のように書かれています。

google/gemma-4-E4B-it ベースである
「データセットや能力には変更がない」と主張している
違いは「拒否応答を外しただけ」と主張している
Aggressive 版は「完全に解放され、プロンプトを拒否しない」と説明している

これらは作者側の主張であり、独立した第三者評価ではありません。ただし、意図している方向性は明確です。これは「安全上の拒否を減らす」ことを狙った非公式派生版です。

公式版 vs いわゆる「脱獄版」

観点	公式 `google/gemma-4-E4B-it`	`Gemma-4-E4B-Uncensored-HauhauCS-Aggressive`
出所	Google 公式	Hugging Face 上の第三者派生版
ベースモデル	Gemma 4 E4B の instruction-tuned 版	同じモデル系統で、モデルカードにも `google/gemma-4-E4B-it` ベースと明記
主目的	汎用アシスタント能力 + Responsible AI 前提	拒否応答を減らし、とにかく出力を続ける
安全方針	Gemma 系列の安全文書・禁止用途ポリシーに沿う	拒否やガードレールを意図的に弱めている
応答傾向	敏感な要求では拒否・回避・慎重回答が増える	公式版なら止まる要求にもそのまま答えやすい
リスク	既定では比較的低いが、完全に安全という意味ではない	既定でより高リスク。不適切または非準拠の出力が出やすい
プロダクト適性	企業や公開サービスで説明しやすい	公開サービスやポリシー重視環境では扱いにくい
追加対策	アプリ側の安全対策は依然必要	モデル側の抑制が弱いため、下流側の安全対策がより重要

本質は「能力向上」より「挙動変更」

uncensored を「より高性能」と受け取るのは、たいてい正確ではありません。

こうした派生版で先に変わるのは次の点です。

どれだけ拒否するか
敏感な要求にどれだけ従うか
最終回答にどれだけ安全フィルタが残るか

一方で、名前に Uncensored と付いているからといって、次のものまで自動的に大きく向上するわけではありません。

モデルアーキテクチャ
コンテキスト長
マルチモーダル能力
推論能力の上限

より正確には、これは 同じモデル系列の中で挙動の調整が違う版 と見るべきであり、上位モデルとみなすべきではありません。

なぜ公式版のほうが保守的なのか

Google の Gemma 公式文書は、この系列を Responsible AI 開発の文脈で位置づけています。Gemma のモデルカードでは誤用、有害コンテンツ、プライバシー、バイアスといったリスクが明示されており、Gemma Prohibited Use Policy では Gemma または派生モデルを次の用途に使うことを禁じています。

危険・違法・悪意ある活動
有害、誤解を招く、欺瞞的なコンテンツ生成
安全フィルタの上書きや回避

つまり、公式版が保守的なのは偶然ではなく、文書・ライセンス・運用前提が最初からそう設計されているためです。

公式通常版が向いているケース

次の点を重視するなら、まずは公式 google/gemma-4-E4B-it のほうが適しています。

プロダクトへの組み込み
チーム利用
企業・公開向け運用
ポリシーや法務リスクの低減
出力挙動の説明可能性

多くの通常用途では、こちらが基本選択です。

あえて脱獄版を試す人がいる理由

こうした uncensored 派生版が選ばれるのは、たいてい次のような理由です。

ローカルでの私的実験
公式版が早すぎる拒否をしていないかの確認
ロールプレイや自由度の高い創作
アラインメント違いの比較

ただし、その分だけ安全責任はモデル提供者ではなく利用者側に移ります。

結論

Gemma 4 E4B のいわゆる「脱獄版」と公式通常版の最も大きな違いは次の通りです。

公式版は「ガードレール付きの実用性」を重視
脱獄版は「拒否を減らした出力継続性」を重視

これは 自動的に高性能になることを意味しません。主に より許容的になる だけです。

安定性、説明可能性、配備のしやすさを重視するなら、まず公式版を使うのが妥当です。ローカル実験目的で、安全性・コンプライアンス・出力リスクを自分で引き受けられる場合に限って、uncensored 派生版を「挙動違いの別バリアント」として比較するのが現実的です。

参考リンク

Hugging Face: HauhauCS/Gemma-4-E4B-Uncensored-HauhauCS-Aggressive
Hugging Face: google/gemma-4-E4B-it
Google AI for Developers: Gemma Prohibited Use Policy
Google AI for Developers: Gemma model card

llama-cli -hf でダウンロードした Hugging Face モデルのデフォルト保存先

Fri, 17 Apr 2026 14:48:04 +0800

llama-cli を使って Hugging Face から直接モデルをダウンロードして実行する場合、たとえば次のように実行します。

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

これは llama.cpp に組み込まれている Hugging Face ダウンロード機能です。新しい llama.cpp では、-hf でダウンロードしたモデルは標準の Hugging Face Hub キャッシュディレクトリに保存されます。

デフォルトのキャッシュ場所

llama-cli -hf でダウンロードしたモデルのキャッシュ場所は、まず LLAMA_CACHE 環境変数で制御されます。LLAMA_CACHE が設定されていない場合は、HF_HUB_CACHE、HUGGINGFACE_HUB_CACHE、HF_HOME などの Hugging Face 関連のキャッシュ変数が確認されます。

これらの変数がどれも設定されていない場合、主なデフォルトパスは次のとおりです。

システム	デフォルトキャッシュディレクトリ
Linux	`~/.cache/huggingface/hub`
macOS	`~/.cache/huggingface/hub`
Windows	`%USERPROFILE%\.cache\huggingface\hub`

Windows では、%USERPROFILE% は通常次の場所を指します。

`1`	`C:\Users\用户名`

そのため、デフォルトのキャッシュディレクトリはおおよそ次のようになります。

`1`	`C:\Users\用户名\.cache\huggingface\hub`

llama-cli のキャッシュディレクトリを変更する方法

モデルキャッシュを指定したディスクやディレクトリに置きたい場合は、LLAMA_CACHE を設定します。Hugging Face の慣例に合わせて HF_HOME を設定することもできます。その場合、実際の Hub キャッシュディレクトリは $HF_HOME/hub になります。

Windows CMD の一時設定例：

1
2

set LLAMA_CACHE=D:\models\llama-cache
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

PowerShell の一時設定例：

1
2

$env:LLAMA_CACHE="D:\models\llama-cache"
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

Linux / macOS の一時設定例：

1
2

export LLAMA_CACHE=/data/models/llama-cache
llama-cli -hf unsloth/gemma-4-E4B-it-GGUF

まとめ

llama-cli -hf ... は llama.cpp のダウンロード機構を使いますが、新しいバージョンでは標準の Hugging Face Hub キャッシュがデフォルトです。
Linux / macOS デフォルト：~/.cache/huggingface/hub
Windows デフォルト：%USERPROFILE%\.cache\huggingface\hub
場所を変更したい場合：LLAMA_CACHE、または HF_HOME / HF_HUB_CACHE を設定する

Windows で llama-cli から Hugging Face に直接アクセスすると SSL 証明書検証に失敗する場合の対処

Fri, 17 Apr 2026 14:20:29 +0800

Windows で次のコマンドを実行したとします。

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

そして、次のようなエラーが表示される場合があります。

1
2

get_repo_commit: error: HTTPLIB failed: SSL server verification failed
error: failed to download model from Hugging Face

この場合、問題は CUDA や llama.cpp 本体ではないことが多いです。多くの場合、現在の環境でプログラムがシステムの証明書チェーンを正しく参照できず、HTTPS の検証に失敗しています。

ログを見ると、ggml-rpc.dll と ggml-cpu-alderlake.dll は正常に読み込まれています。つまり、実行環境自体はおおむね利用可能で、問題は主にモデルのダウンロード段階にあります。

一番手軽な方法：先にモデルを手動ダウンロードする

とにかく早く動かしたい場合は、ローカルに手動でダウンロードする方法がもっとも安定しています。

対象の Hugging Face リポジトリページを開きます。
Files and versions から必要な .gguf ファイルをダウンロードします。
ダウンロード後、ローカルファイルのパスを指定して実行します。

`1`	`llama-cli -m C:\Users\knightli\Downloads\gemma-4-e4b-it.gguf`

この方法なら、-hf のダウンロード段階で発生する SSL 検証問題を回避できます。まずモデルが正常に推論できるか確認したい場合に向いています。

それでも `-hf` の自動ダウンロードを使いたい場合

証明書ファイルのパスを手動で指定し、現在のセッションで利用できる CA 証明書をプログラムに見つけさせます。

cacert.pem は curl 公式が管理している CA Extract ページから取得できます。

ページ：https://curl.se/docs/caextract.html
直接ダウンロード：https://curl.se/ca/cacert.pem

ブラウザでダウンロードする場合は、上の直接ダウンロード URL を開いて cacert.pem として保存します。PowerShell で固定ディレクトリにダウンロードすることもできます。

1
2

New-Item -ItemType Directory -Force C:\certs
Invoke-WebRequest -Uri https://curl.se/ca/cacert.pem -OutFile C:\certs\cacert.pem

ダウンロード後、コマンドラインで次のように設定します。

1
2

set SSL_CERT_FILE=C:\certs\cacert.pem
set CURL_CA_BUNDLE=C:\certs\cacert.pem

その後、元のコマンドをもう一度実行します。

`1`	`llama-cli -hf unsloth/gemma-4-E4B-it-GGUF`

問題の原因が証明書チェーンにある場合、この方法で解決できることが多いです。

llama.cpp Hugging Face から GGUF モデルを取得する方法

Sun, 12 Apr 2026 09:31:38 +0800

llama.cpp は、Hugging Face の GGUF モデルで直接使用できます。最初にファイルを手動でローカルにダウンロードする必要はありません。

モデルウェアハウス自体が GGUF ファイルを提供している場合は、次のようにコマンドラインで -hf パラメーターを直接使用できます。

`1`	`llama-cli -hf ggml-org/gemma-3-1b-it-GGUF`

デフォルトでは、このパラメータは Hugging Face からモデルをダウンロードします。
Hugging Face API と互換性のある別のモデルホスティングサービスを使用している場合は、環境変数 MODEL_ENDPOINT を通じてダウンロードエンドポイントを切り替えることもできます。

llama.cpp は、GGUF 形式のみを直接使用できることに注意してください。
他の形式でモデルファイルを取得した場合は、まずウェアハウス内の convert_*.py スクリプトを使用して、それを GGUF に変換する必要があります。

Hugging Face は、llama.cpp に関連するいくつかのオンラインツールも提供します。一般的な用途には次のようなものがあります。

モデルを GGUF に変換します
モデルを定量化し、サイズを縮小する
LoRA アダプターを変換する
GGUF メタデータをオンラインで編集する
llama.cpp 推論サービスを直接ホストする

最も実用的な結論だけを覚えておきたい場合は、まず GGUF をすでに提供しているモデルウェアハウスを探し、次に llama-cli -hf <user>/<model> を直接使用します。これが通常は最も簡単な方法です。

Llama の GGUF モデルを選択するときの量子化の選択方法: Q8 から Q2 までの実践的な提案

Sat, 11 Apr 2026 20:07:29 +0800

Hugging Face で Llama の GGUF モデルを選択する場合、まず量子化レベルを「解像度」として理解できます。解像度が低いほど使用する VRAM/RAM は少なくなりますが、品質は徐々に低下します。

まずは32、16、Qシリーズについて理解しましょう

32: 最高品質のオリジナルの非圧縮バージョンとして理解できますが、ハードウェア要件は非常に高くなります。
16: 元の品質に近く、サイズは 32 の約半分で、より実用的です。
Q8: ここから量子化バージョンが来ます。通常は Q8_0 または Q8 と書かれます。
Q6、Q5、Q4、Q3、Q2: 数値が小さいほど、リソースの使用量が低くなり、目に見える品質の低下が発生しやすくなります。

`K_M` / `K_S`とは

K_M および K_S は、ハイブリッド量子化戦略を表します。

ほとんどの重みは現在の量子化レベルを使用します
一部の主要部品はより高い精度を維持

したがって、同じレベルでは、Qx_K_M または Qx_K_S は、通常、純粋な Qx よりもわずかに優れています。

実用的な選択の提案

十分なハードウェア: 優先順位 Q8。
ビデオメモリまたはメモリが不足しています: Q6 / Q5 / Q4 まで段階的にダウンします。
下限の提案: Q4 を下回らないようにし、Q4_K_M を優先します。
Q3 以下: 品質の低下がますます顕著になります。

品質の勾配 (高から低)

32
16

– この点を超えると、品質は同じですが、ハードウェア要件が非常に高くなります –

Q8
Q6_K_M
Q6_K_S
Q6
Q5_K_M
Q5_K_S
Q5

– これが古典的なスイートスポットです –

Q4_K_M
Q4_K_S
Q4

– この点を下回ると、品質の低下が顕著になります –

Q3_K_M
Q3_K_S
Q3
Q2_K_M
Q2_K_S
Q2

単純な結論が必要な場合: ほとんどのシナリオでは、Q8 または Q6_K_M から開始するだけでは十分ではなく、通常は Q5 または Q4_K_M にダウングレードする方が安全です。

Hugging Face から GGUF モデルをダウンロードし、Ollama にインポートします。

Thu, 09 Apr 2026 11:00:07 +0800

モデルの公式 Ollama ライブラリに既製バージョンがない場合、または Hugging Face で特定の GGUF ファイルを使用したい場合は、手動でダウンロードして Ollama にインポートできます。

ステップ 1: Hugging Face から GGUF ファイルをダウンロードする

まず、Hugging Face で対象モデルに対応する GGUF ファイルを見つけます。次のような複数の量子化バージョンが表示されるのが一般的です。

Q4_K_M
Q5_K_M
Q8_0

どのバージョンを選択するかは、ビデオメモリ、メモリ、速度と品質の選択によって異なります。ダウンロード後、.gguf ファイルを固定ディレクトリに置き、後で Modelfile で直接参照します。

ステップ 2: モデルファイルを作成する

モデルファイルと同じディレクトリに新しい Modelfile を作成します。最も基本的な書き方は次のとおりです。

`1`	`FROM ./model.gguf`

ファイル名が異なる場合は、次のように実際のファイル名に変更します。

`1`	`FROM ./gemma-3-12b-it-q4_k_m.gguf`

最初に実行したいだけの場合は、通常、FROM 行で十分です。

ステップ 3: Ollama にインポートする

次に、以下を実行します。

`1`	`ollama create myModelName -f Modelfile`

myModelName は、Ollama で使用するローカルモデル名です。
-f Modelfile は、この構成ファイルからモデルを作成することを意味します

作成が成功すると、この GGUF ファイルは直接呼び出すことができるローカルモデルになります。

ステップ 4: モデルを実行する

作成後に直接実行します。

`1`	`ollama run myModelName`

以降の使い方は基本的にollama pullのモデルと同じです。

既存のモデルのモデルファイルを表示する方法

Modelfile の書き方がわからない場合は、既存のモデルの構成を直接表示できます。

`1`	`ollama show --modelfile llama3.2`

このコマンドは、参照に適した llama3.2 の Modelfile コンテンツを出力します。

FROMの書き方
テンプレートとシステムプロンプトはどのように構成されていますか?
パラメータの宣言方法

このルートを使用するのが適切なのはどのような場合ですか?

次のシナリオは、Hugging Face からの手動インポートに適しています。

必要なモデルは、公式 Ollama ライブラリではまだ利用できません。
特定の量子化バージョンを使用したい場合
GGUF ファイルを手動でダウンロードしました
モデルのパッケージ化方法をよりきめ細かく制御したい

公式ライブラリに既製のバージョンがある場合は、通常、pull を直接使用する方が簡単です。ただし、特定の量子化やカスタムパッケージングが必要な場合は、GGUF + Modelfile の方がより柔軟です。

共通の注意点

FROM の後のパスは、実際の .gguf ファイルの場所と一致している必要があります。
ファイル名にスペースや特殊文字が含まれている場合は、最初に簡単な名前に変更することをお勧めします。
GGUF の量子化バージョンが異なると、メモリと速度に大きな影響を与えます。インポートが成功しても、操作がスムーズに行われるとは限りません。
モデルがチャットモデルの場合、効果がより安定するように、後でその形式に応じてプロンプトテンプレートを調整する必要があります。

結論は

Hugging Face から GGUF ファイルをダウンロードして Ollama にインポートするのは複雑ではありません。モデルファイルを準備し、使用可能な最小限の Modelfile を書き込み、その後 ollama create を実行してサードパーティの GGUF モデルを Ollama に接続します。