2026 LONG CONTEXT ON
APPLE_SILICON_
KV_SWAP_MLX.
128K のスライダーを先に出荷してから「本当に増えるのは GGUF ではなく統合メモリ上の KV」に気づくチームは少なくありません。本稿は Apple Silicon で MLX または llama.cpp を運用し、RAG／エージェントの長プロンプトを正直に扱うエンジニア向けに、4 つの失敗モード、32K／64K／128K の粗い見積り表、TTFT・decode 分位と swap 面積の 5 段階受け入れ、そして大型ノートよりリモート MLX が勝つ条件を整理します。MACGPU の統合メモリ swap 方針、vllm-mlx 並列、SSH と VNC の選定記事と併読すると設計レビューが通りやすくなります。
1. 痛みの分解：パラメータを上げるより長コンテキストが効く理由
第一に、KV とワーキングセットはシーケンス長に比例し prefill が一気に尖ります。第二に、統合メモリは GPU・Neural Engine・OS キャッシュと共有であり、ComfyUI のレンダや Xcode のインデックスが静かに余白を奪い decode のばらつきを広げます。第三に、swap が閾値を超えると Metal 推論はなだらかに劣化せず、UI は止まっていないのに tok/s が一桁に落ちます。第四に、TTFT と swap を見ず decode 平均だけを追うと、法律文書や巨大リポジトリ級プロンプトでは壁時計が prefill に支配される SLA リスクを隠します。広いメモリ戦略は MACGPU のローカル LLM swap 記事とセットで読むのが安全です。
2. KV の粗い見積り：マーケの窓からエンジニアの封筒へ
初日からバイト完全一致の KV 式は不要ですが、設計レビューで全員が引用する一枚表は必要です。重み常駐はパラメータ数×量子化バイト×バッチ、KV 上界は層×ヘッド×次元×2（K/V）×長さ×dtype に 1.2〜1.35 の碎片係数を掛けます。経験的に 7B〜13B Q4 で 32K は 48GB 級ノートでも成立しやすく、64K は同時サービスとの兼ね合いが厳しく、128K は 64GB で第二レーンや重い GUI と衝突しがちです。下表は方向性のリスクマップでありハード保証ではありません。
| 窓 | 典型シグナル | 単機での緩和 | リモート MLX を検討 |
|---|---|---|---|
| 32K | TTFT p95 が約 8s を超えがち、decode のばらつき大 | batch=1 固定、量子化固定、GPU 占有を止める | 30B 級を二本立て、または無人 7x24 |
| 64K | 常駐が RAM 約 78% 超、swap スパイク | RAG をチャンク化、ツール JSON を削る、要約 | swap なし全貼り付けをプロダクトが要求 |
| 128K | ファン全開、swap が 2GB 超を持続 | 推論専用 Mac、エディタと分離 | 192GB Studio 級または時間課金プール |
3. 五段階受け入れ：swap ゲートと最低限の tok/s
Step 1 プロンプト集合を固定
8K／32K／128K の合成またはマスク済み実データを temperature=0・固定シードで用意し、週次回帰で同条件比較を可能にします。
Step 2 量子化と同時実行を固定
リリース列車ごとに量子化は最大二段階まで。同時リクエストは 1 から始め、swap の原因切り分けを壊さないようにします。
Step 3 TTFT、decode p50/p95、swap 積分を記録
Activity Monitor とメモリ圧ツールで、swap が 512MB を超えた最初の瞬間と tok/s をログ化します。
Step 4 最低限の tok/s ゲートを公開
例：サポートチャット decode p95 は 12 tok/s 以上、コード補完は 28 tok/s 以上を下回ったらリリース停止、など。
Step 5 OS とランタイム指紋付きで CSV 保管
macOS マイナー、MLX または llama.cpp のコミット、モデルチェックサムをメトリクスと一緒に残し、四ヶ月後も説明可能にします。
4. 判断表：ローカル維持／窓縮小／RAG 再設計／MLX 逃がし
| トリガ | 優先手 | 次善手 | 避ける |
|---|---|---|---|
| swap が 90 秒間 1GB 超 | 窓を縮めるか第二レーン停止 | 192GB リモートへ長窓を移す | 運命任せに同時実行だけ増やす |
| TTFT p95/p50 が 2.8 超 | system prompt とツール JSON を削る | prefill をリモート、小さな編成モデルをローカル | いきなり更大パラメータへ跳ぶ |
| 128K 全貼り付けが要件 | 専用推論イメージ | ピークは時間課金のリモート Mac プール | 36GB ノート本番 |
社内 Wiki に貼れる三つの数値ゲートです。常駐が物理 RAM の 82% を 10 分維持し、いずれかの swap サンプルが 768MB を超えたら自動で 32K へ降格またはリモートへ振り分け。エクスポート負荷下で decode p95 がグラフィックスアイドル基準より 35% 悪化したら描画キューか推論移設。OOM や jetsam が週二回なら第三台ノートの前にハイブリッド PoC を必須化します。
5. 事例：法務 RAG が「全貼り付け 128K」から階層要約＋リモート 128K へ
金曜に swap が 6GB まで達するまで 128K OCR 全投下を続けましたが、長尺ブランチをリモート MLX Studio に移しノートは 8B 編成にしたところ、P95 が 4 分から 22 秒になりました。
6 名のリーガルテックチームが MLX で契約差分を扱い、数百ページ OCR と多ラウンド tool JSON を投入していました。第 1 週は完了可否だけを見、第 2 週で swap と TTFT 分位を重ねると 128K が OS キャッシュを追い出し decode を震わせていることが判明。全文貼り付けをベクトルチャンク検索＋章要約に置き換え、争点条項だけ 128K 窓へ昇格、そのブランチを 192GB のレンタル Mac Studio に固定し、ノートは対話 Q&A に限定しました。リーダーには swap 面積の前後比較図が渡り、CapEx の議論が「ノート追加」から「時間課金の Mac 計算」へ移りました。長コンテキスト障害の多くは情報設計の問題であり、リモート MLX は CUDA 専用農場に飛ばさず dtype デバッグを速い Apple Silicon スタックに留めたまま隔離を買えます。
6. 展望：コンテキスト長マーケと監査可能 SLA のズレ
モデルカードの窓はさらに伸びますが、統合メモリ帯域と SSD swap の物理は四半期ごとに倍になりません。残るのは三段階窓ごとの分位曲線、swap 積分、自動降格パスです。プロトタイプはノート単体でもよいですが、64K〜128K を契約要件にする本番は、オンプレ Mac 専用推論か電源と熱が読める弾性リモート Mac プールが現実的です。リモート操作は MACGPU の SSH と VNC ガイドを、長窓とマルチエージェントの重ね掛けは vllm-mlx 並列記事を参照し、統合メモリ予算の二重殺しを避けてください。
ノート単体の長窓はジッターを許容する個人向けに成立します。swap が許容できず窓長が譲れないとき、時間課金で大きい統合メモリの Mac ノードへピークを逃がす方が、毎世代最高 BTO を追うより合理的なことが多いです。MLX のピークを CUDA 運用だけに追いやらずに逃がしたい場合、MACGPU のリモート Mac レンタルがその隙間を埋めます。