M2 MacBook Pro（32GB RAM）でQwen 3.6 35B-A3Bを回してコーディングするフィールドレポート

TL;DR: ついにこれが動くようになって、32GB RAMのMacというかなり厳しい条件の中で、ちゃんと実作業できるようになりました。

では、Julien Chaumondのように飛びたい人のために、更新版のHOW-TOと、私がやったことの理由の説明、そして実際にどれくらいちゃんと動くのかについての私見をまとめます。

これはある時点のスナップショットです。セットアップが良くなるにつれて、修正版を継続して投稿します。

HOW-TO

* モデルはローカルで動かすために llama.cpp を使います。ただし、これらのモデルは本当に新しく、バグは常に修正されています。なので llama.cpp はソースからビルドする必要があります。思ったより簡単です。

もし一度もやったことがないなら、MacOS のコマンドライン開発者ツールをインストールしてください：

xcode-select --install 

これで llama.cpp をビルドできます：

git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DCMAKE_BUILD_TYPE=Release cmake --build build --config Release -j$(sysctl -n hw.logicalcpu) export PATH="$HOME/llama.cpp/build/bin:$PATH" 

* この export 行を .bashrc または .zshrc に追加しておけば、毎回アクセスできます。

* モデル本体をダウンロードします。私はこれらをそのまま直接ダウンロードするのが好きです：

* ホームディレクトリ内に models サブディレクトリを作成してください。

* https://huggingface.co/unsloth/Qwen3.6-35B-A3B-GGUF にアクセスします

* UD-IQ4_XS をクリック

* Download をクリック

* ダウンロードしたファイルを models に移動します

* 一致するビジョンアダプタをダウンロードするために、https://huggingface.co/unsloth/Qwen3.6-35B-A3B-GGUF/blob/main/mmproj-BF16.gguf にアクセス

* Download をクリック（そこにあります、よく見てください）

* そのファイルも models に移動します

* CHROME と TERMINAL 以外のすべてのアプリを閉じてください。はい、vscode も含めてです。できる限りブラウザのタブをたくさん閉じてください。 長時間の徹夜セッションなら、Chrome も閉じてください。Chrome は大量のRAMを使い、無駄なRAMは敵です。このモデルは……ぎりぎり……なんとか収まります。

* 動作確認：

llama-cli -m ~/models/unsloth/Qwen3.6-35B-A3B-UD-IQ4_XS.gguf --mmproj ~/models/unsloth/mmproj-BF16.gguf -c 131072 --batch-size 256 -ngl 99 -np 1 --host 0.0.0.0 --port 8899 

これらのオプションをそれぞれ使った理由は、後で説明します。

これはシンプルなチャットUIを起動し、完全にあなたのマシン上だけで動作します。

最初の問い合わせはかなり時間がかかります！ただし、放置しない限り、後続の応答はずっと速くなります。llama.cpp は、使っていないときは身を引いてリソースをシステムに返すように設計されています。

* 次に、.bashrc または .zshrc にエイリアスを追加して、いつでもチャットUI、または OpenAI 互換のAPIサーバを起動できるようにします：

alias qwen-server='llama-server -m ~/models/unsloth/Qwen3.6-35B-A3B-UD-IQ4_XS.gguf --mmproj ~/models/unsloth/mmproj-BF16.gguf -c 131072 --batch-size 256 -ngl 99 -np 1 --host 0.0.0.0 --port 8899' alias qwen-chat='llama-cli -m ~/models/unsloth/Qwen3.6-35B-A3B-UD-IQ4_XS.gguf --mmproj ~/models/unsloth/mmproj-BF16.gguf -c 131072 --batch-size 256 -ngl 99 -np 1 --host 0.0.0.0 --port 8899' 

* source ~/.bashrc を実行するか、新しいターミナルを開いて、今すぐこれらのエイリアスを使い始められるようにします。

* qwen-server を起動します。

* 別のターミナルウィンドウで opencode をインストールします。最新リリースを最短で取る方法は：

curl -fsSL https://opencode.ai/install | bash 

繰り返しになりますが、状況はどんどん変わっていくので、最新リリースを使うのが良いです。別の手段でインストールしたい場合や、私が変なアドバイスをしていないことを確認したい場合は、opencode のサイトを見てください。

* たぶん .bashrc または .zshrc にこの行を追加して、手動で opencode を PATH に入れる必要があったと思います：

export PATH=/Users/boutell/.opencode/bin:$PATH 

* opencode がローカルモデルと通信するように設定します。

~/.config/opencode/opencode.json を作成して、次のように入力します：

{ "$schema": "https://opencode.ai/config.json", "tools": { "task": false }, "provider": { "llama.cpp": { "npm": "@ai-sdk/openai-compatible", "name": "llama-server (local)", "options": { "baseURL": "http://127.0.0.1:8899/v1" }, "models": { "Qwen3.6-35B-A3B-UD-IQ4_XS": { "name": "Qwen3.6-35B-A3B-UD-IQ4_XS", "limit": { "context": 131072, "output": 49152 }, "attachment": true, "modalities": { "input": ["text", "image"], "output": ["text"] } } } } } } 

各設定値は後で説明します。

* では、cd であなたのプロジェクトのどれかに移動して opencode を実行：

opencode 

* opencode のUIが出てきたら、正しいモデルを選びます。間違えて無料のデフォルトのクラウドモデルで30分も作業しないでください。まあ、そんなことをする人は知らないですけどね。ええと。

具体的には、このモデルを選びます：

Qwen3.6-35B-A3B-UD-IQ4_XS

見当たらない場合、たぶん opencode.json を正しく設定できていません。

* 「hello」と言って応答を待ちます（繰り返しですが、最初はとても遅いかもしれません。後続の応答は速くなります）。

* これで準備完了です！ opencode は Claude Code と同じように使えます。

うまくいかないこと

* うっかりして electron アプリやブラウザのタブに大量のRAMを使ってしまうと、非常に遅くなるか、llama-server がメモリ不足エラーでクラッシュします。

* ときどき、XMLっぽい思考トレースを表示して、そのまま……止まることがあります。続行するようにプロンプトすれば動きます。おそらく qwen がツール呼び出しをうまくやれておらず、opencode 側にその種類の応答を上手く認識して再試行するためのコードがないのが原因だと思われます。

「なぜその量子化モデルを選んだの？」

Mac は素晴らしいです。統一メモリ（unified RAM）を搭載しているので、CPU と GPU の両方がそのRAMを100%見ることができます。とはいえ、32GB RAM はこれらのモデルにとっては単に超・超・きついです。そもそも収まるのが奇跡みたいなものです。知能や精度をある程度犠牲にすることになっても、量子化モデルを選ばざるを得ません。

フルサイズのモデルは絶対に入りません。そこで最初は、多くのガイドに載っている Q4_K_M を試しました。技術的には入るのですが、十分なコンテキストサイズのためのメモリが残りませんでした。

IQ4-XS（Extra Small）モデルは、さらに数GB分のRAMを取り戻してくれます。しかも必要なのはまさにそのすべてです。

「なぜそれらのオプションを全部使うの？」

そのコマンドがこれ：

llama-server -m ~/models/unsloth/Qwen3.6-35B-A3B-UD-IQ4_XS.gguf --mmproj ~/models/unsloth/mmproj-BF16.gguf -c 131072 --batch-size 256 -ngl 99 -np 1 --host 127.0.0.1 --port 8899 

* -m はもちろんモデルを指定します。

* --mmproj は「ビジョンプロジェクター」ファイルを選びます。opencode にスクリーンショットを貼り付けられるようにするには、これが必要です。この機能により、opencode は playwright を使ってスクリーンショットを撮影し、それを確認して問題をデバッグできる可能性もあります。

* -c 131072 はコンテキストサイズを 128K に設定します。このモデルは最大 256K まで対応しますが、このマシンではメモリの余裕が足りません。しかし Qwen は、128K 未満に下げないでほしいと言っています。さもないとモデルが混乱するからです。なので、これは私なりの折衷案です。

* --batch-size 256 は、ビジョンに必要なシステム要件を抑えるのに役立ちます。--mmproj とプロジェクターのファイルを省くなら、これをスキップできます。

* -ngl 99 は、すべてのモデル層を最適なパフォーマンスのために VRAM（Mac の場合はユニファイドメモリ）に読み込みます。

* -np 1 は、 llama.cpp が同時に複数のリクエストを処理しようとしないようにします。代わりに、それらをキューに入れて順番に処理します。これは、メモリとコンテキストの両方が厳しいときに重要です。試しに -np 2 を使ってみるのはいいかもしれませんが、これより上にはしません。

* --host 127.0.0.1 は、接続を自分のコンピューターからのみに制限します。

* --port 8899 は、他のサービスが通常取らないポートを選びます。opencode.json が一致していることだけ確認してください。

「なぜこれらの opencode 設定を使うのですか？」

大部分は、単に「正しい場所」（正しいポート付きの正しい API URL、正しいモデル名）を指しているだけです。

ただ、より面白いのは次の設定です：

 "limit": { "context": 131072, "output": 49152 }, "attachment": true, "modalities": { "input": ["text", "image"], "output": ["text"] } 

limit は、コンテキストサイズがどれくらいか、そして qwen からの単一の応答がどれくらいの大きさになり得るかを opencode に伝えます。そうすることで、セッションをいつコンパクトにする必要があるかを判断できます。コンテキストウィンドウが小さいと、コンパクションは必須で、しかも十分早く行われないとセッションが失敗します。出力の値を高く設定しないと、モデルが頻繁にコンテキスト切れを起こして諦めてしまうのを見つけました。出力を 49152 に設定することで解決します。

attachment と modalities は、単にこのモデルが何をサポートしているかを宣言しているだけです。これらに加えて mmproj オプションがないと、opencode は貼り付けたスクリーンショットを読み取ったり、テスト中に playwright が作成した画像を見たりできません。画像サポートが不要なら、これらはスキップして構いません。

「じゃあ、なぜただ…しないのですか？」

* Claude Code は使いませんか？ 小さなコンテキストウィンドウ向けの最適化が足りないせいで問題がありました。長時間かけて大きなプロジェクトを独立して完了させるようなタスクは、私にとって重要です。だから Claude Code は使いません。

* pi.dev は使いませんか？ ええ、知っています。限定されたコンテキストウィンドウには、そっちの方がなお良いです。とはいえ、コンテキストを保存できるのが常に理想です。それが次の候補です。

* エージェントに対して Web 検索ツールを提供しませんか？ これも私のリストにあります。

* mlx を使いませんか？ llama.cpp と mlx のギャップはかなり小さくなっています。特に M2 しかない場合は。しかも mlx 側では後から問題が解決される傾向がありますし、私は非常に新しい qwen 3.6 で作業しています。少し速いかもしれませんが、私にとって根本的な問題を解決するわけではないと思います。

すごい！でも…どれくらい使えますか？

まあ…

実際の作業から、かなり現実的な 2 つの難題（フェアな挑戦）を与えました。これらは Claude Code が Opus 4.6 で完了できたものです。そして最近の経験から、Opus 4.5 の頃までさかのぼっても、たぶん同様に動いていたと思います。あの有名な 11 月のリリースの日です。私のような経験豊富な開発者の多くが、それまでキーボードを叩いてコードを書いていたのをやめて、代わりに Claude Code を指揮するようになった日。

1 つ目は、挨拶カードを作るためのかなりシンプルな Web アプリです。私は、前から「自分では調べるのが面倒で放置していた」古いバグを見つけるように頼みました。バグは、Web ベースの CSS 駆動エディタと、pdfkit ベースの PDF サポートの間で、カード上の画像の位置に不一致があることに関係していました。

2 つ目は、ApostropheCMS の代替データベースバックエンドとして SQLite サポートを追加することです。ApostropheCMS のデフォルトは MongoDB です。

さて、1 つ目はもっと簡単そうに思うでしょう。ですが、このモデルは幾何学（ジオメトリ）の理解がどうしても少し足りません。たいてい実際の問題（これは Opus がすでに正確に当てていたので私には分かっています）を言い当てますが、その後の実装では大きく迷走します。これまでに複数回、2 つのサイズの間でエディタのサイズが激しくチラつく（strobe）ような実装を作ってしまいました。ええ、つらかったです（でも、ちょっと面白かった）。ただ 1 回だけ、なんとか直ったように見えたのですが、画像の下に余計に見えるスペースが追加されてしまい、それを取り除けませんでした。

なので次は 2 つ目の問題に取り掛かりました。そしてそれも、最初はやっぱりがっかりでした。

Qwen は Opus と同様の推論の流れで進めました。ApostropheCMS における mongodb の Node.js API の既存の利用箇所を棚卸しし、同じ API を使ったエミュレーションを作る。

しかし最初の実装は、私がそうするように指示したにもかかわらず、実際の JSONB の操作を使いませんでした。データベース全体を取得してから、RAM 上でドキュメントをフィルタリングする、というものでした。うーん…違います。

Qwen はまた、ApostropheCMS のユニットテストをすべて通そうとしても迷走しました…というより、どれか一つでも通すのが難しい感じでした。さまざまなプロパティがどこから来ているのかを追跡しようとするのですが、常に行き詰まり、CMS 本体のコードまで修正し始めました。あーもう、絶対にダメ。

私は Qwen に、ユニットテストやアプリケーションコードには決して触れず、アダプタコードそのものだけを修正するよう指示しました。mongodb で通るなら、受け入れ可能なエミュレーションでも通るはずだからです。Qwen はその方針を受け入れましたが、それでも問題を追い切れませんでした。

正直、この限られたコンテキストウィンドウではコードベースがそもそも理解しきれないほど大きかったのかもしれません。とはいえ Claude はコンテキストを 2 倍ちょっと（256K）にしただけでうまくいっていました。

そこで私は、Opus 自身が自然に気づいたようなヒントを Qwen に与えました。mongodb API の操作について、まず自分のテストスイートを書き、それを両方のアダプタが通ることを確認することです。もちろん mongodb が通らないなら、テスト自体を壊していることになります。

そして…これでかなりうまくいきました。Qwen は実際の JSONB の操作を使う本物のアダプタを作りました。ちゃんと小さめのテストスイートが用意されていて、そのテストは sqlite と実際の mongodb の両方で通ります。

なので、次は Qwen に実際の apostrophecms テストを通すためのイテレーションに戻るよう頼みました。これらも mocha テストです。ただしユニットテストよりも、機能テストにずっと近いです。なぜならシステムの多くを実際に動かして検証するからです。私の仮説は、単純なところがデバッグできた今なら、統合のこのレベルで発生する問題を追跡するのも、Qwen のほうがうまくいくはずだということです。

もしくは単に圧倒されてしまっているだけかもしれません。どうなるか見てみます。

では…役に立ちますか？

いくつかのタスクでは、私は「はい」だと思います。

私の 2 つ目のタスクは、実は AI コーディングエージェントにとっての定番の勝ちパターンです。アダプタパターンです。「これは動いている。しかも大規模なテストスイートがある。同じテストスイートを通る互換のものを作れ。テストがすべて通るまで完了ではない。」

そして最終的に、Qwen もそれなりにうまくやれたと思います。Claude Code よりはより多くのガイダンスが必要でしたが、それでも、あれだけ多くの MongoDB っぽいクエリロジックを手でゴリゴリ作り込むよりは、私は Qwen を選びます。

ただし、私の 1 つ目のタスクは難題で、Qwen がそれでも思考ループに詰まる可能性があることを示しています。少なくともこの量子化設定とコンテキストサイズでは（ここは公平に書きます）。

Edit: 2 つ目のテストを本来の規模で扱うのも、依然として課題です。長い自律実行の途中で、まさに今そういうやりとりがありました。私は改めて「これがやりたいことだ」と伝えましたが、また同じ場所に戻ってしまうかもしれません：

* piを試す。

* ドキュメントを読むために、Web検索ツールの提供を試す。

* クラウドホスティングされたQwen 3.6 35B A3Bを、量子化なしで、それでもなお現実的な家庭用ハードウェアからどこまで得られるかを見るために、試してみる。

AIの資金調達バブルが縮み始めているのを見ながら、妻と私はどちらも「これを自宅で動かせる？ 無理なら、他に持続可能で手の届く価格の選択肢はある？」のような疑問を持っています。

私のMacがこれをできるのは、すでにクールで役に立ちます。でも、もう少しRAMが多い（OK、2倍）専用のマシンと、より強力なGPUで動かせば、「クールで役に立つ」から、費用のかかるクラウドAI提供者にある程度の作業を“日常的に”オフロードするところまで、一段進めるかもしれません。私の仕事は、このコストに見合うだけ十分なのかを調べることです……特に、DeepSeek 4のような安価なクラウドAPIオプションも存在するのですから。

ありがとうございます

過去の投稿に対して、助言をくれた多くの皆さんへ：ありがとうございます！あなたたちは、正しい方向へ私を導いてくれました。