世界を動かす技術を、日本語で。

Unsloth Dynamic 2.0 GGUFsは、自然な日本語に翻訳すると「Unsloth Dynamic 2.0 GGUFs」となります。特定の製品名や技術用語はそのまま使用します。

概要

  • Unsloth Dynamic v2.0量子化 の紹介と主な進化点
  • 精度維持と省メモリ化 を両立した新手法のベンチマーク結果
  • KL Divergence を活用した正確な評価指標の重要性
  • モデルごとの最適化 やApple Silicon対応など多彩な機能追加
  • 実装・運用ノウハウ や再現性確保のための工夫も解説

Unsloth Dynamic v2.0量子化の革新

  • Dynamic v2.0量子化 は従来の手法を大幅に上回る精度と効率性を実現
  • Aider Polyglot、5-shot MMLU、KL Divergence など主要ベンチマークで新記録
  • 量子化済みLLM の高精度な推論・ファインチューニングが可能
  • GGUF形式 でllama.cppやLM Studio等、主要推論エンジンに対応
  • ベンチマーク でフル精度モデルを凌駕する場合も多数

レイヤー選択とカスタム量子化

  • 全レイヤーを動的に量子化 し、モデルごとに最適な組み合わせを自動選択
  • Gemma 3とLlama 4 など、モデルごとに量子化対象レイヤーが大きく異なる設計
  • Q4_NL、Q5.1、Q5.0、Q4.1、Q4.0 など多様なフォーマット追加でApple SiliconやARM環境にも最適化
  • 1.5Mトークン超の高品質キャリブレーションデータセット で会話性能向上
  • MoE/非MoE両対応 で幅広いモデルに適用可能

ベンチマークと評価指標

  • 独自の評価フレームワーク で公式5-shot MMLUスコアと整合性を確保
  • KL Divergence を主要指標とし、量子化誤差や「flips」(正誤逆転)の観点で評価
  • パープレキシティ(Perplexity) は誤った指標であることを論文に基づき指摘
  • キャリブレーションデータセットの過学習回避 のため、公平な評価用データを厳選
  • Efficiency Metric (効率指標)で精度とディスクサイズのバランスを可視化

モデルごとの実装・再現性

  • MMLU 5-shotの再現性確保 のため独自実装を開発
  • Llama 3.1やGemma 3 等で公式スコアとの差異を徹底検証
  • 細かな実装差異(例:トークン化の違い) も考慮し精度向上
  • Google QAT版Gemma 3 との比較で、動的4bit版が2GB小さく+1%精度向上

Llama 4への貢献とバグ修正

  • Llama 4 ScoutのRoPE ScalingバグQK Normの修正 に貢献
  • MMLU Proスコアが68.58%→71.53%へ上昇 など、精度向上に寄与
  • GGUF形式の4bit Dynamic QAT量子化 で高精度・省サイズを両立

実行方法(Llama 4 Scout例)

  • llama.cppのクローンとビルド
    apt-get update
    apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y
    git clone https://github.com/ggml-org/llama.cpp
    cmake llama.cpp -B llama.cpp/build -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON -DLLAMA_CURL=ON
    cmake --build llama.cpp/build --config Release -j --clean-first --target llama-cli llama-gguf-split
    cp llama.cpp/build/bin/llama-* llama.cpp
    
  • Huggingface Hubからモデル取得
    pip install huggingface_hub hf_transfer
    import os
    os.environ["HF_HUB_ENABLE_HF_TRANSFER"] = "1"
    from huggingface_hub import snapshot_download
    snapshot_download(
      repo_id = "unsloth/Llama-4-Scout-17B-16E-Instruct-GGUF",
      local_dir = "unsloth/Llama-4-Scout-17B-16E-Instruct-GGUF",
      allow_patterns = ["*IQ2_XXS*"],
    )
    
  • 実際の推論コマンド例
    ./llama.cpp/llama-cli \
      --model unsloth/Llama-4-Scout-17B-16E-Instruct-GGUF/Llama-4-Scout-17B-16E-Instruct-UD-IQ2_XXS.gguf \
      --threads 32 \
      --ctx-size 16384 \
      --n-gpu-layers 99 \
      -ot ".ffn_.*_exps.=CPU" \
      --seed 3407 \
      --prio 3 \
      --temp 0.6 \
      --min-p 0.01 \
      --top-p 0.9 \
      -no-cnv \
      --prompt "<|header_start|>user<|header_end|>\n\nCreate a Flappy Bird game.<|eot|><|header_start|>assistant<|header_end|>\n\n"
    

まとめ

  • Unsloth Dynamic v2.0量子化 は精度・効率・再現性の面で現行最高水準
  • 多様なモデル・ハードウェア環境 への適応力や、 公平なベンチマーク設計 が特徴
  • LLMの量子化・運用 における新たなスタンダードとして推奨

Hackerたちの意見

ICYMI、unslothがQwen3.5のローカルモデルで大きな進展を遂げたよ! https://unsloth.ai/docs/models/qwen3.5/gguf-benchmarks Qwen3.5の35B A3BをQ4で使って、RTX5080 16GBのローカル環境で62.98トークン/秒で200kのコンテキストを処理してる。

ぶっちゃけ、突破口ってよりは、壊れた最初のバッチのバグ修正って感じだね。

え、Q4の量子化って20GB以上なのに16GBのGPUに収まるの?そんなことできるなんて知らなかった。いつも自分のVRAMより小さいモデルに制限してたから。

RTX 4090を2台、Q8、256kコンテキスト、110 t/s

これがHNに載るとは思わなかった haha - でも、Qwen3.5の新しいベンチマークのために、量子化の少し違ったアプローチを考案したんだ。これからはすべての新しいモデルに展開する予定だよ!

それは興味深いね。同じカード持ってるから、試してみようかな。CPUやRAM、ストレージの容量も気になる。ローカルセットアップの設定に関するリソースはある?うちのメディアスタックはWSLのディストロで一つのコンポーズファイルにまとめてるから、ローカルLLMも同じように動いてくれたら嬉しいな。

それをするためにどんな方法を使ってるの?最近、llama.cppで遊んでて、32GBのVRAMと64GBのシステムRAMでしっかりしたコンテキストウィンドウを得るためのクリーンなオプションを探してるんだ。

llama.cppはもうQwen3.5に対応してるの?前に試したときは、「qwen35moe」がサポートされてないアーキテクチャだってエラーが出たんだよね。

この分野の進展はいつでも歓迎だね。kldの値の変化は前のバージョンと比べてかなり控えめだと思うけど、これが実際にはどうなるのか知ってる人いる?線形的な感じなのか、それとも指数的なのか…。

新しいブログ記事、https://unsloth.ai/docs/models/qwen3.5/gguf-benchmarks には、コミュニティの人たちによるクワントのベンチマークが載ってるよ。他のモデルとの比較もあって、LiveCodeBenchでの結果が面白い!

この投稿どうしたの?ずっと前からあるリンクだし、下には死んだコメントがたくさんある。なんか変なSEOキャンペーンの一環?

UnslothがQwen 3.5のダイナミック量子化のパフォーマンスについてベンチマークを発表したよ! https://unsloth.ai/docs/models/qwen3.5/gguf-benchmarks

これもHNに載るとは思わなかった haha - おそらくQwen3.5に関連してるね。

ダニエル、マイク、チームのみんな、ありがとう!これからも頑張ってね!

ありがとう!

自分はLlama 3.2の3Bをローカルで使って、レイテンシが重要な分類をやってる(50ms未満だから、もっと大きいモデルは無理)。そのスケールだとQ2_KとQ4_K_Mは単に小さいだけじゃなくて、Q2はQ4が正解するyes/noの回答をひっくり返し始めることがある。頻繁ではないけど、実際の運用で気づくくらいには。だから、ここでのKLダイバージェンスの数字は正直MMLUの表よりも自分には役立つ。MMLUは安定してるのに、出力分布がずれて下流で問題を引き起こすことがあった。3Bのキャリブレーションデータセットって、そんなに違いが出るのかな?冗長性がほとんどないから、キャリブレーションデータの質に関わらず、すぐに床に達しそうな気がする。

シンプルな分類タスクの場合、一般的には高度な動作よりも正則化を優先した方がいいから、パラメータを減らして大きな量子化にするのは理にかなってる。もっと一般的なチャットみたいな用途では、大きいモデルのQ2が小さいモデルのQ4よりも好まれることが多いかも。

50ms未満の推論には何を使ってるの?

Q6はほぼ完璧で、Q3はかなり良い感じだね。すごく印象的!

これは結構面白いね。ブログ記事によると、僕が「レイヤー感度」データを生成するために使っている技術に似たものを使っているみたい。僕の(まだベータ版の)ggufyプロジェクトは、主に拡散(画像)モデル向けなんだけど。 https://github.com/qskousen/ggufy

Q3の120B(64GBに収まる)と、Q4の小さいモデルの実際の使用感はどうなの?

モデルが大きい方が勝つよ、ちゃんと量子化されてればね。

unslothの取り組みが大好き!ただ、ggufフォーマットがもっとvllmに対応してたらいいのに。vllmと相性の良い信頼できるクワントを見つけるのが時々難しいんだよね。

タイミングがいいね。今日LM Studioでモデルをダウンロードしたけど、すごくうまく動いてるよ。24GBのM5で動かすためのHNモデルのおすすめや、実行中のベストプラクティスはある?