Hugging Face、transformersでGGUFモデルを量子化したまま実行する初期対応を発表　Apple Silicon向け

量子化したまま動かす初期対応はApple Silicon向け

発表時点で、量子化した重みを保持して推論する経路はApple SiliconのMPS専用です。量子化したまま読み込む機能（ローダー）の対象は、Qwen3.5のdenseとMoEのアーキテクチャに限られます。互換性のあるQwen3.8のチェックポイントも含みます。

読み込みにはfrom_pretrainedを使い、モデルIDに加えてgguf_fileにファイル名を指定します。その後は、通常のtransformersのAPIでテキストを生成できます。

重みをMetal上で量子化したまま保持できる場合、transformersはggml由来の演算用カーネルを自動で読み込みます。アテンションにはggml-org/ggml-attnを使い、取得できないと警告を出してsdpaへ切り替えます。

一方、対応する量子化カーネルがなければ、モデルを逆量子化して読み込みます。この場合はメモリ使用量が増えます。

ソフトウェアの条件は、発表時点ではtransformersのmainブランチと、互換性のあるkernelsライブラリです。PyTorchは公開済みの量子化カーネルが対応する版が必要で、通常は直近の二つのリリースが対象です。

初期対応が想定するのは、一つの対話を手元で実行する用途です。パディングを含むバッチ処理では、不要なパディングマスクを省く最適化が使えず、性能が下がる場合があります。

Hugging Faceは効率重視ならllama.cpp推奨

Hugging Faceは、効率的なローカル推論を優先する場合の推奨エンジンは引き続きllama.cppだとしています。

今回の対応については、同じGGUFのチェックポイントをtransformersの中で扱う手段と位置付けています。挙げている用途の一つが、既存のtransformersの評価手順で、量子化したチェックポイントの品質を測ることです。

PyTorchのフックで途中の層の出力（中間活性値）を調べる、といった実験の用途も挙げています。

同社の開発者にとっては、元のチェックポイントとGGUFへの変換版を両方読み込むことで、量子化の誤差を踏まえて、重みの変換が正しいかを確かめやすくなるとしています。

速度比較は片方だけプリフィルを含む

Hugging Faceは三つのGGUFモデルで測定し、transformersの速度はllama.cppに近いと評価しています。ただし、transformers側は入力（プロンプト）を処理するプリフィルを含み、llama.cpp側は生成部分だけを測った比較です。

transformers側では、12トークンの入力から128トークンを生成しました。プリフィルを含み、ウォームアップ後の三回の測定から最良値を採っています。

llama.cpp側では、測定ツールllama-benchで128トークンの生成速度を測りました。プリフィルを除外し、三回の平均値を使っています。

測定に使ったのは、M2 Max搭載のMacBook Proで、ユニファイドメモリは32 GBです。電源に接続した状態で測定しています。

OSはmacOS 26.6です。PyTorch 2.12.1とkernels 0.17.0を使っています。