Macが重いときのメモリの読み方｜KVキャッシュとswap

先に結論

MacのローカルLLMが重いとき、アクティビティモニタの「メモリプレッシャー／swap」と、推論runtime内部の「context・KV cache・graph buffer」は別の層の情報です。両者を混同せず、遅い時刻と負荷を同時に観察してから、他アプリ、context、並列実行を一つずつ調整します。

swapの値だけで原因を決めたり、contextを下げれば常に速くなると結論づけたりはできません。容量表や推奨モデルではなく、OSの観測値と推論runtimeの確保領域を読み分ける分析です。

確認日: 2026年10月2日（Asia/Tokyo）
対象: Appleのアクティビティモニタと、2026年10月2日公開のllama.cpp b11344。
確認方法: Apple資料と、b11344のrelease note・tag固定README／実装を照合した公式資料のみの調査です。Mac上でモデルを動かす実測、速度比較、スクリーンショット取得は行っていません。設定名や挙動はアプリとllama.cppの版で異なる場合があります。
画像: アイキャッチは確認手順を示す要点図解で、実際のアクティビティモニタ画面ではありません。

OSのメモリ表示と推論runtimeの値は別物

Apple Siliconの統合メモリを含め、アクティビティモニタはMac全体のメモリ状態を示します。一方、llama.cppはモデルの重み、context、計算領域など、推論runtime側の割り当て・予約を管理します。同じ「メモリ」という言葉でも、前者はシステム全体の状態、後者はモデルを処理する内部資源です。

この区別が実際のruntime不具合にも関わる例として、llama.cppのb11344 releaseには、Metal実行時に一時bufferを解放できずmemory leakになる問題を直したPR #29777が含まれています。特定のMetal経路で長時間実行後に問題が出た報告と修正であり、Mac上の遅さやswap表示すべてがこの不具合を示すわけではありません。ここで分かるのは、runtime内部の不具合とOS全体のmemory pressureは、観測層も原因も別々に確認すべきだということです。

同じb11344には、特定のk-pool型memoryを使うモデルで、context全体を埋めるbatch時にgraph reserveの上限を超えて再確保を要求する問題の修正も含まれます。修正対象はruntime内部のcache pool／計算graphの境界です。これはmacOSのswapを直接調整する変更でも、一般的なメモリ使用量や速度が減るという測定結果でもありません。修正PR #29805とb11344の実装で確認できます。

つまり、Activity Monitorにswapが見えることから、llama.cppのKV cacheがディスクへ出たと断定することはできません。OS全体の圧力とruntimeのcontext設定を、同じ時刻・同じ実行条件で比べて切り分けます。

まず、遅い状態を記録してから止める

返答が遅いまま何度も生成を重ねると、負荷の原因を切り分けにくくなります。操作できる状態なら、まずアクティビティモニタの「メモリ」タブで、遅い状態の表示と時刻をメモします。その後、生成をアプリの停止ボタンで止め、編集中のデータを保存してください。操作が難しい場合は生成の停止を先に行い、「停止後の状態」として記録します。詳しい表示の見方はAppleのアクティビティモニタ公式ガイドにあります。

メモリプレッシャーのグラフ、物理メモリ、使用済みメモリ、圧縮、swap使用量を見ます。可能ならLLMを動かしていない普段の状態も記録しておき、遅い状態と比べてください。ここで見る「使用済み」はmacOSの表示で、モデルファイルの容量やKV cacheの単独値ではありません。

Appleの説明では、メモリプレッシャーは空きメモリ、swapの動き、wired memory、cached filesなどから決まります。緑はメモリを効率よく使えている状態、黄色は将来さらに必要になる可能性、赤はメモリ不足の状態を示します。ただし、短い色の変化だけで「LLMが原因」「モデルが大きすぎる」とは判断できません。色が続く時間と、Macが重くなった時刻が重なるかを確認します。

「Swap Used」は起動ディスク上でswapに使われている容量です。Appleはメモリプレッシャーの判定にswapのrateも含めると説明していますが、画面のswap使用量は容量の表示です。数字があるだけで、今も頻繁に読み書きしている、あるいはそのLLMが原因だとは限りません。Appleのメモリ確認ガイドも、未使用メモリの量だけで性能を判断しないよう説明しています。

手順1：メモリを使っているアプリを確認する

アクティビティモニタでメモリ使用量の多い順に並べます。ブラウザのタブ、動画編集、仮想マシン、開発環境など、自分が開いたアプリが普段より多く使っていないか見てください。アプリごとの「メモリ」と、画面下部のシステム全体の使用量は別の見方です。片方だけで原因を決めず、メモリプレッシャーも同じ時刻に確認します。

LLMのアプリやllama-serverが使っている場合も、いきなり強制終了せず、まずそのアプリの停止・終了操作を使います。システムプロセスを終了したり、sudoでOSの設定を変えたりする必要はありません。作業内容を保存してから、自分で開いた大きなアプリを一つずつ閉じ、プレッシャーと体感がどう変わるか見ます。

手順2：LLMのcontextと同時実行を一つずつ減らす

他のアプリを閉じても重いときは、同じモデルでLLM側の負荷を見直します。会話履歴や入力文が長くなっていないか、画像などを追加していないか、別の生成が同時に走っていないかを確認してください。長いcontextや複数の同時実行は、モデルの重みとは別に実行時メモリを使います。

llama.cpp b11344ではcontext sizeを-cまたは--ctx-sizeで指定し、serverでは-npまたは--parallelで並列slot数を指定します。b11344のserver READMEで、手元の版の--helpと照らし合わせてください。アプリの画面から設定する場合も、最大値に固定せず、必要な入力と出力が収まる範囲で少しずつ下げます。

確認中は一度に一項目だけ変えます。たとえば、他アプリを閉じた状態で元のpromptを一度実行してから、contextだけを下げて再確認します。途中でモデル、量子化、backendまでまとめて変えると、どれが効いたか分からなくなります。llama.cppの版やbuildで使える設定が異なるため、実行ファイルの--versionと--helpを先に確認してください。b11344のbuild資料ではmacOSのMetalは既定で有効ですが、別buildやアプリ内蔵runtimeが同じ条件とは限らないため、遅さが続く場合は実行環境を記録してから確認します。b11344公式buildガイド

手順3：変更後の状態を同じ条件で比べる

再実行中も、同じタブでメモリプレッシャーとswap使用量、アプリごとの使用量を見ます。次の項目を簡単にメモすると、再現や相談がしやすくなります。

• Macの機種、macOS、LLMアプリまたはllama.cppの版
• モデル名と量子化、context設定、同時実行の有無
• 遅くなった時刻、プレッシャーの色、swap表示、同時に使っていたアプリ
• 変更した項目と、その後に体感や表示がどう変わったか

入力を短くする、他アプリを閉じる、並列数を下げる操作の後に状態が落ち着くなら、同時使用するメモリ負荷が関係した可能性があります。これは条件を絞る手がかりで、全てのMacやモデルに当てはまる速度保証ではありません。プレッシャーが緑で安定し、他アプリを閉じても同じ遅さが続く場合は、メモリ不足と決めつけず、GPU backend、CPU負荷、更新前後の速度差など別の原因を調べます。llama.cppが遅い原因を区間別に調べる手順も参考になります。

応答が最初に返るまでの待ち時間を区間ごとに診断する手順は、ペア記事ローカルLLMの返答が遅い原因を切り分けるで扱います。Macのメモリ容量からモデルを選ぶ話はメモリ別ローカルLLM一覧、重み・KV cache・計算領域の概算は必要メモリの計算方法に分け、本記事では数値を再掲しません。

参考資料

• Apple：アクティビティモニタでメモリ使用状況を表示する（2026年10月2日確認）
• Apple：Macにメモリの追加が必要か確認する（2026年10月2日確認）
• llama.cpp：b11344 release（2026年10月2日公開）
• llama.cpp：Metal一時buffer leak修正PR #29777（2026年10月1日merge）
• llama.cpp：k-pool reserve上限の修正PR #29805（2026年10月1日merge）
• llama.cpp：b11344 HTTP Server README（2026年10月2日確認）
• llama.cpp：b11344 Buildガイド（2026年10月2日確認）