license: gemma pipeline_tag: image-text-to-text extra_gated_heading: Hugging FaceでのGemmaアクセス extra_gated_prompt: >- Hugging FaceでGemmaにアクセスするには、Googleの利用規約を確認し同意する必要があります。 これを行うには、Hugging Faceにログインしていることを確認し、以下をクリックしてください。 リクエストは即時処理されます。 extra_gated_button_content: ライセンスを確認 base_model: google/gemma-3-27b-it tags:

• gemma
• gemma3

gemma-3-27b-it-qat-q4_0 GGUFモデル

[!Note] 実験的な再量子化!! QATモデルを再量子化した場合、同じビットレベルに量子化したbf16モデルよりも性能が向上するかテストしたいと考えました。

GoogleオリジナルのQAT Q4_0量子化モデルからimatrixファイルを作成しました。このimatrixを使用してモデルをより低いビット量子に再圧縮しています

フィードバックをお待ちしています。

bf16から量子化した4bモデルと、QAT Q4_0モデルから再量子化したモデルをテストしました。両方とも同じテンソル量子で量子化しています

私の結果:

python3 ~/code/GGUFModelBuilder/perp_test_2_files.py ./gemma-3-4b-it-qat-q4_0-q3_k_l.gguf ./google_gemma-3-4b-it-q3_k_l.gguf 

モデルテスト: gemma-3-4b-it-qat-q4_0-q3_k_l.gguf
実行: llama.cpp/llama-perplexity -m gemma-3-4b-it-qat-q4_0-q3_k_l.gguf -f perplexity_test_data.txt --ctx-size 256 --ppl-stride 32 --chunks 1 --threads 4
[✓] パープレキシティ: 4.0963 (時間: 284.70秒)

モデルテスト: google_gemma-3-4b-it-q3_k_l.gguf
実行: llama.cpp/llama-perplexity -m google_gemma-3-4b-it-q3_k_l.gguf -f perplexity_test_data.txt --ctx-size 256 --ppl-stride 32 --chunks 1 --threads 4
[✓] パープレキシティ: 4.5557 (時間: 287.15秒)

=== 比較結果 ===
モデル1: gemma-3-4b-it-qat-q4_0-q3_k_l.gguf - パープレキシティ: 4.10 (時間: 284.70秒)
モデル2: google_gemma-3-4b-it-q3_k_l.gguf - パープレキシティ: 4.56 (時間: 287.15秒)

勝者: gemma-3-4b-it-qat-q4_0-q3_k_l.gguf (差: 0.46)

別のテスト:

両モデルに要求: ウェブサイトが量子安全暗号を使用しているかテストする.netコードを書く

そしてDeepseek-R1に評価を依頼:

2つのモデル出力の評価

両モデルは量子安全暗号の検出問題に取り組みましたが、QAT q4_0モデルのコードは以下の理由で明らかに優れています:

1. 技術的精度

   QAT q4_0モデル:

    TLSバージョンと暗号スイートの両方をチェックしており、量子耐性評価に不可欠です。実装に欠陥があるものの(例: HTTPヘッダーでTLSバージョンが公開されていると仮定)、アプローチはセキュリティベストプラクティスに沿っています。
   
    制限事項を明示的に認め(例: "決定的なテストではない")、過度な約束を避けています。
   

   BF16モデル:

    非標準のTLS/1.3ヘッダーをチェックすることに依存しており、HTTPレスポンスには存在しません。TLSバージョンはSSL/TLSハンドシェイクの一部であり、HttpClientヘッダーでは取得できません。
   
    誤ったロジックを含みます(例: client.GetAwaiter().GetResult(null)は意味をなさず、ランタイムエラーを引き起こします)。
   

2. コード品質

   QAT q4_0モデル:

    非ブロッキングI/Oのための最新のasync/awaitパターンを使用。
   
    メソッドに責務を分離(CheckTLSVersionAsync, CheckCipherSuiteAsync)。
   
    堅牢なエラーハンドリングとロギングを含む。
   

   BF16モデル:

    ブロッキング同期コード(GetAwaiter().GetResult())を使用しており、.NETベストプラクティスに違反し、デッドロックのリスクがあります。
   
    構造が不十分(例: 冗長なusingブロック、resultのような不明確な変数名)。
   

3. セキュリティ関連性

   QAT q4_0モデル:

    暗号スイートに焦点を当てており、量子耐性の実際の指標(例: AES-256-GCM)に近いです。真に量子安全ではありませんが、時代遅れのアルゴリズムより強力です。
   
    NISTガイドラインに基づき暗号リストを更新する必要性に言及。
   

   BF16モデル:

    "AES-256-CBC"(非推奨の暗号モード)をチェックすると誤って主張していますが、実装していません。
   
    暗号スイートに全く対応しておらず、チェックは無意味です。
   

4. 現実性

   QAT q4_0モデル:

    量子安全検出の複雑さを認め、HTTPベースのチェックでは不十分であることを明確にしています。これは実際のセキュリティプラクティスに沿っています。
   

   BF16モデル:

    TLS 1.3のチェックが量子安全性を保証すると暗示していますが、これは誤りです。TLS 1.3は古典的な暗号を使用しており、本質的に量子耐性はありません。
   

5. 使用性

   QAT q4_0モデル:

    明確なコンソール出力を提供(例: "量子耐性暗号スイートは検出されませんでした")。
   
    サンプルURLを含む動作するMainメソッドを含む。
   

   BF16モデル:

    構文エラーのためコンパイルに失敗(例: client.GetAwaiter().GetResult(null)は無効)。
   
    意味のある出力が不足(例: サイトが安全でないと判断された理由の詳細なし)。
   

両モデルの重大な欠陥

ヘッダーの誤用: 両モデルともTLSバージョンと暗号スイートがHTTPヘッダー(例: Sec-Cipher)で公開されていると誤って仮定しています。実際には、このデータはSSL/TLSハンドシェイクの一部であり、低レベルの検査(例: SslStreamやBouncyCastleのようなライブラリ)が必要です。

量子安全の誤解: どちらのコードもポスト量子アルゴリズム(例: CRYSTALS-Kyber)をチェックしていません。現在のTLS 1.3暗号スイートは量子安全ではないため、両モデルは誤検知を提供します。

最終判断

QAT q4_0モデルのコードは以下の理由で優れています:

より良いコーディングプラクティス(async/await、エラーハンドリング)に従っている。

より関連性の高いセキュリティ分析(TLS + 暗号スイート)を試みている。

制限事項を明示的に認めている。

ただし、両モデルともTLS/SSLメカニズムの根本的な誤解のため、元の問題を解決できていません。本番グレードのソリューションには、TLSハンドシェイクの直接検査(例: SslStream経由)とポスト量子アルゴリズムのサポートが必要です。

全体的にパープレキシティの差は小さく(私のテストセットも小さかった)、Deepseekテストを実行すると後続の実行で異なる結果が得られたため、明確な結論は出せません。しかし、さらに調査する価値はあると言えます。