Hugging Faceのtransformersがllama.cppのGGUF量子化を直接実行可能にggmlカーネルを流用し対応は当面Apple Silicon・Qwen3.5系のみ

2026年9月25日昼（日本時間）時点の情報です。 Hugging Faceは2026年9月22日、公式ブログ「Transformers now runs llama.cpp quants」（著者はMarc Sun・Arthur Zucker・Lysandre Debut）で、transformersライブラリがllama.cpp形式のGGUF量子化チェックポイントをfrom_pretrainedで読み込み、効率的に動かせるようにしたと発表した。ブログによると、性能をllama.cppに近づけるため、llama.cppの土台であるggmlのMetalカーネルをkernelsライブラリ経由で再利用し、generateのオーバーヘッドも減らした。ただしブログ自身が明記している通り、当面の対象はApple Silicon搭載Macで、量子化したまま（パック済みで）動くアーキテクチャもQwen3.5系（密モデル・MoE、互換性のあるQwen3.8のチェックポイントを含む）に絞られている。GGUFファイルを読み込んで重みを展開（dequantize）して使う経路は今回の発表以前からあり、ブログはこれを「別のオプションとして残る」と位置づけている。今回のニュースは、量子化した重みを展開せずに扱う効率的な経路の追加である。

3行まとめ

1. transformersがGGUF量子化を、量子化したまま専用カーネルで動かせるようになった。 ブログの手順では、transformersの開発版（main）とkernelsをpip installし、from_pretrained(model_id, gguf_file=filename)でHub上のGGUFファイルを読み込む。OpenAI互換APIを立てるtransformers serveでも同じファイルを使える。
2. 対応は当面Apple SiliconのQwen3.5系のみ。 ブログによると、パック済みの推論経路は今のところMPS（Apple SiliconのGPU）専用で、前提条件は「Apple Silicon搭載Mac」。パック済みで動くのはQwen3.5の密モデル・MoEと、互換性のあるQwen3.8のチェックポイント。MacBook Pro M2 Max・32GBでの計測で、Qwen3.5-4B（Q4_K_M）はtransformersが毎秒70.4トークン、llama.cppが71.8トークンとグラフに示されている（両者の計測条件は揃っていない）。
3. Hugging Face自身が、効率重視ならllama.cppを推奨すると書いている。 ブログは"llama.cpp remains our recommended engine when your priority is efficient local inference."（効率的なローカル推論を優先するなら、引き続きllama.cppが推奨エンジンだ）と書き、transformers側の使い道として、PyTorchでの実験・量子化チェックポイントの評価・変換の検証・GGUFからのファインチューニングといった開発者向けの用途を挙げている。この位置づけに従えば、LM Studio・Ollama・Janのようなアプリを置き換える性格の発表ではない。

ブログに書かれた条件

Unsloth配布のQwen3.5-4Bを例にした量子化ごとのファイルサイズも、ブログの表としてそのまま載っている。

ブログはQ4_K_Mから試し、メモリに余裕があればQ5_K_MやQ6_Kを試すことを勧めている。量子化を強くするほど大きいモデルが載りやすくなるが、品質への影響はモデルとタスク次第なので「実際にやらせたい作業で評価する」よう促している。

重みを展開せずに読む経路が加わった

transformersはこれまでもgguf_file引数でGGUFファイルを読み込めたが、その経路は重みを展開（dequantize）して通常のPyTorchモデルにするものだった。transformersの現行ドキュメントも、Qwen3.5系以外のアーキテクチャは従来の読み込み経路（legacy loader）を通り、常に重みを展開すると説明している。ブログはこの展開経路を「別のオプションとして残る」と位置づけており、明示的に選ぶ場合はGgufConfig(dequantize=True)を使う（後述のファインチューニングの用途）。

今回加わったのは、量子化された重みをMetal上でパックしたまま扱うためのカーネル群で、ブログは次の5つを挙げている。

• ggml-quantization: パック済みの量子化重みを読んで行列演算を行う（MoEで選ばれたエキスパートの分を含む）。デコードのたびに重み行列全体を展開せずに済む
• ggml-norm: Qwen3.5・Qwen3.8が使うzero-centered RMSNormなどの正規化処理を融合する
• ggml-attn: プロンプト処理とトークンのデコードに、ggmlのMetal版flash attentionを提供する
• ggml-gated-delta-net: Qwen3.5・Qwen3.8のハイブリッド構造で、線形アテンション層が使うgated delta networkを高速化する
• topk: MoEモデルでトークンごとのエキスパートを選ぶ（softmaxとtop-kのルーティングをまとめる）

前の4つはggmlのカーネルを土台にしたもので、topkはHugging Face自身のMetal実装だとブログは書いている。これらはkernelsライブラリを通じてHubで配布される。

ブログによると追加の設定は要らず、重みがMetal上でパックされたままのときは、対応するggml/Metalの層カーネルが自動で読み込まれ、アテンション実装にはggml-org/ggml-attnが使われる。このアテンション用カーネルを取得できない場合は警告を出して"sdpa"にフォールバックし、attn_implementation="sdpa"を渡せば常に"sdpa"を強制できる（transformersのドキュメント側は、取得できない場合は元のアテンション実装のままになると書いており、表現が少し違う）。一方、対応する量子化カーネルが無い場合は、モデルを展開して読み込むためメモリを多く使う、とブログは注記している。

読み込みのコード例はブログにそのまま載っている。

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "unsloth/Qwen3.5-4B-GGUF"
filename = "Qwen3.5-4B-Q4_K_M.gguf"

tokenizer = AutoTokenizer.from_pretrained(model_id, gguf_file=filename)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    gguf_file=filename
)

ブログは、GGUF固有の手順はこのgguf_fileの指定だけで、あとはapply_chat_templateやgenerateなど通常のtransformers APIがそのまま使えるとしている。事前に必要なものとしてブログが挙げるのは次の3点だ。

1. Apple Siliconを搭載したMac
2. 公開されているggml-quantizationカーネルのビルドが対応するPyTorchバージョン（通常は直近2リリース）
3. transformersの最新版（次の正式リリースまではmainブランチ）と、対応するバージョンのkernels

pip install -U "git+https://github.com/huggingface/transformers.git" kernels

OpenAI互換のAPIとして立てることもできる

transformers serveを使うと、同じGGUFチェックポイントをOpenAI互換のAPIとして公開できる。

pip install -U "transformers[serving] @ git+https://github.com/huggingface/transformers.git" kernels

transformers serve "unsloth/Qwen3.5-4B-GGUF:Qwen3.5-4B-Q4_K_M.gguf"

モデル指定は<model_id>:<filename>.ggufの形式で、コロンの前がHub上のリポジトリ、後ろが読み込むファイル名になる（1つのリポジトリに複数の量子化バリアントが入っている場合の選び方）。JanやPiのようなクライアントからは、Base URLにhttp://localhost:8000/v1、Model IDにunsloth/Qwen3.5-4B-GGUF:Qwen3.5-4B-Q4_K_M.ggufを指定するカスタムのOpenAI互換プロバイダとして接続できる、とブログは説明している。チャットテンプレートが思考（thinking）に対応したモデルでは、--reasoning offで思考を省き、--reasoning onで有効にできる。既定の--reasoning autoはチャットテンプレートの既定に従う。

LM Studio・Ollamaとの役割分担

ブログによると、GGUFはllama.cppチームが開発した形式で、llama.cppの推論エンジンはOllama・LM Studio・Janといったローカル向けのツールを動かしている。GGUFチェックポイントはggml-org名義でHugging Face Hubに公開されているほか、Unsloth・LM Studio Community・bartowskiといった配布元が量子化バリアントを公開しており、「GGUFモデルは数百万回ダウンロードされてきた」（"GGUF models have been downloaded millions of times."）とも書かれている。

ブログは、GGMLとllama.cppがHugging Faceに加わった際に「llama.cppはローカル推論の土台、transformersはモデル定義の土台」という補完的な役割を説明していたと振り返り、今回のGGUF対応が両者を近づけるとしたうえで、次のように書いている。

"llama.cpp remains our recommended engine when your priority is efficient local inference." （効率的なローカル推論を優先するなら、引き続きllama.cppが推奨エンジンだ）

この位置づけに従えば、GGUFを手早くチャットで動かしたいだけの利用では、llama.cppそのもの、あるいはブログがllama.cppで動いていると紹介するLM Studio・Ollama・Janのようなアプリを使う従来の選び方は変わらない。ブログがtransformers経由でGGUFを使う利点として挙げているのは、次のような開発者寄りの用途だ。

• Python・PyTorchでの実験: フックで中間の活性化を調べたり、forward処理を書き換えたり、独自レイヤーを試作したりできる
• GGUFモデルの評価: 既存のtransformersの評価ワークフローで、量子化チェックポイントの品質を測れる
• GGUF変換の検証: 元のチェックポイントとGGUF変換版の両方をtransformersで読み込み、量子化誤差を考慮に入れて、重みが正しく変換されたかを確かめやすくなる（ブログはこれを、Hugging Faceの開発者自身にとっての利点として書いている）
• 新しいデコード手法の試作: generateでカスタムのlogitsプロセッサや停止条件を使ったり、独自の生成ループをPythonで書いたりできる
• GGUFチェックポイントからのファインチューニング: GgufConfig(dequantize=True)で重みを展開し、通常のtransformersの学習ワークフローにつなげる

当サイトの読みとしては、今回の発表は「個人ユーザーがGGUFを動かす手段が増えた」というより、「Hugging Faceのエコシステム（Hub・評価・学習コード）の中でGGUFチェックポイントを扱いやすくした」という性格が強い。ふだんLM Studio・Ollamaでチャット用途に使っている人にとって、すぐに乗り換える理由になる発表ではない。

速度はどのくらい近いのか

ベンチマークは3種類のGGUFチェックポイント（小型の密モデル・大型の密モデル・MoEモデル）で比較されている。ブログのグラフはSVG形式で、モデル名と値がラベルとして書き込まれている。その値をそのまま写すと次のとおり（単位は毎秒のトークン数）。

ブログ本文は「3つのチェックポイントすべてでllama.cppに近い」（"Transformers is close to llama.cpp across all three checkpoints."）と書いている。27Bではtransformers側の値のほうが大きいが、両者の計測条件は揃っていない。llama.cpp側はllama-bench（build 5f55650a7、release b10200、ggml 0.18.0のMetalバックエンド）をllama-bench -m <file> -p 0 -n 128 -r 3で実行したtg128、つまり128トークンをデコードする速度の3回平均で、プロンプト処理を含まない。transformers側は、12トークンのプロンプトから同じ128トークンをgenerateで生成し、ウォームアップ後の3回の計測のうち最良の値を採ったもので、prefill（プロンプト処理）を含む。prefillを含む点はtransformers側に不利、平均ではなく最良値を採る点はtransformers側に有利に働く、向きの違う差が混ざっている。ブログ自身も、このグラフは「同一のベンチマーク条件を意味するものではない」（"it does not imply identical benchmark conditions"）と断っている。なお、ブログに載っている計測スクリプトには、連続で実行すると10%以上速度が落ちるため、各計測の前に90秒待つというコメントが付いている。

ブログは速度の内訳も2枚のグラフで示している。どちらもグラフのラベルから写した値で、量子化カーネルだけの場合と層カーネルを全部使った場合の比は、Qwen3.5-4Bで1.59倍、Qwen3.8-27Bで1.51倍、Qwen3.5-35B-A3Bで2.09倍。generate側の2つの変更の前後では、同じ順に1.42倍・1.16倍・1.79倍だった。その2つの変更とは、パディングの無い入力で全要素が1のattention maskを生成の最初に取り除く変更（PR #48814）と、停止判定を非同期でコピーして次のステップで使い、CPUがGPUの処理を待たずに次の作業を積めるようにする変更（PR #47975）だ。ブログは、この2つはGGUFに限らずtransformersの全モデルの改善につながると書いている（"which results in improvements for all transformers models (not just when running GGUF files)"）。

対応モデルの範囲は、まだ狭い

ブログの「現在の制約と次のステップ」（Current limitations and next steps）の節は、次のように書いている。

"The packed inference path is MPS-only for now. GGUF import through dequantization remains a separate option; support for the file format does not imply that packed kernels are available on every device." （パック済み推論の経路は今のところMPS専用だ。dequantizeによるGGUF読み込みは引き続き別のオプションとして残る。ファイル形式に対応したからといって、パック済みカーネルがすべてのデバイスで使えるわけではない）

"The packed loader currently covers the Qwen3.5 dense and MoE architectures, including compatible Qwen3.8 checkpoints. Adding support for other architectures is relatively straightforward, and we’ll expand coverage gradually." （パック済みローダーが現時点で対応するのは、Qwen3.5の密モデル・MoEアーキテクチャで、互換性のあるQwen3.8のチェックポイントを含む。他のアーキテクチャへの対応は比較的容易で、段階的に広げていく）

この記載に従えば、Llama系・Gemma系・Mistral系・DeepSeek系・GLM系など、GGUFで広く配布されている他のアーキテクチャは、今回の「パック済み」の経路にはまだ入っていない。transformersのドキュメントによると、Qwen3.5系以外は従来の読み込み経路（legacy loader）を通って重みが展開され、その対応先としてLlama・Mistral・Qwen2・Phi3などが挙がっている。パディングとバッチ処理についても「まだ作業が必要」（"Padding and batching still need work."）とあり、パディングを含むバッチは先のattention maskの省略を使えず性能が下がる場合があるとして、MPSでのgenerate_batchにもこの作業を広げたいと書いている。他のアーキテクチャをいつまでに追加するかという時期は、ブログ本文には示されていない。節の最後は、transformersで使いたいGGUFモデルがあれば、チェックポイントとユースケースを添えてissueを立ててほしい、という呼びかけになっている。

Hubのファイル一覧と正式版ドキュメントで照合したこと

当サイトは9月25日、ブログ本文をGitHub上の元原稿（huggingface/blogリポジトリ）と突き合わせたうえで、HubのAPIからunsloth/Qwen3.5-4B-GGUFのファイル一覧を取得した。BF16・Q6_K・Q5_K_M・Q4_K_Mの4ファイルのサイズは、ブログの表の値と小数第2位まで一致した（たとえばQ4_K_Mは2,740,937,888バイトで、表の「GB」は10億バイト単位）。速度の節の表は、ブログに埋め込まれたSVGのテキストラベルをそのまま写したもので、画像の見た目から値を推し量ったものではない。

ブログは導入にtransformersのmainブランチを使うよう書いているが、GitHubで2026年9月9日（UTC）に公開された正式版v5.17.0のGGUFドキュメント原稿にも、MPS上で重みをパックしたまま行列演算を行う経路の記述がすでにあり、そこでは対応アーキテクチャを「Qwen3.5のみ」としていた（"Right now, the only architecture supported is Qwen3.5."）。MoE版やQwen3.8互換のチェックポイント、generateの変更がv5.17.0にどこまで入っているかは、当サイトでは照合していない。また、当サイトはこの経路を実機で動かしてはおらず、速度の値はすべてブログのグラフからの転記である。本文とfrontmatterに載せたURLは、9月25日にcurlで200が返ることを確認した。