2026 MLX ローカル API
MACMLX_
BATCH_
MATRIX.
Cursor や社内エージェントを localhost の OpenAI 互換 /v1 に繋ぐとき、Apple Silicon では二つの MLX 実装が並びます。Swift ネイティブの macMLX はメニューバー常駐と mlx-swift-lm を同一プロセスに載せ、Electron を避けます。mlx-batch-server 系は mlx-lm の BatchCoordinator と MLX_BATCH_BATCH_WINDOW_MS など明示ノブで集約スループットを狙います。どちらも /chat/completions に見えますが、並行意味論・RSS・ログの切り口が異なるため、インタラクティブ編集とオフライン集約を同居させると TTFT と SSE 初バイトが崩れます。統合メモリの奪い合いは Activity Monitor とバッチ統計の両方で見ないと誤診します。LiteLLM は鍵ローテーションには強いですが Metal の空き帯域を増やしません。OpenAI 互換 API + launchd と vllm-mlx 並列 と合わせて読むとトポロジ全体が繋がります。
1. 課題整理：`/v1` でも運用負荷が変わる理由
ランタイム境界が違えばログも違います。macMLX は対話 UX とモデル固定ピンを優先し、mlx-batch-server はスライディング窓でのリクエスト束ねを優先します。窓が 50–180ms と広いと集約 tok/s は伸びますが IDE 補完の TTFT が犠牲になります。統合メモリでは Xcode のインデックスや VideoToolbox と GPU が同じプールを使うため、曜日や時間帯でベースラインが変わります。ベンチにはワークロード指紋を固定してください。
2. 対照表：デスクトップ macMLX vs サーバ型 mlx-batch-server
| 観点 | macMLX | mlx-batch-server 型 |
|---|---|---|
| 想定ユーザー | 個人開発・GUI/CLI 一体利用 | 10 並列以上の HTTP 集約 API |
| ポート例 | :8000/v1 | :10240/v1（設定可） |
| ノブ | KV 階層・モデルプール | MLX_BATCH_*、動的 load/unload |
| リモート Mac のきっかけ | IDE はローカルに残しピークだけ移す | 熱設計と電源が SLA に見合わないとき |
3. 五段階受理ラダー
Step 1
ストリーミング対話とオフライン batch を同一チューニングセッションで混在させない。
Step 2
バッチ窓(ms)、最大並列スロット、RSS ピーク（物理 RAM 比）を三点セットで記録する。
Step 3
TTFT と SSE 初バイト、バッチではスロットあたり tok/s p95 を見る。
Step 4
窓を 50→200ms と振って劣化が許容外ならチーム上限として固定する。
Step 5
チップ世代・MLX コミット・ノブ値を変更チケットに貼る。
4. 継続ローカル / LiteLLM / リモート Mac
| 条件 | 優先 | 次善 | 避ける |
|---|---|---|---|
| 対話 TTFT が悪いが offline は健康 | 窓縮小またはプロセス分割 | 対話専用インスタンス | 単にモデルを肥大化 |
| RSS が 10 分連続で RAM 82% 超 | 並列制限または最重モデル移設 | 専用リモート推論 Mac | ルーティングだけの LiteLLM 万能視 |
| プロバイダ複数の監査ルートが必要 | Explicit fallback の LiteLLM | クラウド溢出し契約の事前レビュー | 未監査ゲートウェイ多重化 |
チケット用閾値の例：① swap が 90 秒連続で 768MB を超えたらランプダウン。② 窓最小でも TTFT p95/p50 が 2.8× を超えるなら対話と集約を分離。③ 週二回以上 OOM/jetsam なら購買より先にリモート Mac PoC。
5. 事例：ノートに mlx-batch-server を載せた夜のデモ週
デモ前週、180ms 窓で tok/s を伸ばした結果ファンが鳴り SSE が荒れた。バッチ層だけリモート Mac mini に移し、Cursor 向け macMLX はローカル維持で収束した。
原因はストリーミング完了と batch が同一プロセスを共有していたことです。権重量と MLX 重み整合は保ったまま SLA 言語を「対話」「オフライン」に分けると経営側とも対話しやすくなります。クリエイティブ作業とエージェント試作にはノートの統合メモリが有利ですが、24×7 の集約スループットは冷却余裕のある筐体へ載せ替えるのが筋です。
6. 洞察：2026 年の MLX 二股と実行可能 SLA
Swift 優先の macMLX は環境摩擦を下げ、Python バッチサーバは並列経済を取りに行きます。LiteLLM は要件が固まった後の鍵とレート制御に置くべきで、GPU 常駐リセットの代替にはなりません。クラウド API だけより MLX-on-Mac は量子化再現性が高く、過剰なノートより時間課金のリモート Mac がピーク整合に向きます——カフェ Wi-Fi を推論 SLA に混ぜないのが MACGPU のような時間課金ノードの位置付けです。
まとめ：プロトタイプはネイティブ MLX で早く回し、本番スループットはバッチ窓・RSS・明示オフロード条件で縛る。熱と swap が許容できないピークは、SSH トンネルより電源が読めるレンタルリモート Mac に載せ替えるのが堅実です。