Qwen3-Coder-Next 80B Gemma4-26B-A4B MoE MXFP4 コーディング・ベンチマーク ローカルLLM
🔍 まず結論から：Qwen3-Coder 8.7 vs Gemma4 8.3
NVIDIA DGX Spark環境で、2つの強力なローカルLLMを同時に動かしてみました。その名も、Qwen3-Coder-Next 80BとGemma4-26B-A4Bです。どちらのモデルもMoE (Mixture of Experts) アーキテクチャとMXFP4量子化技術を採用しており、コストを気にせず利用できます。
しかし、「どの作業にどのモデルを使うべきか？」という問いには、明確な答えが必要です。そこで、コード生成からリファクタリングまで、5つの主要カテゴリでベンチマークを実施しました。結果として、Qwen3-Coderが平均8.7点でGemma4の8.3点を上回りましたが、モデルごとの特性は全く異なるものでした。
📋 テスト環境とモデルスペック
今回のテストの核となる機材は、DGX SparkのGB10 Grace Blackwellスーパーチップです。このチップは128GBの統合メモリを備えており、CPUとGPUがメモリを効率的に共有できます。そのため、VRAMのボトルネックを気にすることなく、大型モデルを即座にロードすることが可能です。
| 項目 | Qwen3-Coder-Next | Gemma4-26B-A4B |
|---|---|---|
| 総パラメータ数 | 80B | 26B |
| 活性化パラメータ数 | 3B (3.75%) | 3.8B (14.6%) |
| アーキテクチャ | MoE (Sparse) | MoE (Sparse) |
| 量子化 | MXFP4 MOE (GGUF) | MXFP4 MOE (GGUF) |
| コンテキストウィンドウ | 200K | 200K |
| 推論コスト | 無料 (ローカル) | 無料 (ローカル) |
| 特化分野 | コーディング | 汎用 |
MoEは、全パラメータのうち、その作業に必要な少数の「エキスパート (Expert)」レイヤーのみを活性化させる技術です。Qwen3-Coderは80Bのうち3Bのみ、Gemma4は26Bのうち3.8Bのみを使用します。これにより、メモリ帯域の負荷を抑えつつ、大型モデル並みの性能を引き出すことができます。
両モデルとも活性化パラメータが4B未満であるため、推論速度が非常に高速です。特にQwen3-Coder-Nextは、活性化パラメータに対して約10倍高いスループットを示すという研究結果もあります。
🛠️ 5つのテスト詳細結果
Test 1: コード生成 — Thread-safe LRU Cache
最初のテストは、「Thread-safe LRU CacheをO(1)の時間計算量で実装せよ」というリクエストです。モデルがどれほど正確なロジックと型を生成できるかを確認しました。
| メトリクス | Qwen3-Coder | Gemma4 |
|---|---|---|
| ジェネリック・タイピング | Generic[T] (値のみ) | Generic[K, V] (キー+値) |
| 入力検証 | isinstance + 正数チェック | 正数チェックのみ |
| 追加メソッド | delete, contains, len, repr | size, clear, repr |
| テストの包含 | 使用例のみ | assertions + スレッド安全性テスト |
| トークン (prompt/completion) | 48 / 1,610 | 55 / 1,631 |
| スコア | 8.0 | 9.0 ✓ |
このテストではGemma4が勝利しました。Generic[K, V]を活用した精巧な設計と、実行可能なテストスイートを併せて提供したためです。ゼロからコードを書く作業においては、Gemma4の型ヒントを活用する習慣が大きな強みとなります。
Test 2: バグ検出 — 3つの関数の分析
二番目は、意図的にバグを仕込んだ3つの関数（ソート・マージ、二分探索、辞書の平坦化）を分析するテストです。モデルがどれほど細部までコードを読み取れるかを評価しました。
| メトリクス | Qwen3-Coder | Gemma4 |
|---|---|---|
| merge_sorted_lists のバグ | 発見 (tailの欠落) | 発見 |
| binary_search のバグ (3つ) | すべて発見 + 実行トレース | すべて発見 |
| flatten_dict の評価 | “バグなし” (正解) | 偽陽性 ⚠️ |
| 分析の深さ | ステップごとの実行追跡 | 明快だが誤判定を含む |
| トークン (prompt/completion) | 263 / 1,742 | 323 / 1,200 |
| スコア | 10.0 ✓ | 7.0 |
flatten_dict 関数を「バグがある」と誤って判断しました。再帰呼び出しの結果が失敗すると主張しましたが、実際にはPythonのイテレーション規則に従って正常に動作します。このような誤判定は、開発者に不要なデバッグ時間を強いる可能性があります。
結果として、Qwen3-Coderが満点を獲得し、圧勝しました。コードの論理的な欠陥を見つけ出す正確性は、妥協できない重要な要素だからです。
Test 3: アルゴリズム — Merge Overlapping Intervals
三番目は、重なり合う区間をマージするアルゴリズムの実装テストです。効率的なロジックと実装スタイルを比較しました。
| メトリクス | Qwen3-Coder | Gemma4 |
|---|---|---|
| 実装スタイル | current_start/end 変数 | merged[-1] を直接修正 (Pythonic) |
| 型ヒント | なし | List[List[int]] |
| 計算量分析 | 正確 | 正確 + LaTeX表記 |
| エッジケース | 4つ明示 | 簡潔 |
| スコア | 8.0 | 8.5 ✓ |
Gemma4がわずかに優勢でした。Pythonらしい（Pythonicな）コードスタイルと、明確な型ヒントを提供したためです。ただし、Qwen3-Coderは4つのエッジケースを丁寧に指摘しており、防御的プログラミングの観点では非常に優れていました。
Test 4: コード解説 — Run-Length Encoding
四番目は、特定のアルゴリズム（RLE）のコードを見て、それをユーザーに説明する能力のテストです。
| メトリクス | Qwen3-Coder | Gemma4 |
|---|---|---|
| 核心概念の把握 | 即座にRLEを識別 | 即座にRLEを識別 |
| 解説の深さ | 詳細、制限事項に言及 | 簡潔、要約表を含む |
| 注意事項 | “連続する文字のみ”, “文字列を想定” | 基本的 |
| スコア | 9.0 ✓ | 8.0 |
コードを深く理解し、説明する能力においてはQwen3-Coderが勝っていました。アルゴリズムの限界点や注意事項を先回りして指摘するスタイルは、実務におけるドキュメント作成において非常に有用です。
Test 5: リファクタリング — 複雑な条件分岐 + 選択ソート
最後は、既存の複雑なコードをより綺麗に改善するリファクタリング・テストです。
| メトリクス | Qwen3-Coder | Gemma4 |
|---|---|---|
| 主要なリファクタリング | TYPE_RULES 辞書 + sorted() | TYPE_CONFIG 辞書 + sorted() |
| ガード節戦略 | unknown type → continue | inactive FIRST → continue (より効率的) |
| 型ヒント | なし | List[Dict[str, Any]] |
| 設定の配置 | 関数内部 | モジュールレベル (より良い習慣) |
| スコア | 8.5 | 9.0 ✓ |
リファクタリングではGemma4が勝利しました。ガード節（Guard Clause）の順序を効率的に配置し、設定をモジュールレベルに切り出すなど、構造的な設計センスがより際立っていました。
📊 総合分析：数字が語ること
最終スコア表
| テスト項目 | Qwen3-Coder | Gemma4 | 勝者 |
|---|---|---|---|
| 1. コード生成 | 8.0 | 9.0 | Gemma4 |
| 2. バグ検出 | 10.0 | 7.0 | Qwen3-Coder |
| 3. アルゴリズム | 8.0 | 8.5 | Gemma4 |
| 4. コード解説 | 9.0 | 8.0 | Qwen3-Coder |
| 5. リファクタリング | 8.5 | 9.0 | Gemma4 |
| 平均スコア | 8.7 | 8.3 | Qwen3-Coder |
Gemma4は5戦中3勝を挙げましたが、平均スコアではQwen3-Coderが上回りました。その理由は、バグ検出項目における大きな点差にあります。正確性が不可欠な分析作業において、Qwen3-Coderは圧倒的な安定性を示しました。
トークン使用量の比較
| テスト項目 | Qwen3-Coder (合計) | Gemma4 (合計) |
|---|---|---|
| 1. コード生成 | 1,658 | 1,686 |
| 2. バグ検出 | 2,005 | 1,523 |
| 3. アルゴリズム | 715 | 1,040 |
| 4. コード解説 | 1,027 | 891 |
| 5. リファクタリング | 1,104 | 1,246 |
| 合計 | 6,649 | 6,615 |
トークン使用量は両モデルともほぼ同等です。ローカル環境で無料で利用できるため、トークン数は性能に直接影響するものではなく、あくまで参考指標として捉えてください。
公式ベンチマークとの比較
私たちのローカルテスト結果が、公式のベンチマークデータと一致するかを確認しました。
Qwen3-Coder-Next 関連指標:
| ベンチマーク | Qwen3-Coder-Next | 比較対象 | 出典 |
|---|---|---|---|
| SWE-Bench Verified | 70.6 | DeepSeek-V3.2 (70.2) | HuggingFace |
| SWE-Bench Pro | 44.3% | GLM-4.7 (40.6%) | VentureBeat |
| SecCodeBench | 61.2% | Claude Opus 4.5 (52.5%) | WinBuzzer |
Gemma4-26B 関連指標:
| ベンチマーク | Gemma4-26B | 比較対象 | 出典 |
|---|---|---|---|
| LiveCodeBench v6 | 77.1% | Gemma 3 27B (29.1%) | Gemma4 Wiki |
| AIME 2026 | 88.3% | 3.8B 活性化パラメータ基準 | Google Blog |
| Arena AI テキスト | #6位 | 20倍大きなモデルと競合中 | Google Blog |
Qwen3-Coderがセキュアコーディングや複雑な分析に強く、Gemma4がコーディングコンテストや数学的推論に強いというパターンは、公式データとも一致しています。
🎯 用途別ルーティング・ガイド
テスト結果に基づいた、実践的な活用ガイドです。どのような作業を行う際に、どのモデルを呼び出すべきかの参考にしてください。
| 用途 | 推奨モデル | 選択の根拠 |
|---|---|---|
| コード分析 / バグ検出 | Qwen3-Coder | 偽陽性ゼロ、詳細な実行トレースを提供 |
| コード生成 / スキャフォールディング | Gemma4 | 優れた型ヒントとPythonicなスタイル |
| コード解説 / ドキュメント化 | Qwen3-Coder | エッジケースと限界点を明確に識別 |
| リファクタリング | Gemma4 | 構造的な設計センスとOCP原則の適用 |
| 単純な情報抽出 | どちらでも可能 | 軽量な作業では差がほとんどない |
| デフォルト・ルーティング | Qwen3-Coder | 全体的な平均精度の優位性 |
📚 References
- Qwen3-Coder-Next Model Card — HuggingFace (2026)
- Gemma 4: Byte for byte, the most capable open models — Google Blog (2026)
- How DGX Spark’s Performance Enables Intensive AI Tasks — NVIDIA Technical Blog
- Qwen3-Coder-Next: Ultra-Sparse MoE Coding Model — VentureBeat (2026)
- Gemma 4 Coding Performance Benchmarks — Gemma4 Wiki (2026)
- Performance of llama.cpp on DGX Spark — llama.cpp Discussion
- Gemma 4 Day-1 Inference on DGX Spark — NVIDIA Developer Forums
- 関連記事: DGX Sparkでllama.cppデュアルサーバーを構築する
✅ まとめ
Qwen3-Coder-NextとGemma4-26Bは、それぞれ異なる強みを持つ相補的なモデルです。Qwen3-Coderはコードを「読み、分析する」作業において圧倒的な性能を発揮し、Gemma4はコードを「新しく書き、構造化する」作業において優れたセンスを見せてくれます。
DGX Sparkの128GBメモリ内で両モデルを同時に動かし、作業の性質に応じて適切に使い分けることが、まさに最強の戦略です。MoEアーキテクチャのおかげでメモリにも余裕があり、APIコストをかけずに最高峰のモデルの性能をそのまま享受できます。ローカルLLMの時代は、すぐそこまで来ていますね！