Ainz Diary Blog

OllamaでHugging Faceの量子化モデルが500エラーで動かない話（Unsloth GGUFの互換性とllama.cppという選択肢）

最近、Ollama を使ってローカルLLMを動かして遊んでいます。クラウドのAPIを叩くのとは違って、手元のPCで完結するのが楽しくて、ついつい色々なモデルを試したくなってしまいます。

そんな中で「Hugging Faceから有名どころの量子化モデルを取ってくれば、もう少し快適に動くのでは？」と思って試したところ、500 Internal Server Error で見事につまずきました。今回はその顛末と、調べてわかった原因・対処法、そして最終的に思ったことをメモとして残しておきます。

きっかけ：コンテキストサイズを上げると精度は上がるが、遅い

Ollama公式サイトから取得したモデルで遊んでいて、まず気づいたのが「コンテキストサイズ（num_ctx）を大きくすると出力の精度は良くなるけれど、その分どんどん遅くなる」という現象でした。

最初は「なぜコンテキストを広げただけでこんなに遅くなるんだろう？」と不思議だったのですが、調べてみると、これはGPUのメモリ（VRAM）に乗り切っていないことが関係していそうだとわかりました。

仕組みとしては、こういうことのようです。

LLMは会話の文脈を「KVキャッシュ（Key-Valueキャッシュ）」という形でメモリに溜め込みながら推論します。
このKVキャッシュは、コンテキストを広げる（トークン数を増やす）ほど、ほぼ比例して大きくなります。コンテキストを倍にすれば、キャッシュもおおよそ倍です。
モデル本体とKVキャッシュがVRAMに収まっているうちは高速ですが、収まり切らなくなった瞬間に、はみ出した分がCPU側のメインメモリにオフロードされます。
このGPU↔CPUのやり取りが発生すると、速度が一気に落ちます。資料によっては、毎秒50〜100トークン出ていたのが毎秒2〜5トークンまで、つまり20〜50倍も遅くなることがあるそうです。

つまり「精度を上げようとコンテキストを広げる → KVキャッシュが膨らむ → VRAMからあふれる → CPUに逃がす → 激遅」という流れだったわけです。なるほど、と納得しました。

それなら量子化モデルだ、と思ったのですが……

VRAMに乗り切らないのが原因なら、もっと軽い（＝メモリ消費の少ない）モデルを使えば良いはず。そう考えて、Hugging Faceにある有名どころの量子化モデル、特に Unsloth が公開しているGGUF形式の量子化モデルを試してみることにしました。量子化を強めれば、その分メモリにも収まりやすくなって処理も速くなるだろう、という期待です。

（途中で「LM Studio を使えばこのあたりは丸ごと解決しそうだな」とも思ったのですが、せっかくOllamaに慣れてきたところなので、まずはOllamaで粘ってみることにしました。）

ところが、いざ実行してみると、こうなりました。

ollama run hf.co/unsloth/gemma-4-E4B-it-GGUF:Q4_K_M
Error: 500 Internal Server Error: unable to load model:

モデルのダウンロード自体は成功しているのに、いざロードしようとすると 500 Internal Server Error で落ちてしまいます。

原因を調べてみる

ググってみると、まったく同じ現象に遭遇している人がたくさんいました。GitHubのIssueやHugging Faceのディスカッションでも報告が上がっていて、どうやらこれは自分の環境固有のミスというより、Ollama側の対応状況に起因する問題のようです。

要点だけ簡潔に知りたかったので Perplexity でも聞いてみたところ、整理された答えが返ってきました。それも踏まえてまとめると、原因はこういうことのようです。

UnslothのGGUF（特に新しいアーキテクチャの-itバージョン）が、Ollamaとうまく噛み合っていない。 新しいモデル（Gemma 4 など）の量子化版で頻発しています。
ビジョン（マルチモーダル）対応モデルは、画像処理用の「mmproj」ファイルがGGUF本体とは別ファイルに分かれている。 この「本体とビジョンが別ファイルに分割されたGGUF」を、現状のOllamaはうまく読み込めません。
その結果、ダウンロードは通るのに、ロード時に内部エラー（テンソルの境界外参照や不完全ファイルとして認識される、など）が起きてしまう、というわけです。

要するに「Ollamaが、そのモデルの形式・構成にまだ追いついていない」状態ですね。自分の設定が悪いわけではなかったので、その点は少し安心しました。

解決策の候補

調べた範囲では、対処法としてはおおむね次の3つが挙がっていました。

1. Modelfileを手動で作り直す（テキストモードで動かす）

問題がビジョン用のmmprojまわりなら、その部分を取り除いてテキスト専用として動かしてしまえばよい、という発想です。

# 既存モデルのModelfileを書き出す
ollama show --modelfile hf.co/unsloth/gemma-4-E4B-it-GGUF:Q4_K_M > Modelfile.custom

# 書き出したModelfileから、ビジョン関連（mmprojなどの記述）を削除・コメントアウトする

# 加工したModelfileから新しいモデルを作成
ollama create custom-gemma4 -f Modelfile.custom

# 実行
ollama run custom-gemma4

2. 代替モデルを使う

そもそもOllama公式や、llama.cpp互換が確認できているGGUFを選ぶ、という素直な方法です。

# Ollama公式側で配布されているものを使う
ollama run gemma4:e4b

Unsloth以外の量子化版を探すか、後述するllama.cppで直接動かすのも手です。

3. Ollamaを更新する／入れ直す

そもそもバージョンが古くて未対応、というパターンもあります。実際、Ollama側でllama.cppの組み込みが更新されたバージョン以降は、テキスト専用版であればUnslothの量子化モデルが動くようになった、という報告もありました。

# Ollamaを最新版に更新したうえで、

# 一度モデルを削除して
ollama rm hf.co/unsloth/gemma-4-E4B-it-GGUF:Q4_K_M

# pullし直す
ollama pull hf.co/unsloth/gemma-4-E4B-it-GGUF:Q4_K_M

なお、どうしてもビジョン機能（画像入力）まで使いたい場合は、現状はOllamaよりllama.cppを直接使うほうが確実そうです。

「直せそうだけど、本末転倒かも」と思った話

解決策を眺めていて、正直に思ったのは「Modelfileを加工すれば直せそうだけど、なんだかなあ」ということでした。

理由は2つあります。

ひとつは、モデルを自分で加工して管理するのが、地味に面倒くさいこと。モデルごとにModelfileを書き出して、ビジョン部分を消して、create し直して……というのを毎回やるのは、遊びの範囲だと億劫です。
もうひとつは、ollama list でモデルをまとめて管理できるという、Ollabaを使う最大の利点が薄れてしまうこと。手元で加工したカスタムモデルが増えていくと、「結局これは何を元にしたモデルだっけ？」と分からなくなりがちで、せっかくの手軽さが台無しです。これでは本末転倒な気がしました。

だったらllama.cppを直接使うほうが早いかも

ここまで来て思ったのは、「モデルを加工してまでOllamaにこだわるくらいなら、いっそ llama.cpp を直接使ったほうが早いのでは？」ということです。

そもそも今回エラーになったような「本体とビジョンが別ファイルに分かれたGGUF」や、新しいアーキテクチャのモデルは、llama.cpp側では先行して対応していることが多いです。Ollamaはそのllama.cppを内部で使いつつ、扱いやすくラップしてくれている存在なので、Ollamaが未対応のものは、大元のllama.cppを直に叩いたほうが動くケースがある、というのは理屈としても納得できます。

もちろん、llama.cppを直接使うと、Ollabaが提供してくれていた「モデルの一元管理」「サーバーの起動の手軽さ」といった快適さは手放すことになります。なので、

手軽さ・モデル管理のしやすさを優先するなら → Ollama（＋公式モデルや、対応が確認できたモデル）
最新・特殊なモデルや、ビジョン込みでとにかく動かしたいなら → llama.cppを直接

という使い分けに落ち着きそうだな、と今のところは考えています。

まとめ

今回は、OllamaでHugging Face（Unsloth）の量子化GGUFを動かそうとして 500 Internal Server Error に遭遇した話をまとめました。改めて整理すると、

コンテキストを広げると精度は上がるが、KVキャッシュが膨らんでVRAMからあふれると激遅になる
Unslothの新しいGGUF（特にビジョン対応・mmprojが別ファイルのもの）は、現状のOllamaだと読み込めず500エラーになることがある
対処は「Modelfileを加工してテキスト専用化」「代替モデル」「Ollama更新・入れ直し」あたり
ただしモデルを加工すると管理が面倒で、ollama list の手軽さという利点も薄れてしまう
特殊・最新モデルをとにかく動かしたいなら、いっそllama.cppを直接使うほうが早そう

という感じでした。

ローカルLLMは、動かすところまでが半分趣味みたいなところがあって、こういうエラーにぶつかるのも含めて結構楽しいです。次はllama.cppを直接触ってみて、Ollamaとの使い心地の違いも記事にできたらいいなと思っています。

参考文献

この記事は、以下の情報を参考に作成しました。より詳しい内容や最新情報は、各リンク先をご確認ください。