TransformersがGGUF圧縮推論パスを追加、まずはApple Siliconに注力

Hugging Faceは9月22日、TransformersにGGUFの圧縮重みを使った推論パスを導入すると発表した。開発者はPythonのモデルおよび生成インターフェース内で、ggmlのMetalカーネルを利用できる。初期対応はApple Siliconでの単一会話の処理と、Qwen3.5のDenseおよびMoE（Mixture of Experts）アーキテクチャに重点を置いており、発表では互換性のあるQwen3.8の重みも挙げられている。現時点ではmainブランチからのインストールが必要で、通常の安定版パッケージがすでに完全対応しているとは限らない。[公式発表](https://huggingface.co/blog/transformers-llama-cpp-quants)

鍵となるのは、重みを使った演算の仕組みだ。従来の読み込みでは量子化重みを先に展開していたが、新たな推論パスでは行列演算が圧縮ブロックを直接読み取り、完全な展開に必要なメモリを削減する。読み込み時に`gguf_file`を指定すれば、その後は既存の生成・評価フローを引き続き利用できる。ただし、互換性のある量子化カーネルが見つからない場合、ローダーは逆量子化にフォールバックするため、導入時には実際のメモリ使用量を確認する必要がある。[GGUFドキュメント](https://huggingface.co/docs/transformers/main/en/quantization/gguf)

生成ループでは、CPUとGPUが互いを待つ時間も削減する。関連実装では、デバイス側の停止フラグを非同期でコピーし、次のステップで読み取ることで、ホストが演算をキューに追加し続けられるようにしている。そのため、余分に1ステップ実行した後、余分なトークン、出力の記録、キャッシュを切り落とす場合がある。この処理にはロールバック可能なキャッシュが必要で、すべての生成モードに適用できるとは限らない。[実装と制限](https://github.com/huggingface/transformers/pull/47975)

公式発表では、32 GBのユニファイドメモリを搭載したM2 Maxで3種類の重みをテストし、llama.cppに近いスループットが得られたとしている。ただし、llama.cpp側は128トークンの生成のみを計測し、3回の平均値を採用している。一方、Transformers側は12トークンのプロンプトのプリフィルを含み、3回のウォームアップ後に得た最良値を採用している。両者は集計方法が異なるため、性能が同等だと断定するには不十分だ。[テスト方法](https://huggingface.co/blog/transformers-llama-cpp-quants)

研究者にとって、この推論パスは同じPyTorchモデル内で中間出力を確認し、デコード規則を変更し、量子化誤差を評価しやすくする。実装面では、圧縮推論が現時点でMPSに限られ、ほかのアーキテクチャでは引き続き逆量子化が使われる可能性がある点に注意が必要だ。長さをそろえるためにパディングが必要なバッチでも、すべての高速化手法を適用できるわけではない。今後は安定版への取り込み時期、バッチ対応、そして中国語の長文処理やコーディングタスクにおける品質、レイテンシー、ピークメモリ使用量を見ていく必要がある。[対応範囲](https://huggingface.co/docs/transformers/main/en/quantization/gguf)

中国語の用途では、同じチャットテンプレート、出力上限、サンプリング設定を使い、元の重みと量子化重みの出力品質を比較することが推奨される。長文ドキュメントについては、最初のトークンが出力されるまでの時間と、その後の生成速度を分けて記録する。テストにはコールドスタートと継続的なサービス運用も含め、ウォームアップ後の短いプロンプトによる速度測定だけでユーザーの体感性能を推定しないようにする。これらは今後実施すべき導入検証であり、発表ですでに示された中国語の実測結果ではない。