GGUFとは？ Hugging Face TransformersがGGUFを圧縮したまま動かせるように。初心者向けに解説【Macで実測】

はじめに：ニュースの一文を読み解く
第1章：まず用語から。GGUFとは何か
第2章：これまでの困りごと。AIの世界は「2つの国」に分かれていた
- 「動かす国」と「作る・調べる国」
- 以前もGGUFは読めたが、「全部解凍」していた
第3章：今回のリリースで、何ができるようになったのか
第4章：自分のMacで試すセットアップ
第5章：実際の使い方
第6章：うまく動かないときは
まとめ
- 次のステップ
参考リソース

はじめに：ニュースの一文を読み解く

2026年9月22日、Hugging Faceが「Transformersがllama.cppの量子化モデル（GGUF）をそのまま動かせるようになった」と発表しました。

AIに詳しい人の間では話題になりましたが、初めての方には分からない言葉が多いと思います。「GGUF」「量子化」「Transformers」「llama.cpp」と、知らない言葉が1文の中に4つも並んでいるからです。

この記事では、次の順番で1つずつほどいていきます。

GGUFとは何か（まず用語をやさしく）
これまで何に困っていたのか
今回のリリースで何ができるようになったのか
自分のMacで試すセットアップ
実際の使い方（チャットアプリから・Pythonから・AIの中をのぞく・追加学習の入口）

筆者も実際にMacでセットアップして動かしました。すると、公式の手順どおりに進めるだけではつまずく落とし穴が2つ見つかりました。その回避方法も含めてお伝えします。

想定読者：ChatGPTなどのAIは使ったことがあり、「自分のパソコンでAIを動かす」ことに興味がある方です。プログラミング経験がなくても、第1章から第3章までは読めるように書いています。第4章からはターミナルでコマンドを実行しますが、コピー＆ペーストで進められるようにしています。

まずは結論を1枚の図にまとめました。左が「これまで」、右が「これから」です。

これまでは同じGGUFファイルでも、軽く動かす道具（Ollama・LM Studio・llama.cpp）と、中を調べる道具（Transformers）で扱いが分かれ、Transformersでは元の大きさに展開してメモリが何倍にもなっていた。これからは同じファイルをTransformersで圧縮したまま動かし、チャット・中をのぞく・評価・追加学習の入口まで使える

図1：同じGGUFファイルを「動かす」にも「調べる」にも使えるようになった（静止画）

ひとことで言うと、「パソコンでAIを動かすためのファイルを、AIを研究・改良する作業台でも、そのまま扱えるようになった」というニュースです。ここから順番に見ていきます。

第1章：まず用語から。GGUFとは何か

AIモデルの正体は「大量の数字」

ChatGPTのようなAIの中身は、AIモデルと呼ばれるデータです。AIモデルの正体は、何十億個もの数字の集まりです。この数字を重み（weights）と呼びます。

AIは文章を大量に読んで学習し、そのとき身につけた知識やクセが、この数字の並びとして記録されています。数字が多いほど賢くなりやすい一方で、ファイルは大きくなります。

たとえば今回試した「Qwen3.5-4B」は、約40億個（4B = 4 Billion）の数字でできたモデルです。圧縮しない状態では、ファイルが8.42GBあります。

GGUFは「動かすのに必要なもの全部入り」の1ファイル

GGUF（ジー・ジー・ユー・エフ）は、こうしたAIモデルを保存するファイル形式の名前です。自分のパソコンでAIを動かすソフト「llama.cpp（ラマ・シーピーピー）」の開発チームが作りました。

GGUFの特徴は、動かすのに必要なものを1つのファイルにまとめていることです。

GGUFファイルの中には、①説明書き（メタデータ）、②重み（AIの知識そのもの。ファイルの大部分で、量子化されるのはこの部分）、③トークナイザー（言葉の区切り方の辞書）、④チャットの書式（チャットテンプレート）が入っている。1つ置けばllama.cpp・Ollama・LM Studio・Janなどで動き、今回からTransformersも本格対応

図2：GGUFファイルの主な中身（静止画）

図の4つの中身を、それぞれ短く説明します。

中身	ひとことで言うと	たとえるなら
① 説明書き（メタデータ）	モデルの種類・構造・圧縮方式などの情報	家電の型番シール
② 重み	AIの知識そのもの。ファイルの大部分を占める	本の中身
③ トークナイザー	文章をAIが読める数字の列に変える辞書	翻訳用の辞書
④ チャットテンプレート	「ここから質問」「ここから回答」の目印の付け方	手紙の書式

アプリのインストーラーのように、このファイル1つを持ってくれば動くのが便利な点です。

実は、Ollama（オラマ）、LM Studio、Janといった「パソコンでAIを動かす人気アプリ」の多くは、裏側でllama.cppを使っています。そのため、GGUFはパソコンでAIを動かす世界の標準フォーマットと言ってよい存在になっています。

量子化（クオンタイズ）＝数字を「粗く」して小さくする

GGUFのもう1つの大きな特徴が、量子化（quantization）への対応です。

量子化とは、重みの数字の細かさを少し落として、ファイルを小さくすることです。写真のJPEG圧縮や、スマホに入れる動画の画質を下げるのと同じ考え方です。少しだけ細かさを捨てる代わりに、大幅に軽くなります。

量子化のイメージ。圧縮なし（16bit）では1つの数字を16個の0/1で表すが、4bitに量子化すると4個で表し、0.7342529がだいたい0.73になる。Qwen3.5-4Bの実際のファイルサイズはBF16が8.42GB、Q6_Kが3.53GB、Q5_K_Mが3.14GB、Q4_K_Mが2.74GBで、公式はQ4_K_Mから試すことを勧めている

図3：量子化の考え方と、実際のファイルサイズ。上段はイメージで、下段は公式ブログの値です（静止画）

GGUFのファイル名に付いている「Q4_K_M」や「Q6_K」は、どのくらい圧縮したかを表す記号です。ざっくりした読み方は次のとおりです。

記号	意味	サイズ（Qwen3.5-4B）	向いている人
BF16	圧縮なし（基準）	8.42GB	研究・学習用
Q6_K	6bit前後。品質重視	3.53GB	メモリに余裕がある
Q5_K_M	5bit前後。中間	3.14GB	品質とサイズのバランス
Q4_K_M	4bit前後。軽さ重視	2.74GB	まずはここから

「Q」のあとの数字が小さいほど、ファイルは小さくなり、そのぶん品質は少し下がります。「K_M」は、重要な部分だけ細かさを残すように工夫した方式を表します。

Hugging Face自身も「まずQ4_K_Mで試し、メモリに余裕があればQ5_K_MやQ6_Kへ」と勧めています。この記事でもQ4_K_Mを使います。

第2章：これまでの困りごと。AIの世界は「2つの国」に分かれていた

「動かす国」と「作る・調べる国」

AIモデルを扱う道具は、大きく2つのグループに分かれていました。

	動かす国	作る・調べる国
代表的な道具	llama.cpp・Ollama・LM Studio	Transformers・PyTorch
主な利用者	AIを手元で使いたい人	研究者・AI開発者
得意なこと	GGUFを軽く速く動かす	中身の分析、品質の評価、改造、追加学習
苦手なこと	中身をのぞく・改造・学習	圧縮されたGGUFを軽いまま扱う

Transformers（トランスフォーマーズ）は、Hugging Faceが作っているPythonのライブラリ（便利な道具のセット）です。世界中のAI研究者・開発者が「AIモデルを読み込み、動かし、調べ、学習させる」ための標準の道具として使っています。

PyTorch（パイトーチ）は、そのTransformersの土台になっている計算用のライブラリです。

以前もGGUFは読めたが、「全部解凍」していた

実はTransformersは、以前からGGUFを読み込むこと自体はできました。問題は読み込み方です。

これまでの読み込み方は、圧縮されたファイルを元の大きさに全部展開（解凍）してから使う方式でした。ZIPファイルを毎回すべて解凍しないと中身を使えない状態を想像すると分かりやすいです。

これでは、せっかく2.7GBに小さくしたファイルが、メモリの上では何倍にも膨らんでしまいます。筆者のMacで実際に測った結果が次の図です。

同じ2.7GBのGGUFファイルでも、展開して読むとメモリ使用量のピークが約22GB（ファイルの約8倍）になるのに対し、圧縮のまま読むと約4.5GBで済む。展開方式は、今回の部品が使えないときには今でも使われる

図4：同じファイルでも、読み込み方でメモリがこんなに違います。筆者のMac（M5 Max）で実測（静止画）

約22GBとなると、メモリ16GBのノートPCでは動かせません。そのため多くの人は、次のように使い分けていました。

動かすとき：GGUFをOllamaやLM Studioで使う
調べる・改良するとき：圧縮前の大きなモデルを、別途Transformersで使う

同じモデルなのに、目的によって道具もファイルも使い分ける必要があったわけです。これが「2つの国に分かれていた」という意味です。

第3章：今回のリリースで、何ができるようになったのか

できるようになった4つのこと

今回のアップデートで変わった点を、4つにまとめます。

圧縮したまま動く：GGUFを展開せず、圧縮された形のまま計算します。メモリが軽いままです
速さもllama.cppに近い：公式の測定では、llama.cppとほぼ同じ速さが出ています
チャットアプリから使えるAPIサーバーになる：transformers serve という1行のコマンドで、ChatGPTと同じ形式の窓口（OpenAI互換API）を手元に立てられます
同じファイルで「調べる・作る」まで完結：AIの途中計算の観察、品質の評価、変換が正しいかの検証、新しい文章生成の方法の試作、展開しての追加学習まで、Transformersの中でできます

仕組み：llama.cppの計算部品を「借りて」いる

なぜ急にこれができるようになったのでしょうか。答えは、llama.cppの計算部品をそのまま借りてきたことにあります。

llama.cppの土台には「ggml（ジー・ジー・エム・エル）」という計算用のプログラムがあり、その中に圧縮されたデータを直接計算できる高速な部品（カーネルと呼びます）が入っています。今回、この部品をHugging Faceの「kernels」というライブラリ経由で配布し、Transformersから呼び出せるようにしました。

①あなたのコードでGGUFを指定する → ②Hugging Face Hubからファイルを取得（初回だけダウンロード）→ ③kernelsライブラリがllama.cppの土台ggmlの、MacのGPU用の計算部品を取得 → ④圧縮されたままMacのGPUで計算 → あとはいつものTransformersの書き方で使える。部品が見つからないとき（PyTorchの版が合わない・対応外のモデル・Mac以外）は、警告を出して全体を展開する方式に自動で切り替わる

図5：中で起きていることの流れ（静止画）

図の右側にある「部品が見つからないとき」の分岐が、あとで出てくる落とし穴に関係します。部品が見つからなくてもエラーでは止まらず、黙って展開方式に切り替わるので、気づかないうちにメモリを大量に使っていることがあります。

実際の速さとメモリ

公式ブログでは、MacBook Pro（M2 Max・メモリ32GB）で次の結果が報告されています（単位は1秒あたりに生成できるトークン数。トークンは文字のかたまりで、多いほど速い）。

モデル	Transformers	llama.cpp
Qwen3.5-4B（Q4_K_M）	70.4	71.8
Qwen3.8-27B（UD-Q4_K_M）	15.9	13.4
Qwen3.5-35B-A3B（UD-IQ4_XS）	60.2	61.3

ただし公式も注記しているとおり、両者の測り方は完全には同じではありません（llama.cppは生成部分だけ、Transformersは入力の読み込みも含めて測定）。

筆者も自分のMac（MacBook Pro、M5 Max・メモリ128GB）で、同じファイルを3通りの読み込み方で測りました。

筆者のMacでの実測。メモリ使用量のピークは、圧縮のまま4.5GB、展開BF16が14.4GB、展開FP32が22.1GB。生成の速さは、圧縮のままが1秒あたり109トークン、展開BF16が42、展開FP32が29。参考としてllama.cppは131（測り方が違うため参考値）

図6：同じGGUFを3通りの読み込み方で比べた結果（静止画）

読み込み方	メモリのピーク	速さ（トークン/秒）
圧縮のまま（今回の仕組み）	4.5GB	109
展開してBF16で読む	14.4GB	42
展開してFP32で読む（部品が使えないとき）	22.1GB	29
参考：llama.cpp（生成部分のみで測定）	－	131

今回の仕組みは、部品が使えずにFP32で展開された場合と比べてメモリが約5分の1、速さは約4倍でした。BF16で展開した場合と比べても、メモリは約3分の1、速さは約2.6倍です。llama.cppと比べると筆者の環境では8割強の速さで、公式の測定ほどは差が縮まっていません。とはいえ、日常的な対話には十分な速さです。

測定条件：Qwen3.5-4B Q4_K_M、23トークンの入力から128トークンを生成、準備運転のあと3回測った最良値。メモリはmacOSの /usr/bin/time -l が出す「peak memory footprint」。PyTorch 2.13.0、Transformers開発版（2026年9月23日時点）、kernels 0.17.1。

誰にとってうれしい話なのか

正直に言うと、チャットで使いたいだけなら、今もOllamaやLM Studioのほうが手軽です。Hugging Face自身も、「効率よく手元で動かすことが最優先なら、引き続きllama.cppを推奨する」と書いています。

今回の恩恵を直接受けるのは、主にAIを作る・調べる側の開発者です。

実際に配布されているGGUFと同じもので、品質を評価できる
圧縮によって答えがどう変わったかを、途中計算まで追って検証できる
新しい文章の生成方法を、手元のMacですぐ試せる

非エンジニアの方にとっては、「手元で動くAIを改良・評価するサイクルが速く回るようになり、よいモデルが早く届きやすくなる」という間接的なメリットだと考えるとよいでしょう。

自分にはどれが合う？

目的別の選び方を図にまとめました。

手元のPCでAIモデルを使いたい場合、チャットで使えれば十分ならOllama・LM Studioがいちばん手軽。中を調べたい・評価したい・改造したい場合、Apple SiliconのMacでなければ今は展開方式（メモリ多め）。Macでも対象がQwen3.5/Qwen3.8系でなければ今は展開方式。両方はいならTransformers＋GGUF（今回の仕組み）。迷ったらまずOllamaなどで触ってみて、中を知りたくなったらTransformersへ

図7：目的別の選び方（2026年9月23日時点。静止画）

現時点の制約

始まったばかりの機能なので、制約もあります。

制約	内容
対応パソコン	圧縮のまま動くのは Apple Silicon（M1以降）のMacだけ。Windows・NVIDIA GPU環境は展開方式になる
対応モデル	Qwen3.5系（通常型とMoE型）と、互換性のあるQwen3.8系のみ。ほかは展開方式
使い方	1つの会話を順番に処理する使い方が主な対象。複数の依頼をまとめて同時に処理する機能は今後の課題
バージョン	次の正式リリースまでは、Transformersの開発版を入れる必要がある
PyTorch	計算部品が用意されているPyTorchの版でしか使えない（2026年9月23日時点で2.12と2.13）

最後の「PyTorchの版」が、次の章で出てくる1つめの落とし穴です。

第4章：自分のMacで試すセットアップ

ここからは実際に手を動かします。流れは次の図のとおりです。

セットアップの流れ。①チップを確認する、②ターミナルを開く、③uvを入れる、④作業フォルダとPython 3.12の環境を作る、⑤ライブラリを入れる（PyTorchは2.13に固定）、⑥「Dequantizing the whole model」の警告が出なければ成功。最新のPyTorch 2.14を入れると計算部品が見つからず展開方式になる（メモリ約5倍）のが一番の落とし穴

図8：セットアップの流れ（静止画）

必要なもの

項目	目安
パソコン	Apple Silicon（M1以降）のMac
メモリ	4BモデルのQ4_K_Mなら、実測のピークが約4.5〜4.9GB。16GBあれば余裕を持って試せます
ストレージ	空きが10GB程度（モデル2.7GB＋PyTorchなどのライブラリ）
ネット接続	初回のダウンロードに必要

手順1：Macのチップを確認する

画面左上のAppleメニューから「このMacについて」を開きます。「チップ」の欄が「Apple M1」「Apple M4」のように Apple M〇 になっていれば対応しています。「Intel」と書かれている場合は、今回の高速な仕組みは使えません。

手順2：ターミナルを開く

⌘（command）＋スペース でSpotlightを開き、「ターミナル」と入力してEnterを押します。黒または白の画面が開けば準備完了です。以降のコマンドは、この画面に貼り付けてEnterで実行します。

手順3：uv（Pythonの準備係）を入れる

uv（ユーブイ）は、Pythonの本体やライブラリをまとめて準備してくれる道具です。次の1行で入ります（公式のインストール方法です）。

# uv をインストールする
curl -LsSf https://astral.sh/uv/install.sh | sh

インストールが終わったら、ターミナルを一度閉じて開き直してください。開き直さないと uv コマンドが見つからないことがあります。

# uv が使えるか確認する（バージョン番号が表示されればOK）
uv --version

手順4：作業フォルダとPython環境を作る

ホームフォルダの中に作業用フォルダ gguf-test を作り、その中にPython 3.12の環境を作ります。この「環境」は、道具を入れる専用の箱のようなものです。箱の中に入れたライブラリは、パソコンのほかの作業に影響しません。

# 作業フォルダを作って移動する
mkdir gguf-test && cd gguf-test

# Python 3.12 の環境を作る（なければ uv が自動でダウンロードする）
uv venv --python 3.12

# 作った環境に入る（行の先頭に (gguf-test) などと表示される）
source .venv/bin/activate

ターミナルを開き直したときは、毎回 cd gguf-test と source .venv/bin/activate を実行してから作業します。

手順5：ライブラリを入れる（ここが1つめの落とし穴）

必要なライブラリは3つです。

torch（PyTorch）：計算の土台
transformers：AIモデルを扱う道具。今回の機能はまだ開発版にしか入っていないので、GitHubから直接入れる
kernels：llama.cppの計算部品を取ってくる係

ここで大事なのが、PyTorchのバージョンを2.13に固定することです。

# PyTorch は 2.13 に固定し、Transformers は開発版、kernels と一緒に入れる
uv pip install "torch==2.13.*" \
  "transformers[serving] @ git+https://github.com/huggingface/transformers.git" \
  kernels

なぜ固定するのか：筆者が最初に最新版のPyTorch（2.14）を入れたところ、エラーは出ないまま、次の警告が出て展開方式に切り替わりました。

Dequantizing the whole model, because no GGUF matmul kernel is published for this device.

調べると、計算部品（ggml-quantization）がMac向けにPyTorch 2.12と2.13用しか公開されていなかったのが原因でした（2026年9月23日時点）。公式ブログにも「部品が対応するPyTorch（通常は直近の2つのリリース）が必要」とあります。PyTorchは頻繁に新版が出るので、この「対応する版」は今後も変わります。うまくいかないときは、警告が出ていないかを確認してください。

手順6：準備できたか確認する

# PyTorch の版と、Mac の GPU（MPS）が使えるかを表示する
python -c "import torch; print(torch.__version__, torch.backends.mps.is_available())"

2.13.0 True のように表示されればOKです。True はMacのGPUが使える状態であることを示します。本当に圧縮のまま動いているかは、次の章でモデルを読み込んだときの表示で確かめます。

第5章：実際の使い方

使い方を4つのパターンで紹介します。非エンジニアの方はパターン1、開発者の方はパターン2〜4がおすすめです。

パターン1：チャットアプリから使う（非エンジニア向け）

transformers serve を使うと、Macの中にChatGPTと同じ形式の「受付窓口（APIサーバー）」を立てられます。チャットアプリからその窓口に話しかけると、Macの中のモデルが答えてくれます。

チャットアプリから使うときの流れ。あなたのMacの中で、Jan（チャットの画面）から①質問がtransformers serve（受付の窓口 localhost:8000/v1）へ送られ、②GGUFを圧縮したままGPUで計算するモデルに渡り、③回答がJanに返る。Hugging Face Hubからは初回だけモデルと部品をダウンロードする。質問と回答はMacの中だけでやりとりされ、外部のAIサービスには送られない

図9：チャットアプリから使うときの流れ（静止画）

手順1：サーバーを起動する

作業フォルダで環境に入った状態で、次のコマンドを実行します。初回はモデル（約2.7GB）と計算部品のダウンロードが走るので、少し待ちます。

# Qwen3.5-4B の Q4_K_M 版を読み込んで、サーバーを起動する
transformers serve "unsloth/Qwen3.5-4B-GGUF:Qwen3.5-4B-Q4_K_M.gguf" --reasoning on

"リポジトリ名:ファイル名" の形で指定するのがポイントです。Hugging Face上の1つの置き場（リポジトリ）には、Q4_K_MやQ6_Kなど複数の圧縮版が並んでいることが多く、その中から使う1つを選ぶための書き方です。

Uvicorn running on http://localhost:8000 と表示されたら起動完了です。このターミナルは開いたままにしておきます。

2つめの落とし穴：--reasoning on を付ける理由

--reasoning は、モデルに「考えてから答える（思考モード）」をさせるかどうかの設定です。本来は off にすると思考を省いて速く答えます。

ところが筆者の環境（2026年9月23日時点の開発版）では、off や既定の auto にすると、同じ文を延々とくり返す壊れた回答になりました。調べたところ、GGUFから読み込んだトークナイザー（言葉の区切り方の辞書）が、思考の区切り記号 <think> を1つの記号として扱えず、<th ink > の3つに分けてしまうことが原因でした。

--reasoning on にすると正常に答えます。思考の内容は回答とは別の欄（reasoning_content）に分けて返されます。少し時間はかかりますが、確実に動く設定として、現時点ではこちらをおすすめします。

手順2：動いているか確認する（任意）

ターミナルのウィンドウをもう1つ開き（⌘＋N）、次のコマンドで質問を送ってみます。

# 手元のサーバーに質問を1つ送る
curl -s http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "unsloth/Qwen3.5-4B-GGUF:Qwen3.5-4B-Q4_K_M.gguf",
       "messages": [{"role": "user", "content": "雨の日に家でできる気分転換を3つ、短く教えて"}],
       "max_tokens": 2000}'

筆者の環境では、"content" の欄に次のような回答が返ってきました（実際の出力から回答部分だけを抜き出しています）。

雨の日に家でできる気分転換3選：

1. **映画やドラマを見る**
   好きな作品をゆっくり観て癒やされる

2. **お菓子作り**
   簡単なレシピでクッキングを楽しみ、香りを楽しみながら

3. **本を読む**
   本棚から好きな本を選び、没入して読み込む

手順3：チャットアプリ「Jan」とつなぐ

公式ブログでは、無料のチャットアプリ Jan から使う方法が紹介されています。Janの設定で、カスタムのOpenAI互換プロバイダを追加し、次のように入力します。

設定項目	入力する値
Base URL	`http://localhost:8000/v1`
Model ID	`unsloth/Qwen3.5-4B-GGUF:Qwen3.5-4B-Q4_K_M.gguf`
API Key	不要（何か入力を求められたら適当な文字列でよい）

あとはJanの画面でいつもどおりチャットするだけです。画面はJan、実際の計算はMacの中のTransformersという分担になります。質問と回答はMacの中（localhost）だけでやりとりされるので、会話の内容が外部のAIサービスに送られることはありません。

筆者はサーバーの動作（通常の応答と、文字が少しずつ届くストリーミング応答）までを確認しました。Janアプリの画面での操作は公式ブログの手順にもとづいており、筆者の環境では試していません。

パターン2：Pythonから直接使う（開発者向け）

次のコードを chat.py という名前で作業フォルダに保存し、python chat.py で実行します。

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

repo = "unsloth/Qwen3.5-4B-GGUF"      # GGUFが置いてある場所（リポジトリ）
gguf = "Qwen3.5-4B-Q4_K_M.gguf"       # その中の、使いたい圧縮版ファイル

# 言葉の区切り方（トークナイザー）は元のQwenから読む（理由は下の「注意」を参照）
tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen3.5-4B")
# モデル本体はGGUFから、圧縮したまま読み込む
model = AutoModelForCausalLM.from_pretrained(repo, gguf_file=gguf)

messages = [{"role": "user", "content": "冷蔵庫にある卵・玉ねぎ・ごはんで作れる夕食を1つ提案して"}]
inputs = tokenizer.apply_chat_template(
    messages, add_generation_prompt=True, enable_thinking=False,
    tokenize=True, return_dict=True, return_tensors="pt",
).to(model.device)

with torch.inference_mode():
    out = model.generate(**inputs, max_new_tokens=800)

# 入力した部分を除いて、回答だけを表示する
print(tokenizer.decode(out[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True))

GGUFならではの書き方は、from_pretrained に gguf_file= を付けるところだけです。それ以降は、ふだんのTransformersの書き方がそのまま使えます。

実行すると、玉ねぎと卵の炒めご飯のレシピが、材料・作り方・ポイントに分かれて表示されました。モデルがダウンロード済みの状態なら、筆者の環境では読み込みから回答まで約11秒でした。

注意：トークナイザーを元のQwenから読む理由

公式ブログの例では、トークナイザーもGGUFから読み込んでいます（AutoTokenizer.from_pretrained(repo, gguf_file=gguf)）。しかし筆者の環境では、パターン1で説明した <think> の区切りの問題が起き、思考を省いた設定（enable_thinking=False）で同じ文をくり返す回答になりました。

そこで、元のモデルを公開しているQwen公式の置き場からトークナイザーだけを読み込むように変えました（小さな設定ファイルだけのダウンロードで、モデル本体は取りに行きません）。すると、llama.cppで同じファイル・同じ設定で出した回答と一字一句同じ回答になりました。圧縮のまま計算する部分は正しく動いており、問題はトークナイザー側だけだと分かります。今後の開発版で直る可能性が高い部分です。

圧縮のまま動いているかの見分け方：実行中に Dequantizing the whole model という警告が表示されなければ、圧縮のまま動いています。表示された場合は展開方式になっているので、第4章の手順5を見直してください。

パターン3：AIの頭の中をのぞく（Transformersならではの使い方）

ここが「作る・調べる国」の道具であるTransformersの本領です。OllamaやLM Studioでは難しい、AIが次にどんな言葉を考えているかを数字で見てみます。

AIは文章を「次に来そうな言葉を1つずつ選ぶ」ことで作っています。そこで「日本でいちばん高い山は」の次に、どの言葉をどのくらいの確率で候補にしているかを表示させます。次のコードを peek.py として保存し、python peek.py で実行します。

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

repo = "unsloth/Qwen3.5-4B-GGUF"
gguf = "Qwen3.5-4B-Q4_K_M.gguf"
tokenizer = AutoTokenizer.from_pretrained(repo, gguf_file=gguf)
model = AutoModelForCausalLM.from_pretrained(repo, gguf_file=gguf)

text = "日本でいちばん高い山は"
inputs = tokenizer(text, return_tensors="pt").to(model.device)

with torch.inference_mode():
    logits = model(**inputs).logits[0, -1]      # 次の1語についての「点数」
probs = torch.softmax(logits.float(), dim=-1)    # 点数を確率に直す
top = torch.topk(probs, 5)

print(f"「{text}」の次に来そうな言葉 TOP5")
for p, i in zip(top.values, top.indices):
    print(f"  {tokenizer.decode([int(i)])!r:>12}  {p.item():6.1%}")

筆者の環境での実際の出力です。

「日本でいちばん高い山は」の次に来そうな言葉 TOP5
          '富士'   17.4%
           '、'   12.8%
           '「'    9.8%
           '？'    6.9%
          'どれ'    6.6%

「富士」が1位なのは納得ですが、確率は17.4%にとどまり、「、」や「「」も候補に残っていることが分かります。AIが迷いながら言葉を選んでいる様子が、数字で見えるわけです。

チャットの書式を使わない短い文章なので、ここではGGUFのトークナイザーをそのまま使っても問題ありません。同じ方法で、Q4_K_M版と圧縮前のモデルの確率を比べれば、圧縮によってAIの判断がどれだけ変わったかを調べられます。こうした検証が、実際に配布されている圧縮ファイルのままでできるのが今回の大きな価値です。

パターン4：追加学習の入口

GgufConfig(dequantize=True) を指定すると、重みを展開した状態で読み込めます。こうすると、ふだんのTransformersの追加学習（ファインチューニング）の流れにそのまま乗せられます。

import torch
from transformers import AutoModelForCausalLM, GgufConfig

# GGUF を展開して、BF16 の通常のモデルとして読み込む
model = AutoModelForCausalLM.from_pretrained(
    "unsloth/Qwen3.5-4B-GGUF",
    gguf_file="Qwen3.5-4B-Q4_K_M.gguf",
    quantization_config=GgufConfig(dequantize=True),
    dtype=torch.bfloat16,
)

この書き方では、モデルはCPU側のメモリに読み込まれます（筆者の環境で確認）。MacのGPUに載せたい場合は、from_pretrained の引数に device_map="mps" を追加してください。

ただし、実務では次の点に注意してください。

失われた細かさは戻らない：Q4からBF16に展開しても、圧縮で捨てた情報は復元されません。「粗い写真を大きく引き伸ばした」状態です
メモリは展開後の大きさになる：筆者の実測でピーク14.4GB。学習を始めると、さらに増えます
本格的な学習は元のモデルから：圧縮前のモデルが公開されているなら、そちらから学習するほうが品質面で有利です

この方法は「手元にGGUFしかないモデルを、試しに少し調整してみる」ための入口と考えるのがよいでしょう。

筆者は、この書き方での読み込みと文章の生成までを確認しました。学習そのものは試していません。

第6章：うまく動かないときは

筆者が実際に遭遇した症状も含めて、確認する順番を図にしました。

うまく動かないときの確認順。1. 起動時にDequantizing the whole modelと出るなら、PyTorchを2.13に入れ直す。2. 同じ文をくり返す・回答が終わらないなら、サーバーは--reasoning onで起動し、Pythonでは元のQwenのトークナイザーを使う。3. ggml-attnが取れずsdpaに切り替えたと出るなら、そのままでも動く（少し遅くなる）のでネット接続を確認して起動し直す。4. メモリ不足で止まる・とても遅いなら、ほかのアプリを閉じ、小さいモデルやQ4_K_Mを選ぶ。それでも解決しなければ、表示されたメッセージを添えてTransformersのGitHub Issueで報告・検索する

図10：うまく動かないときの確認順。1と2は筆者が実際に遭遇した症状です（静止画）

ほかにも、実行中に表示されても気にしなくてよいメッセージがいくつかありました。

表示されるメッセージ	意味	対応
`Dequantizing the whole model, because no GGUF matmul kernel is published for this device`	計算部品が見つからず、展開方式に切り替わった	要対応。PyTorchを2.13に入れ直す
`You are sending unauthenticated requests to the HF Hub`	Hugging Faceにログインせずにダウンロードしている	気にしなくてよい（ダウンロードの速さに影響する程度）
`No kernel mapping found for layer ...`	一部の計算は標準の方法で行う、というお知らせ	気にしなくてよい
`... is falling back to its reference PyTorch implementation ...`	一部の処理が標準の実装で動いている	気にしなくてよい
`[ERROR] image_like_kwargs is part of ... docstring`	開発版の内部の説明文に関するチェック	気にしなくてよい（動作には影響しない）

最初の1行以外は、筆者の環境ではすべて正常に動いている状態で表示されたものです。「ERROR」と書かれていても動作は止まらなかったので、慌てずに回答が出るかを確認してください。

まとめ

この記事の要点を振り返ります。

GGUFは、AIモデルの重み・言葉の辞書・会話の書式をまとめた「全部入りの1ファイル」で、パソコンでAIを動かす世界の標準フォーマット
量子化は数字の細かさを落としてファイルを小さくする技術。Qwen3.5-4Bなら8.42GBが2.74GB（Q4_K_M）になる
これまでは、Transformersで読むと元の大きさに展開され、メモリが何倍にも膨らんでいた（実測で約22GB）
今回から、Apple SiliconのMacなら、llama.cppの計算部品を借りて圧縮したまま動く（実測で約4.5GB・展開方式の約4倍の速さ）
同じファイルで、チャット用のAPIサーバー、AIの中の観察、品質の評価、追加学習の入口までTransformersで扱える
2026年9月23日時点では、PyTorchを2.13に固定すること、思考モードの設定かトークナイザーを工夫することが、つまずかないためのポイント

「動かす国」と「作る・調べる国」の間にあった壁は、この一歩でかなり低くなりました。今はMacとQwen系モデルに限られていますが、公式は対応モデルを順次増やす方針で、将来的には画像や音声のモデルにも広げたいとしています。

次のステップ

まずはパターン1で、自分のMacの中だけで動くチャットを体験してみる
開発者の方はパターン3を応用して、Q4_K_MとQ6_Kで次の言葉の確率がどう違うかを比べてみる
より大きな Qwen3.5-35B-A3B（MoE型）も、公式のドキュメントに読み込み例があります。メモリに余裕がある方は試してみてください

参考リソース

Hugging Face Blog「Transformers now runs llama.cpp quants」（2026年9月22日）：https://huggingface.co/blog/transformers-llama-cpp-quants
Transformers ドキュメント「GGUF」：https://huggingface.co/docs/transformers/main/en/gguf
使用したモデル（unsloth/Qwen3.5-4B-GGUF）：https://huggingface.co/unsloth/Qwen3.5-4B-GGUF
uv 公式ドキュメント：https://docs.astral.sh/uv/
Jan 公式サイト：https://jan.ai/

検証環境：MacBook Pro（Apple M5 Max・メモリ128GB）、macOS 26.6.2、Python 3.12.14、PyTorch 2.13.0、Transformers 5.18.0.dev0（2026年9月23日時点の開発版）、kernels 0.17.1。記事中の実測値・出力例は、すべてこの環境で筆者が実行した結果です。開発版は日々更新されるため、記事の手順や症状は今後変わる可能性があります。