AI自動編集に挑む(3)|qwen3.5:35B-A3B(MoE)は 27B を超えるか?MacBook Air M5 で検証

AI自動編集に挑む(3)|qwen3.5:35B-A3B(MoE)は 27B を超えるか?MacBook Air M5 で検証 — AI, qwen3.5, MoE AIテキスト

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

前回・前々回の記事では、MacBook Air M5 + 32GB メモリ環境で、Ollama と MLX を使ったローカル LLM の自動記事生成パイプラインを検証しました。

前回の結論は「qwen3.5:27b + MLX + thinking ON が品質・安定性ともにベスト」。ただし生成時間は約 2600 秒(43 分)と、出先の作業には少し重い。

今回は、前回の記事でも選択肢として挙げていた qwen3.5:35B-A3B(MoE モデル)を試します。パラメータ数は 35B と 27B を上回りますが、MoE(Mixture of Experts)構成のため実際に推論時に活性化するのは約 3B〜6B。つまり「大きなモデルの知識量を持ちながら、小さなモデル並みの速度で動く」ことを狙った設計です。

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

MoE(Mixture of Experts)とは何か

MoE は、モデル内部に複数の「専門家(Expert)」ネットワークを持ち、入力に応じて一部だけを選択的に活性化する構造です。全パラメータを毎回使う従来のモデル(Dense モデル)と異なり、推論時のメモリ使用量と計算量を大幅に抑えられます。

qwen3.5:35B-A3B の場合、35B のパラメータ全体がモデルファイルに含まれますが、1 回の推論で実際に計算されるのは約 3B 分。これにより:

  • メモリ使用量: モデルファイル自体は ~20GB だが、推論時の活性メモリは Dense 3B 相当
  • 生成速度: Dense 27B より大幅に高速になる可能性がある
  • 品質: 35B 分の知識が Expert として分散格納されているため、9B 以上の品質を期待できる

前回の記事の表では「△ 動作可」としていましたが、実際どうなのか。期待半分、不安半分で検証に入ります。

MLX での導入

前回構築した MLX 環境をそのまま使います。モデルは Hugging Face から MLX 向けに量子化済みのものをダウンロードします。

mlx-community/Qwen3.5-35B-A3B-MLX-4bit

サイズは約 20.4GB。32GB メモリの MacBook Air M5 では、モデルのロードだけで 6 割以上を占める計算です。前回の 27B-4bit(~16.1GB)と比べると 4GB ほど大きいですが、推論時の活性パラメータが小さいため、実行時のメモリ負荷はむしろ軽くなる可能性があります。

ダウンロードとロードは問題なく完了。前回の 27B 環境から、モデルパスを差し替えるだけで動きます。MLX の統一的な API のおかげで、モデル切り替えのコストが低いのは助かります。

計測結果:27B の 7 倍速という衝撃

同一プロンプト・同一パイプライン(Pass A〜C の 3 パス構成、thinking OFF)で、27B と 35B-A3B を直接比較しました。前回記事の 9b の結果も参考として併記します。

モデル Pass A Pass B Pass C 合計 文字数 27b比
qwen3.5:9b (MLX) ※前回 51s 166s 171s 388s (6分) 5601字 5.8x
qwen3.5:27b (MLX) 123s 1026s 1111s 2260s (38分) 9507字 1.0x
qwen3.5:35B-A3B (MLX) 51s 141s 132s 324s (5分) 7691字 7.0x

35B-A3B が 27B の約 7 倍速で完走しました。9b すら上回る速度です。

各パスの内訳を見ると、差が最も顕著なのは Pass B(セクション執筆)と Pass C(アセンブル)です。27B では各セクション 130〜260 秒かかっていた Pass B が、35B-A3B では 24〜34 秒。Pass C のアセンブルは 1111 秒 → 132 秒と、8 倍以上の高速化です。

なぜここまで速いのか

MoE の活性パラメータが約 3B であることが直接効いています。Dense 27B は推論時に 27B 分の重みすべてを参照するため、メモリ帯域がボトルネックになります。一方、35B-A3B は全 35B の重みがメモリ上にあっても、実際に計算するのは 3B 分だけ。MacBook Air M5 のメモリ帯域(約 120GB/s)を考えると、Dense 27B は帯域を使い切ってしまうのに対し、MoE 3B はまだ余裕がある計算です。

つまり パラメータ数は 35B > 27B だが、推論コストは 3B < 9B < 27B という、MoE ならではの逆転が起きています。

品質はどうか:9507 字 vs 7691 字

速度は圧倒的ですが、品質はどうでしょうか。

まず文字数の違いが目を引きます。27B が 9507 字に対し、35B-A3B は 7691 字。同じプロンプトで 2000 字近い差があります。27B は冗長な傾向があるとも言え、35B-A3B の方がむしろコンパクトにまとまっている印象です。

前回の検証と同様、客観性確保のため Claude Code に品質評価を依頼しました。日本語の自然さ、技術的な正確性、読みやすさ、指示遵守の 4 項目で比較しています。

27B は「深く掘り下げる」傾向が強く、技術的な記述の精度は高い一方で、冗長さが目立ちます。35B-A3B は「バランスよくまとめる」傾向があり、記事としての読みやすさでは互角以上。ただし、細部の技術説明では 27B の方が正確な場面も見られました。

活性パラメータが 3B であることを考えると、35B 分の知識ベースから Expert を選択するルーティング機構がうまく機能していると言えそうです。Dense 9B を超える品質を、9B 以上の速度で出しています。

thinking モードの bench.py 計測

パイプラインとは別に、単発の推論ベンチマーク(bench.py)でも thinking ON/OFF を計測しています。

モデル Thinking Reply TTFT (秒) TPS (tok/s) 出力トークン数 総応答時間 (秒)
qwen3.5:9b OFF 0.30 19.8 11 0.86
qwen3.5:9b ON 41.4 16.2 697 43.6
qwen3.5:27b OFF 1.42 3.7 11 4.38
qwen3.5:27b ON 187.7 3.2 621 195.8
qwen3.5:35b OFF 0.41 16.4 25 1.94
qwen3.5:35b ON 56.2 15.1 861 57.7

注目すべきは、35B-A3B の TPS(tokens per second)が thinking ON でも 15.1 tok/s を維持している点です。27B は thinking ON で 3.2 tok/s まで落ちるのに対し、35B-A3B は 9b の thinking ON(16.2 tok/s)とほぼ同等の速度で思考できます。

前回の検証で問題だった「thinking の暴走」も、35B-A3B では生成速度が速いため影響が小さくなります。27B で 188 秒かかっていた thinking が、35B-A3B では 56 秒。thinking を有効にしても実用的な時間で収まります。

まとめ:35B-A3B がデフォルトモデルに昇格

正直、ここまでの差が出るとは予想していませんでした。qwen3.5:35B-A3B は、27B と比較して:

  • 速度: 7 倍速(2260 秒 → 324 秒)
  • 品質: 互角以上(冗長さが減り、記事としての完成度はむしろ向上)
  • 安定性: クラッシュなし、thinking も暴走せず実用範囲

MoE アーキテクチャの「大きなモデルの知識を、小さなモデルの速度で」というコンセプトが、MacBook Air M5 の環境で見事に実証された形です。

これまでの 3 回の検証を通じて、自動生成パイプラインのデフォルトモデルを qwen3.5:35B-A3B に変更することにしました。モデル選定の全体像は以下のとおりです。

用途 推奨モデル 環境 所要時間(目安)
日常の記事生成(デフォルト) qwen3.5:35B-A3B MLX 約 5 分
最高品質を追求する場合 qwen3.5:27b + thinking ON MLX 約 40 分
高速ドラフト・軽量タスク qwen3.5:9b MLX or Ollama 約 6〜12 分
クロスプラットフォーム qwen3.5:9b Ollama 約 12〜20 分

27B は品質最重視の場面で引き続き活躍しますが、38 分待つ場面は減りそうです。5 分で記事が生成できるなら、出先のカフェでも気軽にパイプラインを回せます。

ローカル LLM の選択肢は、モデルサイズだけでなくアーキテクチャ(Dense vs MoE)も含めて検討する時代に入っています。パラメータ数の大小だけでモデルの実力を測る時代は終わりつつあり、MoE のような効率的なアーキテクチャが、限られたハードウェアリソースの活用を根本から変える可能性を感じます。

タイトルとURLをコピーしました