按8GB到128GB内存档位推荐可流畅运行的模型规模(2B-120B),并给出各档位实际使用场景和主要制约因素。
简单直接的回答:选 Mac 做本地 AI,先看统一内存,再看芯片代数。至少留 25–30% 的内存给 macOS、上下文和你的实际使用程序。
能加载的模型不一定能流畅运行。本指南将 Mac 内存档次与现实可行的模型规模对应起来,不拿 benchmark 分数当购买建议。
8GB:短 prompt、分类、提取任务用紧凑型 2–4B 模型。
16GB:通用 7–9B 模型;20B 可以跑,但几乎触到极限。
24GB:运行 9–20B 模型的实用主流档次。
36–48GB:27–35B、编码、文档工作的平衡区间。
64GB:70B 4-bit 量化开始变得可行。
96–128GB:大型 70–120B 模型、长上下文、并行工作负载。
使用 AI Feed Local AI 监控工具按内存、许可证和任务对比当前模型。
这些是实用的余量目标,不是硬性限制。实际使用情况会因量化方式、运行时和上下文长度而变化。
Apple Silicon 使用统一内存:CPU 和 GPU 共享一个内存池。这有助于本地推理,因为加速器可以直接访问机器的大部分内存,无需将权重复制到独立的 VRAM 中。
代价是竞争。模型权重、Safari、IDE、Docker、显示系统以及 KV 缓存都使用同一个内存池。当权重几乎耗尽所有内存时,macOS 开始交换数据、生成速度变慢,更长的 prompt 可能导致进程终止。
内存需求 = 权重 + KV 缓存 + 计算缓冲区 + 运行时 + macOS + 应用
权重是可以估算的大型组件。Q4 量化每个参数大约占用半字节,外加开销。
KV 缓存随对话和上下文窗口增长。
计算缓冲区取决于架构和运行时。
系统仍需为浏览器、编辑器和后台服务留出空间。
这就是为什么一个 17GB 的模型文件可能在 24GB Mac 上运行,但在 36GB 机器上感觉好得多。
看 Qwen、Phi、Gemma 等系列 2–4B 变体,大小控制在约 3–4GB 以下。它们适合分类、字段提取、短文本重写和简单补全。用它们处理大型代码库或长文档并不现实。
现代 7–9B Q4/Q5 模型可以编辑文本、基于本地文档回答问题、协助处理小型函数。OpenAI 称 gpt-oss-20b 可以在 16GB 内运行,但这给上下文和应用留下的空间很小。可能不等于舒适。
对大多数买家而言,这是第一个真正可用的本地 AI 配置。它可以让一个强力的 9–14B 模型常驻,同时运行浏览器和编辑器;或者用合理的余量跑 gpt-oss-20b。
实用选择包括:
27–35B 类模型为上下文、IDE 和浏览器留出了空间。在 48GB 下,更高质量的量化或多个进程变得可行。
更多 GPU 核心让模型跑得更快。更多内存决定能跑哪一类模型。对很多开发者而言,这意味着 36–48GB 比配更大内存的更快芯片更有价值。
在 64GB 下,70B Q4 模型变得现实。权重通常占用约 42–48GB,留下有限但可工作的余量。
更多参数不一定意味着更好的体验。一个现代 35B MoE 模型在工具使用上可能比一个老旧的稠密 70B 模型更快、更可靠。
这些容量在确实需要非常大模型、多个并发客户端或长上下文时才有意义。OpenAI 估算 gpt-oss-120b 需要约 80GB,因此 96GB 是实用的起点,128GB 则留有充足的应用余量。
对于偶尔的高强度任务,云模型仍然可能更快更便宜。AI Feed API 价格计算器有助于比较成本数量级。
从 Ollama 或 LM Studio 开始。当有可靠的转换版本时,尝试 MLX。当你想直接控制上下文、缓存、卸载和服务器设置时,使用 llama.cpp。
指令遵循、仓库访问和工具使用与模型规模同等重要。一个配有优秀编码工具链的 9–20B 模型通常比一个没有上下文余量的大模型更有用。
扩散模型使用内存的方式与 LLM 不同。紧凑型生成器在 16–24GB 可以运行,而高分辨率、多个 ControlNet 和批处理需要更多资源。
本地视频仍然是最重的工作负载。24–36GB 的 Mac 可以为短视频运行紧凑模型,但需要漫长等待,并不等同于云端视频服务。
Apple MLX:统一内存
llama.cpp:macOS Metal 构建版本
OpenAI:gpt-oss 内存需求
Hugging Face:gpt-oss-20b
Microsoft:Phi-4 Mini Instruct
更新时间:2025 年 9 月 25 日。尺寸指特定量化版本,可能随运行时演进而变化。
使用 Local AI 模型选择器对比当前模型。原文及后续更新留在 AI Feed。