35Bのモデルが3B分のメモリで動く — Qwen3.6-35B-A3BをMacで試す

Qwenチームが4月16日にリリースしたQwen3.6-35B-A3Bは、名前に仕掛けがある。

35Bは総パラメータ数。A3Bは「Active 3B」の略。つまり、35億パラメータのモデルでありながら、推論時に実際に使うのは3億パラメータ分だけ。残りの91%は寝ている。

これがMixture of Experts（MoE）というアーキテクチャの本質だ。入力されたトークンに応じて、最適な「専門家」だけを選んで起動する。結果として、3Bモデル程度のメモリとコストで、35Bモデルの表現力を引き出せる。

ベンチマークは嘘をつかない

SWE-bench Verifiedで73.4%。同じQwenシリーズの27B Dense版が叩き出した数字を上回っている。Gemma 4-31Bの52.0%とは比較にもならない。

MCPMark（MCPツール統合のベンチマーク）では37.0%で、Gemma 4-31Bの18.1%の2倍以上。エージェンティックなワークフローとの相性が良い。

コンテキスト長は262Kトークンがデフォルトで、YaRN設定で1Mトークンまで拡張可能。Apache 2.0ライセンスなので商用利用も制限なし。

このモデルの真価はローカルで動くところにある。

Unslothが公開している4bit GGUF量子化版を使えば、24GBのApple Silicon Mac（M3 Max、M2 Ultra等）で動作する。Ollamaでの起動は1コマンドだ。

ollama run qwen3.6-35b-a3b

フルF16で動かすには約72GBのメモリが必要になるが、日常的な開発用途なら4bit量子化で十分だ。量子化による精度低下はあるものの、SWE-bench相当のタスクではほぼ体感できないレベルに収まる。

Qwen3.6には27B Dense版も存在する。こちらは27Bパラメータのすべてを毎回使う従来型のアーキテクチャだ。

使い分けの基準はシンプル。

API経由で使うなら、Dense版の方が安定した推論速度を出しやすい。MoEはルーティングのオーバーヘッドがあるため、単一リクエストのレイテンシではDense版に分がある。

一方、ローカルでコストを抑えて動かしたいなら35B-A3Bの方が合理的だ。必要なメモリがDense版の約3分の1で済む。

コーディング性能だけを見れば、35B-A3BとDense 27Bはほぼ同水準。SWE-bench Multilingualでは35B-A3Bが67.2%、Dense 27Bが若干下回る。差は小さいが、メモリ効率を考えればMoE版に軍配が上がる。

MoEモデル共通の課題として、推論時のルーティング不安定さがある。同じプロンプトでも実行ごとに微妙に異なる出力になることがある。コーディングタスクのように「正解が1つ」のケースでは問題になりにくいが、クリエイティブなタスクでは気になるかもしれない。

また、262Kコンテキストは公称値で、128K以上を使うと推論品質が落ちるとQwenチーム自身が推奨最小値を128Kとしている。大きなコードベース全体を一度に読ませたい場面では注意が必要だ。

Qwen3.6-35B-A3Bが示したのは、「高性能＝大量のGPU」という等式がもう成り立たないということだ。

MacBookでSWE-bench 73%のモデルが動く。API不要、データは外に出ない、月額費用はゼロ。クラウドのAPIに毎月数百ドルを払っている開発者にとって、この選択肢が存在するという事実だけで検討する価値がある。

DeepSeek V4がMoEで1.6T/49Bという構成でフロンティアに迫ったのと同じ流れが、今度はローカル実行可能なスケールに降りてきた。「手元のマシンでフロンティア級の推論を回す」未来が、すでに始まっている。