こんにちは、パレイド技術部です。
昨日 (4/17) の記事で、新しくオープンウェイト化された Qwen3.6-35B-A3B を Qwen3.5 と比較し、記事執筆補助の用途では、3.6 は3.5とほぼ同等という結果を確認しました。
パレイドQwen 3.6 オープンウェイト版の実力は？記事執筆用途の 32GB MacBook Air M5 で Qwen 3.5 と世代対決こんにちは、パレイド技術部です。 先週 (4/7) の記事で、Alibaba が発表したフラッグシップ LLM Qwen 3.6-Plus のニュースを取り上げ…
最近のリリースで、 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 | 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/6・4/17 の記事と同一条件。他アプリ停止の状態で計測(4/17 実測で裏作業の影響が見られたため)
評価は2段階: 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 に逆転されていますが、これは前述の生成ループによる字数膨張の影響で、品質を伴っていません。
品質評価
生成された 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 回繰り返される生成ループ、mlx.core.free() という存在しない APIを記述 |
後半の破綻で記事として公開不可能な状態 |
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 の最適化と、コミュニティからの安定性報告を待つ段階
- 重要な教訓: モデルの公称スペックと実行速度は比例しない。推論エンジンの最適化状況が同じくらい効く。新モデルが出ても「ベンチで確認するまで採用しない」方針が正解
なお今回はMoEに絞って比較を行なっていますが、denseモデルの qwen3.5:27B は、品質面では 35B よりも標準的に高い結果が出ます。メモリが厳しいものの、同条件（32GB Mac）ではMLXを利用すれば比較的安定して動くためこちらも有力な選択肢です。