2026年4月16日、AlibabaのQwenチームからQwen3.6-35B-A3Bがリリースされた。35B総パラメータ・3Bアクティブのスパース MoEモデルで、SWE-bench Verified 73.4%を記録した注目作だ。Apache 2.0ライセンスで商用利用OKという点も、個人開発者には嬉しい。
「32GBのMacでどこまで使えるのか」——その疑問に正面から向き合った。本記事では、MacBook Pro M1 Pro / 32GB RAM環境でのメモリ・速度・実用性の実測データを包み隠さず公開する。
結論を先に言おう。「ロマンはある。ただし日常運用には工夫が必要」——これが率直な感想だ。
この記事で分かること
- Qwen3.6-35B-A3Bの実機メモリ消費(32GB Macでの現実)
- MLX版とGGUF版、どちらを選ぶべきか
- LM Studioでの実測推論速度
- Thinking modeの落とし穴と対処法
- Brave Search MCP連携の実態
- 32GB Macでの現実的な運用パターン
Qwen3.6-35B-A3Bとは
35B総パラメータのうち、推論時にアクティブになるのは3Bだけ、というMoE(Mixture of Experts)モデルです。メリットは:
- アクティブ3Bなので推論速度は軽量モデル並み
- 総重量35Bの表現力を持つ
- Apache 2.0で商用利用OK
- Thinking modeで長考推論可能
Simon Willisonの「ペリカン描画ベンチ」でClaude Opus 4.5を超えたと話題になった一方、「35Bの全重量をロードする必要がある」という制約は変わりません。つまりVRAM/RAMは35B相当必要。
使った環境
| 項目 | スペック |
|---|---|
| マシン | MacBook Pro M1 Pro |
| RAM | 32GB 統合メモリ |
| 推論エンジン | LM Studio 0.4.12+1 |
| モデル | jedisct1/Qwen3.6-35B-A3B-q3-mlx |
| 量子化 | Q3(約15.2GB) |
モデル選びのポイント:MLX版とGGUF版は別条件で比較する
Apple Siliconでは、使うアプリ・バックエンド・量子化・context lengthに対応する形式を選ぶ。この記事の速度はMLX Q3での一例で、MLXとGGUFの一般的な優劣を示す比較ではない。同じQ3でもGGUFよりMLXの方が:
- 速度は比較条件をそろえて測定する必要がある
- メモリ効率が良い
- LM Studioが公式サポート
Hugging Faceで検索すると複数のQ3バリアントが出てくる。変換者の実績とDL数を見て判断するのが無難だ。「Unsloth Dynamic」系はGGUF専用のため、「UD-MLX」と表記されていても実態はGGUFの可能性がある。READMEで必ず確認しよう。
✅ モデル選択チェックリスト
- Apple Siliconなら「mlx」と明記されたバリアントを選ぶ
- Q3量子化を選ぶ(32GB Mac推奨サイズ:約16GB)
- 変換者のDL数・実績を確認する
- 「UD-MLX」表記はREADMEで中身を確認する
実測①:メモリ消費のリアル
モデルをロードした直後のアクティビティモニタがこちらです。
- 使用済みメモリ:30.81GB / 32GB
- スワップ:8.17GB
- メモリプレッシャー:黄色
swapの表示量だけから継続的な書込み量やSSD寿命を判断することはできない。この時はMemory Pressureが黄色だったため、モデルを必要時だけロードする運用を選んだ。
メモリ内訳の推定
| 用途 | 消費メモリ |
|---|---|
| LM Studio(モデル本体) | 約16GB |
| Next.js開発サーバー | 約8GB |
| ブラウザのAIタブ(ChatGPT/Claude) | 約4.5GB |
| システム・その他 | 約2GB |
モデルをEjectした後は使用済みメモリが9.73GB(21GB解放)、スワップも1.48GBまで落ちた。「常駐させる運用は32GB Macでは厳しい」——これが実感だ。必要な時だけロードする運用が現実解になる。
実測②:推論速度とThinking modeの罠
Q3 MLX版での実測速度は約32トークン/秒。M1 Proとしては悪くない数字です。ところが、実際に使ってみると「遅い」と感じる場面が多発しました。
原因:Thinking modeが常時ON
「Brave Searchできないの?」という単純な質問に対して:
| 項目 | 計測値 |
|---|---|
| Thinking時間 | 1分43秒 |
| 生成トークン数 | 3,525(ほぼ思考) |
| 回答生成時間 | 12.38秒 |
| 合計 | 約2分 |
モデル自体は32 tok/sで動いているのに、思考ループが長すぎて体感は激遅になる。「速いのに遅い」という矛盾した体験の原因はここだ。
対処法
LM Studioのシステムプロンプト欄に以下を設定:
/nothink
You are a helpful assistant running locally.
Answer concisely in Japanese.
Thinking is not needed for simple questions.
この試行で使った設定(一般的な推奨ではない)
- この試行ではシステムプロンプトの先頭に
/nothinkを置いた(対応と挙動はモデル・版で確認する) - Context Lengthは必要な長さを選び、メモリ使用量を実測する
- Flash Attentionの対応可否と設定項目はLM Studioの版・バックエンドで確認する
- GPU OffloadやKV Cache Quantizationは、この記事で使ったMLX Q3の設定として検証していない。LM Studioの版、モデル形式、バックエンドごとに対応項目を確認する
- Idle TTLはこの試行では10分にした。自動アンロードの設定項目は版で確認する
実測③:Brave Search MCP連携の落とし穴
LM Studioは最近のバージョンでMCP(Model Context Protocol)に対応しました。Brave Search MCPを接続して、ローカルLLMに検索させてみます。
「東京の品川でおすすめのランチ教えて」
結果:ツールを呼ばずに全部ハルシネーション。存在しない店舗名が複数登場し、「スタバリザーブ東京」が品川にある設定で答えた(実際は中目黒)。
この試行では、MCPを接続してもツールを呼ばず誤った店舗情報を返した。モデル、MCP設定、入力、版を変えた場合の頻度は測定していない。
対処法:システムプロンプトで強制する
実在する場所・店舗・価格・最新情報に関する質問には、
必ず brave_local_search または brave_web_search を呼び出すこと。
ツールを使わずに具体的な店名・住所を答えることは禁止。
これでも完璧な矯正はできない。「ローカルLLMのMCPは補助的なもの」と割り切ることが現実的だ。
実用検証:どんなタスクに向いているか
初期検証で試した範囲では、得意・不得意の傾向が見えた。継続利用の観測期間は元記録から確認できないため、以下を長期利用の結論にはしない。
得意なタスク
| タスク種別 | 評価 | コメント |
|---|---|---|
| コード補完・リファクタリング | ◎ | 英語コードは品質が高い。オフラインで完結できるのが強み |
| 機密情報を含むコードレビュー | ◎ | クラウドに送れない社内コードに最適 |
| 日本語の文章校正・要約 | ○ | 水準は満たすが、Claudeには及ばない |
| 最新技術情報の質問 | ✕ | 学習データのカットオフ後の情報はハルシネーション率が高い |
| ローカル情報(店舗・交通等) | ✕ | MCP連携があっても不安定。クラウドLLMに任せるべき |
Claude / GPT-5との使い分け基準
以下はこの試行での使い分け案であり、一般的な優劣や最適解を示すものではない。
- Qwen3.6を使うとき: オフライン必須の場面、社内機密コードの処理、Claude APIコストを削りたい反復作業
- Claudeを使うとき: 最新情報が必要な質問、複雑なマルチステップ推論、日本語の品質が重要なコンテンツ生成
- GPT-5を使うとき: 画像理解が必要なタスク、OpenAIエコシステムとの連携
結論:32GB Macでの現実的な運用
使い込んでみて辿り着いた運用パターンはこちらです。
❌ 非推奨:Qwen3.6-35B-A3Bの常駐
メモリプレッシャー常時黄色、スワップ発生、開発環境と併存できない。swap量だけではSSDへの影響を判断しない。
✅ 推奨:役割分担する
| 用途 | 使うモデル |
|---|---|
| 常駐・日常用 | より小さいモデル(形式・提供状況は公式で確認)(約6GB)or Bonsai(1.58GB) |
| オフライン機密作業 | Qwen3.6-35B-A3B(必要時のみロード→即Eject) |
| 検索・最新情報・複雑タスク | Claude(クラウド) |
| コード開発 | Claude Code |
Auto-unloadの活用
LM Studioの「Idle TTL」設定で、一定時間未使用でモデルを自動アンロードできます。「Settings → Developer → Auto-unload models after X minutes」を10分に設定しておくと、Eject忘れを防げます。
ローカルLLMの本質的な価値は「軽快さ」
今回の検証で痛感したのは、ローカルLLMは「軽快に動かせる小型モデル」が一番実用的ということ。
- クラウドとローカルの出力品質は、タスク・モデル・評価条件をそろえて比較する必要がある
- 大型モデルを無理に動かすと開発環境を圧迫する
- Web検索・最新情報では、利用する検索ツールと根拠確認の手順を用意する
35Bモデルはロマンです。でも「速い・小さい・常駐できる」の三拍子が揃ったモデルの方が、日々の生産性には確実に貢献します。ローカルLLMが輝く場面は、オフラインで完結する文章整形・校正、機密情報を含むコードレビュー、Claude APIの料金を節約したい反復作業、通信環境の悪い場所での補助ツールに限られると割り切るのが賢明だ。
まとめ
- Qwen3.6-35B-A3Bは32GB Macで動く。ただし常駐は厳しい
- MLX Q3での初期検証値は約16GB、32 tok/sだった(他形式との優劣は未比較)
- この試行ではThinking設定で応答が長くなった。設定の対応と効果はモデル・版ごとに確認する
- MCP連携してもローカル35Bは幻覚を返すことが多い
- 用途ごとにローカルとクラウドを比較して選ぶ
次の一手:まずQwen3.5-9Bから始めよう
いきなり35Bに挑戦するより、まずはより小さいモデル(形式・提供状況は公式で確認)(約6GB)から始めることを強くすすめる。常駐しても開発環境を圧迫せず、体感速度も軽快だ。「これでは物足りない」と感じたタイミングで35Bを試す——端末のメモリ余力と作業時間を見ながら選ぶ現実的な順序だ。
ローカルLLMは進化が速い。Mac Studio M2 Ultra 128GBクラスなら話は別だが、32GB Macの現時点での最適解はクラウドとローカルの適材適所だ。利用時は、モデル形式・context・メモリ使用量・応答品質を自分の環境で測定する。小さな一歩が、長期的な生産性の底上げにつながる。


