MoE 三つ巴｜gemma4 vs Qwen3.5 vs Qwen3.6、32GB MacBook Air M5 で記事生成に最適な MoE はどれか

こんにちは、パレイド技術部です。

昨日 (4/17) の記事で、新しくオープンウェイト化された Qwen3.6-35B-A3B を Qwen3.5 と比較し、記事執筆補助の用途では、3.6 は3.5とほぼ同等という結果を確認しました。

最近のリリースで、 MoE 系ローカル LLM の主要候補が 3 つ揃いました。gemma4:26b（Google、4/6 既測）、qwen3.5:35b（Alibaba、4/17 既測）、qwen3.6:35b-a3b（Alibaba、4/17 計測）。それぞれ異なる哲学で作られた MoE で、32GB Mac という制約の中でどれが記事生成パイプラインに最適か、同一条件で突き合わせます。

本記事はローカル LLM による自動執筆パイプラインで生成されました。現段階ではクラウド AI（Claude 等）の補助や人間の編集が介在していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。

対戦カード
検証環境
ベンチマーク設計
パイプライン実行結果
品質評価
考察
まとめ

対戦カード

モデル	提供元	総 / 活性	エキスパート	コンテキスト	特徴
gemma4:26b	Google	25.8B / 4B	Dense → MoE 化	128K	Apache 2.0、最も軽量・最速候補
qwen3.5:35b	Alibaba	36.0B / 3B	128 エキスパート	262K	Ollama ブログの推奨 MoE
qwen3.6:35b-a3b	Alibaba	35B / 3B	256 エキスパート（8+1）	262K（YaRN で 1M）	Vision-Language、Gated DeltaNet 混成

活性パラメータは 3〜4B で近接、しかし総パラメータ・エキスパート設計・対応コンテキスト長に違いがあります。gemma4:26b は「小さくて速い」、qwen3.5:35b は「確立された標準」、qwen3.6:35b-a3b は「最新だが Ollama 最適化未完了」という立ち位置です。

検証環境

MacBook Air (M5, 32GB Unified Memory)
macOS Tahoe 26.4
Ollama v0.21.0（MLX バックエンド対応版）
Python 3.12
全モデル Q4_K_M 量子化、thinking OFF

4/17 の実測で裏で作業しながらの実測は影響があったため、今回も他アプリ停止の状態で計測しています。現実にはもう少しメモリに余裕があるハードが好ましいと言えます。

ベンチマーク設計

4/6 および 4/17 の記事と同一条件です。

Tier 1: 記事執筆パイプライン実行 — Pass A (骨子) → Pass B (セクション執筆) → Pass C (アセンブル) の所要時間・tok/s・文字数
Tier 2: 品質評価 — Claude sonnet4.6 で 4 軸（日本語自然さ・技術正確さ・読みやすさ・指示遵守）× 5 段階

パイプライン実行結果

モデル	Pass A (秒)	Pass B (秒)	Pass B tok/s	Pass C (秒)	Pass C tok/s	合計	文字数
gemma4:26b	29.6s	76.4s	26.9	90.4s	23.0	201.1s	3967字
qwen3.5:35b	56.9s	365.4s	13.7	372.5s	12.8	801.6s	8427字
qwen3.6:35b-a3b	63.4s	310.4s	12.8	618.1s	13.0	998.8s	15479字

スピードの単純比較では、gemma4:26b が全ての Pass で圧勝。合計時間で見ると:

qwen3.5:35b の 4.0 倍速い (201s vs 802s)
qwen3.6:35b-a3b の 5.0 倍速い (201s vs 999s)
tok/s も 2 倍以上: Pass B で 26.9 vs 12〜14

Pass C で qwen3.6 が 618 秒もかかっているのは、同モデルが生成ループに陥って「まとめ」セクションを 3 回繰り返す暴走状態になったためです（後述）。結果として出力が 15479 字と他の 2〜4 倍に膨張しました。

文字数あたりの効率で見る

単純な合計時間はスケジューリングと出力量の両方を反映するため、字/秒で正規化してみます。

モデル	合計時間	文字数	字/秒
gemma4:26b	201.1s	3967字	19.7 字/秒
qwen3.6:35b-a3b	998.8s	15479字	15.5 字/秒
qwen3.5:35b	801.6s	8427字	10.5 字/秒

字/秒でも gemma4 がトップ。qwen3.5 が qwen3.6 に逆転されていますが、これは qwen3.6 が生成暴走で字数を稼いだ結果であり、品質を伴っていません。生成された記事を見ると、「まとめ」セクションがほぼ同一内容で 3 回繰り返され、15479 字の大半がこの重複で占められた状態でした。

品質評価

生成された 3 記事を Claude sonnet4.6 で 4 軸 5 段階評価しました。

モデル	日本語自然さ	技術正確さ	読みやすさ	指示遵守	合計
gemma4:26b	3	3	4	4	14
qwen3.5:35b	4	3	4	3	14
qwen3.6:35b-a3b	4	2	2	3	11

gemma4:26b と qwen3.5:35b は同点 14/20、qwen3.6 は 11/20 と大幅に下回りました。

各モデルの質的傾向

gemma4:26b（14/20）: – 文体はやや硬質だが論理展開は明快。「導入→環境→TPS→コンテキスト→パイプライン→結論」の流れが整理されている – 弱点: 「パイプマン構築」（パイプラインの誤字）、「8do GB/s」（脱字）、表中に「4.arg」という数値として破綻した値など、単純な誤字・脱字が 3 箇所 – 特徴: 構成力で勝ち、細部の校正で失点するタイプ

qwen3.5:35b（14/20）: – 自然な技術文体、章立ては論理的 – 弱点: MLX の説明で「NPU（ニューラルエンジン）を効果的に活用」と繰り返し記載（実際は Metal GPU を使用）、ベンチマーク数値の出典が不明 – 特徴: 文体の完成度は最も高いが、もっともらしい誤情報を生成する傾向

qwen3.6:35b-a3b（11/20）: – 致命的な問題: 「まとめ」セクションが 3 回繰り返される生成ループ（読みやすさ 2 点の主因） – mlx.core.free() という 存在しない API を記述（技術正確さ 2 点） – 文体と章立て自体は悪くないが、後半の破綻で記事として公開不可能な状態

qwen3.6 の生成ループは 4/17 記事では発生していなかった

4/17 記事で計測した 2 回の qwen3.6 実行では、このような重複生成は発生していません。同じモデル・同じ条件でも時々暴走するという再現性の揺らぎがあることを意味しており、運用する場合は生成後に重複チェックが必須になります。

考察

なぜ gemma4:26b は速いのか

活性パラメータが 4B（qwen の 3B よりむしろ多い）にもかかわらず gemma4:26b が圧倒的に速い理由は、以下の複合要因と考えられます。

Ollama の最適化対象: gemma4 は Google が直接配布元と組み、Ollama 側でアーキテクチャ最適化が早い段階で入っている。qwen 系は既出の最適化未完了問題（4/17 記事参照）を抱えたまま
総パラメータが小さい: gemma4:26b は 25.8B、qwen3.5/3.6 は 35〜36B。メモリ帯域とキャッシュ局所性で有利
MoE 設計の成熟度: gemma4 は MoE 化が比較的新しいが、Ollama での実装が成熟している可能性

実際、qwen 系はこれまでの実績として Ollama ではあまり安定して動作しません。リリースからスムーズに動いた qwen3.5:35B はむしろ例外的です。当サイトでも、MLXを導入した主な理由がこれです。この結果は、「モデルの公称スペックだけでは実行速度は決まらない」という重要な教訓を与えます。推論エンジン側の最適化状況が同じくらい効く、ということです。

速度と品質のトレードオフは存在しない

今回の興味深い点は、Ollamaでの記事執筆補助という用途においては、gemma4:26b が速度も品質も勝ったことです。通常「速いモデルは品質が落ちる」というトレードオフを想像しますが、今回のデータからはそれが観測できません。また、32GB Mac という制約の下では、適切にサイズされた軽量 MoE の方がコストパフォーマンスが圧倒的に良い、という結論を支持します。無理に 35B 級を動かすより、26B 級（活性 4B）の方が速くて品質も同等、という状況です。

qwen3.6 の立ち位置

4/17 の記事では「qwen3.5 とほぼ同等」と評価しましたが、今回は 生成ループバグという新たな懸念が加わりました。推測ではありますが、登場からまもないこと、Vision-Language モデルであることやアーキテクチャの複雑さ（Gated DeltaNet 混成）から、Ollama バックエンドでの安定動作を難しくしている可能性があります。

現時点では 本番記事生成に使うには早すぎる状態です。Ollama の最適化が進み、再現性のある動作が確認できるまで、採用を見送るのが合理的な判断です。

まとめ

最速モデル: gemma4:26b（qwen3.5 の 4 倍、qwen3.6 の 5 倍速い）
最高品質モデル: gemma4:26b と qwen3.5:35b とほぼ同等
総合推奨: gemma4:26b。速度・品質・安定性すべてで勝るか同等。32GB Mac では明確に最優先候補
qwen3.5:35b の位置づけ: バックアップ/フォールバック候補。品質は安定しており、gemma4:26b で問題が出た場合の選択肢として有効
qwen3.6:35b-a3b の位置づけ: 現時点では採用非推奨。速度で劣り、生成ループバグという新たな再現性問題が確認された。Ollama の最適化と、コミュニティからの安定性報告を待つ段階
重要な教訓: モデルの公称スペックと実行速度は比例しない。推論エンジンの最適化状況が同じくらい効く。新モデルが出ても「ベンチで確認するまで採用しない」方針が正解