つい最近、LLMの世界に足を踏み入れたのですが、最初にしたことはMac Studio M3 Ultraを512GBで購入することでした（幸い、その構成がもう手に入らなくなる前に購入できました）。
手に入れたらすぐ、OpenCodeをインストールし、ちょうど新発売のQwen3.5シリーズの素晴らしい話題に飛びつきました。
アーキテクチャ、コーディング、デバッグを要するいくつかの実世界のタスクを実行しました。
初心者として、MLXモデルはAppleシリコン向けに安価に最適化されており、シリコンアーキテクチャの素晴らしい恩恵を約束してくれると読みました。
がっかりポイント: 現実のタスクに取り組み始めると、複数ファイル、デバッグセッション、MCP呼び出しを要するタスクで、プロンプト処理が耐え難く遅くなりました。
長時間モニターの前に座って、LM Studioサーバーログの "prompt processing %" が100%へと遅々として進むのを見ていました。
これにより、正直なところ、Macでローカルなエージェント型コーディングは現実的ではなく、4 x 6000 Pro 構成で実行すべきだと考えるに至りました。
先日、Macユーザーはqwen3.5の恩恵を得るために llama.cpp を更新すべきだ、というReddit の投稿を見かけました。私自身は「llama? なぜ？ Macには MLX が最良の選択ではないのか？」と思っていましたが、どうやら違うようです！
unsloth/qwen3.5 モデルのプロンプト処理は、長い文脈では MLX よりはるかに優れており、サイズが大きくなるほど差は大きくなります。
トークン生成は？ llama.cpp が安定した TG を維持するのと違い、mlx では文脈ウィンドウのサイズが大きくなると TG が減少します。
さらに、プロンプトキャッシュは llama.cpp で動く技術のように感じられ、opencode + llama.cpp + qwen3.5 35B（高速用）/122B（品質用）で動作する高速なワークフローを実現し、滑らかに感じました。
なぜこの投稿をしたのか？
1. 発見を共有するためです。もしMacユーザーなら、最新の llama.cpp をビルドして試してみるべきです。
2. 私は初心者で、完全に間違っている可能性があります。私の状況に対する訂正があれば、ぜひアドバイスを教えてください。
llama-server コマンド：
./llama-server \ -m 'path to model' \ --host 127.0.0.1 \ --port 8080 \ --jinja \ -ngl all \ -np 1 \ -c 120000 \ -b 2048 \ -ub 2048 \ -t 24 \ -fa on\ --temp 0.6 \ --top-p 0.95 \ --top-k 20 \ --min-p 0.0 \ --presence-penalty 0.0 \ --reasoning auto \ いかなる助言・情報も、私にとっても多くの人にとってもありがたいです。
[リンク] [コメント]
