こんにちは、パレイド技術部です。
先週 (4/7) の記事で、Alibaba が発表したフラッグシップ LLM Qwen 3.6-Plus のニュースを取り上げました。
その時点ではクラウド API (OpenRouter / Bailian) 経由でしか触れず、オープンウェイト版は「数日以内に公開予定」とだけ告知されていました。それから約 1 週間、Qwen3.6-35B-A3B の重みが Hugging Face に公開されました。
今回は、このオープンウェイト版を 32GB の MacBook Air (M5) に載せ、4/6 の記事で使ったのと同一条件のベンチマークで Qwen 3.5 との世代対決を行います。MoE 同士・同じ活性 3B・同じ Ollama という、変数を極力絞った比較です。
本記事はローカル LLM による自動執筆パイプラインで生成されました。現段階ではクラウド AI（Claude 等）の補助や人間の編集が介在していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。
Qwen3.6-35B-A3B の概要
公開されたのは MoE (Mixture-of-Experts) の 1 バリアントのみです。
| 項目 | 内容 |
|---|---|
| モデル名 | Qwen3.6-35B-A3B |
| 公開日 | 2026-04-16（Hugging Face） |
| タイプ | MoE（Mixture-of-Experts） |
| 総パラメータ | 35B |
| 活性パラメータ | 3B（8 routed + 1 shared エキスパート） |
| ネイティブコンテキスト | 262,144 トークン |
| 拡張コンテキスト | 1,010,000 トークン（YaRN スケーリング） |
| モダリティ | テキスト + 画像 + 動画（Vision-Language Model） |
| 推論エンジン | SGLang / vLLM / Transformers（公式）、MLX-LM / Ollama（コミュニティ） |
| ライセンス | Apache 2.0 |
Qwen3.5 系との位置づけ
先月 (4/3) の記事で Qwen3.5 のラインナップをベンチマークしました。
あくまで当サイトでのユースケースをベースとした独自ベンチマークですが、一般的な傾向としては参考になるかと思います。
そのとき Ollama ブログが推していたのが qwen3.5:35b (35B-A3B MoE)、メモリ消費 ~30GB で 32GB Mac ギリギリのモデルでした。今回の 3.6 版は総・活性パラメータ数とも 3.5 の 35b とほぼ同じ構成で、32GB Mac での動作条件もほぼ同一と予想されます。
4/7 記事で書いた「常時 CoT」懸念は？
Qwen 3.6-Plus (クラウド版) は thinking ON/OFF が切替不可の「常時 CoT」仕様でした。4/7 の記事では、これが Pass A→B→C の多段パイプラインで暴走するリスクを懸念しました。
thinking は強力な機能ですが、チャットなど日常の利用では過剰な場合が多く、オンオフが選べることは重要です。
オープンウェイト版で Hugging Face のモデルカードを確認したところ、enable_thinking: False パラメータによる ON/OFF 制御が可能でした。Qwen3.5 と同様に扱えるため、今回のベンチも thinking OFF で統一できます。
32GB MacBook Air M5 で動かせるか
公式対応の推論エンジン (SGLang / vLLM) はサーバー GPU 前提で、Apple Silicon 向けではありません。コミュニティサポートの以下 2 経路から選ぶことになります。
| 経路 | 期待値 | リスク |
|---|---|---|
| Ollama + Unsloth GGUF (Q4) | ~20GB VRAM で動作見込み。qwen3.5:35b (Ollama) と同クラス | Ollama の MLX バックエンドが 3.6 アーキテクチャ（Gated DeltaNet 混成）を最適化しているか不明 |
| mlx-lm 直接 | Ollama のオーバーヘッドを回避できる可能性 | 4/6 記事で qwen3.5:35b が OOM クラッシュ。3.6 も同様のリスク |
4/6 の先例に倣い、今回は Ollama 経由で計測します。
ベンチマーク設計
4/6 の gemma4-pipeline-benchmark と同一条件で実施します。
当サイトで、普段から記事執筆の補助に実際に使っている構成です。
評価の 2 層構造
| 層 | 評価内容 | 手法 |
|---|---|---|
| Tier 1: パイプライン実行 | 速度・安定性・出力量 | 固定シナリオで Pass A→B→C を実行し、各 Pass の所要時間・tok/s・文字数を計測 |
| Tier 2: 品質評価 | 日本語品質・技術正確さ | Claude sonnet4.6 で 4 軸 5 段階評価 |
品質評価の 4 軸
| 評価軸 | 内容 |
|---|---|
| 日本語自然さ | 文法・語彙・文体の自然さ |
| 技術正確さ | 技術的な内容が正確か |
| 読みやすさ | 構成が論理的か、見出し・段落の区切りが適切か |
| 指示遵守 | プロンプトの指示に従っているか |
再現性の確保
- 固定シナリオ: 4/6 と同一プロンプト・同一連載設定
--no-rag --no-adjust: RAG 検索と文字数調整を無効化- thinking OFF: 全モデルで
enable_thinking: False
検証環境
- MacBook Air (M5, 32GB Unified Memory)
- macOS Tahoe 26.4
- Ollama v0.21.0（MLX バックエンド対応版。4/6 計測時の v0.20.2 から更新）
- Python 3.12
対象モデル
| モデル | タイプ | 総 / 活性 | 量子化 | 実行方式 |
|---|---|---|---|---|
| qwen3.5:35b | MoE | 36.0B / 3B | Q4_K_M | Ollama |
| qwen3.6:35b-a3b-q4_K_M | MoE | 35B / 3B | Q4_K_M | Ollama |
同じ Alibaba 製・同じ MoE・同じ活性 3B・同じ Q4_K_M 量子化・同じ Ollama で、世代差のみを浮き彫りにする構成です。なお 4/6 記事の qwen3.5:35b は Ollama v0.20.2 で計測したため、今回は v0.21.0 環境下で qwen3.5:35b も再計測しています。
パイプライン実行結果
計測は 2 回実施しました。通常の作業を行いながら計測を行なったところ、直感と異なる結果が出たため、他アプリを落としてメモリを可能な限り空けた状態であらためて計測を実施しています。結果の揺らぎと、メモリ制約の影響を分離するためです。
Run 1: VS Code等で作業をしながらの計測
| モデル | Pass A (秒) | Pass B (秒) | Pass B tok/s | Pass C (秒) | Pass C tok/s | 合計 | 文字数 |
|---|---|---|---|---|---|---|---|
| qwen3.5:35b | 43.3s | 270.1s | 17.6 | 330.3s | 14.5 | 656.8s | 8578字 |
| qwen3.6:35b-a3b | 77.4s | 373.3s | 12.4 | 346.7s | 13.0 | 804.1s | 8355字 |
Run 2: 作業を止めてメモリを空けた状態での計測
| モデル | Pass A (秒) | Pass B (秒) | Pass B tok/s | Pass C (秒) | Pass C tok/s | 合計 | 文字数 |
|---|---|---|---|---|---|---|---|
| qwen3.5:35b | 46.2s | 257.6s | 15.7 | 288.3s | 13.9 | 598.5s | 7332字 |
| qwen3.6:35b-a3b | 59.8s | 276.9s | 13.6 | 299.7s | 13.1 | 642.6s | 7374字 |
2 回の比較で見えた 2 つの事実
事実 1: どちらの条件でも qwen3.6 が若干遅い
| Run | qwen3.5 合計 | qwen3.6 合計 | 3.6 / 3.5 倍率 |
|---|---|---|---|
| Run 1（通常） | 656.8s | 804.1s | 1.22 倍 |
| Run 2（メモリ空け） | 598.5s | 642.6s | 1.07 倍 |
差の大小はあれど、qwen3.6 が一貫して遅い方向は変わりません。世代更新による速度向上は、現時点の Ollama バックエンドでは確認できませんでした。
事実 2: qwen3.6 の方がメモリの影響を強く受ける？
メモリを空けた Run 2 での時間短縮率は:
| モデル | Run1 → Run2 短縮率 |
|---|---|
| qwen3.5:35b | -9%（656.8s → 598.5s） |
| qwen3.6:35b-a3b | -20%（804.1s → 642.6s） |
同じ 32GB Mac、同じ Q4_K_M 量子化にもかかわらず、qwen3.6 は qwen3.5 よりメモリ圧に敏感でした。厳密なメモリ使用量の測定はしていませんが、目視ではRun1の場合はアクティビティモニタの表示がほぼ黄色でディスクアクセスが高め、Run2は常にグリーンの状態でした。Run 1 の qwen3.6 で Pass A が 77 秒もかかったのは、他プロセスによるメモリ競合で Metal のバッファ確保やスワップが発生していた可能性が高いです。
安定性
両モデル・両 Run とも Pass A→B→C を完走し、thinking OFF が効いていました。暴走や途中停止はなし。4/7 記事で懸念した「常時 CoT」の影響は、オープンウェイト版では enable_thinking: False で確実に抑制できることが確認できました。
mlx-lm でのテストは見送り
4/6 記事で qwen3.5:35b を mlx-lm 直接実行したところ、Metal のメモリバッファ確保で OOM クラッシュしました。3.6-A3B は総パラメータ規模がほぼ同じで、32GB Mac では同じ経路で OOM することが容易に予測されるため、今回は Ollama 経由のみで計測しています。メモリ圧への敏感さを考えると、mlx-lm 直接実行の実用化はさらに遠そうです。
品質評価
各 Run の生成記事を Claude sonnet4.6 で 4 軸 5 段階評価しました。
Run 1 の評価
| モデル | 日本語自然さ | 技術正確さ | 読みやすさ | 指示遵守 | 合計 |
|---|---|---|---|---|---|
| qwen3.5:35b | 4 | 2 | 4 | 3 | 13 |
| qwen3.6:35b-a3b | 4 | 3 | 3 | 3 | 13 |
Run 2 の評価
| モデル | 日本語自然さ | 技術正確さ | 読みやすさ | 指示遵守 | 合計 |
|---|---|---|---|---|---|
| qwen3.5:35b | 4 | 3 | 4 | 3 | 14 |
| qwen3.6:35b-a3b | 4 | 2 | 4 | 4 | 14 |
2 回とも両モデルが同点（Run 1: 13/20 タイ、Run 2: 14/20 タイ）。世代更新による品質の底上げは観測されませんでした。Run 2 が 1 点ずつ上がっているのは生成内容と採点揺らぎの影響で、モデル間の優劣は安定して互角です。
質的な違い（Run 2 の詳細）
今回、qwen3.5/3.6とGemma4の比較についての記事を書かせてみました。
下記は、それぞれが出力した記事の内容に関する比較です。
qwen3.5:35b の弱点:
– Gemma 4 のモデルサイズ（2B・7B・27B）やベンチマーク数値が、実際のリリース情報と一致しない可能性が高い
– mlx.core.device_memory など実在しない MLX API 名を記述
– 「推理エンジン」という誤字（正しくは「推論エンジン」）
qwen3.6:35b-a3b の弱点: – M2 Pro のメモリ帯域幅を 273.6 GB/s と記述（実際は約 200 GB/s） – M3 Pro を 210 GB/s と記述（実際は約 150 GB/s） – 「MLX が NPU を活用」と記述（実際は GPU バックエンド主体）
共通問題: – 両モデルとも “ という未処理プレースホルダが残存。4/6 記事で指摘したパイプライン側の問題が両世代で再発
興味深い違い: 今回の結果だけを見ると、3.5 はソフトウェア寄りの誤り（存在しない API、誤字）、3.6 はハードウェアスペックの誤り（メモリ帯域、NPU 記述）、に寄る傾向があります。両モデルとも「もっともらしい数値や API をでっち上げる」特性は共通しており、少なくとも技術用途ではファクトチェックが必須です。
考察
まず意外だったのは、3.6 が若干遅いこと。結論から言えば実用上の問題はないレベルの違いですが、仮説として 3 つ考えられます。
- Ollama の 3.6 アーキテクチャ最適化が未完了:
qwen3.5:27b(Dense) が Ollama で MLX 加速の対象外だった前例 (#14579) から、3.6 の Gated DeltaNet + Gated Attention 混成レイアウトにも同種の対応漏れがある可能性。実際、ollama showで 3.6 のアーキテクチャ識別子はqwen35moe（= 3.5 のそれ）として認識されており、専用パスが実装されていない可能性を示唆 - Multi-Token Prediction (MTP) が Ollama で活性化していない: MTP は学習時機能だが、推論時に活用するには推論エンジン側の対応が必要。公式対応エンジン（SGLang / vLLM）では速度向上しても、Ollama で同じ効果が出ているとは限らない
- メモリ圧への敏感さ: Run 1 と Run 2 の 20% の速度差は、qwen3.6 が 32GB Mac の限界に近い領域で動いていることを示唆。総パラメータ数は 3.5 とほぼ同じなのに、ワーキングセットは 3.6 の方が大きい可能性があります。これは DeltaNet の state キャッシュや、256 エキスパート構成での routing テーブルなど、新アーキテクチャ固有のメモリ要件が効いているかもしれません
また、今回の用途、かつthinking=OFFの条件では、品質にも目立った差がありません。Qwen3.6 は agentic coding や長文処理の改善を前面に出していますが、記事生成パイプラインのようなブログ文体の長文タスクは、このモデルが狙うユースケースとは少しズレます。SWE-Bench や Terminal-Bench のスコアが高くても、日本語ブログ執筆で自動的に品質が上がるわけではないことを示しています。
現状、qwen3.5で安定して稼働しているようであれば、急いで3.6に飛びつく理由は少ないように思います。
まとめ
- Qwen3.6-35B-A3B はオープンウェイトの MoE（32GB Mac + Ollama で動作）。4/7 記事で懸念した「常時 CoT」はオープンウェイト版では解消され、
enable_thinking: Falseで制御可能 - 速度: 5-10%程度の差ではあるものの、qwen3.5 が速い。MTP / DeltaNet の速度恩恵は現時点の Ollama バックエンドでは確認できず
- 品質: 世代更新による明確な差はない。
- 32GB Mac での実用性: 実用圏内だが、同時に起動できるアプリは限られる。
- 現時点の推奨: qwen3.5:35b を引き続き使う方が速い。Ollama の 3.6 最適化が進むまで、性能面での乗り換え理由は薄い
- 次ステップ: 次回は gemma4 と比較。4/6 の gemma4:26b (MoE, 390s, 14/20) との「MoE 三つ巴」ベンチで、記事生成パイプラインに最適な MoE を確定させる。
