GGUFモデルをローカルで実行する方法:Ollama、llama.cpp、vLLM

.gguf ファイルをダウンロードしたけれど、実際にはどう動かすの?最短ルートは ollama run hf.co/<repo>:Q4_K_M です。OllamaがHugging FaceからGGUFを直接pullしてサーブしてくれます。 GGUFはllama.cppが生み、今やすべてのローカルLLMツールが話す単一ファイルのモデル形式です。同じファイルがOllama、llama.cpp、LM Studio、Jan、そして(但書付きで)vLLMで動きます。このガイドでは各ランナーをコピペできるコマンドとともに扱い、VRAMに合う量子化の選び方と、実際に遭遇するロードエラーを解説します。

GGUFファイルとは何か?

GGUF(GGML Universal File)は、量子化された言語モデル用のコンテナ形式です。1つのファイルに重み、トークナイザー、モデルのメタデータが入ります。追加のダウンロードも、設定ファイルのスープも必要ありません。中の重みは 量子化済み です。16bit浮動小数点から4bit(あるいはそれ以下)の整数へ圧縮されていて、フル精度で約18GB必要な9Bモデルが、Q4ファイルなら約5.5GBに収まり、ゲーミングGPUどころかCPUでも動く、というわけです。

GGUFファイルの名前で重要なのは2つ:

1. ベースモデル — gemma-3-4b-it-GGUF はGemma 3 4Bをfine-tuneしてGGUFへ書き出したものです。
2. 量子化タグ — Q4_K_M、Q8_0、IQ4_XS の仲間たちが、重みをどれだけ強く圧縮したかを示します。選び方は下で。

OllamaでGGUFモデルは動かせる?

はい。GGUFはOllamaのネイティブ形式で、2024年以降はファイルに一切触れずにHugging Faceから直接pullできます:

# Hugging FaceからGGUF量子化を直接pullしてチャットする
ollama run hf.co/bartowski/gemma-2-9b-it-GGUF:Q4_K_M

# コロンの後の量子化タグがリポジトリ内のファイルを選ぶ
ollama run hf.co/ggml-org/gemma-3-4b-it-GGUF:Q8_0

すでに自分で .gguf ファイルをダウンロード済みなら、Modelfileを向けます:

# Modelfile — 1行で十分
FROM ./gemma-2-9b-it-Q4_K_M.gguf

ollama create gemma9b -f Modelfile
ollama run gemma9b

OllamaはGPUオフロードを自動で決め、ポート11434にOpenAI互換APIを公開します。そのAPIを話すものなら何でもこのモデルを使えます。代償は制御力です。GPUに何層乗るかは選べません。

GGUFファイルをllama.cppで実行するには?

llama.cppはGGUFの生みの親です。形式自体がこのために存在するので、サポートは最深かつ最新です。llama-server バイナリは、チャットUIとOpenAI互換エンドポイントの両方を提供します:

# Hugging Faceから直接ダウンロード(自分のマシンに合うGGUFを選んでくれる)
llama-server -hf ggml-org/gemma-3-4b-it-GGUF --port 8080

# または手元にあるファイルを、GPUフルオフロードで実行
llama-server -m ./gemma-2-9b-it-Q4_K_M.gguf -ngl 99 --port 8080

-ngl 99 は99層をGPUへ積みます。VRAMが許すより低く設定すれば、残りはCPUに留まります。この部分オフロードのダイヤルこそllama.cppの十八番です。9Bモデルは48層のうち20層をオフロードするだけで6GBカードでも動きます。ただし遅くなります。サーバーではなく単発のプロンプトなら、llama-server を同じ -m フラグを持つ llama-cli に替えてください。

LM Studioは同じエンジンのデスクトップGUI版です。 .gguf ファイルをmodelsフォルダに放り込むか(アプリ内でHugging Faceを検索しても)、loadを押すだけです。道具選び自体はOllama vs LM Studio比較が扱っています。

どのGGUF量子化をダウンロードすべき?

デフォルトの答えは Q4_K_M です。コミュニティのスイートスポットで、フル精度の品質から1〜2%以内にありながら、サイズは約4分の1です。大きい順の階段はこうなります:

• Q8_0 — ほぼロスなし。VRAMが8.5bit/重みを気づかず飲み込めるならこれを。
• Q6_K / Q5_K_M — ひと回り小さく、30B以上のモデルならまだ優秀です。
• Q4_K_M — デフォルト。7〜14Bモデルでは、品質対GBがここでピークになります。
• IQ4_XS / Q3_K_M — 大きなモデルを小さなカードへ押し込む用。品質劣化が目につき始めます。
• Q2_K 以下 — 最終手段。モデルが文の途中で意味不明になり始めます。

収める目安は、ファイルサイズ(GB)+ コンテキストのオーバーヘッド約1〜2GBがVRAMに収まることです。9Bモデルの4.7GBのQ4_K_Mは8GBカードで余裕です。ひどい量子化の大きなモデルより、 高い量子化の小さなモデル を選びましょう。Q8の4BはたいていQ2の9Bに勝ちます。

GGUF vs Safetensors:必要なフォーマットはどっち?

Safetensorsは 非量子化 のアーカイブ形式です。トレーニング、fine-tuning、transformersやComfyUI向けのフル精度重みです。GGUFは自分のハードウェアで推論するための 量子化済み・実行可能 形式です。GGUFはfine-tuneできませんし、safetensorsファイルは変換なしではOllamaやllama.cppで動きません(llama.cppの convert_hf_to_gguf.py スクリプトはそのためのものです)。ルール:トレーニングや画像パイプライン → safetensors。ローカルチャットとサービング → GGUF。検索が「gguf vs safetensors」から始まったのなら、この切り分けが答えのすべてです。

GGUFランナーはどれを使うべき?

ランナー	向いている用途	インストール	GPUオフロード	OpenAI互換API
Ollama	入れたら忘れる常設サービス	curl 1行	自動	あり(:11434/v1)
llama.cpp	最大の制御、最新機能	ビルド or パッケージマネージャ	手動の -ngl ダイヤル	あり(llama-server)
LM Studio	デスクトップGUI、モデル閲覧	アプリDL	自動	あり(ローカルサーバー)
vLLM	バッチのマルチユーザーサービング	pip install vllm	自動	あり(ネイティブ)

ブート時に立ち上がって見えなくなることを望むならOllamaです。筆者のhomelabでも、ネットワーク上の全員にモデルをサーブする役を担っています。機能が登場した当日に使いたい(新しいアーキテクチャはまずここに着地します)か、レイヤー単位のメモリ制御が要るならllama.cpp。GUIならLM Studio。1つのモデルを多数の同時ユーザーにサーブさせるときだけvLLMです。GGUFサポートは動きますが、ネイティブ形式と比べると二級の扱いです。

GGUFモデルがロードできないのはなぜ?

大半のケースをカバーする4つのエラー:

1. unknown model architecture — ランナーの誕生より後のアーキテクチャをGGUFが使っています(新しいMoEやビジョンモデルは絶えず登場します)。Ollamaを更新するかllama.cppをビルドし直してください。他の直し方は存在しません。
2. ロード時のメモリ不足 — 量子化がVRAM + コンテキストに対して大きすぎます。1段下げる(Q4_K_M → Q3_K_M)、-ngl を下げる、-c 4096 でコンテキストを縮める。
3. ダウンロードの中断・破損 — マジックナンバーかメタデータのエラーでロードが失敗します。再ダウンロードして、Hugging Faceページに表示されるSHA256と照合してください。
4. ollama run ./model.gguf が拒否する — これは仕様通りです。Ollamaの run はモデル名を受け取るのであって、ファイルパスを受け取るのではありません。上に示したModelfileルートを使ってください。

最後にひとつ、知っておく価値のある角度を。ローカルGGUFエンドポイントはエージェント型コーディングツールと相性が良いです。OpenAI互換クライアントを向ければ、completionsのコストは電気代だけです。このガイドの配管が動くようになったあと、どのモデルがその枠に値するかはローカルコーディングLLMのベストで検証しています。