在雲端 Mac mini 上跑本地 LLM 推理:記憶體規劃與量化選型實戰

上週有位做端側 AI 實驗的讀者問我:想跑一下 Llama 3 8B 和一個 13B 的程式碼模型,本機筆電記憶體不夠,買一台 Mac Studio 又怕用不滿,能不能先在雲端租一台試試量級。這其實是個很典型的場景——本文就順著這個思路,把在雲端 Mac mini 上跑本地 LLM 推理的記憶體規劃、環境搭建和量化選型完整走一遍。

為什麼用統一記憶體頻寬反推模型量級

Apple Silicon 的 CPU、GPU、神經網路引擎共用同一塊統一記憶體,不存在顯存與記憶體來回搬移資料的開銷,這對推理任務是天然優勢,但也代表記憶體容量直接卡死了能跑的模型上限。粗略換算規則:一個以 FP16 訓練的模型,經 4-bit 量化後的占用大約是參數量的 0.55~0.6 倍(單位 GB),再加上上下文快取(KV cache)與系統開銷。

這張表只是起步參考,實際能跑多大取決於你是否同時開著 Xcode、瀏覽器等占記憶體的應用程式——推理程序崩潰前先看看 top 裡系統還剩多少可用記憶體,別等 OOM 才排查。

環境搭建:llama.cpp 與 MLX 二選一

兩條路徑互不衝突,可以在同一台機器上都裝好,依任務切換使用。

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。

常見問題