本地运行大语言模型需要多少内存
下载模型准备在本地运行之前，得先确认它能不能装进内存。估算时把三项加起来，再拿结果和机器实际能提供给模型的内存作对比：
need = weights + KV cache + overhead
也就是：模型权重 + KV 缓存 + 额外开销。
当 need <= 0.8 × usable memory 时才算放得下。
下面的数字沿用 osFoundry 桌面应用里本地模型浏览器的估算方法，并与该应用在 16 GB MacBook M3 上显示的结果做了核对。
权重
权重大小等于参数数量乘以每个权重占用的字节数；每个权重占多少字节取决于量化方式：
| 量化方式 | 每个权重占用的字节数 |
|---|---|
| FP16 / BF16 | 2.0 |
| Q8_0 | 1.0 |
| Q6_K | 0.82 |
| Q5_K_M | 0.69 |
| Q4_K_M | 0.56 |
| Q3_K_M | 0.44 |
| Q2_K | 0.31 |
Q4_K_M 是 0.56 而不是 0.5，因为 K-quants 会为每一小块权重保存一个缩放系数，算下来每个权重大约 4.5 bit。
一个 14B 模型使用 Q4_K_M 时：14 × 10⁹ × 0.56 = 7.84 × 10⁹ 字节，约 7.3 GiB。
如果不认识某个量化名称，就按 FP16 估算。这是偏保守的选项，不会把实际放不下的模型误判为能放下。
KV 缓存
生成过程中，模型会保存上下文中每个 token 的键（key）和值（value）。大小计算公式为：
2 × layers × kv_heads × head_dim × context_tokens × bytes_per_element
Qwen2.5 14B 有 48 层、8 个 KV 头（使用分组查询注意力，grouped-query attention），每个头的维度是 128。KV 缓存使用 FP16 时：
- 4K 上下文：2 × 48 × 8 × 128 × 4096 × 2 字节 = 768 MiB
- 32K 上下文：6 GiB
缓存会随上下文长度线性增长，所以一个在 4K 上下文下绰绰有余的模型，到 32K 时可能就放不下了。不说明上下文长度的估算参考价值不大；截图里的估算按 4K 计算。
额外开销
llama.cpp 还需要计算缓冲区和临时空间。粗略估算，可以按权重大小的 10% 再加约 200 MB 预留。对 14B 模型来说，大约是 0.9 GB。
把权重、KV 缓存和额外开销加起来，14B 模型在 Q4_K_M 下大约需要 8 到 9 GB。应用显示的是 8.4 GB。
可用内存
这里是大家最容易搞错的地方。独立显卡：上限是显卡的显存（VRAM）。12 GB 显存的卡就是 12 GB，不管系统内存有多大。
Apple Silicon：内存是统一的，但 GPU 不能全部用掉，操作系统也要占一部分。按总内存的 75% 来算比较合理，所以 16 GB 内存大约可用 12 GB。
再往下就是对比判断，分三档：
- 需求不超过可用内存的 80%：能装下，还留有余量给系统和其他应用
- 在 80% 到 100% 之间：勉强够用，能加载，但会优先把其他应用挤掉
- 超过 100%：开始往硬盘上换页，慢到没法用
在 16 GB 的 Mac 上，结果是这样：Q4_K_M 占 8.4 GB（70%，装得下）、Q5_K_M 占 10.4 GB（87%，勉强）、Q6_K 占 12.3 GB、Q8_0 占 14.9 GB（这两个就超了）。把同样的方法套到多个 Q4_K_M 量化的模型上，这台机器的分界线落在 20B（11.9 GB，勉强）和 27B（15.9 GB，太大了）之间。
生成速度也由这个数决定
每生成一个 token，都要把内存里的所有权重读一遍，所以生成速度的上限就是内存带宽除以模型大小。基础款 M3 的带宽大约 100 GB/s，那么一个 8.4 GB 的模型最高大约能跑到每秒 12 个 token，而 4.9 GB 的 8B 模型能到每秒 20 个左右。实际值都会低一些，但不同模型之间的比例关系基本保持得住。这样算下来，对模型大小的估算一次回答了两个问题：这个模型能不能加载得起来，以及如果能，大致能写多快。
在下载模型准备本地运行之前，得先确认它装不装得进内存。估算方式是把三项加起来，再拿结果和机器实际能提供给模型的内存作比较：
need = weights + KV cache + overhead
fits if need <= 0.8 × usable memory