クラウドMac miniでローカルLLM推論を動かす:メモリ設計と量子化選定

上週、エッジAIの実験をしている読者から質問を受けました。Llama 3 8Bと13Bのコードモデルを動かしたいが、手元のノートPCのメモリでは足りない。Mac Studioを買うにしても持て余しそうで怖いので、まずクラウドで一台借りて量級を試したい、という相談です。これは実はかなり典型的なシナリオです。本稿ではこの流れに沿って、クラウドMac miniでローカルLLM推論を動かすためのメモリ計画、環境構築、量子化フォーマット選定を一通り解説します。

なぜ統合メモリ帯域からモデル量級を逆算するのか

Apple SiliconのCPU・GPU・Neural Engineは同一の統合メモリを共有しており、VRAMとメインメモリ間でデータを往復させるオーバーヘッドが存在しません。これは推論タスクにとって天然のアドバンテージですが、同時にメモリ容量がそのまま動かせるモデルの上限を決めてしまうことも意味します。おおよその換算ルールとしては、FP16で学習されたモデルを4-bit量子化した場合、メモリ占有量はパラメータ数のおよそ0.55〜0.6倍(単位GB)になり、これにコンテキストキャッシュ(KVキャッシュ)とシステムオーバーヘッドが加算されます。

この表はあくまで出発点の参考値です。実際にどこまで動かせるかは、Xcodeやブラウザなどメモリを消費するアプリを同時に開いているかどうかにも左右されます。推論プロセスがクラッシュする前に、topでシステムの空きメモリがどれくらい残っているかを確認しておきましょう。OOMになってから原因を探るのは非効率です。

環境構築:llama.cppとMLXの二択

この2つの経路は排他的ではなく、同一マシンに両方インストールしてタスクに応じて切り替えることができます。

llama.cpp:汎用性重視

brew install cmake
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_METAL=ON
cmake --build build --config Release -j
./build/bin/llama-cli -m models/llama-3-8b-q4_k_m.gguf \
  -p "写一段解释递归的代码示例" -n 256 --ctx-size 4096

-DGGML_METAL=ONが肝です。Metalバックエンドを有効にしないとGPUの性能を最大限使えません。このオプションを付けないと純CPU推論にフォールバックし、速度が数倍落ちます。

MLX:Apple純正フレームワーク

python3 -m venv mlx-env
source mlx-env/bin/activate
pip install mlx-lm
mlx_lm.generate --model mlx-community/Llama-3-8B-Instruct-4bit \
  --prompt "解释一下 KV cache 的作用" --max-tokens 256

MLXはmlx-communityネームスペース上に量子化済みの重みが直接ホストされているため、自分でフォーマット変換をする必要がなく、llama.cppより導入が速いです。ただしエコシステムの成熟度やコミュニティのトラブルシューティング情報の量は、現時点ではまだllama.cppの方が充実しています。

量子化フォーマットの選び方

量子化は精度が低いほど良いわけではなく、タスクの種類に応じて選ぶべきです。

• Q4_K_M:日常的な質疑応答やコード補完であれば十分で、メモリ占有が最も少なく、ほとんどのシーンでのデフォルト選択になります。
• Q5_K_M:長い推論チェーンや多段階の論理判断を伴う場合は、このグレードまで上げることを推奨します。出力の安定性が明らかに向上します。
• Q8_0:オリジナル精度に近く、精度要求の高い評価シーンに適していますが、メモリ占有が倍増するため、メモリに余裕がある(24GB以上)場合にのみ検討してください。

判断基準はシンプルです。まずQ4で実際に使う想定の質問群を実行し、回答品質を人手で確認します。明らかな論理の飛躍や数値の誤りが見られた場合に限り、段階的に上のグレードを試します。最初から最高精度でメモリを埋め尽くす必要はありません。

ディスク容量とスナップショット管理

モデルファイルは数GBから数十GBに及ぶことが多く、レンタル期間終了前に前もって整理計画を立てておく必要があります。

1. ダウンロードしたモデルは~/models/ディレクトリに統一して置くことで、ディレクトリ単位での一括削除や移行がしやすくなります。
2. du -sh ~/models/*で定期的に占有量を確認し、量子化済みの古いバージョンのモデルは早めに削除して、システムディスクが満杯になり推論速度に影響が出ないようにします。
3. 実験環境の設定(仮想環境、ダウンロード済みの重みのリストなど)を残しておきたい場合は、tarballにまとめてローカルにダウンロードしておきましょう。レンタル期限が切れる前に処理を済ませてください。システムディスクは期限切れ後にデータを保持しません。

du -sh ~/models/* | sort -rh | head -5
tar czf mlx-env-backup.tar.gz mlx-env models/*.json

実測フローとモニタリング

推論を実行する際は、リソース使用状況を監視するターミナルウィンドウをもう一つ開いておくと、メモリ圧迫を事前に察知できます。

sudo powermetrics --samplers gpu_power -i 1000 -n 5

GPU使用率と電力消費のカーブを観察し、長時間高い水位を維持しているにもかかわらず応答が遅い場合は、通常コンテキストキャッシュがメモリ帯域を食い尽くしていることが原因です。この場合は--ctx-sizeを短くするか、より小さい量子化グレードに切り替えるべきで、むやみにbatchサイズを大きくすべきではありません。

よくある質問