ローカルAIのための8GB Mac サバイバルガイド

laptop_mac macOS Sonoma Intermediate schedule 8 min read

by Alex Rivera • May 14, 2024

Step 1 8GB ユニファイドメモリの現実確認

まず神話を即座に葬ろう：8GBのユニファイドメモリは、多くの人が主張するようなローカルAIにとっての死刑宣告ではない。 しかし、それは無造作なモデル選択を容赦なく罰し、外科的精度を要求する過酷な環境であることは確かだ。なぜそうなのかを理解するには、Apple Siliconのメモリアーキテクチャを簡単に巡る必要がある。

ユニファイドメモリは「単なるRAM」ではない

Intelの時代のマシンでは、CPUがシステムRAMを持ち、GPUが独自の専用VRAMを持っていた——リソースを共有できない二つの独立したプールだ。Apple Siliconのユニファイドメモリアーキテクチャ（UMA）はこの境界を完全に排除する。CPU、GPU、そしてNeural Engineはすべて同じ物理メモリプールから引き出す。これが、8GBのMacが推論タスクにおいて16GBのDDR4を搭載したPCを凌駕できる理由だ——モデルは計算リソースに到達するためにPCIeバスを越える必要が一切ない。

┌─────────────────────────────────────────────┐
│           Unified Memory (8GB)              │
│                                             │
│   ┌─────────┐  ┌─────────┐  ┌───────────┐  │
│   │   CPU   │  │   GPU   │  │  Neural   │  │
│   │  Cores  │  │  Cores  │  │  Engine   │  │
│   └─────────┘  └─────────┘  └───────────┘  │
│        ↑            ↑             ↑         │
│        └────────────┴─────────────┘         │
│              Shared Memory Bus              │
└─────────────────────────────────────────────┘

このゼロコピーアーキテクチャにより、メモリにロードされたモデルの重みは、すべての計算ユニットに対してフルメモリ帯域幅で即座にアクセス可能となる——M2チップでは最大100 GB/sだ。これを、16x PCIe Gen 4スロットを経由してデータを転送するミドルレンジの外付けGPUの約32 GB/sと比較してほしい。

本当の予算内訳

ここで正直に言わなければならない不都合な事実がある。その8GBはすべてAI推論のために使えるわけではない。macOSはメモリ常駐型のオペレーティングシステムであり、固有のニーズがある：

つまり、実質的な推論予算は現実的に4〜5.5GBであり、8GBではない。すべてのバイトが重要だ。表面上はギリギリ収まるモデルでも、Slack、ブラウザ、Spotifyを同時に起動していれば、システムをスワップ地獄に叩き込む可能性がある。

モデルのメモリフットプリントを理解する

モデルのメモリ要件は、ディスク上のファイルサイズとは異なる。推論中には以下を考慮する必要がある：

• モデルの重み ——最大のコンポーネント。パラメータ数と量子化に応じてスケールする
• KVキャッシュ ——コンテキストウィンドウのサイズとともに増大するキー・バリューアテンションキャッシュ
• ランタイムオーバーヘッド ——フレームワークバッファ、計算グラフ、アクティベーションメモリ

重みメモリを推定するための大まかな計算式：

Memory (GB) ≈ (Parameters × Bits_per_weight) / (8 × 1024³)

Example: 7B model at 4-bit quantization
= (7,000,000,000 × 4) / (8 × 1,073,741,824)
≈ 3.26 GB

これが、4ビット量子化された7Bモデルがおよそ3.5〜4.2GBになる理由を説明している——技術的には8GBハードウェアで動作可能だが、長いコンテキストではKVキャッシュのためのヘッドルームがほぼゼロで動作することになる。

7Bモデルに関する偽りなき真実

8GB MacにおけるLLMの7Bモデルは、本番ワークフローで快適に使用できるものではない。 動作はする。しかし「動作する」と「うまく動作する」は別物だ。

2048トークンのコンテキストウィンドウでは、7B Q4モデルは利用可能な推論予算全体を消費する。4096トークンに押し上げれば、確実にスワップが発生する。エクスペリエンスは滑らかな推論から、断続的なサーマルスロットリングの苦行へと劣化し、メモリプレッシャー管理の優れた教訓を与えてくれる。

8GB Macでローカルを本当に使いこなしているエンジニアやパワーユーザーたちは、異なるメンタルモデルを内面化している：小さく、速く、目的に特化したものは、大きくて汎用的なものに常に勝る。 次のセクションでは、そのスタックを構築する具体的な方法を紹介する。

Step 2 スワップメモリとは何か、そしてなぜ避けるべきか

Macが物理ユニファイドメモリを使い果たしても、macOSはクラッシュしない——静かに、はるかに陰険なことを始める：SSDをオーバーフローメモリとして使用し始めるのだ。このメカニズムはスワップメモリ（または仮想メモリページング）と呼ばれ、セーフティネットのように聞こえるが、ローカルAI推論においては事実上、全速力で突入するパフォーマンスの崖だ。

スワップの仕組み

macOSはメモリ圧縮とスワッピングと呼ばれる技術を使用する。OSはまず非アクティブなメモリページを圧縮し、より多くのデータをRAMに収めようとする。それでも不十分な場合、ページングを開始する——メモリの内容をSSD上のスワップファイルと呼ばれる予約済みスペースに書き込み、必要になったら読み戻す。

Physical Unified Memory (8GB)
        │
        ▼
┌───────────────────────┐
│  Active Data (in RAM) │  ← Lightning fast (400 GB/s bandwidth)
└───────────────────────┘
        │ overflow
        ▼
┌───────────────────────┐
│  Swap on SSD          │  ← ~3,000–7,000 MB/s (NVMe)
└───────────────────────┘

問題はその速度差にある。Apple Siliconのユニファイドメモリは約400 GB/sの帯域幅で動作する。AppleのNVMe SSDでさえ、高端では最大7 GB/s程度だ——スワップに退避されたデータに対して約57倍遅いスループットとなる。

LLM推論においてこれが意味すること

大規模言語モデルは通常のアプリケーションとは異なる。推論中、各トークンを計算するためにモデルの重みが継続的にメモリを通じてストリーミングされる必要がある。4ビット量子化の7Bパラメータモデルは、おおよそ4〜5GBのメモリを占有する。macOSシステムプロセス、ブラウザ、その他のバックグラウンドアプリを既に実行している場合、8GBを超えるのにさほど時間はかからない。

モデルの重みがスワップに溢れ出した瞬間から、すべてのトークン生成がSSDからのデータ読み取りを必要とする。結果は緩やかな低速化ではなく、崩壊だ：

見えないSSD消耗問題

純粋なパフォーマンスを超えて、スワップを真剣に受け止めるべきもう一つの理由がある：SSDの耐久性だ。スワップへの書き込みはSSDのNANDフラッシュストレージへの書き込みに他ならない。スワップを常に酷使するような大規模な推論ジョブを実行することで、数ヶ月から数年の使用にわたってドライブの消耗を意味ある形で加速させる可能性がある。

AppleはMacBookのSSD交換を簡単に（あるいは安価に）できるようにはしていない。SSDを保護することは、ハードウェア投資を保護することだ。

リアルタイムでスワップを監視する方法

モデルをロードする前に、メモリプレッシャーを確認する習慣をつけよう。アクティビティモニタ → メモリタブを開くか、ターミナルで次のコマンドを実行する：

# Check current swap usage
vm_stat | grep "Swapouts"

# Real-time memory pressure monitoring
sudo memory_pressure

クイックスナップショットにはこのワンライナーも使える：

sysctl vm.swapusage

正常な出力はこのようになる：

vm.swapusage: total = 2048.00M  used = 0.00M  free = 2048.00M

モデルを実行中にusedが上昇しているなら、設定が間違っている。 このガイドの残りは、その数字をゼロに保つことに専念している。

黄金律： モデルが軽量なmacOS環境とともに8GBのユニファイドメモリに完全に収まらない場合、いかなるハードウェアの工夫でも克服できないパフォーマンスペナルティを支払うことになる。解決策は常に、より小さく、よりスマートに、より軽量にすることだ——スワップに差異を吸収させることは決して答えではない。

Step 3 8GB Mac向けの最良の小型モデル（Gemma 2B、Phi-3、Qwen）

8GBユニファイドメモリシステムに適したモデルを選ぶことは、妥協することではない——それは精密な選択だ。4B未満のパラメータモデルの状況は劇的に成熟しており、いくつかの有力候補が推論、コーディング、指示への従順性において真に印象的な能力を発揮し、きっと驚かせてくれるだろう。重要なのは、効率的に設計されたモデルと、単に小さいだけのモデルを見分けることだ。

厳格なルールがある：モデルの重み＋KVキャッシュ＋macOSのオーバーヘッドが8GB以内に余裕を持って収まる必要がある。これは一般的に、1.5GBから4GBの間に収まる量子化済みモデルを目標とし、システムが呼吸できる余裕を残すことを意味する。

候補一覧

Gemma 2 2B — Googleの効率的な主力モデル

GoogleのGemma 2 2Bは、そのクラスをはるかに超える実力を発揮する。スライディングウィンドウアテンション機構とロジットソフトキャッピングを採用しており、旧来の2Bクラスモデルよりも著しく一貫性が高い。8GB Macにとって、これは安全な日常ドライバーだ。

# Pull and run Gemma 2 2B via Ollama
ollama pull gemma2:2b
ollama run gemma2:2b

強み： 優れた要約能力、自然な会話の流れ、良好な指示遵守性。
弱み： コーディング品質はPhi-3に劣る；2Bバリアントはコンテキストウィンドウが限定的。

Phi-3 Mini — 推論特化型スペシャリスト

MicrosoftのPhi-3 Mini（3.8B）は、このティアで最も技術的に洗練されたオプションだ。重度にキュレーションされた「教科書品質」のデータセットで訓練されており、はるかに大きなモデルに匹敵する推論とコーディングのベンチマークを達成している。コード生成、論理問題、または構造化された出力にローカルAIを使用するなら、Phi-3 Miniが選択肢だ。

# Run Phi-3 Mini with Ollama
ollama pull phi3:mini
ollama run phi3:mini

# Or target the 128K context variant explicitly
ollama pull phi3:3.8b-mini-instruct-4k-q4_K_M

Q4_K_M量子化では、Phi-3 Miniは約2.4GBに収まり、8GBシステムに十分な余裕を残す。スワップを引き起こすことなく、4K〜8Kのコンテキストウィンドウで快適に実行できる。

強み： 4B未満でクラス最高の推論能力、優れたコード出力、構造化されたJSON生成。
弱み： やや冗長な傾向がある；単純な質問に対して過剰に説明することがある。

Qwen2.5 — 多言語対応の高速モデル

AlibabaのQwen2.5シリーズは、8GB Macに対して2つの魅力的なオプションを提供する：純粋なスピードのための1.5Bと、より高い品質のための3Bだ。Qwenアーキテクチャは効率性のために特別に最適化されており、その多言語トレーニングデータにより、英語以外のワークロードに特に強い。

# Qwen2.5 1.5B — fastest option
ollama pull qwen2.5:1.5b
ollama run qwen2.5:1.5b

# Qwen2.5 3B — better quality, still comfortable on 8GB
ollama pull qwen2.5:3b
ollama run qwen2.5:3b

1.5Bバリアントは自動化パイプラインに特に興味深い——ローカルの分類器、ルーター、または軽量なデータ変換ツールとして使用できるほど高速で、目立ったレイテンシが生じない。

強み： 圧倒的な推論速度、強力な多言語サポート、エージェント/ツール使用パターンへの優秀な対応。
弱み： 1.5Bは複雑な推論タスクでニュアンスが失われる；本格的な使用には3Bが最低限だ。

実践的な推薦マトリックス

一つのモデルだけを選ぶのではなく——タスクに合わせてモデルをマッチングさせる：

• コーディングとデバッグ → phi3:mini
• 一般的なQ&Aとチャット → gemma2:2b
• 自動化、分類、パイプライン → qwen2.5:1.5b
• バランスの取れた日常使用 → qwen2.5:3b
• 多言語作業 → qwen2.5:3b

複数のモデルを実行することも問題ない——Ollamaはオンデマンドでモデルをロードし、アイドル時にメモリから退避する。二つを同時に実行しない限り、何も再起動せずにこれらの間を自由に切り替えられる。

結論：賢く選択すれば8GBは制限ではない。 これらのモデルは妥協品ではなく——まさに実行する環境のために最適化された、異なるクラスのツールだ。

Step 4 量子化の解説：Q4_K_Mがなぜ最良の選択なのか

Hugging FaceやOllamaのモデルライブラリを閲覧したことがあれば、必ず当惑するようなアルファベットのスープに遭遇したはずだ：Q4_K_M、Q8_0、Q5_K_S、F16、IQ3_XS。これらは恣意的な命名規則ではない——同じモデルの根本的に異なるバージョンを表しており、8GBマシンで間違ったものを選ぶことは、使えるツールとシステムを完全に止まらせるものとの差になる。

量子化が実際に行うこと

ニューラルネットワークモデルは、その核心において膨大な数値の重みの集合だ——モデルの思考方法を定義する数十億の浮動小数点数。ネイティブ形式（F32またはF16）では、これらの重みは完全または半精度で格納され、膨大な量のメモリを消費する。

量子化とは、これらの重みの数値精度を下げるプロセスであり、わずかな精度と引き換えに、メモリフットプリントと推論速度を劇的に削減する。

このように考えてほしい：3.14159265358979という数を格納する代わりに、量子化では3.14あるいは単に3として格納するかもしれない。モデルは一部の粒度を失うが、推論能力の大部分は保持する。

命名規則のデコード

GGUFの量子化命名スキーム（llama.cppとOllamaが使用）は構造化されたパターンに従う：

Q[bits]_[variant]_[size]
│        │         └── S = Small, M = Medium, L = Large (parameter mixture)
│        └──────────── K = K-quants (newer, smarter algorithm)
└───────────────────── Number of bits per weight

Q4_K_Mがスイートスポットを射抜く理由

Q4_K_Mの「K」が重要だ。K量子化は、よりスマートで不均一な量子化戦略を使用する——すべての重みに同じ精度削減を均等に適用するのではなく、モデル出力にとってより重要な重みを特定し、それらをより高い忠実度で保持しながら、重要度の低い重みを積極的に量子化する。

その結果、Q4_K_Mは驚くべきことを達成する：7Bパラメータモデルを約4GBに圧縮し、8GBシステムに4GBのヘッドルームを残す。これは以下のために使える： - macOSシステムプロセス（約2GBのベースライン） - アクティブなアプリケーションコンテキスト - KVキャッシュ（推論中のモデルの「作業記憶」） - スワップを防ぐためのオーバーヘッドバッファ

実用的なレベルでは、ベンチマークが一貫して示すように、Q4_K_Mは標準的な推論ベンチマークにおいてフル精度モデルのパフォーマンスの95〜98%を保持する。コーディング支援、テキスト生成、Q&Aといった実世界のほとんどのタスクでは、その差異には気づかないだろう。

Ollamaでこれを実践する

Ollamaでモデルを取得する際、量子化レベルを明示的にターゲットにできる：

# Default pull (Ollama chooses, usually Q4_K_M)
ollama pull llama3.2:3b

# Explicit quantization targeting
ollama pull qwen2.5:7b-instruct-q4_K_M

# Check what you have loaded
ollama list

NAME                              ID              SIZE    MODIFIED
qwen2.5:7b-instruct-q4_K_M      a8b3c2d1e0f9    4.7 GB  2 hours ago
gemma2:2b-instruct-q4_K_M       f1e2d3c4b5a6    1.6 GB  1 day ago

llama.cppを介した手動のGGUF管理では、量子化の指定は同様に直接的だ：

./llama-cli \
  -m ./models/mistral-7b-instruct-q4_K_M.gguf \
  -n 512 \
  --ctx-size 4096 \
  -ngl 99          # Offload all layers to GPU (Metal)

より低くするとき（そしてすべきでないとき）

Q3_K_MやIQ3_XSに下げることが理にかなうシナリオがある——特に、より大きく高性能なモデル（13Bパラメータモデルなど）を実行する場合に、品質の低下を受け入れながらもメモリに収めるためだ。よりスマートなモデルの積極的な量子化は、軽く量子化された弱いモデルを依然として凌駕できる。

しかし、Q4を下回ると次の現象が現れ始める： - ハルシネーション率の増加 - 指示への従順性の低下 - 不整合な推論チェーン - 構造化された出力タスク（JSON、コード）での著しくパフォーマンスの悪化

8GBマシンの黄金律：常にまずQ4_K_Mに手を伸ばすこと。 モデルが単純に収まらない場合にのみ低くし、十分なメモリヘッドルームのある4B未満のパラメータモデルを実行する場合にのみ高く（Q6_K、Q8_0）する。

Step 5 macOSのバックグラウンドタスクの最適化

最も積極的に量子化されたモデルでさえ、macOSが意識的に起動したことのないプロセスに2〜3GBのユニファイドメモリをサイレントに割り当てていれば、スタッターしてスワップする。OllamaやLM Studioを起動する前に、Macを一時的になるべき専用推論マシンとして扱おう。

RAMを消費しているものを理解する

macOSは美しく、意見を持ったオペレーティングシステムであり、常にiCloud同期、Spotlightインデックス作成、そして数十のメニューバーデーモンを並行して実行したいと仮定している。ローカルAIワークロードでは、すべてのメガバイトが重要だ。まずこのコマンドを実行して、メモリプレッシャーの冷酷な現実を把握しよう：

```bash

Real-time memory breakdown

sudo memory_pressure

Continue Reading

Performance

Mistral 7B vs Llama 3 on Apple Silicon

Tools

Best GUI clients for Local LLMs

Advanced

Quantization 101: Speed up your Inference