開発ログ2026年6月5日by K.hirano

gemma4:12bがollamaで直った — 0.30.5で3層バグ全解消を実測確認【回避策は不要に】

gemma4:12bのSIGFPE、macOS専用配布、日本語崩れを同一環境で実測。ollama 0.30.5で何が直り、何を捨ててよいかを整理します。

#Ollama#gemma4#dev-log#LLM#実測

gemma4:12b は ollama 0.30.5 で直りました。SIGFPE・macOS専用配布・日本語崩れの3層バグが半日で全部解消され、公式タグで素直に動きます（4070Ti実測52t/s）。回避策は引退、残る作法は think:false だけです。前日に「壊れている」を記録した同一環境・同一条件で答え合わせしました。

関連記事としては BlogGemma 4 E4B、ランクS確定——24問採点とOCR比較でわかった得意・苦手RTX 4070 TiとOllama v0.20.0でGemma 4 E4Bを実機検証。24問218点のS評価、論理・コード満点、OCRはQwen3-VL 8Bと比較して速度優位を確認。→ もあわせて読むと、今回の論点とのつながりを把握しやすくなります。

この記事で分かること

結論から言うと、gemma4:12b は ollama 0.30.5 で直りました。公式タグで素直に動き、回避策は不要、残る作法は think: false だけです。

この記事では、前日まで再現していた SIGFPE / macOS専用配布 / 日本語崩れ の3層バグが、いつ・どこで・何が直ったのかを、同一環境・同一条件の実測で答え合わせします。

まず結論: 直った、公式タグで動く、回避策不要、think:falseだけ残る

gemma4:12b は、少なくとも私の検証環境では 2026-06-05 時点で素直に使える状態 になりました。

前日までの「壊れている」という評価は、もうそのままでは当てはまりません。ここははっきり言います。ollama 0.30.5 で SIGFPE は解消され、公式タグ gemma4:12b も Linux に降りてきて、GGUF の日本語崩れも修正されました。

つまり、以前やっていた以下の回避策は、原則として引退判断でよいです。

Modelfile で text blob を挟む
llama.cpp 経由で逃がす
「とりあえず動く別ルート」を維持し続ける

ただし、think: false だけはまだ必要です。ここを忘れると、「動いているのに空っぽに見える」ことがあります。gemma4 は思考モデルなので、出力が thinking 側に流れるためです。

この記事で検証したこと

前日に「壊れている」を記録した同一環境（RTX 4070 Ti 12GB）で、以下を実測しました。

検証項目	方法	結果
SIGFPE クラッシュ	前日クラッシュした経路そのもので再生成	✅ 0.30.5 で解消
公式タグの配布	`ollama pull gemma4:12b`（Linux）	✅ 取得成功・正常動作
日本語崩れ	同一質問・temp0・同一リポジトリ GGUF の新旧 blob 比較	✅ 再変換で解消
出力品質の定量化	24問テスト再計測（同一問題セット・同一採点基準）	✅ 173→186点（B→A）
速度・VRAM	サーバー報告値（eval_count/eval_duration）	52t/s・8.1GB（回避策版と同速）

導入手順そのものはBloggemma4:12bはollamaで動かない — 12GB GPUでllama.cpp実測52t/sの最短ルートollamaのHTTP 500やSIGFPEで詰まるgemma4:12bを、llama.cpp経由で12GB GPUに載せる実測手順と判断材料をまとめました。→に、GPU別の可否・速度はBloggemma4 12BはどのGPUで動く？実測3点＋主要18枚の速度早見表【VRAM 8GBは崖の縁】gemma4 12Bを手持ちGPUで動かす判断材料を、VRAM別・実測3点・主要18枚の速度早見表で整理。8GBの限界も明確にします。→にまとめてあるので、ここでは何が直ったかの答え合わせに絞ります。

1. 時系列: 直ったのはいつか

UTC で整理します。JST は混ぜません。

2026-06-04 朝: ollama 0.30.4 で 3 層切り分け検証。SIGFPE、配布形態、日本語崩れを確認
2026-06-04 15:42 UTC: ggml-org 側で GGUF 再変換
2026-06-04 17:00 UTC: ollama v0.30.5 リリース。リリースノートに Fix gemma4:12b floating point exception crash と明記
2026-06-05: 同一環境で再検証。公式タグ gemma4:12b が使えること、日本語崩れが消えたことを確認

ここまでが一次ソースで確認できた事実です。原因の推測と分けて、まず事実だけを時系列で固定しておきます。

この流れを見ると、day-one の壊れたモデルが半日で直る、かなり珍しいケースです。現場では「昨日ダメだったのに今日いける」が一番ややこしい。だからこそ、時系列を切って残す意味があります。

2. 何が直ったのか: 3層を分けると見えやすい

今回の問題は、ひとまとめにすると見誤ります。私の検証では、少なくとも次の3層に分かれていました。

層	修正前（2026-06-04 朝・0.30.4）	修正後（2026-06-05・0.30.5）
ランタイム	generate で SIGFPE クラッシュ	✅ 解消（リリースノートに修正明記）
配布	12b系タグは macOS 専用（412）	✅ 公式タグ `gemma4:12b`（7.6GB）が Linux に配布開始
モデル	「三千島」幻覚＋トークン分裂	✅ GGUF 再変換で正常な日本語に

2-1. SIGFPE: 0.30.5 で解消

前日まで、gemma4:12b は ollama 上で floating point exception を起こしていました。

これが 0.30.5 で修正され、同一環境の 4070Ti 12GB で再現しなくなった のが今回の大きな変化です。前日に実際にクラッシュしていた経路（HF から GGUF を直 pull → generate）そのものでも、0.30.5 では正常に生成できることを確認しました。

ここで原因の見立てを一段戻す必要が出ました。壊れている原因がハード寄りに見えても、実際にはランタイム側の修正で落ちなくなることがあります。だからこそ、GPUだけを疑って終わると外します。

2-2. macOS専用配布: Linux にも公式タグが来た

前は 12b 系の扱いがやや特殊で、macOS 専用配布 という見え方をしていました。

それが今回、gemma4:12b（7.6GB）が Linux にも配布開始 され、ollama pull gemma4:12b でそのまま導入できるようになりました。

ここは実務上かなり大きいです。以前は、回避策として Modelfile や llama.cpp に逃がす判断が必要でした。今は少なくとも、公式タグをまず試す という順序でよくなっています。

2-3. 日本語崩れ: GGUF 再変換で修正

もう一つの問題は、日本語出力の崩れ です。

前日検証では、同一質問「日本の四季について教えてください」を temp0 で投げると、修正前は 「三千島」幻覚 や、トークン分裂っぽい不自然なスペースが出ていました。

ここは因果を雑にしないために、前日と同じ ggml-org リポジトリの GGUF を再 pull して（blob が新しいものに置き換わっていることを digest で確認したうえで）、同一質問・temp0 で比較しました。結果、桜・お花見・三寒四温 を含む、普通の構造化された日本語に戻っています。つまり「同じ配布元の変換物が、再変換の前後で直った」ことを直接確認できました。

なお、新しく登場した公式タグ gemma4:12b（こちらは別の変換物・vision/audio 込み 7.6GB）でも、同じ質問で正常な日本語を確認しています。どちらの経路でも日本語は直っています。

これは単なる見た目の差ではありません。実務では、こういう崩れがあると「文章生成はできるが、そのまま社内文書には使えない」という判断になります。地味ですが、この差は効きます。

3. 同一条件の before/after: 比較はここだけを見る

比較は条件を揃えないと意味がありません。なので、ここでは 同一質問・temp0・同一GPU だけを見ます。

3-1. 比較条件

GPU: 4070Ti 12GB（同一機）
温度: temp0
質問: 「日本の四季について教えてください」
モデル: 同じ ggml-org リポジトリの GGUF（Q4_K_M）。修正前=旧 blob／修正後=再変換後の新 blob（digest が別物であることを確認済み）

3-2. 修正前

三千島 のような幻覚が混入
文章の途中に不自然な分裂やスペース
日本語としてのまとまりが崩れる

3-3. 修正後

桜、お花見、入道雲など、季節の説明が自然に出る
構造化された日本語として読める
そのまま実務のたたき台に使えるレベルまで戻る

この比較で重要なのは、「日本語が出るようになった」ではなく、「崩れ方が消えた」 という点です。

4. 24問テスト: 日本語は+16点、ただし読み方に注意

24問の再計測では、次の結果でした。

D（日本語）: 29 → 45点（+16）
総合: 173/240（B） → 186/240（77.5%・A）

俳句問題では、以前 松尾芭人 と崩れていた固有名詞が、今回は満点回答になりました。これはわかりやすい改善です。

ただし、ここで一つ注意があります。A/B/C の微差は、ランタイム相違（llama.cpp day-one → ollama 0.30.5）込み です。なので、これをそのまま「ollama のほうが全体的に上」と読むのは雑です。

正しくは、ビルド成熟度の差として読む のが妥当です。

ここを間違えると、比較の意味が変わります。モデルそのものの差というより、同じモデルがどこまで整っているか を見ている、という理解が近いです。

4-1. なお、完璧になったわけではない

新たな粗もあります。

A3 でデーヴァナーガリー文字の混入が 1 箇所
C2 は、メカニズム説明は正しいのに出力値を誤答

なので、「直った」は「完璧になった」と同義ではありません。

これは大事です。つい持ち上げたくなりますが、そこは違います。実務では、直った点と残る癖を分けて見ないと判断を誤ります。

5. 速度とメモリ: 移行コストはほぼゼロ

速度面の結果も、回避策を捨てやすい材料です。

52.2〜52.7 t/s
VRAM 8.1GB
GPU 使用率 100%
4070Ti 12GB で回避策版と同速（52.25 t/s）

つまり、公式タグへ移行しても速度面のコストはゼロ でした。

これは実務ではかなり大きいです。見た目が直っても遅くなるなら話は別ですが、今回はそうではありません。だから、少なくとも速度を理由に回避策を残す必要は薄いです。

ただし、8GB帯は引き続き崖の縁 です。VRAM 実測 8.1GB なので、8GB カードではまだ余裕がありません。ここは以前の判断を変えていません。

GPU 別の可否や速度は、早見表記事を見たほうが早いです。

gemma4:12b GPU速度ガイド（2026）

6. いま何をすればいいか: 回避策の引退判断

ここが一番大事かもしれません。回避策を組んだ人がいちばん気になるのは「いつ捨てていいのか」だと思います。

6-1. もう公式タグを試してよい

次の条件に当てはまるなら、まず ollama pull gemma4:12b を試してよいです。

gemma4:12b が動かないという古い情報を見て迷っている
SIGFPE が原因で止まっていた
Modelfile や llama.cpp 迂回を入れている
公式対応を待つべきか、もう戻すべきか判断したい

この場合、今は 回避策を維持するより、公式タグへ戻す のが自然です。

6-2. まだ `think:false` は必要

ただし、繰り返しますが think:false は必要 です。

/api/generate よりも /api/chat + think:false のほうが確実でした。gemma4 は reasoning モデルなので、ここを外すと「反応がない」と誤認しやすいです。

bash

# 0.30.5 以降の最短手順（これだけで動きます）
ollama pull gemma4:12b

curl localhost:11434/api/chat -d '{
  "model": "gemma4:12b",
  "messages": [{"role": "user", "content": "こんにちは"}],
  "think": false,
  "stream": false
}'

なので、今の作法はこうです。

モデル本体の回避策: 不要
推論の見え方対策: think:false を付ける

この切り分けだけ覚えておけば十分です。

7. 読者が共有・検証するときのポイント

もし社内やチームで共有するなら、次の順で伝えると誤解が減ります。

ollama 0.30.5 で gemma4:12b の SIGFPE は修正済み
公式タグ gemma4:12b が Linux でも配布開始
日本語崩れも GGUF 再変換で改善
速度は回避策版と同等
残る注意点は think:false

逆に、次の言い方は避けたほうがいいです。

「完全に別物になった」
「もう何も気にしなくていい」
「どの GPU でも同じ」

そこまで言うと、実態から外れます。現場では、直ったけどまだ作法は残る くらいがちょうどいいです。

まとめ: 壊れた記録があるから、直ったと断言できる

今回の結論はシンプルです。

gemma4:12b は ollama 0.30.5 で直った
公式タグで動くので、回避策は不要になった
日本語崩れも実測で改善した
速度は維持、移行コストはほぼゼロ
残る作法は think:false だけ

前日に「壊れている」と記録していたからこそ、翌日の「直った」を同一条件で確かめられました。こういう答え合わせは、派手さはないですが、現場ではかなり役に立ちます。

古い情報と新しい情報が混ざっているときは、まず時系列を切る。次に、同一条件で再現する。最後に、回避策を残すか捨てるか決める。今回の判断材料は、その順で見るのが一番安全です。

注意点・制約

OS・ライブラリのバージョンが異なると手順が変わる場合があります。
本番環境への適用前にテスト環境で動作を確認してください。

どのように検証したか

前日（0.30.4）の破損記録と同一環境（自宅AIサーバー・RTX 4070 Ti 12GB）・同一質問・temperature 0 で再検証しました。
速度は ollama サーバー報告値（eval_count / eval_duration）で計測しています。
24問テストは同一の問題セット・採点基準で再計測し、結果 JSON を実測台帳に保存しています。
修正の時系列は GitHub リリースノートと Hugging Face の lastModified（いずれも一次ソース）で確認しました。

よくある質問

0.30.5 にしたのに応答が空です。壊れていますか？

ほぼ間違いなく think:false の付け忘れです。gemma4 は思考モデルで、出力が thinking 側へ流れるため応答が空に見えます。/api/chat に "think": false を付けてください。

以前作ったテキストblob Modelfileやllama.cpp迂回は消していい？

公式タグで同速（52t/s）が出るので、原則引退で問題ありません。0.30.4 以前を使い続ける事情がある場合のみ残してください。

8GBのGPUで動くようになりましたか？

いいえ、そこは変わっていません。VRAM実測8.1GBで8GBカードは引き続き崖の縁です。GPU別の可否はBloggemma4 12BはどのGPUで動く？実測3点＋主要18枚の速度早見表【VRAM 8GBは崖の縁】gemma4 12Bを手持ちGPUで動かす判断材料を、VRAM別・実測3点・主要18枚の速度早見表で整理。8GBの限界も明確にします。→をご覧ください。

参考リンク

この記事を書いた人

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！