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環境でのメモリ・速度・実用性の実測データを包み隠さず公開する。

結論を先に言おう。「ロマンはある。ただし日常運用には工夫が必要」——これが率直な感想だ。

この記事で分かること

ローカルLLMの結果は条件と一緒に。実行条件を記録:モデル版・量子化・ランタイム・設定、取得元と測定時点を区別する。互換性を確認:MLX形式とGGUF形式を区別、ランタイムに対応したモデルを使う。結果を比較:同じ課題で待ち時間と品質を測る、SSDを追加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・メモリ使用量・応答品質を自分の環境で測定する。小さな一歩が、長期的な生産性の底上げにつながる。

使用したモデル・ツール