Local LLM 関連の用語メモ

中古のMacBook Pro（M1 Max 64GB）を20万円ほどで運良く購入し、ローカル LLM を触り始めたので、よく見る用語をここに置いておく。詳しい比較は各節末のリンクを参照する。

GGUF

GGUF は llama.cpp 系の量子化モデル用ファイル形式である¹。量子化済みの重み、トークナイザ、チャットテンプレートなどを 1 つの .gguf ファイルにまとめる。

llama.cpp 互換のランタイム（Ollama、LM Studio、Atomic Chat など）で動く
Mac、Linux、Windows、CPU のみ、クラウド GPU など、Apple Silicon 以外でも使える
量子化方式の選択肢が多い（Q4_K_M、Q5_K_M、Q8_0 など）

Hugging Face から .gguf を落として Ollama 等で動かす、という流れでよく出てくる。

量子化（GGUF のファイル名）

GGUF のファイル名に付く Q4_K_M や UD-Q4_K_XL などは、重みを何 bit でどう圧縮したかを表す。同じベースモデルでも、これでファイルサイズと品質のトレードオフが変わる。

ファイル名の読み方

Q4 / Q5 / Q8：おおよその量子化レベル。数字が大きいほど高精度で、ファイルも大きい
_K：k-quants。llama.cpp が層や行列ごとに bit 配分を変える方式。旧来の Q4_0 などの均一量子化より品質が出やすい
_M / _S / _L / _XL：k-quants 内のプリセット（どの行列を何 bit にするかのレシピ）。ファイルサイズの S/M/L/XL とは別物

`Q4_K_M`

llama.cpp 由来の定番プリセットである。重要な行列には Q6_K など高めの精度を当て、それ以外は Q4_K にする、といった層ごとの bit 配分が決まっている。

Q4 帯でバランスを取りたいときの無難な選択肢としてよく見る。

`UD-Q4_K_XL`

UD は Unsloth Dynamic の略称である。 Unsloth が独自のキャリブレーションデータセットを使い、行列ごとに量子化の強さを動的に決める方式。

XL は「特大ファイル」の意味ではない。 Unsloth 側の上位プリセットで、重要な行列には Q5_K などを当てる（Q4_K_M は同じ箇所を Q6_K 寄りにする、などレシピが違う）。その結果、UD-Q4_K_XL の方が Q4_K_M よりファイルが小さいこともある。

Unsloth 公式は Qwen3 などで、可能なら UD-Q*_XL 系を推奨している。 Hugging Face では量子化バリエーションが多く、UI 上で UD-* が見つけにくいことがある（ファイル一覧が折りたたまれる等）。

`IQ4_XS` と `Q4_K_M`

IQ4_XS と Q4_K_M は、どちらも 4 bit 級だが、量子化方式の系統が異なる。

Q4_*：Q-quant 系。Q4_0 や Q4_1 は旧来のブロック量子化で、Q4_K_M は K-quant のプリセットである
IQ4_*：I-quant 系。IQ4_XS は重要度を考慮した量子化方式で、IQ4_NL は非線形な量子化方式である

IQ と Q の違いを、単に「importance matrix を使ったかどうか」と考えるのは正確ではない。通常の Q4_K_M も、量子化時に importance matrix を指定できる。 IQ4_XS と Q4_K_M は、重みを GGUF に格納する基本的なエンコーディング自体が異なる。

ファイル名の 4 も、すべての重みが厳密に 4 bit であることを意味しない。 llama.cpp の量子化形式一覧では、IQ4_XS は 4.25 bpw、IQ4_NL は 4.50 bpw とされている。 Q4_K_M は複数の量子化方式を組み合わせるプリセットなので、平均的な bit 数はモデルやテンソルの配分によって変わる。 bpw は bits per weight の略で、量子化データの平均的な bit 数を表す。

同じファイルサイズなら IQ4_* の方が高品質になる場合もあるが、モデル、キャリブレーションデータ、バックエンドによって結果は変わる。 llama.cpp の対応表では、I-quants は CPU、ARM、Metal、Vulkan で同程度の K-quants より遅い扱いになっているため、Mac では品質だけでなく生成速度も比較したい。

QAT

QAT（Quantization-Aware Training）は量子化認識学習である。学習や微調整の段階から量子化（低 bit 化）を見越して重みを最適化する。

PTQ（Post-Training Quantization）：学習済みモデルをあとから量子化するだけ（Q4_K_M や UD-Q4_K_XL で .gguf に落とす、など）。手軽だが精度落ちが出やすい
QAT：学習中に量子化の影響をシミュレートしながら調整する。同じ bit 数でも PTQ より品質が出やすい

Hugging Face などでは qat-UD-Q4_K_XL のように qat- プレフィックスが付くことが多い。同じ UD-Q4_K_XL 系のレシピでも、QAT 版は非 QAT 版と品質が互角以上なのに推論が速い、という報告もある²。

同じモデルに QAT 版があるなら、まず QAT 版を試すのが無難である。 QAT 版が存在しない量子化レベルしか載らない場合だけ、非 QAT を選ぶ。

MLX

MLX は Apple が公開している Apple Silicon 向けの機械学習フレームワークである。

GGUF のような単一ファイル形式ではなく、mlx_lm.convert などで変換すると safetensors の shard、config.json、tokenizer というディレクトリ構成になる
macOS と Apple Silicon（M1 以降）専用。他プラットフォームでは動かない
統一メモリを活かした推論向け。小〜中規模モデルでは生成速度（tok/s）が速いことが多い一方、prefill（入力を読む処理）が遅いケースもある
Hugging Face の mlx-community などから配布される「MLX モデル」は、このフレームワーク向けに変換された重みを指す

GGUF と MLX はランタイムが別である。 .gguf を MLX でそのまま読むことはできない。

mlx-vlm

mlx-vlm は MLX 向けの Vision-Language Model（VLM）ライブラリである。テキストだけの mlx-lm と並ぶ MLX 系パッケージのひとつ。

画像の説明、画像についての Q&A、複数画像の比較など、テキストと画像の推論向け
mlx-community 上の VLM 系モデル（名前に VL、Vision、mllm などが付くもの）を MLX で動かすときに使う
同系統に mlx-audio（音声）などもあり、モダリティごとにパッケージが分かれている

vllm-mlx

vllm-mlx は Apple Silicon 向けに vLLM ライクな API を提供するフレームワークである（waybarrios/vllm-mlx）。

mlx-lm、mlx-vlm、mlx-audio などを vLLM 風に統一的に扱える（Python API とローカルサーバの両方）
vllm-mlx serve で OpenAI API 互換の HTTP サーバを立てられる（/v1/chat/completions など）
Paged KV Cache、continuous batching など vLLM 系の機能を MLX 上で再現する。参照記事では処理 1.14 倍速、メモリ 80% 節約と紹介されている
本体の vLLM は Metal/MPS 未対応（Mac は CPU のみ experimental）なので、Mac ネイティブ GPU で vLLM 的な運用をしたいときの選択肢になりやすい
Harmony や reasoning 系モデル（gpt-oss、LLM-jp-4 Thinking など）は --reasoning-parser 付きで扱えるケースがある（mlx-lm 単体より向くことがある）

MTP

MTP（Multi-Token Prediction）は投機的デコード（speculative decoding）の一種である。通常は 1 トークン生成ごとにモデルを 1 回走らせる。 MTP 対応モデルは複数の未来トークンを先読み（draft）し、本体モデルがまとめて検証する。

生成に必要な forward pass 回数を減らして出力を速くする。Unsloth では Qwen3.6 で精度を落とさず約 1.4〜2.2 倍速い、としている
MTP 対応 GGUF は通常版と別リポジトリ（例 unsloth/Qwen3.6-27B-MTP-GGUF）。モデル本体に MTP 用の draft テンソルが含まれる
llama.cpp では --spec-type draft-mtp --spec-draft-n-max 2 などで有効化する。--spec-draft-n-max は draft 数。多いほど速くならない。2 前後が無難で、ハードウェア依存
メモリはやや増える（目安 ~1 GB 程度の余裕）。Atomic Chat など一部ランタイムでも MTP 対応あり
Qwen3.5、Qwen3.6 系で Unsloth が GGUF を公開している。Dense モデルの方が MoE より加速率が出やすい、というベンチ結果もある

量子化（UD-Q4_K_XL 等）とは独立した話である。同じ量子化レベルでも、MTP 版 GGUF と MTP 対応ランタイムの両方が必要になる。