1. 痛みの分解：単ストリームが速い理由と限界
（1）ユニファイドメモリは共有予算：重み・KV・ランタイム・OS キャッシュが同一プールを奪い合い、同時実行では帯域とページ回収が先にボトルネックになります。（2）スケジューリングは実装依存：内部キュー、バッチ、ストリーミング分割が Ollama と LM Studio で異なり、クライアント契約（並列度・ストリーム・文脈長）を固定しないと比較できません。（3）エージェントのハートビート：OpenClaw などの短周期呼び出しは単体では軽いですが、積み上がるとインタラクティブ SLO を蝕みます。
2. シナリオ行列：負荷のバケツ分け
| 負荷 | 典型 | 測る指標 |
|---|---|---|
| 対話 | 1–3 並列、ストリーム、4k–32k 文脈 | TTFT、体感ストール、swap |
| バッチ要約・埋め込み | スループット優先、キュー許容 | キュー深さ、時間あたり件数、p95 完了 |
| マルチエージェント | 短い呼び出しが多い＋長文脈が稀 | チャットレーンとの分離、レート制限後の p99 |
3. 五段階ランブック
- モデルと量子化を固定：名前・形式・最大文脈を凍結し、変更時は単一ストリームで回帰します。
- クライアント契約を固定：ストリーム有無、バッチ、HTTP 再利用、プロンプト長を同一スクリプトで駆動します。
- ステップ負荷：1→2→4→8 と段階し、p50/p95/p99 と RSS を記録。膝が見えたら診断に切り替えます。
- OS 信号：メモリ圧力、swap 増分、E コア、ディスク I/O を同時ログします。
- ゲートレポート：スクリプト版、モデル digest、CSV、合意 SLO を添付します。
4. 引用可能な閾値（要再測定）
議論用の目安です。必ず自環境で置き換えてください。
- 対話で p95 が単一並列比 3 倍以上が 10 分再現なら、モデル肥大よりレート制限・レーン分離・ピーク逃がしを優先します。
- 負荷中に swap が 2 GB 超で体感停止が出るなら、ユニファイドメモリ予算破綻です。バッチを専用リモートへ。
- 3 名以上が同一ノートのローカル API に依存し、日中は開発・動画も回すなら、共有 API はリモート Apple Siliconを既定にします。
5. Ollama と LM Studio の違い（典型）
| 観点 | Ollama | LM Studio Server |
|---|---|---|
| 運用向き | CLI・OpenAI 互換が強くチーム向き | GUI 試行が速い |
| キュー | 内部キューと常駐は負荷試験で確認 | Metal 競合と接続形態に注意 |
| 常駐化 | launchd・リバプロと組み合わせやすい | デスクトップ色が強くラップが要ることも |
6. リモート Mac プールへ逃がす判断
| 信号 | アクション |
|---|---|
| 対話作業と推論がメモリで衝突 | バッチと共有 API を高メモリのリモートへ。SSH/VNC |
| デモでテールが読めない | リモート側でキューとレート制限、端末は薄いクライアントに |
| 24/7 が要るがノートはスリープ | 常駐 Mac＋監視 |
| 同一ホストで ComfyUI や書き出し | ホスト分離とトポロジー分割 |
7. FAQ
モデルを変えていないのに遅い？ KV はセッション数に近い線形で増え、膝を越えるとページングで p99 が先に悪化します。
ストリームは軽い？ 体感は良くても総計算は減りません。TTFT と完了時間の両方を記録します。
リモートは常に正解？ 上り RTT が支配的なら悪化もあり得ます。メモリ圧が主因の揺らぎならリモートが有利になりやすいです。
8. 深掘り：SLO に署名するまで
2026 年は単一デモでは説得力がありません。実際の並列下での体験曲線が問われます。ユニファイドメモリはハード OOM を減らす一方、ソフト劣化としてテールとジッタが残ります。
開発機＋推論機＋グラフィックを同一デスクトップに積むのは個人では成立しても、二人並行でメモリ帯域と熱設計が天井になります。デスクトップはオーケストレーション、共有推論は専用ノードへ、という分離が古典的な読み書き分離と同型です。
観測負債は高コストです。ラダー CSV がないチームはデモ現場で破綻します。ゲートレポートを成果物に含めます。
OpenClaw 連携ではハートビート用の安価モデルと本番推論をルーティング分離します（MEMORY／トークン系の記事と併読）。
調達では「メモリを足す」だけが解ではなく、組織的並列ならノード隔離とキューが不確実性を閉じ込めます。
さらに、tokenizer や HTTP 圧縮の有無など「地味な差」が「昨日は速かった」を生みます。バージョンと接続設定をレポートに固定します。
9. 観測性：ジッタを指標化
単一基線、p95/p99、RSS＋swap、キュー深さ、エラー率をセットで見ます。五つ同時悪化はメモリ疑い、エラー単独はタイムアウト／プロキシ疑いです。
| 症状 | 先に疑うもの | 緩和 |
|---|---|---|
| p99 ≫ p95 | swap、Spotlight、バックアップ、同期 | バックグラウンド削減、レート制限、バッチ移動 |
| スループットは良いがカクつく | TTFT とチャンク間隔 | 並列削減、小さなドラフトモデルへルーティング |
| 502 が散発 | プロキシタイムアウト、モデルロード | 常駐、ヘルスチェック、タイムアウト調整 |
9.5 組織運用：レーン、予算、調達の根拠づくり
同じローカル API を複数チームが共有し始めた瞬間から、「自分の環境では速い」という個人評価は通用しません。インタラクティブ、バッチ評価、バックグラウンド処理をレーンとして命名し、同時ストリーム数や許容 RSS を予算として公開してください。スポット的なデモ負荷を止められるオーナーも決めないと、会議室のノートが常に飽和します。
ラダー CSV は性能試験だけでなく、調達・セキュリティレビューへの添付資料になります。「二人がストリームしながらレンダリングすると p95 が倍になる」といったビジネス語への翻訳が、GPU 利用率より説得力を持ちます。
オンコール手順には「swap が一定値を超えたらバッチをどのリモートプールへ逃がすか」を明文化し、夜間にインベントリ作業をさせないでください。DNS ローテーションや証明書更新もメモしておけば、「モデルが壊れた」偽シグナルを減らせます。
サーマルと電力の余裕は SKU ごとに異なります。同じ世代名でも、13 インチとデスクトップでは熱設計が違うため、並列度を上げる前に機種と冷却条件をログに残してください。リモート Mac に移した後は同一スクリプトを繰り返し、ローカル発の熱制限とサーバ側キュー競合を切り離します。
ミニラダー（二段だけの短時間計測）を月次で回すと、ブラウザや同期クライアントの静かな更新によるテール漂移を早期に拾えます。フォーマットより継続を優先し、一行サマリーをプラットフォーム向けニュースレターに載せるだけでも文化は育ちます。
10. まとめ：開発はローカル、共有負荷は分離
（1）限界：高並列ではテールが先に壊れます。索引・同期・GPU 作業が同居すると SLO は安定しません。（2）リモート Apple Silicon：同じ量子化生態を保ちつつデスクトップノイズを減らせます。（3）MACGPU：高メモリのリモート Mac を試しやすく手に入れたいチーム向けに、レンタルノードと公開ヘルプへ誘導します（ログイン不要）。（4）最終ゲート：外部へ遅延を約束する前にラダー CSV と digest を添付します。
11. MLX API と launchd への接続
内製サービス化では launchd・TLS・認可が本線になります。OpenAI 互換 API の記事を参照し、Ollama / LM Studio どちらでも版と契約の固定が先です。