Google Gemma 4がE2BからA4Bまで4サイズ展開、Gemini 3由来の推論性能をApache 2.0で公開
GoogleがGemini 3の技術を使ったオープンウェイトモデル「Gemma 4」を4サイズ同時にリリースした。Apache 2.0ライセンス。Hacker Newsでは1,300ポイント超、390コメント以上と盛り上がっている。
前世代のGemma 3は27B単一サイズだった。同時期にQwenはテキスト汎用のQwen3.5-35B-A3B、コーディング特化のQwen3-Coder-Next、オムニモーダルのQwen3-Omniと用途別にMoEモデルを展開し、Kimi K2.5は1Tパラメータで性能トップを狙い、Sarvamは30B/105Bの2サイズでインド市場を押さえた。Googleだけが27B一本で、ラインナップの薄さが目立っていた。
Gemma 4ではエッジ向け2Bクラスからデスクトップ向け31Bまで一気に4モデル展開し、サイズの穴を埋めてきた。しかし単に数を増やしただけではなく、MoEアーキテクチャに独自の設計判断を入れてきたのが面白い。
4モデルの構成
| モデル | 総パラメータ | アクティブパラメータ | 層数 | コンテキスト長 |
|---|---|---|---|---|
| E2B | 5.1B（実効2.3B） | 2.3B | 35 | 128K |
| E4B | 8B（実効4.5B） | 4.5B | 42 | 128K |
| 26B A4B（MoE） | 25.2B | 3.8B | 30 | 256K |
| 31B Dense | 30.7B | 30.7B | 60 | 256K |
E2BとE4Bの「E」はEdgeの意味で、スマートフォンやRaspberry Pi、Jetson Nanoなど低消費電力デバイスでの推論を想定している。E4Bは音声入力にも対応しており、約300Mパラメータの音声エンコーダを内蔵する。
ラインナップ戦略の違い
このサイズ展開の仕方が、競合と明確に違う。
Qwenは「同じMoEフレームワークの上に用途別モデルを載せる」アプローチだ。テキスト汎用（Qwen3.5-35B-A3B）、コーディング（Qwen3-Coder-Next）、オムニモーダル（Qwen3-Omni）と、それぞれ別のモデルがある。アクティブパラメータは3B前後に揃えつつ、学習データとアーキテクチャの細部で差別化する戦略。
Gemma 4は「同じアーキテクチャを異なるサイズにスケールする」アプローチ。1つの設計思想（Dense FFN並列MoE + ハイブリッドアテンション）をE2Bから31Bまで貫通させている。用途別の特化はせず、全モデルがビジョン対応で、全モデルがツール呼び出しをサポートする。
どちらが正しいかは用途次第だが、開発者にとっての違いは明確だ。Qwenはタスクに合ったモデルを選ぶ必要がある。Gemma 4はデバイスの計算能力に合わせてサイズを選ぶだけでいい。後者のほうがモデル選定のコストが低い。
26B A4Bの競合ポジション
最も注目すべきは26B A4Bモデルだ。MoE（Mixture of Experts）構成で、総パラメータ25.2Bのうち1トークンあたり3.8Bしかアクティベートしない。4Bクラスの推論コストで26Bクラスの精度を目指すモデルということになる。
アクティブパラメータ3.8Bという数字は、競合モデルと並べると位置づけが見えてくる。
| モデル | 総パラメータ | アクティブパラメータ | アクティブ比率 |
|---|---|---|---|
| Gemma 4 26B A4B | 25.2B | 3.8B | 15.1% |
| Qwen3-Omni | 30B | 3.3B | 11.0% |
| Qwen3-Coder-Next | 80B | 3B | 3.8% |
| Sarvam 30B | 30B | 2.4B | 8.0% |
| Kimi K2.5 | 1T | 32B | 3.2% |
Qwen3-OmniとQwen3-Coder-Nextがアクティブ3B前後に揃えているのに対し、Gemma 4はやや多い3.8B。この差はアーキテクチャ上の設計判断（後述するDense FFN並列実行）に起因しており、推論コストと精度のトレードオフが他モデルと異なる。
26B A4BのMoEアーキテクチャ
MoEは「Mixture of Experts」の略で、ニューラルネットワークの中間層に複数の「エキスパート」と呼ばれるサブネットワークを用意し、入力トークンごとにルーターが使うエキスパートを選ぶ仕組みだ。全パラメータの一部だけを使って推論するため、モデルサイズの割に推論が軽い。Qwen3-OmniやFlash-MoEで動かしたQwen3.5-397BでもMoEアーキテクチャが使われている。
Gemma 4のMoE実装は、この分野で見慣れた構成とは異なる。
Dense FFN並列実行という設計
通常のMoEモデルは、Transformerの各層にあるFFN（フィードフォワードネットワーク）をエキスパート群に置き換える。「FFNの代わりにMoE」という構成だ。Kimi K2.5（384エキスパート+共有1）、Sarvam 30B/105B（128エキスパート）、Qwen3-Coder-Next（512エキスパート中10アクティブ）はいずれもこの「FFNをMoEに置き換え」パターンだ。
Gemma 4の26B A4Bは、Dense FFN（GeGLU、hidden=2,112）と128エキスパートのMoE（top-8選択、各hidden=704）を 並列に走らせて出力を加算する という設計を採用している。さらに全トークンが必ず経由する「共有エキスパート」が1つある。
graph LR
A[入力トークン] --> B[Dense FFN<br/>GeGLU h=2112]
A --> C[Router]
C --> D[Top-8 Expert<br/>128中8選択<br/>各h=704]
A --> E[Shared Expert<br/>常時アクティブ]
B --> F[加算]
D --> F
E --> F
F --> G[出力]各層がDense FFNによる「常に使える汎用的な表現力」と、MoEによる「入力に応じた専門的な処理」の両方を持つ。Dense FFNだけでも動くがMoEで精度を上乗せする、という冗長性のある構造だ。
この設計思想は、Nemotron Nano 9BやHolotronが採用するTransformer-Mambaハイブリッドとも対比できる。Nemotron/Holotronは「Transformerの精度 + SSMのメモリ効率」を組み合わせるアプローチで、Holotron-12Bは長い操作履歴をSSMで圧縮しつつ直近の判断にはTransformerを使う。一方Gemma 4は「Dense FFNの安定性 + MoEの専門性」を組み合わせるアプローチで、アーキテクチャは異なるが「2つの仕組みの良いとこ取り」という発想は共通している。
他モデルのMoE設計との比較
| 項目 | Gemma 4 26B A4B | Kimi K2.5 | Qwen3-Coder-Next | Sarvam 30B |
|---|---|---|---|---|
| エキスパート数 | 128 | 384 | 512 | 128 |
| Top-K | 8 | 8 | 10 | - |
| 共有エキスパート | 1 | 1 | 1 | なし |
| Dense FFN並列 | あり | なし | なし | なし |
| ルーティング | - | - | - | sigmoid |
Gemma 4とKimi K2.5はともにTop-8ルーティングを採用している。Kimi K2.5の記事で書いた通り、MixtralなどのTop-2が多い中でTop-8は表現力重視の選択だ。
Qwen3-Coder-Nextの512エキスパートから10を選ぶ構成は「選択肢の広さ」で勝負するアプローチで、Gemma 4の128エキスパートからの8選択とは方向性が異なる。Sarvamはsigmoidルーティングでエキスパートの負荷分散を安定させるという独自路線を取っている。
Gemma 4のDense FFN並列実行は、MoEのルーティングが失敗した場合のフォールバックとして機能する。他モデルではルーティングの精度がそのまま出力品質に直結するが、Gemma 4はDense FFNが常にベースラインの表現力を保証する。この冗長性は安定性と引き換えにアクティブパラメータが増える設計だ。Qwen3.5-35B-A3Bのアクティブ3BとGemma 4の3.8Bの差は、このDense FFN分が効いている。
ではこの追加0.8Bのコストに見合う精度が出ているのか。
ベンチマーク
モデルカードから主要なベンチマーク数値を抜粋した。31B-itと26B-A4B-itはInstruction Tuned版の数値。
| ベンチマーク | 31B | 26B A4B | E4B | E2B |
|---|---|---|---|---|
| MMLU Pro（知識） | 85.2% | 82.6% | 69.4% | 60.0% |
| AIME 2026（数学・ツールなし） | 89.2% | 88.3% | 42.5% | 37.5% |
| LiveCodeBench v6（コーディング） | 80.0% | 77.1% | 52.0% | 44.0% |
| GPQA Diamond（科学知識） | 84.3% | 82.3% | 58.6% | 43.4% |
| BigBench Extra Hard | 74.4% | 64.8% | 33.1% | 21.9% |
ビジョン系ベンチマーク（ビジョンエンコーダ搭載モデル）。
| ベンチマーク | 31B | 26B A4B | E4B |
|---|---|---|---|
| MMMU Pro（マルチモーダル理解） | 76.9% | 73.8% | 52.6% |
| MATH-Vision | 85.6% | 82.4% | 59.5% |
長コンテキスト性能（MRCR v2 128K）は31Bが66.4%、26B A4Bが44.1%と大きく差がつく。Dense構成の31Bはグローバルアテンション層が多いため、長距離依存の捕捉で有利になる。
以下、他モデルとの比較で見ていく。
数学はアクティブ4B未満で88%
| モデル | AIME スコア | アクティブパラメータ |
|---|---|---|
| Kimi K2.5 | 96.1%（AIME 2025） | 32B |
| Sarvam 105B | 88.3%（ツールなし）/ 96.7%（ツールあり） | - |
| Gemma 4 31B | 89.2%（AIME 2026） | 30.7B |
| Gemma 4 26B A4B | 88.3%（AIME 2026） | 3.8B |
| Sarvam 30B | 80.0% | 2.4B |
| Qwen3-Omni | 73.7%（Thinking） | 3.3B |
Gemma 4 26B A4Bの88.3%はアクティブ3.8Bとしては突出している。同じ3B帯のQwen3-Omni（73.7%）を15ポイント近く上回る。ただしAIMEのバージョンが異なる（Gemma 4は2026、Qwen3-Omniは2025）ので直接比較には注意が必要。
注目すべきは31B Denseとの差がわずか0.9ポイントしかない点だ。数学タスクではMoEのDense FFN並列が効いており、アクティブパラメータ3.8Bでほぼ31B相当の精度が出ている。Sarvam 30B（アクティブ2.4B）の80.0%と比較すると、アクティブパラメータ1.4Bの差で8.3ポイントの上乗せがあり、Dense FFNのコストが数学タスクでは明確にペイしている。
コーディングは汎用モデルとしては強い
| モデル | スコア | 備考 |
|---|---|---|
| Kimi K2.5 | 85.0%（LiveCodeBench v6） | アクティブ32B |
| Gemma 4 31B | 80.0%（LiveCodeBench v6） | Dense 30.7B |
| Gemma 4 26B A4B | 77.1%（LiveCodeBench v6） | アクティブ3.8B |
| Sarvam 105B | 71.7%（LiveCodeBench v6） | - |
| Sarvam 30B | 70.0%（LiveCodeBench v6） | アクティブ2.4B |
| Qwen3-Coder-Next | 70.6%（SWE-Bench） | アクティブ3B |
Gemma 4 26B A4Bの77.1%は、アクティブ3.8Bの汎用モデルとしてはかなり強い。コーディング特化のQwen3-Coder-NextがSWE-Bench 70.6%（ベンチマークが異なるため直接比較は難しいが）であることを考えると、特化していないのにこの数字は印象的。
ただしコーディングエージェントの実用性は、ベンチマークスコアだけでは測れない。Cursor Composer 2はKimi K2.5にコーディング特化RLを適用してCursorBench 61.3%を達成し、GPT-5.4 Thinking（63.9%）に肉薄した。Gemma 4はこの種の「RLでコーディング性能を後付け強化する」ベースモデルとしての適性がどうかという観点も重要だ。Apache 2.0ライセンスなので、Kimi K2.5のようにサードパーティがRL適用した派生モデルが出てくる可能性は十分ある。
マルチモーダルは精度互角、対応幅で差がつく
| モデル | スコア | ビジョンエンコーダ |
|---|---|---|
| Kimi K2.5 | 78.5%（MMMU Pro） | MoonViT 400M |
| Gemma 4 31B | 76.9%（MMMU Pro） | 550M |
| Gemma 4 26B A4B | 73.8%（MMMU Pro） | 550M |
| Qwen3-Omni Thinking | 74.9%（MMStar） | SigLIP2 543M |
ビジョン精度は横並びに近い。もっともGemma 4のビジョンエンコーダ（550M）はテキスト+画像の2モダリティに特化しているのに対し、Qwen3-Omniは同等サイズのSigLIP2（543M）で画像+音声+動画まで処理する。精度が似ているなら対応モダリティの幅でQwen3-Omniが上、という評価になる。
一方、Gemma 4は全4モデルにビジョンを標準搭載した。E2B（5.1B）でも画像理解ができる。Qwen3-Omniは単一モデル（30Bパラメータ）でVRAM 69GB以上必要なので、エッジデバイスでの画像理解という用途では勝負にならない。「小さいモデルでもビジョンが使える」のはGemma 4の明確な強みだ。
知識はパラメータ量がものを言う
| モデル | スコア |
|---|---|
| Sarvam 105B | 90.6%（MMLU） |
| Gemma 4 31B | 85.2%（MMLU Pro） |
| Sarvam 30B | 85.1%（MMLU） |
| Gemma 4 26B A4B | 82.6%（MMLU Pro） |
MMLU ProとMMLUは厳密には異なるベンチマーク（MMLU Proのほうが難しい）だが、傾向は読める。知識ベースのタスクでは31BとA4Bの差が2.6ポイントあり、数学の0.9ポイント差より大きい。知識の広さはパラメータ総量に依存する側面があり、MoEのアクティブパラメータだけでは補いきれない。
興味深いのはSarvam 30B（アクティブ2.4B）がMMLU 85.1%で、Gemma 4 31B（Dense 30.7B）の85.2%とほぼ同等な点だ。SarvamはインドのCommon CrawlデータやBharat-Textといった独自コーパスで訓練されており、知識のカバー範囲が異なるとはいえ、パラメータ効率ではSarvamが優れているケースがある。
Dense FFNの追加0.8Bはどこで効くか
ベンチマークを横断すると、Gemma 4 26B A4Bの追加0.8Bアクティブパラメータ（Dense FFN分）が最も効いているのは数学とコーディングだ。知識タスクでは効果が薄い。MoEのルーティングが安定しにくい複雑な推論タスクほど、Dense FFNのフォールバックが活きるということだろう。
Attention設計
Gemma 4の全モデルに共通するのが、ローカルスライディングウィンドウアテンションとグローバルフルアテンションを層ごとに交互に配置するハイブリッド構成だ。
| アテンション種別 | E2B / E4B | 26B / 31B |
|---|---|---|
| ローカルウィンドウ幅 | 512トークン | 1,024トークン |
| グローバル層 | Proportional RoPE適用 | Proportional RoPE適用 |
スライディングウィンドウアテンションは、各トークンが直近N個のトークンだけに注意を向ける。計算量がコンテキスト長に対して線形に増えるため、長い文脈でも推論コストが爆発しない。一方で離れた位置の情報は取れないので、グローバルアテンションの層を挟んで文脈全体の情報を拾う。
グローバル層にはProportional RoPE（p-RoPE）が使われている。通常のRoPE（Rotary Position Embedding）は位置が遠くなるほど高周波成分の精度が落ちるが、p-RoPEはグローバル層とローカル層で周波数帯域を比例的に調整することで、256Kトークンの長距離でも位置エンコーディングの品質を保つ。
長コンテキスト処理のアプローチ比較
2026年前半、主要モデルは長コンテキスト処理に異なるアプローチを取っており、設計思想の違いが際立っている。
1. Gemma 4: ローカル+グローバルの層交互配置（256K）
全層がフルAttentionだが、ローカル層（直近1024トークン）とグローバル層（全文脈）を交互に配置する。シンプルだが、グローバル層ではフルAttentionの計算コストがかかる。
2. Qwen3.5: SSM+Attentionハイブリッド（128K）
Qwen3.5-35B-A3Bは40層中30層がSSM（Mamba系）で、KVキャッシュを消費するのはAttention層の10層だけ。ctx-sizeを4Kから64Kに拡張してもVRAM増加は800MB程度。コンテキスト長に対するKVキャッシュの増加が根本的に小さい。
3. Mamba-3: 完全SSM（16K+）
Mamba-3はAttentionを完全に排除し、固定サイズの状態ベクトルだけで推論する。16384トークンでTransformerの約6.9倍の速度を達成。ただし「細部を忘れる」という特性があり、長距離の正確な情報検索が苦手。
4. プロプライエタリ: 力技で1Mトークン
Claude 1MコンテキストはMRCR v2でフロンティアスコアを達成し、追加料金なしで標準APIに統合された。GPT-5.4も100万トークンに対応（272K超は2倍料金）。プロプライエタリモデルはインフラの力で1Mまで持っていける。
Gemma 4の256Kはオープンウェイトモデルとしては十分だが、プロプライエタリモデルの1Mには遠い。もっともClaude/GPT-5.4はクラウド推論前提で、ローカルで256Kを扱えるGemma 4とは利用シーンが異なる。MRCR v2 128Kで31Bが66.4%、26B A4Bが44.1%という数字は、31Bの長コンテキスト精度がオープンモデルの中では上位であることを示している。
さらに最後のN層でKey/Valueテンソルを前の層から再利用するKVキャッシュ共有も実装されており、推論時のメモリ消費を削減している。SwiftLMのTurboQuantやHypuraのKVキャッシュ圧縮がKVキャッシュのビット数を減らすアプローチなのに対し、Gemma 4は「層間でKVを使い回す」ことでエントリ数自体を削減する。方向性は違うが、KVキャッシュがメモリのボトルネックだという認識は共通している。
ビジョン・音声エンコーダ
全モデルがビジョン入力に対応している。ビジョンエンコーダのパラメータ数はE2B/E4Bが約150M、26B/31Bが約550M。音声入力はE4Bのみ対応で、約300Mの音声エンコーダを搭載する。
マルチモーダル対応の設計比較
各モデルのマルチモーダル対応は、対応範囲と統合の深さで大きく異なる。
| モデル | テキスト | 画像 | 音声入力 | 音声出力 | 動画 | 設計思想 |
|---|---|---|---|---|---|---|
| Gemma 4（全モデル） | o | o | E4Bのみ | x | x | 全サイズビジョン標準 |
| Qwen3-Omni | o | o | o | o（リアルタイム） | o | 単一モデルで全網羅 |
| Kimi K2.5 | o | o | x | x | o | テキスト+ビジョン重点 |
| Nemotron Nano 9B | o | x | x | x | x | テキスト特化+ツール |
Qwen3-Omniは音声出力（Talker）と動画入力まで対応しており、マルチモーダルの網羅性ではGemma 4を大きく上回る。Qwen3-Omniの音声エンコーダ（AuT）は650Mパラメータで2000万時間の教師ありデータで訓練されており、Gemma 4のE4B音声エンコーダ（300M）とは規模が違う。
逆にNemotron Nano 9Bはマルチモーダルを一切持たず、テキスト処理とツール呼び出しに全振りしている。Nejumi Leaderboard 4の10B以下カテゴリで1位を取っているのは、リソースをテキスト性能に集中させた結果だ。
Gemma 4はこの2つの中間にいる。Qwen3-Omniほど広くはないが、Nemotronのようにテキストだけに絞りもしない。「全モデルでビジョン標準搭載」という選択は、E2B（5.1B）のような小さなモデルでも画像理解ができるという点で合理的だ。Qwen3-OmniのVRAM 69GBやKimi K2.5のアクティブ32Bと比べると、エッジデバイスでも画像理解はGemma 4しか現実的な選択肢がない。
140言語をサポートしており、語彙サイズは全モデル共通で262Kトークン。Gemma 3の256Kからわずかに増加している。Sarvamがインド22言語に特化した独自トークナイザーで低fertility scoreを追求しているのとは対照的に、Gemma 4は汎用マルチリンガル路線だ。日本語性能に特化したNemotron Nano 9Bのように言語特化する方向もあるが、Gemma 4は140言語の広さで勝負している。
実際のパフォーマンス
NVIDIA GPU環境
HNのコメントからいくつか実測報告が出ている。
RTX 4090（24GB VRAM）での26B A4Bは約150トークン/秒との報告があり、同条件でのQwen 3.5-35B-A3Bの約100トークン/秒から50%の高速化になっている。
ただしこの速度差をそのままモデルの優劣として見るのは早い。Qwen3.5-35B-A3Bの記事ではVulkan環境で53 t/s（Q6_K）という数値が出ていたが、これはAMD Radeon 8060Sでの値でRTX 4090とは条件が異なる。さらにQwen3.5-35B-A3BはSSM+Attentionハイブリッドでコンテキスト長を伸ばしてもVRAMと速度が安定するという特性があり、64Kコンテキストでも53.6 t/sを維持していた。Gemma 4の26B A4Bがコンテキスト長に対してどう劣化するかはまだデータが出ていない。
31B Denseは精度では26B A4Bを上回るが、推論速度は当然遅い。精度重視なら31B、速度と精度のバランスなら26B A4Bという使い分けになる。
Apple Silicon環境
Apple Silicon環境での推論はまだデータが少ないが、参考になる数字はある。Ollama 0.19のMLXバックエンド移行では、Qwen3.5-35B-A3BがM5チップ上でデコード112トークン/秒（NVFP4量子化）を達成した。Gemma 4の26B A4Bは同じMoE系統でアクティブパラメータが近い（3.8B vs 3B）ため、MLXバックエンド対応が進めば似た水準の速度が期待できる。
ただOllama 0.19のMLXバックエンドはプレビュー段階でQwen3.5が主なターゲットで、Gemma 4の新アーキテクチャ（Dense FFN並列MoE）への対応には時間がかかる可能性がある。Flash-MoEがSSDストリーミングで397Bモデルを48GB MacBookに載せた例もあるが、こちらもモデルごとのMetalシェーダー対応が必要だった。
推論フレームワークの成熟度
初期段階でのトラブルも報告されている。LM StudioやLlama.cppでのチャットテンプレート解析にバグがあり、31Bが入力に関係なく ---\n を返す問題が発生していた。EOSトークンが <turn|> であること、temperature=1.0・top_p=0.95・top_k=64という推奨パラメータが必要なことなど、既存の推論フレームワーク側の対応が追いついていない面がある。
これは新アーキテクチャのモデルでは毎回起きる問題だ。Sarvam 30Bもllama.cppへのsarvam_moeアーキテクチャ対応がマージ待ちだった。AMD Lemonadeのようなllama.cppをバックエンドに使うツールも、上流の対応待ちになる。Unsloth（Daniel Chen）がリリース数時間以内に量子化バリアントを公開したのは早いが、推論フレームワーク全体の安定にはもう少し時間がかかるだろう。
E2B / E4Bのエッジ展開
E2BとE4Bはスマートフォンやシングルボードコンピューターでの完全オフライン推論を想定している。Raspberry PiやJetson Nanoでの動作が公式に謳われている。
エッジ向けモデルの選択肢
エッジLLMの選択肢は増えているが、モデルごとの強みが異なる。
| モデル | パラメータ | ビジョン | 音声 | 強み |
|---|---|---|---|---|
| Gemma 4 E2B | 5.1B（実効2.3B） | o | x | 全モダリティ最小、ビジョン付き |
| Gemma 4 E4B | 8B（実効4.5B） | o | o（入力のみ） | 音声+ビジョンのオフライン処理 |
| Nemotron Nano 9B | 9B | x | x | 日本語1位、ツール呼び出し強い |
| Holotron-12B | 12B | o | x | PC操作特化、H100で8,900 t/s |
Gemma 4 E2B/E4Bの差別化ポイントは「ビジョン付きで最小」であること。Nemotron Nano 9Bは9Bパラメータでテキスト処理とツール呼び出しに特化し、Nejumi Leaderboard 4で10B以下1位を取っているが、ビジョンは非搭載。画像を見る必要がないテキストエージェント用途ならNemotronが上だが、スマートフォンのカメラ入力を処理するような用途ではGemma 4が唯一の選択肢になる。
Holotron-12BはNemotronベースのTransformer-MambaハイブリッドでPC操作AIに特化している。H100上でのスループットは毎秒8,900トークンと高速だが、12Bパラメータなのでスマートフォン向けではない。エッジGPUやサーバーGPUでの運用が前提だ。
メモリ制約の現実
エッジ向けLLMの最大の制約はメモリだ。SwiftLMがiPhone 13 Pro（6GB）でQwen3 1.7Bを動作させていたが、Gemma 4 E2Bは5.1B（アクティブ2.3B）でビジョン付きとなると、より多くのメモリを必要とする。
EVO-X2（Strix Halo）のような64GBユニファイドメモリのミニPCなら余裕だが、スマートフォンの6-8GBではかなりタイトだ。量子化と推論フレームワークの最適化次第で実用性が変わるライン。AMD LemonadeのNPU推論（最大60 TOPS）では小型モデルしか実用的でなかったように、エッジ推論の「現実的に何ができるか」は計算リソースの壁がある。
E4Bは音声エンコーダ付きで、エッジデバイス上での音声認識+テキスト応答が可能。ただしHNのコメントではSVG生成などの複雑なタスクでは2B/4Bクラスの限界が指摘されており、用途は「ビジョン+音声の入力理解」に限定されるだろう。複雑なテキスト生成が必要ならNemotron 9BやQwen3-8Bに軍配が上がる。
ツール呼び出しと推論モード
全モデルがFunction Calling（ツール呼び出し）とThinkingモード（推論チェーン）をサポートしている。Thinkingモードはトークンを消費するが、数学やコーディングのスコアを大幅に引き上げる。
エージェント能力の比較
HNでは26B A4Bでタイムスタンプ計算をテストした報告があり、ツール呼び出しを試みるが結果をハルシネーションするケースが確認されている。同じタスクでQwen 3.5は手動計算で正解に到達しており、ツール呼び出しの信頼性は発展途上だ。
| モデル | エージェント実績 |
|---|---|
| Kimi K2.5 | PARL（並列エージェントRL）でBrowseComp 78.4%、Agent Swarm100サブエージェント協調 |
| Cursor Composer 2 | Kimi K2.5 + コーディングRL、CursorBench 61.3%でGPT-5.4 Thinking（63.9%）に肉薄 |
| Sarvam 105B | Tau2エージェントベンチマーク68.3% |
| Nemotron Nano 9B | Nejumiのツール呼び出しで10B以下トップ |
| Gemma 4 | ツール呼び出し対応、信頼性は未知数 |
Kimi K2.5のPARL（Parallel-Agent RL）は100のサブエージェントを協調実行する仕組みで、複雑なブラウジングタスクを並列処理できる。Cursor Composer 2はこのKimi K2.5にコーディング特化RLを重ねることでGPT-5.4 Thinking並みのコーディング性能を引き出した。
Gemma 4は基盤モデルとしてツール呼び出しに対応しているが、これらの特化型エージェントシステムとは成熟度が違う。ポテンシャルはベンチマーク性能から見てあるが、実際のエージェント用途での評価はこれからだ。Apache 2.0ライセンスなので、ComposerのようなサードパーティによるRL適用のベースとして使われる展開のほうが現実的かもしれない。
配布とライセンス
配布チャネルはHugging Face、Ollama、Kaggle、LM Studio、Dockerで、トレーニングフレームワークとしてJAX、Keras、Vertex AI、Google Kubernetes Engineがサポートされている。ライセンスはApache 2.0で、Gemma 3のカスタムライセンスからの変更が大きい。商用利用に制限がなく、派生モデルの公開も自由だ。
| モデル | ライセンス | 派生モデルの制約 |
|---|---|---|
| Gemma 4 | Apache 2.0 | なし |
| Kimi K2.5 | MIT | なし |
| Qwen3-Coder-Next | Apache 2.0 | なし |
| Sarvam 30B/105B | オープンソース | なし |
| Qwen3.5 | Apache 2.0 | なし |
| Nemotron Nano 9B | NVIDIA Open Model License | 一部制約あり |
Gemma 3のカスタムライセンスからApache 2.0への移行は、商用利用のハードルを下げる明確なシグナルだ。Kimi K2.5はMITで最も緩く、QwenファミリーとGemma 4はApache 2.0で足並みを揃えた。NVIDIAのNemotronはNVIDIA独自ライセンスで、Apache 2.0やMITほど自由ではない。
Cursor Composer 2がKimi K2.5（MIT）をベースにRL適用した例を見ると、ライセンスの緩さは派生モデルのエコシステム形成に直結する。Gemma 4がApache 2.0で出てきたことで、コーディング特化や日本語特化の派生モデルが出やすい環境が整った。
トレーニングデータのカットオフは2025年1月。
オープンウェイトMoE競争の構図
2026年前半のオープンウェイトMoE市場は混戦状態で、各社の設計思想の違いが際立っている。
Qwen: 用途別MoE展開。テキスト汎用（Qwen3.5-35B-A3B）、コーディング特化（Qwen3-Coder-Next）、オムニモーダル（Qwen3-Omni）と、同じMoEフレームワーク上に特化モデルを次々と展開するアプローチ。SSM+Attentionハイブリッドで長コンテキストのメモリ効率も追求。さらにOllama MLXバックエンドがQwen3.5を最初のターゲットにしたように、推論エコシステムの先行者利益がある。
Kimi: 巨大MoEの力技。K2.5は1Tパラメータ中32Bアクティブという規模でベンチマークトップを狙う。AIME 96.1%、BrowseComp 60.2%という数字は、パラメータを積めば積むほど性能が出ることの証明。Cursor Composer 2のベースモデルに選ばれたことで、「RL適用のベースとして最強」という地位を確立した。
Sarvam: 地域特化+推論効率。30B/105Bはインド22言語に特化したトークナイザーと、sigmoidルーティングによる安定した学習を組み合わせる。H100での実測スループットでQwen3ベースラインの3〜6倍を達成しており、推論効率に振り切っている。
NVIDIA: テキスト特化+言語特化。Nemotron Nano 9BはTransformer-Mambaハイブリッドで日本語性能トップ。同等サイズのオープンモデル比で最大6倍のスループット。「9Bで十分な性能を出す」という方向性は、エッジ展開を重視するGemma 4のE2B/E4Bと競合する。
Gemma 4: Dense FFN併用の安定性重視。MoEの上にDense FFNを並列実行する冗長設計で、ルーティングの失敗に強い。アクティブパラメータは3.8Bとやや多めだが、AIME 88.3%という数学スコアでQwen3-Omniを上回り、コーディングでもSarvam 30Bを超える。4モデル同時展開でエッジからデスクトップまでカバーする戦略は、Qwenの用途別展開に対するGoogleの回答だ。
数学でKimi K2.5に勝つモデルはないし、エッジのビジョン処理でGemma 4 E2Bに勝つモデルもない。推論効率ならSarvam、日本語ならNemotron、マルチモーダルの幅ならQwen3-Omni。Gemma 4はどの軸でも上位に入るバランスと、E2Bから31Bまで同じ設計思想で揃うラインナップが差別化ポイントだ。