在云端 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。

常见问题