Hugging Face transformers、GGUFモデルの直接実行をサポート

2026年9月22日

基本情報

収集・肉付けの時点で当サイトのコードが確定させた値です。日付はJST。

概要

Hugging Faceは2026年9月22日、推論ライブラリ transformers において llama.cpp のGGUFフォーマットモデルを直接かつ効率的に実行するためのサポートを追加したと発表した。これにより、利用者は from_pretrained APIを通じてHub上のGGUFチェックポイントをロードし、自身のローカルマシン上で推論を実行できるようになる。初期の最適化対象はApple Silicon環境におけるQwen3.5アーキテクチャのローカル推論となっている。

発表の内容

Hugging Faceは、transformers のエコシステム内でGGUF形式のモデルを直接ロードして実行するための新たな統合機能を発表した。GGUFは llama.cpp チームによって開発され、OllamaやLM Studio、JanなどのローカルAIツールで広く採用されているフォーマットである。今回の機能追加により、開発者は使い慣れた transformers のPython APIやPyTorchワークフローを維持したまま、GGUF形式の軽量なモデルを利用できるようになる。

性能面では llama.cpp に近い実行速度を目指し、kernels ライブラリを介して ggml のMetalカーネルを直接利用する仕組みが導入された。具体的には、行列演算用の ggml-quantization、正規化を行う ggml-norm、アテンション処理用の ggml-attn、並びにハイブリッドアーキテクチャ向けの ggml-gated-delta-net のほか、MoEモデルのルーティングを高速化する独自の topk カーネルが活用されている。重みをパックされた状態のままMetal上で処理することでメモリ消費とオーバーヘッドを削減するが、互換性のあるカーネルが利用できない場合は自動的に sdpa（Scaled Dot-Product Attention）へフォールバックされる。

モデルの利用形態としては、スクリプトからの読み込みだけでなく、transformers serve コマンドを使用したOpenAI互換APIサーバーの立ち上げにも対応している。これにより、JanやPiなどのクライアントアプリケーションから http://localhost:8000/v1 などのローカルエンドポイント経由でモデルを利用可能となる。また、ファインチューニングを行いたい場合は GgufConfig(dequantize=True) を設定することで、量子化を解除して通常の transformers 学習ワークフローに組み込むことができる。

さらに、推論のボトルネックとなるCPUとGPU間の同期を削減するため、generate の生成ループ自体にも改善が行われた。パディングが存在しない入力において不要なアテンションマスクを早期に除外する処理（PR #48814）や、トークン生成時の停止判定を非同期化して処理の重なりを増やす改良（PR #47975）が加えられており、これらの最適化はGGUF以外の全 transformers モデルの推論効率化にも寄与している。

なお、現時点での初期実装にはいくつかの制限が存在する。パックドカーネルによる高速推論パスはApple Silicon（MPS）環境に限定されており、他のデバイスでは重みの展開が必要となる場合がある。また、パディングを含むバッチ処理（generate_batch）の最適化や、Qwen3.5（Dense/MoE）およびQwen3.8以外のモデルアーキテクチャへの対応は、今後の課題として段階的に拡張される計画となっている。

背景

GGMLおよび llama.cpp プロジェクトがHugging Faceに加入した際、両者の補完的な役割について言及されていた。llama.cpp は効率的なローカル推論のための基盤を提供し、transformers はモデル定義のための基盤を提供するという役割分担である。llama.cpp は専用のランタイム、メモリ管理、広範なハードウェアサポートを備えており、効率的なローカル推論を最優先とする場面では引き続き推奨されるエンジンとして位置付けられている。

今回 transformers 内でGGUFフォーマットが直接実行可能になったことで、これら2つの基盤の距離がより近縮された。transformers が提供する柔軟なモデル定義やエコシステムと、ggml の高速な最適化カーネル群を密接に組み合わせることで、開発者は単一の環境下でローカル推論と高度なカスタマイズ・検証を同時に進めることが可能となる。

ローカルLLMの利用者への影響

自分のPCやサーバーなどのローカル環境でオープンウェイトのモデルを運用する開発者・技術者にとって、今回の統合は標準的なPythonやPyTorchのワークフローを維持しながらGGUFチェックポイントを活用できるという大きな利点をもたらす。資料に示されている具体的な影響と活用ポイントは以下の通りである。

1. Python/PyTorch環境での柔軟な実験と検証
   使い慣れたPyTorchのツールキットを利用して、フック（hook）による中間アクティベーションの視察、モデルの順伝播（forward pass）の直接変更、カスタムレイヤーのプロトタイピングなどをGGUFモデルに対して行えるようになる。また、generate に独自のlogitsプロセッサや停止条件を組み込んだり、Python上でカスタムの生成ループを記述したりといった実験も容易に行える。

2. 既存ワークフローでの評価とファインチューニング
   既存の transformers 向け評価ワークフローをそのまま適用し、様々な量子化タイプのチェックポイントにおける生成品質を測定できる。さらに、元のチェックポイントとGGUF変換後のモデルを同時に transformers 上で読み込んで比較することで、量子化誤差を踏まえた変換精度の検証が可能となる。学習を行いたい場合は、GgufConfig(dequantize=True) を指定して重みを逆量子化することで、標準的な transformers のファインチューニング作業へと進めることができる。

3. GGUF形式を超えたカーネルの活用と他モダリティへの展開
   今回の最適化は単にGGUFファイルを読み込むだけに留まらない。ggml の最適化カーネル（行列演算、正規化、アテンションなど）はテンソル単位で機能するため、モデル全体がGGUF形式で提供されていない場合や、llama.cpp 側でフル実装が提供されていない新規アーキテクチャ・研究用モデル・独自変種に対してもPyTorch経由で処理を加速できる可能性がある。さらに将来的な展望として、画像、音声、マルチモーダルモデルなどの他モダリティへのカーネル適用も視野に入れられている。

4. 現在の制限事項とリクエストの受け付け
   現時点において、パックドカーネルによる高速化パスはApple Silicon（MPS）環境に限定されており、互換性のあるカーネルが利用できない場合は重みの展開（逆量子化）を伴うフォールバック動作となり、メモリ消費が増大する。また、パディングを含むバッチ処理（generate_batch）の最適化や、Qwen3.5（DenseおよびMoE）やQwen3.8以外のアーキテクチャ対応は今後の課題とされている。Hugging Face側は、ローカル環境で利用したいGGUFモデルがある場合、GitHub上のIssueでチェックポイントやユースケースを共有するよう利用者に呼びかけており、要望に基づいて対応モデルの優先順位を決定し順次拡張していく方針である。

関連記事

• 物理学的アプローチでLLMを高速化するブロック削除手法「CBO」公開

出典

• https://huggingface.co/blog/transformers-llama-cpp-quants