こんにちは、パレイド技術部です。
これまで数回にわたり、ローカル LLM の速度ベンチマークを行ってきました。
速度はわかりました。MoE は速い、Dense は安定している。でも肝心の問いが残っています。
「実際に記事を書かせたら、どのモデルが一番使えるのか？」
今回は、pareido.jp の記事生成パイプラインに gemma4 を投入し、qwen3.5 との実戦比較を行います。速度だけでなく、生成される記事の品質も AI ジャッジで評価。自作ベンチマークとして体系化を試みます。
本記事はローカル LLM による自動執筆パイプラインで生成されました。現段階ではクラウド AI（Claude 等）の補助や人間の編集が介在していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。
これまでの経緯
| 記事 | 判明したこと |
|---|---|
| AI自動編集に挑む(1) | M5+32GB で gpt-oss:20b / qwen3.5:9b が実用可。qwen3.5:27b は Ollama でタイムアウト |
| AI自動編集に挑む(2) | MLX に移行。qwen3.5:27b (MLX) が安定動作。27b+thinking が最高品質 |
| Qwen3.5 ベンチマーク | MoE (35B) は Dense (27B) の 4 倍速。thinking ON は 50 倍遅い |
| Gemma 4 速報 | gemma4:26b (MoE) が 42.5 tok/s で最速。VRAM も最小 |
残った課題: gemma4 の「速さ」は確認できた。しかし記事生成に使ったときの品質は未検証。
ベンチマーク設計
今回、再現可能なベンチマークとして以下の 2 層構造で評価します。
評価の 2 層構造
| 層 | 評価内容 | 手法 |
|---|---|---|
| Tier 1: パイプライン実行 | 速度・安定性・出力量 | 固定シナリオで記事生成パイプライン (Pass A→B→C) を実行し、各 Pass の所要時間・tok/s・文字数を計測 |
| Tier 2: 品質評価 | 日本語品質・技術正確さ | 生成された記事を Claude Code CLI で 4 軸 5 段階評価 |
品質評価の 4 軸
| 評価軸 | 内容 |
|---|---|
| 日本語自然さ | 文法・語彙・文体の自然さ。口語と文語の混在がないか |
| 技術正確さ | 技術的な内容が正確か。誤解を招く記述がないか |
| 読みやすさ | 構成が論理的か。見出し・段落の区切りが適切か |
| 指示遵守 | プロンプトの指示に従っているか。文字数・構成の要件を満たしているか |
再現性の確保
- 固定シナリオ: 同一プロンプト・同一連載設定で全モデルを実行
- 外部依存排除:
--no-rag --no-adjustで RAG 検索と文字数調整を無効化 - Thinking OFF: 全モデル thinking (推論過程の内部生成) を無効化
検証環境
- MacBook Air (M5, 32GB Unified Memory)
- macOS Tahoe 26.4
- Ollama v0.20.2（MLX バックエンド対応版）
- mlx-lm（Python MLX 直接実行）
- Python 3.12
対象モデル
| モデル | タイプ | パラメータ | 実行方式 | 備考 |
|---|---|---|---|---|
| gemma4:31b | Dense | 31.3B | Ollama | Google, Apache 2.0 |
| gemma4:26b | MoE (活性化4B) | 25.8B (総) | Ollama | Google, Apache 2.0 |
| qwen3.5:27b | Dense | 27.8B | MLX 直接 | Alibaba, Apache 2.0 |
| qwen3.5:35b | MoE (活性化3B) | 36.0B (総) | Ollama | Alibaba, Apache 2.0 |
Dense 対決（gemma4:31b vs qwen3.5:27b）と MoE 対決（gemma4:26b vs qwen3.5:35b）の 2 軸で比較します。
実行方式が異なる理由
当初は全モデルを統一環境で実行する予定でしたが、2つの制約が判明しました。
- mlx-lm (v0.31.1) が gemma4 未対応 — gemma4 サポートは main ブランチにマージ済み (PR #1093) だが未リリース
- Ollama の MLX バックエンドが qwen3.5:27b (Dense) に非対応 — MLX 加速の対象は qwen3.5:35b-a3b (MoE) のみ。27b は Metal/GGML パスにフォールバックし、パフォーマンスが著しく低下 (#14579)
さらに、qwen3.5 は Ollama 内部で Go ランナーに強制される制約があり (#14493)、penalty 系パラメータが無視されるなどの既知問題も存在します。
さらに、qwen3.5:35b (MoE) を mlx-lm で直接実行したところ、メモリ不足 (kIOGPUCommandBufferCallbackErrorOutOfMemory) でクラッシュしました。35B MoE は総パラメータ数 36.0B で、4bit 量子化でも ~20GB のメモリを消費し、32GB Mac では推論時のバッファ確保に失敗します。
そのため最終的な実行構成は: – gemma4:31b / gemma4:26b / qwen3.5:35b → Ollama v0.20（内部で MLX フレームワークを利用） – qwen3.5:27b → mlx-lm による直接実行
いずれも Apple Silicon の MLX を活用している点は共通ですが、推論エンジンの違いによる速度差が含まれる点に留意してください。
パイプライン実行結果
全 4 モデルで同一プロンプト・同一連載設定で記事生成パイプライン (Pass A→B→C) を実行しました。
Dense 対決: gemma4:31b vs qwen3.5:27b
| モデル | 実行方式 | Pass A (秒) | Pass B (秒) | Pass B tok/s | Pass C (秒) | Pass C tok/s | 合計 | 文字数 |
|---|---|---|---|---|---|---|---|---|
| gemma4:31b | Ollama | 179s | 995s | 2.4 | 888s | 2.4 | 2069s | 4155字 |
| qwen3.5:27b | MLX 直接 | 274s | 1749s | ※ | 1248s | ※ | 3271s | 9445字 |
※ mlx-lm 直接実行ではトークン統計が取得できない（Ollama API のみ提供）
Dense 同士の比較では、gemma4:31b が約 1.6 倍速い結果となりました。ただし qwen3.5:27b は文字数が 2 倍以上多く、指示よりも多くの内容を生成する傾向があります。両モデルとも 32GB Mac では 2〜3 tok/s 程度で、Dense モデルの実用には忍耐が必要です。
MoE 対決: gemma4:26b vs qwen3.5:35b
| モデル | 実行方式 | Pass A (秒) | Pass B (秒) | Pass B tok/s | Pass C (秒) | Pass C tok/s | 合計 | 文字数 |
|---|---|---|---|---|---|---|---|---|
| gemma4:26b | Ollama | 58s | 177s | 12.3 | 150s | 14.1 | 390s | 4181字 |
| qwen3.5:35b | Ollama | 61s | 265s | 12.9 | 281s | 12.9 | 615s | 6681字 |
MoE 対決では gemma4:26b が約 1.6 倍速い。しかし速度差以上に注目すべきは、両モデルとも Dense の 5〜8 倍速いこと。gemma4:26b は 390s（約 6.5 分）で記事を完走しており、実用に十分な速度です。
全モデル一覧
| モデル | タイプ | Pass A | Pass B | Pass C | 合計 | 文字数 | 実行方式 |
|---|---|---|---|---|---|---|---|
| gemma4:26b | MoE | 58s | 177s | 150s | 390s | 4181字 | Ollama |
| qwen3.5:35b | MoE | 61s | 265s | 281s | 615s | 6681字 | Ollama |
| gemma4:31b | Dense | 179s | 995s | 888s | 2069s | 4155字 | Ollama |
| qwen3.5:27b | Dense | 274s | 1749s | 1248s | 3271s | 9445字 | MLX 直接 |
過去データとの比較
前回記事 (Post 1919) での MLX 直接実行の計測値との比較:
| モデル | 環境 | 合計 | 文字数 | 備考 |
|---|---|---|---|---|
| qwen3.5:27b | 今回 MLX | 3271s | 9445字 | thinking OFF |
| qwen3.5:27b | 前回 MLX | 1771s | 3720字 | thinking OFF |
| qwen3.5:9b | 前回 MLX | 727s | 5339字 | thinking OFF |
今回の qwen3.5:27b は前回より大幅に遅い結果となりました。プロンプトの違い（固定ベンチマーク用 vs 通常の記事執筆）と、参考記事の有無による入力長の差が主因と考えられます。生成文字数が 9445 字と過大な点も、処理時間を押し上げた要因です。
qwen3.5:35b の MLX 直接実行はメモリ不足でクラッシュ
qwen3.5:35b を mlx-lm で直接実行したところ、Metal のメモリ不足エラーでクラッシュしました:
35B MoE は総パラメータ数 36.0B で、4bit 量子化でも推論時のバッファ確保に 32GB Mac では足りません。同じ MoE でも gemma4:26b（25.8B）は VRAM 20.1GB で余裕がある対照的な結果です。Ollama 経由ではメモリ管理が最適化されており、同モデルが問題なく動作します。
品質評価
生成された 4 記事を Claude sonnet4.6 で 4 軸 5 段階評価しました。
| モデル | タイプ | 日本語自然さ | 技術正確さ | 読みやすさ | 指示遵守 | 合計 |
|---|---|---|---|---|---|---|
| gemma4:31b | Dense | 4 | 3 | 5 | 4 | 16 |
| gemma4:26b | MoE | 3 | 3 | 4 | 4 | 14 |
| qwen3.5:35b | MoE | 4 | 3 | 4 | 3 | 14 |
| qwen3.5:27b | Dense | 4 | 2 | 3 | 3 | 12 |
品質の傾向
gemma4:31b が最高品質 (16/20)。遅いが、構成の論理性と読みやすさで他モデルを上回りました。「アーキテクチャ → 環境構築 → 性能評価 → 品質検証 → 安定性 → 結論」という明快な流れが高評価です。
gemma4:26b と qwen3.5:35b は同スコア (14/20)。MoE 同士で同等の品質ですが、傾向は異なります。gemma4:26b は構成が整理されている一方で誤字が目立ち（「オーバーホード」「トレードラン」）、qwen3.5:35b は文体の完成度は高いものの未処理プレースホルダーが残りました。
qwen3.5:27b は最低評価 (12/20)。文字数は 9445 字と最多ですが、技術正確さが 2 点と低い。存在しない API パラメータ（gpu_only=True）の記載や、科学的に成立しない因果説明（速度変動が出力品質に影響する）など、事実検証なしに生成している印象です。記事が途中で終了している点も減点対象でした。
共通の課題
全モデルに共通して「“」という未処理プレースホルダーが残りました。パイプラインが参考記事なしの状態で実行されたため、blogcard の挿入先が見つからず、テンプレートがそのまま出力されています。これはモデルの問題ではなくパイプライン側の改善点です。
まとめ
- 速度: MoE が圧倒的。gemma4:26b は 390s（約 6.5 分）で記事を完走し、Dense 最速の gemma4:31b（2069s）の 5.3 倍速い。32GB Mac では Dense モデルの常用は厳しいが、MoE なら実用圏内
- gemma4 vs qwen3.5: 同じアーキテクチャ同士で比較すると、gemma4 が一貫して 1.6 倍速い。ただし qwen3.5 は文字数が多く、詳細な記事を生成する傾向がある
- 安定性: 全 4 モデルが記事生成パイプラインを完走。ただし qwen3.5:35b は mlx-lm 直接実行ではメモリ不足でクラッシュし、Ollama 経由が必要だった
- 推奨構成: 32GB Mac で記事を速く書かせるなら gemma4:26b (Ollama)。品質と詳細さを重視するなら qwen3.5:27b (MLX) だが、約 55 分かかる覚悟が必要
- 環境の分断: 2026年4月時点で、gemma4 と qwen3.5 を同一の推論エンジンで動かすことができない。mlx-lm は gemma4 未対応、Ollama は qwen3.5:27b を MLX 加速しない。この状況は数週間以内に改善される見込み
- ベンチマーク体系化: 固定シナリオ + AI ジャッジの 2 層構造で、今後のモデル追加時にも同一条件で比較可能な枠組みを整備した。品質評価は次のステップとして実施予定
