transformersがGGUFをggmlカーネルごと読み込む理由

Hugging Face, “Transformers now runs llama.cpp quants”, Hugging Face Blog, 2026年9月22日公開。「transformersでGGUFモデルを効率よく動かす対応を加える。これにより、ノートPCのメモリに合う大きさのチェックポイントを、使い慣れたtransformersのAPIで使える」(“We’re adding support for running GGUF models efficiently in transformers, so you can use checkpoints sized for your laptop’s memory through the familiar transformers APIs.”)、「その推論エンジンは、Ollama、LM Studio、JanといったローカルAIの道具を動かしている」(“Its inference engine powers local AI tools such as Ollama, LM Studio, and Jan.”)、「llama.cppチームが開発したGGUFは、ローカル推論で広く使われる形式である」(“GGUF, developed by the llama.cpp team, is a widely used format for local inference.”)。MLX については「MLX のようなプロジェクトとともに、ローカル推論を日常の実用的な選択肢にしてきた」(“Alongside projects like MLX, it has helped make local inference a practical option for everyday use.”)と書く、「GGUFモデルは何百万回もダウンロードされてきた」(“GGUF models have been downloaded millions of times.”)、「llama.cppに性能を近づけるため、kernelsライブラリを通して下層のggmlカーネルを再利用し、generateのオーバーヘッドを減らしている」(“To bring performance close to llama.cpp, we’re reusing its underlying ggml kernels through the kernels library, and reducing overhead in generate.”)、「GGUFは、トークナイザの情報と任意のチャットテンプレートを含むメタデータと、モデルの重みを一つのファイルにまとめる」(“GGUF packages model weights and metadata, including tokenizer information and an optional chat template, in one file.”)、「llama.cppはローカル推論の土台を、transformersはモデル定義の土台を提供する」(“llama.cpp provides a foundation for local inference, while transformers provides a foundation for model definition.”)、「効率的なローカル推論が優先なら、llama.cppが引き続き推奨するエンジンである」(“llama.cpp remains our recommended engine when your priority is efficient local inference.”)、「別の推論ランタイムでモデルを置き換えずに、ggmlの成果をPyTorchのモデルに持ち込む」(“That brings ggml’s work into the PyTorch model without replacing the model with a separate inference runtime.”)、「カーネルはテンソルに作用する。モデル全体がGGUFファイルから来る必要はない」(“A kernel operates on tensors; it does not require the whole model to come from a GGUF file.”)、「packedの推論経路は当面MPSのみである」(“The packed inference path is MPS-only for now.”)、「パディングとバッチ処理はまだ手を入れる必要がある」(“Padding and batching still need work.”)、「packedのローダーが現在扱うのは、互換のQwen3.8チェックポイントを含む、Qwen3.5のdenseとMoEのアーキテクチャである」(“The packed loader currently covers the Qwen3.5 dense and MoE architectures, including compatible Qwen3.8 checkpoints.”)、「実際にモデルにさせたい作業で評価せよ」(“Evaluate it on the work you actually want the model to do.”)、「展開によるGGUFの読み込みは、別の選択肢として残る」(“GGUF import through dequantization remains a separate option”)、「transformersは三つのチェックポイントのいずれでもllama.cppに近い」(“Transformers is close to llama.cpp across all three checkpoints.”)、「MPS上のgenerate_batchへ広げたい」(“We want to extend the work to generate_batch on MPS.”)、「他のアーキテクチャへの対応は比較的素直で、少しずつ広げていく」(“Adding support for other architectures is relatively straightforward, and we’ll expand coverage gradually.”)、「各アーキテクチャにはまだ統合と検証が要る」(“Each architecture still needs integration and validation”)、「互換の量子化カーネルが無ければ、ローダーはモデルの展開に切り替え、より多くのメモリを使う」(“Without a compatible quantization kernel, the loader falls back to dequantizing the model and uses more memory.”)、必要なものとして「最新版のtransformers（次のリリースまでは当面main）」(“The latest version of transformers (main for now, until the next release)”)、「量子化を強めると大きなモデルを収めやすくなるが、品質との引き換えはモデルと課題による」(“More aggressive quantization can help larger models fit, but the quality tradeoff depends on the model and the task.”)と書く。ファイルの大きさはUnslothのQwen3.5-4BでBF16が8.42 GB、Q4_K_Mが2.74 GB。測定条件について、llama.cpp側は「tg128を報告する。デコードした128トークンにわたるトークン生成速度を3回の繰り返しで平均し、プロンプト処理は除く」(“which reports tg128: the token-generation rate over 128 decoded tokens, averaged across three repetitions, with prompt processing excluded”)、transformers側は「transformersの列は、12トークンのプロンプトから同じ128トークンを生成するgenerateで、ウォームアップ後の3回のうち最良を取り、prefillを含む」(“The transformers column is generate producing the same 128 tokens from a 12-token prompt, best of three warmed runs, and it includes prefill.”)と書く。立ち位置: GitHubのhuggingface/transformersは2018年10月29日作成、スター166,594（GitHub API、2026年9月25日時点）。https://huggingface.co/blog/transformers-llama-cpp-quants ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵ ↩²⁶ ↩²⁷ ↩²⁸ ↩²⁹ ↩³⁰ ↩³¹ ↩³² ↩³³ ↩³⁴

Hugging Face, transformers v4.41.0 リリースノート（GitHub Releases、2024年5月17日公開）。「GGUFの量子化の大半を、transformersのfrom_pretrainedで直接読み込み、通常のPyTorchのモデルへ変換できるようになった」(“You can now load most of the GGUF quants directly with transformers’ from_pretrained to convert it to a classic pytorch model.”)と書く。リリースノートは変換先の精度を書かないが、同じ版に同梱のドキュメント（docs/source/en/gguf.md）は「モデルを読み込むとき、まずfp32へ展開し、それからPyTorchで使う重みを読み込む」(“When loading a model, we first dequantize it to fp32, before loading the weights to be used in PyTorch.”)と書く。https://github.com/huggingface/transformers/releases/tag/v4.41.0 https://raw.githubusercontent.com/huggingface/transformers/v4.41.0/docs/source/en/gguf.md ↩ ↩² ↩³

Hugging Face Hub docs, “GGUF”（2026年9月30日取得）。量子化の型の表で、Q4_Kを「4ビット量子化。8個のブロックからなるスーパーブロックで、各ブロックは32個の重みを持つ。（中略）結果として重み1個あたり4.5ビット」(“Super-blocks with 8 blocks, each block has 32 weights.” / “resulting in 4.5 bits-per-weight”)と書く。重みの式にはブロックごとの倍率（block_scale）と最小値（block_min）が入る。Hugging Faceの発表記事は、量子化の型の説明としてこの頁を指す。https://huggingface.co/docs/hub/gguf ↩

Hugging Face, transformers docs, “GGUF”（mainの版、2026年9月30日取得）。「別のデバイスや量子化の型では、モデルは読み込み時に展開され、まだ対応していないアーキテクチャは従来のローダーを通る」(“On another device or quantization type, the model is dequantized at load time, and an architecture that isn’t supported yet goes through the legacy loader.”)、「従来のローダーが対応するのは、Llama、Mistral、Qwen2、Qwen2Moe、Phi3、Bloom、Falcon、StableLM、GPT2、Starcoder2などである」(“The legacy loader supports Llama, Mistral, Qwen2, Qwen2Moe, Phi3, Bloom, Falcon, StableLM, GPT2, Starcoder2”)、展開して得たモデルについて「出てくるのは通常のdenseなモデルで、GGUFのチェックポイントを渡したdtypeへ持ち込む方法でもある」(“The model that comes out is a regular dense model, so this is also how you take a GGUF checkpoint into the dtype you passed.”)と書く。https://huggingface.co/docs/transformers/gguf ↩ ↩² ↩³

ggml-org, llama.cpp README（2026年9月25日取得）。「llama.cppの主な目的は、最小限のセットアップと最先端の性能で、幅広いハードウェア上で、ローカルでもクラウドでも、LLM（およびVLM）の推論を可能にすることである」(“The main goal of llama.cpp is to enable LLM (and VLM) inference with minimal setup and state-of-the-art performance on a wide range of hardware - locally and in the cloud.”)と書く。立ち位置: GitHubのggml-org/llama.cppは2023年3月10日作成、スター129,419（GitHub API、2026年9月25日時点）。https://github.com/ggml-org/llama.cpp ↩

llama.cpp, “quantize” README（2026年9月25日取得）。「ただしこの処理は、いくらかの精度低下を招きうる。その低下は通常、次の指標で測られる」(“This process however, may introduce some accuracy loss which is usually measured in”)、「これは適切なimatrixファイルを使うことで最小化できる」(“This can be minimized by using a suitable imatrix file.”)と書く。測る指標としてperplexityとKLダイバージェンスを挙げる。https://github.com/ggml-org/llama.cpp/blob/master/tools/quantize/README.md ↩

vLLM project, vllm-gguf-plugin（2026年9月26日取得）。GGUFの行列演算カーネルmmq.cuhは、冒頭のコメントでllama.cppのビルドb2899のggml-cuda/mmq.cuからの複写（“copied from”）と記す。b2899は2024年5月16日のコミットである（GitHub API）。READMEは導入の前提に「CUDA toolkit or ROCm toolkit」を挙げる。https://github.com/vllm-project/vllm-gguf-plugin ↩

vLLM docs, “GGUF”（2026年9月25日取得）。「vLLMのGGUF対応は現時点で非常に実験的で最適化が不十分であり、他の機能と両立しないことがある点に注意してほしい」(“Please note that GGUF support in vLLM is highly experimental and under-optimized at the moment, it might be incompatible with other features.”)、「現在のところ、GGUFはメモリ使用量を減らす手段として使える」(“Currently, you can use GGUF as a way to reduce memory footprint.”)、「GGUF対応は本体外のvllm-gguf-pluginへ移った。GGUFモデルを動かす前にプラグインを入れておくこと」(“GGUF support has migrated to OOT vllm-gguf-plugin” / “Make sure you have GGUF plugin installed before serving a GGUF model.”)、「GGUFモデルではなく元のモデルのトークナイザを使うことを勧める。GGUFからのトークナイザ変換は時間がかかり不安定で、語彙の大きいモデルでは特にそうだからだ」(“We recommend using the tokenizer from base model instead of GGUF model. Because the tokenizer conversion from GGUF is time-consuming and unstable, especially for some models with large vocab size.”)と書く。https://docs.vllm.ai/en/latest/features/quantization/gguf.html ↩ ↩² ↩³

vLLM, “[RFC]: Migrate bitsandbytes and GGUF quantization support to OOT plugin”, GitHub issue #39583（2026年4月11日起票）。起票時の題は「[RFC]: Deprecate bitsandbytes and GGUF quantization support」で、2026年5月20日に現在の題へ改められた（GitHub APIのtimeline）。本文は「このRFCは、両方のバックエンドを非推奨にし、いずれ取り除くことを提案する」(“This RFC proposes deprecating both backends and eventually removing them, to simplify the core weight loading infrastructure and unblock further cleanup.”)と書く。「bitsandbytesとGGUFは、課す保守の負担に比べて利用が非常に少ない（私の見る限り、それぞれおよそ0.5%と0.1%）」(“bitsandbytes and GGUF are two quantization/format backends in vLLM that see very low usage relative to the maintenance burden they impose (roughly 0.5% and 0.1% respectively from what I can tell).”)、「性能も芳しくなく、利用者からは、手元のGPUでのバッチサイズ1の性能を重んじる違いから、GGUFモデルはllamacppで動かすほうが速いという声がよく出る」(“In addition, performance is not great when using these methods, with users often citing running GGUF models with llamacpp to be faster due to different priorities wrt bs=1 performance on consumer GPUs.”)と書く。https://github.com/vllm-project/vllm/issues/39583 ↩