はじめに

2026年4月、Gemma 4（Google）とQwen3.6（Alibaba）が相次いでリリースされました。どちらもApache 2.0のオープン重みで、同じタイミングで同じようなパラメータ帯に投入された「対抗馬」という位置づけです。

さらに Gemma 4 はDense版とMoE版の両方を同時公開しており、「同じ学習データ・同じチームで作ったDenseとMoE」を横並びで試せる珍しい状況。そこで今回は、Gemma 4 Dense / Gemma 4 MoE / Qwen3.6 MoE の3モデルを DGX Sparkでガチ比較しました。

結論から言うと、Gemma 4 26B MoEが速度・メモリ・品質のすべてで総合勝利。Qwen3.6-35B-A3B は速度・メモリでは僅差ですが、本気のコーディング課題では動かないコードを量産するという衝撃の弱点が判明しました。Dense版の Gemma 4 31B は実用上ほぼ使う理由がなくなっています。MoEアーキテクチャの実効性と、モデル選びで見落としがちな落とし穴、両方が数字で見える面白い比較になりました。

対戦カード

モデル	種別	パラメータ	アクティブ	ファイルサイズ
`gemma4:31b`	Dense	31B	31B	19 GB
`gemma4:26b` (正式名 26B-A4B)	MoE	26B	4B	18 GB
`qwen3.6:35b-a3b`	MoE	35B	3B	23 GB

いずれもQ4量子化済み、Ollama一発で試せます。

ollama pull gemma4:31b
ollama pull gemma4:26b
ollama pull qwen3.6:35b-a3b

検証環境

項目	内容
マシン	NVIDIA DGX Spark (GB10 Blackwell, 128GB統合メモリ)
OS	Ubuntu 24.04.3 LTS
推論エンジン	Ollama v0.16.2
実行モード	think=off（非推論モード）
コンテキスト	262,144 tokens

ベンチマーク設計

5カテゴリ×12プロンプトを用意し、3モデルに同じ質問を投げます。

カテゴリ	プロンプト数	内容
速度	2	短文生成・中文解説
日本語	3	要約・翻訳・敬語変換
コード	3	FizzBuzz・JSON操作・バグ修正
推論	3	数学・論理パズル・算数
長文	1	1500字技術記事

評価軸:

速度（tok/s、eval_duration から計算）
GPUメモリ使用量
品質（応答内容の目視評価）

ベンチスクリプトは短いので本文末尾に貼ります。

結果1: 速度 — MoE圧勝、Gemma 4 MoEが僅差トップ

全12プロンプトの生成速度：

プロンプトID	Gemma 4 31B Dense	Gemma 4 26B MoE	Qwen3.6-35B-A3B
speed_short	10.69	59.77	54.91
speed_medium	10.59	60.16	55.62
ja_summary	10.72	59.80	56.01
ja_translate	10.49	58.75	55.32
ja_keigo	10.50	59.10	53.99
code_fizzbuzz	10.67	59.73	54.65
code_parse_json	10.62	60.69	54.68
code_debug	10.36	59.11	53.28
reason_math	10.14	59.20	54.29
reason_logic	10.06	56.86	54.17
reason_apple	10.48	59.58	54.47
long_tech	10.04	57.27	55.00
平均	10.45	59.17	54.70

Gemma 4 26B MoE が全プロンプトで首位、平均 59.17 tok/s。Qwen3.6-35B-A3B が 54.70 tok/s で僅差2位、Dense版Gemma 4 31B は 10.45 tok/s で大きく離されました。

比率で見ると：

Gemma 4 MoE ÷ Dense = 5.66x
Qwen3.6 MoE ÷ Dense = 5.24x
Gemma 4 MoE ÷ Qwen3.6 MoE = 1.08x

MoE同士ではほぼ同等ですが、一貫してGemma 4のMoEが5〜10%速い結果になりました。

結果2: メモリ — Gemma 4 MoEが最軽量

Ollama実行時のGPUメモリ使用量（コンテキスト 262K 付き）：

モデル	GPUメモリ使用量
Gemma 4 31B Dense	47 GB
Gemma 4 26B MoE	25 GB
Qwen3.6-35B-A3B	34 GB

Gemma 4 MoE が 25 GB で最軽量。Dense版と比べて22 GBも軽く、Qwen3.6 MoE と比べても 9 GB軽い。

重みファイル自体は 18〜23 GB とほぼ同じですが、コンテキスト 262K のKVキャッシュと活性化メモリの差が実ロード時に大きく効いてきます（Dense は全レイヤーで毎トークン計算が走るぶん作業領域が肥大化しやすい傾向。厳密な内訳は実装依存なので本記事では深追いしません）。

DGX Spark 128GB統合メモリなら3つとも余裕で動きますが、Gemma 4 26B MoEなら他プロセスやマルチセッション運用に大幅な余裕を残せるのは大きな利点。

結果3: 品質 — MoE化しても劣化なし

日本語要約 — 3モデル互角

Prompt: DGX Sparkの説明文を100字以内で要約

Gemma 4 31B Dense:

NVIDIAが2026年初頭に発売したDGX Sparkは、GB10 Blackwell GPU等を搭載した小型AI開発機です。大規模モデルやMoE型モデルを個人環境で効率的に扱える点が評価されています。

Gemma 4 26B MoE:

NVIDIAが2026年初頭に発売したDGX Sparkは、Blackwell GPU搭載のデスクトップ型AI開発機です。個人環境で大規模モデルを扱えるのが特徴で、特にMoE型モデルでの高品質な推論に優れています。（99文字）

Qwen3.6:

NVIDIAのデスクトップ型AI開発機「DGX Spark」は、2026年初頭にリリースされた。GB10 GPUと128GBメモリを搭載し、従来のサーバー環境でしか難しかった大規模MoEモデルを個人レベルで高品質に推論可能にするのが特徴である。

→ 3つとも過不足なし。Gemma 4 MoEは文字数カウントまで添えてくる律儀さ、Qwen3.6は「128GBメモリ」という具体値を拾うお利口さ。

日本語翻訳 — Gemmaスタイル貫徹

Prompt: 英語の技術文1文を日本語に翻訳

Gemma 4 31B Dense / 26B MoE: ともに「標準的・専門的・噛み砕いた」の3バージョンと解説付き。Gemma 4ファミリー共通のスタイルがMoE版でも完全に保たれています。
Qwen3.6: 1文だけ、素直に翻訳。

→ Dense→MoE で学習データ・振る舞いがほぼ継承されていることが確認できます。指示従順性の観点ではQwen3.6が優位、「提案型」が好みならGemma 4。

コーディング（基礎） — 3モデルとも同品質

FizzBuzz・JSON操作・バグ修正ともに、3モデルすべて模範解答を生成。ここまでは差が見えません。

コーディング（応用） — ここで本当の差が出ました

基礎課題だけでは差が出なかったので、「本当に使えるモデルはどれか」を炙り出すために、Trie + 編集距離によるファジー検索という歯ごたえのある実装課題を与えました。

プロンプト要約:

insert / search / starts_with / delete / autocomplete / fuzzy_search を備えた Trie クラスの実装
delete は「他単語の接頭辞として使われているノードは残す」条件付き
fuzzy_search はナイーブな全走査ではなく、Trie特性を活かして DPテーブルを枝刈り共有する効率実装
動作テストコードも添付、説明文不要

これは GitHub で言えば「LeetCode Hard」レベル。特にTrie上での編集距離DPは、書き慣れていないと設計ミスしやすい典型問題です。

結果を用意した8項目のテストスイートで自動検証しました：

モデル	生成トークン	Wall Time	テスト結果	備考
Gemma 4 31B Dense	1,670	187.7s	✅ 全8項目PASS	簡潔で的確
Gemma 4 26B MoE	2,206	47.7s	✅ 全8項目PASS	Dense と同等品質を4倍速で
Qwen3.6-35B-A3B	4,422	127.4s	❌ 7項目FAIL	`fuzzy_search` が空を返す

Qwen3.6 の何が壊れたのか

生成された346行のコードを精査したところ、fuzzy_search が内部で呼んでいる _fuzzy_search_dfs が pass だらけの未完成メソッドでした：

def _fuzzy_search_dfs(self, node, target, max_distance, current_col, results):
    if min(current_col) > max_distance:
        return
    if node.is_end and current_col[len(target)] <= max_distance:
        # We need the actual word. We don't have it here, so we need to track the word.
        # Let's change the DFS signature to include the current word being built.
        pass   # ← 結果収集なし

    # To get the word, we need to know the path. Let's modify the signature.
    # But for now, let's just store the node and reconstruct later? No, that's inefficient.
    # Let's pass the current word string.
    pass   # ← 子ノード探索もなし

正しい実装は別メソッド _fuzzy_search_dfs_with_word として存在しているのですが、fuzzy_search からは旧メソッドを呼び続ける配線ミスのまま出力が終わっています。Qwen3.6が生成中に「あ、引数に単語が必要だ」と気づいて新メソッドを追加したものの、呼び出し元を更新し忘れたという典型的な途中変更ミス。

さらに、fuzzy_search 本体には175行もの "LLMが考え込んでいる自問自答" コメントがそのまま残っていました：

# We will traverse the trie, maintaining a DP matrix at each step.
# However, maintaining a full DP matrix at each node is expensive in memory.
# ...
# But wait, the target word is fixed. We want to find all words...
# Actually, we can do a DFS, and at each node, we have a DP row...
# But note: the standard recurrence is:
# dp[i][j] is distance between T[:i] and P[:j].
# dp[i][j-1] + 1 corresponds to deleting T[i-1]? No.
# Let's define:
# ...

プロンプトでは「docstring は最小限、コメントは核心のみ」と明示していたので、これは指示違反かつ "動かないコード" という二重の減点です。

Gemma 4 の冴え

対するGemma 4は、DenseもMoEも簡潔で正しい実装を生成：

def fuzzy_search(self, word: str, max_distance: int) -> List[str]:
    results: List[str] = []
    current_row = list(range(len(word) + 1))

    def _search_recursive(node: TrieNode, char: str, row: List[int], path: str):
        next_row = [row[0] + 1]
        for i in range(1, len(word) + 1):
            insert_cost = next_row[i - 1] + 1
            delete_cost = row[i] + 1
            replace_cost = row[i - 1] + (0 if word[i - 1] == char else 1)
            next_row.append(min(insert_cost, delete_cost, replace_cost))

        if node.is_end_of_word and next_row[-1] <= max_distance:
            results.append(path)

        if min(next_row) <= max_distance:  # 核心的な枝刈り
            for next_char, next_node in node.children.items():
                _search_recursive(next_node, next_char, next_row, path + next_char)

    for char, node in self.root.children.items():
        _search_recursive(node, char, current_row, char)
    return results

DP行を子ノードに渡して共有しつつ、最小値が閾値を超えた時点で枝刈りというTrie上ファジー検索の教科書通りの実装。コメントは核心の1行だけ。プロンプトの要件を正確に満たしています。

結論: 基礎的なコーディング課題では3モデルとも合格でしたが、アルゴリズム設計力が問われる実装課題では Gemma 4 ファミリーが明らかに優位。Qwen3.6 は思考プロセスを吐き出しすぎて設計途中でブレ、最終的に動かないコードを提出しました。

Claude Code等のバックエンドとして、「ちゃんと動くコードを書かせたい」なら Gemma 4 26B MoE が現時点の最適解と言えそうです。

算数 — 3モデル正解

「りんご20個を1/4, 1/3, 1/2と配ったら残りは？」→ 3モデルとも「5個」で正解、段階計算つき。

数学（整数解存在判定） — 3モデル正解

「条件を満たす3桁の整数を全て求めよ」→ 実は $5x = 34$ という非整数解になる引っかけ問題。3モデルとも「該当なし」を正しく導出。特にGemma 4 MoEは "$a = 17/2.5 = 6.8$" と分数処理も綺麗。

論理パズル — 3モデルで性格が分かれた

Prompt: 3人のうち1人だけ嘘つき。A「Bは嘘つき」B「Cは嘘つき」C「AとBは嘘つき」。嘘つきは誰？

この問題、実は厳密には条件を満たす解が存在しません（全パターンで矛盾が生じる）。3モデルの反応：

モデル	初回結論	生成tok	壁時計	振る舞い
Gemma 4 31B Dense	B	1,223	122.4s	矛盾を認識して「慣例的にB」
Gemma 4 26B MoE	C	1,622	29.5s	途中で自己修正を試みる
Qwen3.6-35B-A3B	A	3,325	62.9s	長々と自己修正、最終的に"B"

壁時計（実時間）で見ると Gemma 4 MoE が圧倒的に速い。29.5秒で応答完了するのは、この3モデル中で際立っています。Qwen3.6 はトークンを多く吐くぶん実時間でも遅くなっています。

長文生成 — 3モデルとも合格ライン

「MoEの仕組みを1500字で解説」には、3モデルすべて構造化された技術記事を生成。Gemma 4（Dense/MoEとも）は $k$ 等の数式表記を使う論文寄りスタイル、Qwen3.6は自然な日本語プロース寄り。好みの問題です。

総合評価

評価軸	勝者
速度（tok/s）	✅ Gemma 4 26B MoE (59.17)
メモリ効率	✅ Gemma 4 26B MoE (25 GB)
指示従順性（短い指示）	✅ Qwen3.6（翻訳等で素直）
指示従順性（制約込み）	✅ Gemma 4（"コメント最小"等の制約遵守）
応答の豊かさ	✅ Gemma 4 系（Dense/MoEとも3案提示）
日本語品質	3モデルほぼ同等
基礎コーディング	3モデルほぼ同等
応用コーディング（Trie+DP）	✅ Gemma 4 両方（Qwenは致命バグ）
推論タスク	3モデルほぼ同等（壁時計はGemma 4 MoE）
長文生成	3モデルほぼ同等

こう使い分けたい

Gemma 4 26B MoE を選ぶべき場合（本命）:

ほぼすべての汎用用途 — DGX Spark でローカルLLMを使うなら現時点の第一候補
対話エージェント、Claude Code等のバックエンド
マルチセッション、長コンテキスト運用

Qwen3.6-35B-A3B を選ぶべき場合:

指示に素直な応答が欲しい（Gemma 4の"3案提示"が邪魔な用途）
短めのチャット・単純な生成タスクで速度も欲しいとき
ただし複雑なアルゴリズム実装を任せるのは要注意（本記事のTrie+DP課題では致命的な未配線バグが発生）

Gemma 4 31B Dense を選ぶべき場合:

Denseモデル特有の推論特性を研究したいとき
バッチ推論で総トークン消費を抑えたいとき（生成tokが少なめに収まる傾向）
それ以外の実用用途では、正直メリットを見つけにくい

まとめ

DGX Sparkで同世代のDense/MoE 3モデルを比較したところ、Gemma 4 26B MoE が速度・メモリ・品質のすべてでバランス最強という結果になりました。Qwen3.6-35B-A3B は速度・メモリでは僅差で並ぶものの、アルゴリズム実装のような本気のコーディング課題では動かないコードを生成してしまう弱点が見えました。

一方、Dense版の Gemma 4 31B は、同一ファミリーのMoE版が5.66倍速く22GB軽くて品質も同等という現実の前に、用途を選ぶ立場になりました。

2026年、MoEはもう「将来の技術」ではなく「いま選ぶべき標準解」 です。Dense一辺倒の時代は確実に終わりました。

DGX Sparkのようなローカル大規模推論環境をお持ちの方は、ぜひ3モデルともpullして手元で検証してみてください。

おまけ：ベンチスクリプト

Ollama APIを直叩きするPythonスクリプトです。

import json, urllib.request

def run(model, prompt):
    data = json.dumps({
        "model": model, "prompt": prompt, "stream": False,
        "think": False, "options": {"num_predict": 4096},
    }).encode()
    req = urllib.request.Request(
        "http://127.0.0.1:11434/api/generate",
        data=data, headers={"Content-Type": "application/json"},
    )
    with urllib.request.urlopen(req, timeout=600) as resp:
        r = json.loads(resp.read())
    tok_s = r["eval_count"] / (r["eval_duration"] / 1e9)
    return r["response"], r["eval_count"], tok_s

text, n, tps = run("gemma4:26b", "Pythonでhello出力のワンライナー")
print(f"{n} tok, {tps:.1f} tok/s")

参考: