2026年9月22日、Hugging Face は公式ブログで、transformers が GGUF 量子化モデルを直接読み込めるようになったと発表した。from_pretrained に gguf_file を渡すだけで、Hub 上の GGUF チェックポイントを慣れ親しんだ transformers API に載せ、ローカルマシンで動かせる。ggml の低レイヤーカーネルを再利用したことで、推論性能は llama.cpp に迫るという。
引数ひとつで GGUF が transformers の中に
使い方は想像よりシンプルだ。
from transformers import AutoModelForCausalLM, AutoTokenizer
model = AutoModelForCausalLM.from_pretrained( "unsloth/Qwen3.5-4B-GGUF", gguf_file="Qwen3.5-4B-Q4_K_M.gguf",
)あとは標準の transformers ワークフロー。tokenizer も generate も、カスタム logits プロセッサもそのまま使える。同じチェックポイントは transformers serve で OpenAI 互換 API として公開でき、Jan や Pi といったクライアントをチャットの前面に出せる。
今回の更新で最も説得力があるのは性能だ。Hugging Face は MacBook Pro M2 Max（32GB ユニファイドメモリ）で3種類のチェックポイント——小型 dense モデル、大型 dense モデル、MoE モデル——を実測し、transformers の生成スループットは llama.cpp の llama-bench とほぼ互角だった。秘訣は ggml の Metal カーネルの再利用にある。量子化行列演算、融合正規化、flash attention といった主要演算子が ggml 実装を直接呼び出し、Python はオーケストレーションに専念する。
誰のためか：速度追求者ではなく研究者のため
公式ブログは対象ユーザーを明確にしている。この統合が担うのは主に4つのニーズだ。Python/PyTorch での GGUF 実験、既存の評価ワークフローによる量子化チェックポイントの評価、GGUF 変換の正しさの検証、そして GGUF からの逆量子化によるファインチューニングの継続だ。解決するのは「開発の利便性」であって「速さ」ではない。ブログには、効率的なローカル推論の推奨エンジンは依然として llama.cpp であると明記されている。
境界も見ておこう。初期サポートは Apple Silicon のみで、Qwen3.5 アーキテクチャから開始。transformers の main ブランチと kernels パッケージが必要。互換性のある量子化カーネルがなければ逆量子化ロードにフォールバックし、メモリ使用量は明らかに増える。以前本サイトでは llama.cpp のローカル推論基盤としての位置づけを紹介した（llama.cpp は誰のため？ ローカルモデルの軽量基盤でありチャット製品ではない (/zh/article/1856-llama-cpp-shi-he-shui-ben-di-pao-mo-xing-de-qing-liang-di-zuo-bu-shi-liao-tian-c)）。今回の更新はこう読める。推論は引き続き llama.cpp、研究やプロトタイプでは同じ GGUF ファイルを transformers の中で直接いじれる。2つのツールチェーン間で重みを行き来させる必要はもうない。
中国の開発者にとっても現実的な意味がある。Qwen3.5 のような人気モデルの GGUF 配布版（Unsloth、bartowski など）は Hub で膨大にダウンロードされている。PyTorch エコシステムで使うにはこれまで独自のロード処理を書く必要があったが、公式の道が整備された。
