2026 Mac：Cursor / Continue / Zed 向けローカル LLM — LM Studio ヘッドレス、macMLX /v1、Ollama OpenAI 互換の選定と TTFT 検証

Cursor／Continue／Zed を localhost の OpenAI 互換 /v1/chat/completions に向ける際、2026 年の Apple Silicon で現実的な三通りは LM Studio Server（ヘッドレス）、Swift macMLX（多くは :8000/v1）、Ollama の互換レイヤーです。失敗パターンはプロトコル不一致ではなく、暗黙の単路化・ポート運用の口伝・統合メモリと Xcode／ブラウザ争奪が典型的です。誤解四則、比較表、五段階受理（Base URL 凍結、1／4 並列 TTFT、冷／熱曲線、swap 面積、ロールバック）、数値ゲート付きリモート Mac 分岐まで整理します。関連：Ollama・LM Studio・MLX 比較、OpenAI 互換 API と launchd、macMLX vs mlx-batch-server、SSH/VNC 選定。

1. 課題の分解：三路とも繋がるが、IDE 負荷に本当に合うのは一つとは限らない

1）接続成功 ≠ 並行意味論が正しい：IDE は同一 Base URL へ複数 streaming を並列投入する。後端が単一キューならネットワーク切断に見える数十秒停止が出る。2）ポート衝突と二重インスタンス：LM Studio Server、macMLX、Ollama は既定ポート文化が異なり、Docker や実験ゲートウェイと混ざると EADDRINUSE が夜を潰す。3）TTFT と decode の二部作：コーディング支援は対話 UX。平均 tok/s だけ見て初トークンと最初の SSE を無視すると誤診する。4）統合メモリ上の階段状 swap：Xcode Indexing とブラウザ多タブと 7B–13B 常駐を重ねると RSS 競合で尾遅延が跳ねる。モデル変更ではなくプロセス分離または硬体形態が必要なことが多い。

2. 比較表：LM Studio ヘッドレス vs macMLX vs Ollama（OpenAI 互換視点）

IDE に /v1 を載せる前提の座標表。数値はコミュニティのアンカーであり、本番 SLA の約束ではない。

軸	LM Studio Server	macMLX（Swift）	Ollama
典型ポート	1234 系（可変）	8000 系が多い	11434 系
ランタイム形	Electron 系 GUI＋サーバ	Swift ネイティブ、Python 常駐なし（追加エンジン除く）	Go 常駐＋Metal
重み形式	GGUF 等（エンジン依存）	MLX／safetensors	レジストリ GGUF
向くチーム	GUI で型抜き後 headless	ネイティブ常駐と依存最小	カタログ幅と CLI 習熟
尖ったリスク	GUI/サーバ二重の混乱	モデルプールと RAM 上限の手詰め	高並列時のキューと文脈膨張
mlx-batch 関係	対話用と並行可能	mlx 系と役割分担	LiteLLM 上流に載りやすい

3. 五段階検証：ポート・並行・TTFT を Runbook 化

Step 1 Base URL とポートを単一信源に凍結

スキーム、ホスト、ポート、パス、モデル文字列を wiki に固定。Cursor 系は http://127.0.0.1:PORT/v1 とモデル名の整合が必須。

Step 2 単路と四路ストリーミング探針

同一の短いプロンプト（256 token 目安）で 1 レーンと 4 レーンを測り、各ストリームの TTFT と 50 token 到達時刻を記録。四路 p95 が単路の 2.5× を超えるなら帯域ではなくキューが疑わしい。

Step 3 冷起動と温駐の曲線を分離

少なくとも 24 サンプル。初回ロードの冷起動 TTFT を日次 SLA に混ぜない。

Step 4 swap の「面積」を見る

swap が 512MB を超えたタイムスタンプと、メモリ圧の黄帯が 1 分超続いた区間をログ化。RSS と Xcode／エミュを重ね合わせる。

Step 5 ロールバック手順を添付

13B Q8 → 8B Q4 など量子化ダウングレード表と、監督付き再起動手順。IDE 設定 JSON を git 管理して口伝を禁止。

for i in 1 2 3 4; do
  curl -sS http://127.0.0.1:PORT/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model":"M","messages":[{"role":"user","content":"ping"}],"stream":true}' &
done; wait
                

4. 分岐表：ローカル継続／二重インスタンス／リモート Mac

信号	主策	次策	非推奨
マルチクライアントで TTFT p95 が悪化	IDE Mac と推論 Mac を分離	並列削減／小型量子化	無制限にクラウド API キーを足す
RSS>物理 RAM 80% が継続し swap が階段	最重モデルをリモート常駐へ	文脈上限とツール出力を削る	再起動だけの儀式
多ベンダルーティングが必要	LiteLLM で明示 fallback	内部 Base URL を一本化	開発者ごとの口頭ポート

チケット向け数値門：① 四路 TTFT p95 が単路の 2.8× を超えたら 2 週間以内に「対話／スループット分離」をレビュー。② 任意 90 秒で swap 平均 >768MB なら新規クライアント追加禁止。③ 週 2 回以上 OOM ならリモート PoC を優先。

5. ケーススタディ：開発 Mac と推論 Mac を別計上にした五人チーム

「8B チャットはノートの macMLX、13B バッチとリファクタはラックの Mac mini。Colima と Android エミュとの DRAM 争奪から抜け出せた。」

当初は Ollama の互換エンドポイントを各ノートに直刺し。モデルのホットスワップを直列化せず ollama pull が全チャットを 2 分塞いだ事故と、Docker＋エミュが統合メモリを食い TTFT 分散が爆発した誤診（IDE の不具合扱い）が重なった。対策は二つ：推論ホストを内部 DNS／hosts に固定し口頭 localhost:11xxx を禁止；重負荷は冷却と電源が読めるリモート Apple Silicon に寄せ、軽量対話だけローカル macMLX／LM Studio に残す。4 週間後、TTFT p95 の分散は桁違いに低下し、on-call の「誰が推論を再起動するか」も消えた — launchd とヘルスチェックがリモートで回り、ノートは IDE に専念できる。教訓は OpenAI 互換はワイヤ仕様の一致であり、公平なスケジューラではない という一点に尽きる。

6. 2026 年の洞察：URL は同一でも背後のスケジューラは分岐する

マーケは「/v1 が動く」へ収斂するが、エンジニアリング現実は Metal キュー深さ、GGUF と MLX の住み分け、デスクトップ常駐の要否で分岐する。ブランドより統治：クライアント設定をエクスポートし、探針ヒストグラムを週次 SRE ノートに貼る。swap 持続時間を予算科目として扱えば、デモから本番への距離が縮まる。

タイムゾーンを跨ぐチームでは、推論を「誰かのノート」に縛るのは SLA を睡眠と出張に縛るのと同義。安定ティアを 24/7 のリモート Mac に置き、TLS リバプロで社内に Base URL を出す方が SSH トンネル地獄より堅い。MACGPU のような時間課金ノードは、この分離を資本的支出なしで試す手段になる。

クライアント側で temperature／max_tokens を極端化すると Metal 以前に尾遅延を壊す。版管理スニペットに閉じ込め、インシデント時に差分で原因を切る。無測定の HTTP リバースプロキシを無限に重ねない — DNS・バッファ・タイムアウト語義が層ごとに増える。

クラウド API は dtype 試行コストを下げるがトークン請求とコンプライアンスルーティングを増やす。ノート単機は柔軟だが SLA をカフェ Wi-Fi に接続する。冷却が読めるリモート Apple Silicon は、アシスタント体験と熱余裕を切り離す最も安い杠杆の一つ。

実務メモ：モデル検証でポートやモデル文字列を一時変更したら、同じ PR に内部 wiki と Cursor/Continue のエクスポート JSON を必ず含める。口頭の「自分の Mac だけ通った」は月曜のスタンドアップで不可視な技術負債になる。

さらに、四条並列プローブを週次で自動化し CSV に落とすと、レビュー会議で「体感が遅い」ではなく p95 の差分で意思決定できる。数値が揃うと LiteLLM 前置やリモート Mac 追加を財務と共有しやすい。

7. 長文コンテキスト、ツールループ、「見えない token 課税」

コーディングエージェントがメモリを壊すのはユーザ本文よりツール出力の無制限コピー（巨大な grep、丸ごとファイル、ログ tail）です。LM Studio、macMLX、Ollama は KV cache とバッチ方針が一致しません。運用ルールは三つ：ツール出力に行数上限と截断を必須化する；max_tokens と停止シーケンスの二段ゲートを IDE 設定にも書く；冷起動測定と熱パス測定を別シートに分け、初回重みロードを週次 SLA に混ぜない。サブタスクごとに system プレフィクスを重ねるクライアントは tokenizer 負荷だけ倍増しやすく、週次の JSON diff で早期発見してください。

モデルエイリアスが裏で大型 MLX 重みを指しているケースもあり、RSS だけが止まりません。SERVICES.md にポート・別名・量子化を固定し、PR でポートだけ変える行為を禁止すると再現性が出ます。

8. レビュー用の数値ゲート（表）

性能保証ではなく合流ブレーキとして使う数字です。① TTFT サンプル数 N≥24 未満の「体感速い」はマージ理由にしない。② 四並列／単並列 TTFT p95 比は社内文書に明文化（§4 の 2.8× を採用または厳格化）。③ swap は瞬間値ではなく90 秒平均と圧力バーの黄色滞留時間を記録する。

指標	目安	止める変更
冷起動 TTFT	別枠管理	初回 pull を回归遅延と混同する説明
熱パス TTFT p95	人＋エージェント並行とセット	同一デーモンにクライアントだけ足す
4/1 TTFT 比	>2.8× でアーキレビュー	単一キューに負荷を積む
swap 平均（90s）	>768MB で新規接続凍結	DRAM 予算なき機能拡張

9. FAQ（実務で増える質問）

Q: 三口座を日替わりで切替えても安全？ A: Base URL とモデル辞書を二系統維持しないと IDE キャッシュが旧名を握り続けます。Q: LiteLLM でメモリも直る？ A: いいえ、オフロード先（リモート Mac）をセットしない限り帯域は生まれません。Q: localhost が遅いのは DNS？ A: 127.0.0.1 に固定して切り分け、mDNS 差分を潰してください。