frontier AI

transformersがGGUFをggmlカーネルで実行：従来との違いと制約

2026/10/2 （更新: 2026/10/11）

🤖 AIを使用して執筆

2024年の読み込みは展開し、今回の経路はggmlのカーネルが直接読む

transformersはHugging Faceのライブラリで、作り手は自らを「モデル定義の土台」と位置づける¹。llama.cppはggml-orgの推論エンジンで、READMEは主な目的を、LLMの推論を、最小限のセットアップと最先端の性能で、幅広いハードウェアの上で行えるようにすることだと書く。対象はローカルとクラウドの両方である⁵。GGUFを作ったのはllama.cppのチームで、GGMLとllama.cppはHugging Faceに加わっている¹。

作り手は対応の背景として、手元の機械で行う推論（ローカル推論）にGGUFが広く使われていることを挙げる。llama.cppの推論エンジンは「Ollama、LM Studio、JanといったローカルAIのツールを動かして」おり、「GGUFモデルは何百万回もダウンロードされてきた」¹。

2024年5月のv4.41.0から、transformersはGGUFの重みを読み込み、通常のPyTorchのモデルへ変換していた²。読み込むときに重みをすべて展開する方法で、その後の演算は展開した値を読むので、PyTorchの汎用の演算をそのまま使える。重みが使うメモリは重みの個数と展開後のビット数で決まり、量子化を強めても減らない。同じ版のドキュメントは、展開する先をfp32と書いている²。32ビットは16ビットの倍なので、16ビットで持つ量子化前のモデルより多くのメモリを使う。いまの展開の経路では、展開する先の精度を使う人が指定する⁶。展開して読む経路は、今回の対応の後も別の選択肢として残る¹。

量子化でファイルがどれだけ小さくなるかは、作り手の記事に実例がある。UnslothのQwen3.5-4Bは、量子化しない版のファイルが8.42 GBで、大半の重みを4ビットにした版（Q4_K_M）が2.74 GBである¹。4ビットの型でも重み1個あたりは4ビットを超える。この版は量子化に敏感な一部の重みを高い精度で残し¹、GGUFの型は重みを小さな区画に分けて区画ごとの倍率なども持つからである⁴。量子化を強めれば、より大きなモデルもメモリに収めやすくなるが、品質との引き換えはモデルと課題で変わる¹。

今回の経路で量子化したままの重みを読むのは、ggml-quantizationというカーネルである。このカーネルは、量子化したままの重みを行列演算の中で直接読み、トークンを一つ生成するたびに重み行列全体を展開することはしない¹。重みを量子化したまま置いて演算の直前に展開する方法なら、常に置く重みは小さく保てるが、トークンを生成するたびに展開が入る。作り手が避けたと書くのは、この動作である。

ggmlのカーネルをtransformersから呼べるようにするのが、kernelsライブラリである。kernelsは、Apple SiliconのGPU向けのggmlのカーネルを、互換のビルドにしてHugging Face Hubで配り、transformersがそれを呼び出す¹。使い方は2024年からの読み込みと同じで、from_pretrainedにgguf_fileを渡す。重みがApple SiliconのGPUの上に量子化したまま置かれると、transformersは互換のカーネルを自動で読み込む¹。互換のカーネルが無いとき、ローダーは展開に切り替わり、より多くのメモリを使う¹。

作り手がggmlのカーネルを再利用した目的は、性能をllama.cppに近づけることである¹。測定の結果について、作り手は、三つのGGUFチェックポイントのいずれでもtransformersがllama.cppに近かったと書く¹。ただし作り手が明記するとおり、測り方は揃っていない。llama.cpp側は、プロンプトの処理を除いて128トークンを生成する速さを3回測り、平均した値である。transformers側は、12トークンのプロンプトの処理を含めて同じ128トークンを生成する速さを3回測り、最良を取った値である¹。この比較を、そのまま推論エンジンどうしの優劣としては読めない。

速さに効いている変更は、重みを読むカーネルだけではない。作り手は、重みを読む演算のほかにもggmlのカーネルを使い、生成の処理でCPUがGPUの結果を待つ回数も減らした¹。生成の処理の変更は、GGUFに限らずtransformersの他のモデルにも効くが、作り手が対象とするのは対応済みの経路と、詰め物（パディング）の無い入力である¹。

各層を定義するコードが残るので、内部を調べるツールが使える

置き換わるのが個々の演算であることは、kernelsライブラリの効果についての作り手の説明に出ている。作り手は、モデルを別の推論エンジンで置き換えることなく、ggmlの成果をPyTorchのモデルに持ち込めると書く¹。transformersが取り込んだのはカーネルで、llama.cppの推論エンジン全体は取り込んでいない。各層の計算を定義するコードは、transformersのものがそのまま動く。ただし、どのモデルでも量子化したまま計算できるわけではない。置き換える演算はアーキテクチャごとに統合と検証が要り、いま済んでいるのはQwen3.5系だけである¹。

そのため、transformersの上で動くツールを、量子化したままのモデルに使える。作り手は用途を五つ挙げる。途中の層の出力を取り出す仕組み（hook）を使った実験、GGUFモデルの評価、GGUFへの変換の検証、生成の手順を変える試行、微調整である¹。五つのうち微調整は、重みを展開してから行う¹。そのため微調整では、重みが使うメモリは展開後のビット数で決まる。

作り手は、二つのツールの役割を分けている。「llama.cppはローカル推論の土台を、transformersはモデル定義の土台を提供する」とし、「効率的なローカル推論が優先なら、llama.cppが引き続き推奨するエンジンである」と明記する¹。

演算だけを置き換える設計は、GGUFのファイルの外にも及ぶ可能性がある。作り手は、カーネルが作用する相手は個々のテンソル（数値の配列）で、モデル全体がGGUFのファイルから来ている必要はないと書く¹。作り手はその先に、llama.cppに専用の実装が無いアーキテクチャ（モデルの層の組み方）でも、transformersのモデル定義の上でggmlの演算を使えるようにしていくことを見込み、これを「より大きな機会」と呼ぶ¹。ただしその場合も、アーキテクチャごとの統合と検証は要る。

代償は対応範囲、量子化の損失、推論エンジンごとの差

量子化したまま計算する経路が使える範囲は、デバイスでも、アーキテクチャでも、量子化の型でも狭い⁶。作り手によると、この経路は当面Apple SiliconのGPUの上でしか動かない¹。対応するアーキテクチャは、Qwen3.5の密なモデルとMoEのモデル、互換のQwen3.8のチェックポイントである¹。複数の入力をまとめて生成する処理にも、まだ改善が要ると作り手は書く¹。作り手の記事は、この経路にtransformersのmainブランチを指定し、次のリリースまでの措置とした¹。Qwen3.5を量子化したまま計算する経路そのものは、2026年9月9日公開のv5.17.0にすでに入っていた⁶⁷。MoEのモデルとQwen3.8への対応は、9月30日公開のv5.18.0で加わった⁸。

範囲の外では、読み込むときに展開する方法に戻る。Apple Silicon以外の環境や、Qwen3.5系以外のモデルでは、transformersの従来のローダーが対応するアーキテクチャに限って、重みを展開して読む⁶。展開して読むと、重みが使うメモリは展開後のビット数で決まる大きさになる。内部は調べられるが、量子化で減らしたメモリは増える。

デバイスとアーキテクチャの二つの制約は、見通しが違う。作り手が広げると書いているのは、対応するアーキテクチャと、Apple SiliconのGPUの上で複数の入力をまとめて生成する処理である。ほかのデバイスについては「当面」と書くだけで、予定は示していない¹。本稿は、アーキテクチャの狭さは一時的だが、デバイスの制約はいつ解けるか見通せないと判定する。

量子化による精度低下の可能性は、展開して読む経路でも、量子化したまま計算する経路でも残る。展開はビット数を戻す処理で、量子化で丸めた値は元に戻らないので、どちらの経路でも計算に使うのは量子化した後の値だからである。llama.cppのquantizeのREADMEは、量子化が「いくらかの精度低下を招きうる」と書く。量子化のときに適切な補助のファイルを使えば、低下を最小化できるとも書く⁹。

低下が出るか、どれだけ出るかは課題とモデルで変わり、Hugging Faceの記事も「実際にモデルにさせたい作業で評価せよ」と書く¹。本稿はこの手間を恒久的な代償と判定する。形式や推論エンジンを替えても、量子化した重みを使う限りこの確認は要る。

保存形式を直接読むカーネルがあるかどうかで決まるのは、メモリと展開の量までである。速さと安定は、それだけでは決まらない。比較のため、同じGGUFを受け入れたもう一つの推論エンジンとしてvLLMを見る。vLLMも、GGUFの計算にllama.cppのggmlカーネルを使っている。ただし使うのは、2024年5月のllama.cppのビルドからCUDA向けのカーネルを複写して自前で持つもので¹⁰、transformersがHubから受け取るApple SiliconのGPU（Metal）向けのカーネルとは別物である¹。そのため、vLLMとtransformersの速さと安定の違いが推論エンジンの差なのかカーネルの差なのかは、この比較からは分けられない。

vLLMのドキュメントは、現時点ではGGUFをメモリ使用量を減らす手段として使えると書く。速さと安定については、GGUF対応を「非常に実験的で最適化が不十分であり、他の機能と両立しないことがある」と書く³。

vLLMは、GGUFの対応を本体から外し、別のプラグインへ移した³。元の提案は対応の廃止で、利用が保守の負担に比べて非常に少ないこと、手元のGPUではllama.cppで動かすほうが速いという利用者の声を理由に挙げていた。利用の少なさは、提案者自身の見立てによる見積もりである。プラグインへ移す形は議論の中で出て、提案の題が改められた¹¹。本稿は、vLLMとtransformersの速さと安定の差を、恒久とも一時的とも判定できないと見る。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。