これはGemma 4チャレンジへの提出です:Gemma 4について書く
ローカルモデルを選ぶ際、開発者が最もよく犯す間違いはベンチマークスコアに基づいて選ぶことです。二番目に多い間違いはVRAMに収まるものを選ぶことです
これらのことは重要です。しかし、どちらも実際の最初の質問ではありません
実際の最初の質問は次のとおりです:どの環境でモデルが動作し、何をそこで行う必要があるか?
Gemma 4はE2B、E4B、26B A4B(MoE)、31Bの4つのバリエーションで出荷されており、Googleはそれぞれに対して非常に意図的なアーキテクチャの選択を行いました。それらの選択を理解すれば、適切なバリエーションを選ぶのに約5分かかります。そのステップをスキップしてベンチマークショップを行うと、256Kのコンテキストが必要な作業を携帯電話用のE4Bで行う(建設不足)あるいは、ローカルで実行するのに十分なE4Bがあるのに月額80ドルのクラウドコンピューティングを利用する31Bモデル(建設過剰)になる結果になります。
この投稿はその五分間の決断ガイドです.
ゲンマ4の実際の内容
2026年4月2日にApache 2.0ライセンスでリリースされたGemma 4は、Google DeepMindの最新のオープンベースモデルファミリーです。各バリエーションは多モーダル理解(テキスト+画像をベース、2つの最も小さなモデルでオーディオをネイティブに)、ネイティブな関数呼び出し、そして140以上の言語のサポートを装備しています。
Gemma 4を過去の世代と区別する見出しの能力は、どの单一機能でもありません。それはパラメータあたりの知能比率です。26B MoEモデルはフォワードパスごとに約4Bのパラメータのみを活性化します。E4Bは携帯電話で動作します。31BはAIME 2026数学ベンチマークで89.2%のスコアを記録しています - これは1年前には数倍の大きいモデルが必要だったスコアです.
この可能性を創り出すアーキテクチャの決定:
- 交代するローカル/グローバル注意層(ローカル層は512-1024トークンのスライディングウィンドウを使用、グローバル層は長距離コンテキストを処理)
- エッジバリアントにおけるペアレベルエンコーディング(PLE)、パラメータ数を少なくしながら表現力を保つ
- 26Bにおけるエキスパートの混合(各トークンを関連するエキスパート層のみを通過させ、フルネットワークを通過させない)
これが単なる効率性のための効率性ではない。4億パラメータのモデルが4GBのRAMを搭載したAndroidスマートフォンでオフラインで動作し、同時に128Kのコンテキストウィンドウを持つことを可能にするものだ。この組み合わせは以前は存在しなかった.
四つのバリエーション、実際に説明する
Gemma 4 E2B - スマートフォンモデル
~2.3B有効パラメータ、PLEを含め~5.1B総パラメータ、35層、128Kコンテキスト
エッジがデプロイターゲットである場合に選ぶモデルです。Google AICoreでAndroid 12以降、Raspberry Pi、Jetsonデバイス上で動作します。テキスト、画像、オーディオをネイティブにサポートします。
名前の"E"は効果的を意味しており - PLEはモデルが前向きパスでアクティベートするパラメータよりも総パラメータが多いことを意味し、アーキテクチャの異なるレベルでMoEが機能するのと同様です。実用的な結果は、2Bパラメータ数で示されるものをはるかに上回る機能を持つ1.5GBのフットプリントです.
E2Bを使用する場合: モバイルアプリ、エッジ推論パイプライン、デバイスローカルアシスタント、またはネットワーク遅延やデータプライバシーがリモートAPIへのリクエストを不可容許とする何かを構築している場合、
実際の使用例: 完全にオフラインで動作するレシートスキャン支出トラッカーで、画像入力を読み取り、項目をパースし、支出をカテゴライズする - すべてデバイス上で、API呼び出しなし、電話からデータが離れることはない。
# Running E2B locally with transformers
from transformers import AutoTokenizer, AutoModelForCausalLM
import torch
model_id = "google/gemma-4-E2B-it"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
model_id,
torch_dtype=torch.bfloat16,
device_map="auto"
)
messages = [
{
"role": "user",
"content": "Extract the total amount and vendor name from this receipt text: ..."
}
]
inputs = tokenizer.apply_chat_template(
messages,
return_tensors="pt",
return_dict=True
).to(model.device)
with torch.no_grad():
outputs = model.generate(**inputs, max_new_tokens=256)
response = tokenizer.decode(outputs[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True)
print(response)
ゲマ4 E4B - ノートパソコンモデル
~4.5Bの有効パラメータ、~8Bの総パラメータ、42層、128Kのコンテキスト
これは、専用のGPUハードウェアなしでローカルで高性能モデルを実行したい開発者のための毎日の仕事の主力です。16GBの統合メモリを搭載したMacBookで、統合GPUを備えた中規模のラップトップで、クラウドインスタンスを立ち上げたくないどんなマシンでも快適に動作します。
E2BからE4Bへの移行は単なるパラメータの増加ではなく、追加の層とパラメータ予算により、顕著に向上した指示の追従能力、より信頼性の高い構造化出力、そして長い会話中のコンテキストを保持する必要があるタスクにおける強化された性能を提供します。
E2Bと同じテキスト、画像、音声モダリティをサポートしており、開発者ツールリングにとって重要な意味で本当にマルチモーダルです - スクリーンショット、図、音声のテキストをパイプラインの一部として渡すことができ、別のビジョンモデルを必要としません.
E4Bを使用する場合: ローカル推論が要件で、あなたのハードウェアには独立したGPUがない、または後でより大きなモデルに拡張するものをプロトタイピングしていて、高速なイテレーションサイクルを望んでいる場合です。
実際の使用例: ローカルコードレビューツールで、あなたのエディタと差分のスクリーンショットを取得し、両方を理解し、コンテキストに応じたフィードバックを提供するもの - すべてあなたのラップトップで実行され、テレメトリはありません。
# Quick Ollama setup for E4B (easiest local path)
# After installing Ollama: https://ollama.com
# In terminal:
# ollama pull gemma4:e4b
import ollama
response = ollama.chat(
model="gemma4:e4b",
messages=[
{
"role": "user",
"content": "Review this function for edge cases and suggest improvements:",
}
],
options={
"temperature": 0.3,
"num_ctx": 8192 # can go up to 128K
}
)
print(response["message"]["content"])
Gemma 4 26B A4B (MoE) - 消費者向けGPUモデル
総パラメータ量25.2B、フォワードパスあたりのアクティブパラメータ量約3.8B、層数約30、コンテキスト256K
これはアーキテクチャのストーリーが興味深いものにしています。26B MoEは260億パラメータ分の計算能力が必要そうですが、そうではありません。各トークンに対して約40億パラメータが活性化するだけなので、フル精度で単一のRTX 3090またはRTX 4090で実行でき、より大きな密集モデルと競争する品質を提供します。
256Kのコンテキストウィンドウへの移行は開発者にとって重要です。128Kでは中規模のコードベースや非常に長いドキュメントを収めることができます。256Kでは大規模なリポジトリ、複数のドキュメントを扱う研究コンテキスト、またはカスタマーフェースアプリケーションにおける完全な会話履歴を収めることができます。
MoEアーキテクチャは、パラメータ数が同等の密集モデルと比較して量子化時に品質がより優雅に低下するという意味でもある。26B MoEのINT4の方が、同等の密集モデルのINT4より良い見栄えになる。
26B A4Bを使用する場合: 消費者向けのGPU(24GB VRAM)をお持ちで、256Kのコンテキストが必要であり、フラグシップハードウェアのコストなしでフラグシップクオリティを求めています。また、モデルが多段階のタスクを計画するために大規模なコンテキストを推論する必要があるあらゆるエージェント的な用途に適しています.
実際の使用例: 単一のプロンプトで完全な法的契約(または完全なコードベース)を取り込み、全ての文書を推論し、構造化データを抽出するか特定の質問に答えるエージェントドキュメントプロセッサーで、ローカルで4090上で実行しています.
# Using the Gemma 4 26B with native function calling
from transformers import AutoTokenizer, AutoModelForCausalLM
import torch
import json
model_id = "google/gemma-4-26B-A4B-it"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
model_id,
torch_dtype=torch.bfloat16,
device_map="auto",
load_in_4bit=True # fits on 24GB with 4-bit quant
)
# Native function calling - define your tools
tools = [
{
"name": "search_contracts",
"description": "Search the contract database by clause type or party name",
"parameters": {
"type": "object",
"properties": {
"query": {"type": "string", "description": "Search query"},
"clause_type": {
"type": "string",
"enum": ["liability", "termination", "payment", "IP"],
"description": "Type of clause to filter by"
}
},
"required": ["query"]
}
}
]
messages = [
{
"role": "user",
"content": "Find all termination clauses across the Q1 vendor contracts and summarize the notice periods."
}
]
inputs = tokenizer.apply_chat_template(
messages,
tools=tools,
return_tensors="pt",
return_dict=True
).to(model.device)
outputs = model.generate(**inputs, max_new_tokens=512)
response = tokenizer.decode(outputs[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True)
print(response)
Gemma 4 31B - サーバーモデル
31億の密集パラメータ、256Kのコンテキスト、フルマルチモーダル、思考モード
これは旗艦モデルです。ファミリーに搭載されている全ての機能がここに揃っています。思考モード(思考の連鎖推理)が有効です。数学ベンチマークスコアは非常に高いです:AIME 2026で89.2%を達成し、Gemma 3 27Bは同じベンチマークで20.8%でした。Arenaオープンモデルリーダーボードで第3位に位置しています。
FP16で約20GBのVRAMが必要で、INT4量子化であれば約12GBです。A100 80GBの1台で完全な精度で快適に処理できます。テンソル並列化を利用したRTX 4090の2台でも動作します。これはサーバーにデプロイするモデルで、ラップトップで実行するものではありません.
31Bを使用するのは次の場合: ベンチマークの品質はあなたのアプリケーションにとって重要です。推論が重いタスクには思考モードが必要です。複数のユーザーからのリクエストを処理するプロダクションサービスを構築しているか、またはオープン重みモデルで利用可能な最良の数学的およびコーディングパフォーマンスが必要です.
実際の使用例: は、あなたのチームの開発者が自社でホストするエンドポイントを通じてクエリを実行するコーディングアシスタントAPIで、31Bインスタンスがあなたのエンジニアリング組織全体をサービスし、同等の専有API呼び出しのコストの一部です。
# Serving 31B with vLLM for production throughput
# pip install vllm
from vllm import LLM, SamplingParams
llm = LLM(
model="google/gemma-4-31B-it",
tensor_parallel_size=2, # across 2x RTX 4090
dtype="bfloat16",
max_model_len=65536 # 64K for production balance
)
sampling_params = SamplingParams(
temperature=0.2,
top_p=0.9,
max_tokens=2048
)
# Thinking mode for complex reasoning
prompts = [
"<start_of_turn>user\nThink step by step: Given this algorithm, what's the worst-case time complexity and where is the bottleneck?\n\n[your code here]\n<end_of_turn>\n<start_of_turn>model\n"
]
outputs = llm.generate(prompts, sampling_params)
for output in outputs:
print(output.outputs[0].text)
決定のマトリックス
5分間のバージョンはこちらです:
| 状況 | モデル |
|---|---|
| モバイルアプリ、ラズパイ、オフライン優先 | E2B |
| ラップトップ開発、GPUなし、高速イテレーション | E4B |
| 消費者向けGPU(24GB)、256Kコンテキストが必要 | 26B A4B モデル |
| サーバー展開、最良の品質、チーム向け | 31B |
| 多数のツール呼び出しを含むエージェントパイプライン | 26B A4B モデル (アクティブパラメータ効率) |
| 数学、プログラミング、または論理集中型の生産 | 31B |
| プライバシーに敏感なユーザーデータ、APIコールなし | E4BまたはE2B |
| A100を持っているあなたは最高のものを求めています | 31B |
ここで起こっている大きなこと
一瞬、仕様から離れてみたく思います。
数学の重要なベンチマークで89.2%のスコアを達成し、256Kのコンテキストをサポートし、多モーダル推論を実行し、エージェントタスク用のネイティブ関数呼び出しをサポートするモデルは、現在オープンウエイトで、Apache 2.0ライセンスで、開発者が実際に所有できるハードウェアで実行されています。
128Kのコンテキストとオーディオサポートを搭載したラップトップで動作するE4Bは「小規模モデルの妥協」ではありません。2年前にはフロンティアレベルの機能でした。オフラインで携帯電話で動作するE2Bはデモのトリックではありません。本格的なデプロイメントターゲットです。
実際の意味は、「クラウドかローカルか?」という建築的な問題が、もはや能力の問題ではなく、コスト、遅延、プライバシーに関する問題であるということです。多くのアプリケーション——ユーザーデータが機密性が高く、オフラインでの利用が重要で、APIコストがスケールで複合的に増加するもの——では、ローカルが勝っています。
Gemma 4はその議論をしない。ただし、それに反論するのは非常に難しいだけです。
5分以内で始めましょう
Gemma 4のいかなるバリアントをローカルで実行するための最速の方法はOllamaです:
# Install Ollama (macOS/Linux)
curl -fsSL https://ollama.com/install.sh | sh
# Pull the variant you want
ollama pull gemma4:e4b # ~5GB, laptop-ready
ollama pull gemma4:26b # ~15GB, GPU-ready
# Run it
ollama run gemma4:e4b
# Or use the API directly
curl http://localhost:11434/api/chat -d '{
"model": "gemma4:e4b",
"messages": [
{ "role": "user", "content": "Hello, what can you do?" }
]
}'
Pythonと完全なtransformersエコシステム(関数呼び出し、思考モード、多モーダル)が必要な場合、各バリアントのHugging Faceモデルカードには完全に動作する例があります。始めましょうgoogle/gemma-4-E4B-it - それは最もアクセスしやすいエントリーポイントであり、多くの開発使用ケースをカバーしています。
ライセンスに関する簡単な注意点
Apache 2.0ライセンスは、Gemma 4を商用利用し、重みを変更し、それを基に製品を構築し、派生作品を配布することができます - 特許使用料を払うことなく、許可を求めることなく。これは、すべての「オープン」モデルには当てはまりません。ローカル推論を基にビジネスを構築している誰にとっても、これは非常に重要です。
正しいGemma 4のバリエーションは、ユーザーがいる場所で動作し、実際にプロビジョニングできるハードウェアに合い、タスクを設計しているのに十分なコンテキストを持っているものです。他のすべては最適化です.
不確かであればE4Bから始めてください。タスクが要求する場合にスケールアップしてください.
タグ: devchallenge gemmachallenge gemma ai machinelearning python opensource










