Transformersがggml量子化カーネルを統合、Apple Siliconで圧縮GGUFを直接実行可能に

Hugging Faceは9月22日、TransformersへのGGUF量子化推論の統合を発表した。開発者はApple Silicon上で重みを圧縮したまま、従来のPythonモデルと生成インターフェースを利用できる。今回公開されたのは統合方法と速度測定結果で、公式にはメインブランチからのインストールが必要とされており、安定版の機能とはまだ位置づけられていない。[公式発表](https://huggingface.co/blog/transformers-llama-cpp-quants)

主な違いは、ロード後の計算方法にある。対応するggmlカーネルがパックされた量子化ブロックを直接読み取って行列演算を行うため、重み全体を事前に展開する必要がない。ロード時に`gguf_file`を指定すれば、その後は既存の生成フローを引き続き利用できる。対応するカーネルがない場合は、重み全体を逆量子化する処理にフォールバックし、必要なメモリが増える。したがって、ファイルをロードできても、メモリを節約する経路が使われるとは限らない。ドキュメントによると、圧縮状態でのロードでは演算型として単精度が自動的に採用される。この経路ではMPS上で単精度のほうが高速なためで、別の型を明示的に指定すると警告が表示される。重みの保存精度と演算型は、それぞれ確認する必要がある。[GGUFドキュメント](https://huggingface.co/docs/transformers/main/en/quantization/gguf)

生成ループでも待ち時間を削減している。対応するパディングなしの入力では、不要なマスクを早い段階で除去する。停止条件の判定には非同期コピーを使い、読み取りを1ステップ遅らせることで、プロセッサがGPUの処理を引き続きキューに投入できるようにする。停止位置を超えて生成された余分な出力は切り落とされる。これらの変更はすでに先行してマージされており、すべてが発表当日に導入されたと解釈すべきではない。[停止判定の修正](https://github.com/huggingface/transformers/pull/47975)、[マスクの修正](https://github.com/huggingface/transformers/pull/48814)

性能比較には測定条件の違いが残る。公式は32 GBのユニファイドメモリを搭載したM2 Maxで3モデルをテストした。ただし、llama.cppはデコードを3回測定した平均値を採用している一方、Transformersは3回のウォームアップ後の最良値を採用し、短いプロンプトのプリフィルも含めている。この結果はローカル環境で実験する際の出発点にはなるが、両実行環境の性能が完全に同じだとする根拠にはならない。[測定方法](https://huggingface.co/blog/transformers-llama-cpp-quants)

現時点で、圧縮された重みを使う推論経路はMPSに限られ、主にQwen3.5のDenseおよびMixture of Experts（MoE）アーキテクチャに対応する。パディングとバッチ処理には、なお改善の余地がある。研究者にとっての価値は、量子化チェックポイントを、使い慣れた評価、モデルフック、カスタムデコードのフローに組み込める点にある。導入時にはコミットとカーネルのバージョンを固定し、逆量子化へのフォールバックが発生していないことを確認したうえで、中国語タスクの品質、最初のトークンが出力されるまでの遅延、ピークメモリ使用量を個別に測定する必要がある。また、起動時のコストを定常状態の速度に混ぜないよう、カーネルの初回ダウンロード時間とウォームアップ時間も記録すべきだ。短いプロンプトを使った単一ユーザーの対話結果だけでは、長いコンテキストや複数ユーザー向けサービスの性能を代表するには不十分である。[対応範囲](https://huggingface.co/docs/transformers/main/en/quantization/gguf)