Apple Silicon Local Llm Serving

Apple Silicon ローカル LLM serving: mlx_lm.server vs Ollama

Apple Silicon で「もっと速く / もっと大きいモデルを」運用したくなったとき、NVIDIA 前提の知識（VRAM の壁・量子化ラベル・MoE オフロード）はそのまま当てはまらない。Ollama から MLX (mlx_lm.server) に寄せる際は、非自明な3つの制約（埋め込み非対応・構造化出力非対応・コンテナ不可）で詰まりやすい。このスキルはその判断軸と落とし穴を持つ。

Contemplative Agent では ADR-0064 でこの判断を実装している（LLM_BACKEND=mlx で生成のみ mlx_lm.server、埋め込みは Ollama 据え置き）。以下は実測・ソース精読で確定した汎用知見。

ランタイム選択

• mlx_lm.server（Apple 純正 MLX ランタイム）は同一重みで速い・軽い。M1/16GB・Qwen 9B 実測で Ollama (Metal/GGUF) 比 生成 ~1.8x 速・メモリ 8.6→5.2GB。差は本質的（後述の交絡チェックで確認済み）。API は OpenAI /v1/chat/completions 形式。
• ただし生成専用。2つの「無い」に注意:

1. 埋め込み endpoint が無い → 埋め込み（nomic-embed-text 等）は Ollama (/api/embed) に残す。結果は「生成 = mlx_lm.server :8080 / 埋め込み = Ollama :11434」の2サーバ併走になる。
2. response_format / JSON schema 拘束が無い（Ollama の format= 相当が無い）→ 構造化出力は プロンプト指示 + パース fallback で代替する。単純スキーマ（{"items":[...]} 等）なら instruct モデルは十分クリーンな JSON を返す（実測でフォールバック発動0）。複雑スキーマで崩れるなら、その呼び出しだけ Ollama に残す。

• thinking 系モデルの thinking off は per-request chat_template_kwargs={"enable_thinking": false}（または起動時 --chat-template-args '{"enable_thinking": false}'）。
• mlx-lm を依存に入れない: アプリは HTTP を叩くだけなので uvx --from mlx-lm / uv tool install mlx-lm で server を回し、アプリの依存は increase させない。

ユニファイドメモリの効き方（NVIDIA 知識の翻訳）

• 「VRAM 容量の壁」→「メモリ帯域の問い」に変わる。CPU/GPU が同一メモリプールをゼロコピー共有するので容量制約は緩いが、生成（デコード）は帯域律速: 生成 tok/s ≈ メモリ帯域 ÷ モデルサイズ。無印 M1=68GB/s は Pro(200)/Max(400) の数分の一で、これが tok/s の天井を直接決める。プロンプト処理（プリフィル）は計算律速。
• MoE は Apple Silicon では RAM を節約しない。トークン毎に一部エキスパートしか活性化しなくても全エキスパート重みが常駐必須（別 VRAM プールが無いので NVIDIA のエキスパート CPU オフロード手法は無効）。「8GB GPU で 120B」式の MoE オフロードは Apple Silicon に移植できない。
• 16GB で重みに使えるのは実用 ~11GB（Metal の recommendedMaxWorkingSetSize が物理 RAM の ~67–75% にソフト制限）。sudo sysctl iogpu.wired_limit_mb で引き上げ可（ハード上限ではない）。9–10GB の重み + KV キャッシュ + OS で枠を超えればスワップする。
• コンテナ不可: macOS Docker は Metal パススルー非対応で、コンテナ内 MLX/Ollama は CPU 推論に落ちて 3–5x 遅い → 推論サーバはホスト実行（→ docker-local-llm-tradeoff 参照）。

ベンチ A/B の落とし穴

• メモリ圧（スワップ）の交絡: 重いモデルを 16GB で測ると、片方がスワップ中・もう片方が低スワップだと差が不当に出る。疑わしい arm を低スワップ条件に揃えて再測定し、速度差がランタイム本質か資源圧の副産物かを切り分ける（今回 Ollama を低スワップで再測定し、~7 tok/s で不変 → MLX の優位は本質と確定した）。
• 公平性の統一: thinking ON/OFF・temperature・max_tokens・量子化ビットを両 arm で揃える。特に thinking 不一致はトークン数と速度を別物にする。ウォームアップ1回を捨て、3回の中央値を取る（初回はモデルロードと Metal シェーダコンパイルが混ざる）。
• 量子化は arm 間でバイト等価でない（GGUF Q4KM ≠ MLX 4bit）。速度比較は妥当だが、品質差はランタイムでなく量子化方式の差が混ざる。品質を測るなら量子化を近づける（混合精度の OptiQ 系など）。

When to Use

• Apple Silicon でローカル LLM ランタイム（Ollama / mlx-lm / LM Studio）を選ぶ・併用するとき
• mlx_lm.server を既存 Ollama 構成に足すとき（埋め込み・構造化出力で詰まる前に）
• 「16GB でもっと速く / 大きいモデルを」を NVIDIA 前提（VRAM の壁・MoE オフロード）で考えてしまったとき
• ローカル LLM のベンチ A/B が腑に落ちないとき（メモリ圧の交絡を疑う）

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: shimo4228
• Source: shimo4228/contemplative-agent
• License: MIT
• Homepage: https://doi.org/10.5281/zenodo.19212118

Install and usage instructions live in the source repository linked above.