結論から言います。Gemma-4-E4Bは、RAG事実抽出専用モデルとして確実に使えます。問題はオーディオです — マルチモーダルのオーディオ入力自体は、うちのllama.cppサーバーで実際に動作します。ただし、デフォルト設定のままだと、4秒を超えるクリップでエラーなく空の応答だけが返ってきます。原因を追ってみると、モデルが「考える」ことにトークン予算を使い切ってしまい、正解は思考の中にしか残っていませんでした。この記事では、その落とし穴をうちのDGX Sparkで直接再現・修正した記録と、RAG抽出の性能、そしてこのモデルが実際どこに向いているのかを整理します。

🔍 Gemma-4-E4Bとは、どんなモデルなのか

Gemma-4-E4Bは、GoogleのGemma 4ファミリー(2026年7月2日に技術レポート公開)のエッジ向けバリアントです。公式カードによると、有効パラメータ約4.5B(埋め込み込みで8B)、コンテキスト128K、PLE(レイヤー別埋め込み)とローカル/グローバルのハイブリッドアテンション構造を採用しています。テキスト・画像・動画・オーディオをすべてネイティブに受け付けるマルチモーダルモデルというのが公式の説明です。

📊 RAG事実抽出、実際どれくらい速かったのか

私たちのメモリシステム(RAG)は、会話や文書から事実を抽出してJSONに構造化する処理を常に実行しています。以前はメインモデルのGemma-4 26Bがこの役割も兼ねていましたが、抽出自体は重い推論を必要としない作業です。そこで、韓国語サンプル5件でE4Bと26Bを直接比較してみました(両方ともthinkingをオフにした同条件、同じプロンプト)。

E4Bは約1.45倍速く(180〜190 tok/s対125 tok/s)、10回とも有効なJSONで幻覚もありませんでした。ただし、これはあくまで自社比較です。あるベンチマークでは、Qwen3-4BがRAG事実抽出で95.64%の精度を出したと報告されていますが、これはGemma-3世代を基準にした数値であり、E4Bとの直接比較ではありません。同じベンチマークでは、推論特化型の小型モデルをRAGと組み合わせるとむしろ精度が下がるケースも報告されています — 「小型モデル+RAG」が自動的に良くなる組み合わせというわけではないのです。

🎙️ オーディオ/STT、本当に動くのか自分で試してみました

意外な発見はオーディオでした。E4Bはテキストだけでなくオーディオまで受け付けるマルチモーダルモデルなので、うちのDGX Spark(llama.cpp b9917)に直接聞かせてみました。短い韓国語TTSクリップ(「こんにちは。今日は本当にいい天気ですね」、2.9秒)を送ったところ、一字一句正確に書き起こされました。

問題はその次でした。もう少し長いクリップ(5.2秒、「Raspberry Pi 5とクロディ、ミニ、シウォルがマルチモーダルモデルをテストしました」)を送ると — エラーもなく、空の文字列だけが返ってきたのです。

直し方は簡単でした。リクエストに次の二つのフィールドを追加して、思考モードをオフにするだけです。

{
  "chat_template_kwargs": {"enable_thinking": false},
  "reasoning_format": "none"
}

同じクリップを送り直すと、0.5秒、トークン30個だけで、同じ精度の答えが返ってきました。思考モードをオンにしたままトークン予算を1000に増やしても正解は出ますが(2.4秒、312トークン)、オフにする方が5倍速く、コストは10分の1でした。

書き起こし自体も興味深いものでした。「シウォル」(시월、名前)が「10月」(10월)と聞き間違えられました — 発音が重なる本物の同音異義語の混同で、二回のテストで同じ結果が再現されました。数字もそのまま読み上げ通りには書き起こされませんでした。「12パーセント」「200ミリ秒」と話した内容が「12%」「200ms」と正規化されて表記されており、文字通りの書き起こしというより、すでに整理された表記に変換する方向に近い挙動でした。

この結果には明確な限界があります。クリップはわずか5件、それもmacOSのTTSで作った綺麗な音声です。KAISTの韓国語Whisper評価(large-v2基準でCER 14.66%)のような正式なCER/WERベンチマークではなく、現場での簡易チェックに近いものです。さらに、これはllama.cppサーバーに直接聞かせた結果です — Ollamaレイヤーのマルチモーダルバグは別の層の問題であり、このテストでそのバグが存在しないと言えるわけではありません。

🌱 コミュニティはE4Bをどう見ているか

コミュニティの反応を見ると、E4Bの立ち位置がはっきりします。r/LocalLLaMAでローカル万能モデルとして最も多く挙げられているのはE4Bではなく、Gemma-4 26B A4B(またはQwen 3.5/3.6 MoE)です。あるユーザーはコメントで「Gemma 26B A4Bは素晴らしい…それに比べるとE4Bはかなり物足りなかった」と書いています。E4Bは常時待機するエッジ・サイドカー用モデルとして扱われており、毎日使うメインモデル扱いはされていません。

ディスク容量をめぐる議論もあります。公式タグgemma4:e4bは4ビット量子化基準で約9.6GBです。「’4B’なのになぜ10GB近くあるのか」という指摘がコミュニティで繰り返し出ています。有効パラメータ数とディスク容量は、そもそも別の数字だということです。

🔧 セットアップ奮闘記

小さなモデル一つをきちんと動かすのも、決して楽ではありませんでした。

• flash-attentionがクラッシュしました。Blackwell GPUでE4BのFAをオンにすると、ウォームアップ中にfattn.cu:110で落ちました。FAカーネルが要求する共有メモリがこのアーキテクチャの限界を超える、すでに知られたパターンでした。結局FAをオフにして運用しています。
• 128Kの天井。コンテキストを大きく取ろうとして、このモデルの学習上の上限が128Kであることを確認しました。それを超える分は意味なく切り捨てられます。
• 「思考モード」の罠、テキスト編。抽出は決定的である必要があるため、thinkingをサーバー側で完全にオフにしていましたが、そのせいで「必要なときだけオンに戻す」という道が塞がれていました。そこで方針を転換しました — サーバーはthinkingをデフォルトでONにしておき、決定的な出力が必要な呼び出し側(抽出処理)だけがリクエスト時にオフにする方式です。
• 「思考モード」の罠、オーディオ編。その方針転換が、今度はブーメランになりました。オーディオのように新しく追加された経路は、サーバーのデフォルト値(thinking ON)をそのまま引き継ぎます — 上のオーディオの節は、まさにその再現記録です。
• ポート単位でルーティングされます。このサーバーはリクエストの「モデル名」ではなく、ポートでルーティングしています。エイリアスは表示用に過ぎません。

🤔 では、E4Bは常に正しい選択なのか

正直に取り上げるべき反論があります。

一つ目、リリース初期の不安定さは実際にありました。gooseのissueでは、古いバージョンのllama.cppがGemma-4のJinjaチャットテンプレートを処理できず、応答が壊れたと報告されています — llama.cppを新しいバージョンに上げることで解決しました。Zedの未解決issueでは、ローカルでサービングしたGemma 4がエージェント作業中にファイルを誤って書き込んだり、コンソールに代わりに出力したりする問題が報告されています。出たばかりのモデルをローカルで動かすなら、スタック全体を最新に保つ必要があるということです。

二つ目、Qwen3-4Bとの直接比較はまだ存在しません。最も強力な小型モデルのRAG数値(Qwen3-4B 95.64%)はGemma-3世代を基準にしたもので、E4Bはまだその舞台に立ったことがありません。「E4Bが最高の小型抽出器」という主張は未検証です — 「有力な候補」というのが正直な表現です。

三つ目、本格的な韓国語STTが目的なら、今でもWhisper系が安全な選択です。KAISTの評価では、ファインチューニングしたWhisper-large-v2がCER 10.48%まで下がりました。Gemmaのオーディオ経路が動くこと自体は確認できましたが、正式なベンチマークで検証された精度があるわけではありません。短く軽い音声のやり取りは同じモデルで処理しつつ、本格的な書き起こし作業は今もWhisperを併用するのが現実的です。

🎯 E4B、いつ使えばいいのか

RAG事実抽出のような決定的で軽い作業、そして短い音声メモの処理には、E4Bはちょうど良い体格です。毎日使うメインのコーディング・エージェントモデルを探しているなら、26B A4BかQwen 3.5/3.6 MoEの方がコミュニティが実際に選んでいる答えです。本格的な韓国語書き起こしが目的なら、今もWhisper系が実績のある選択肢です。そして、どの経路でオーディオを使うにしても、まず思考モードを確認してください — オンのままだと、短いクリップを数個テストしただけで「動く」と判断しがちですが、少し長くなるだけで静かに空の応答を返してきます。

📚 参考資料

• Gemma 4 Technical Report (arXiv:2607.02770, 2026-07-02)
• HuggingFace — google/gemma-4-E4B
• Google AI for Developers — Gemma 3n overview
• Benchmarking SLMs/SRLMs on System Log Severity Classification (arXiv:2601.07790)
• Evaluating ASR Systems for Korean Meteorological Experts, KAIST (arXiv:2410.18444)
• goose — Issue #9110, Gemma-4 Chat Template Support
• Zed — Issue #57416, Local Gemma4 + llama.cpp tools problems
• Ollama Library — gemma4
• r/LocalLLaMA — Gemma 4 26B is the perfect all around local model
• ollama/ollama — Issue #16532

あわせて読みたい — Mac Mini リモート開発サーバー構築記