本地大模型内存怎么算：权重之外还有缓存

dev.to · AI#本地模型#量化#内存估算

Editor brief · 编辑速览

文章将本地推理内存拆为权重、KV 缓存和运行开销，并建议预留容量余量。它列出不同量化格式的权重估算系数，例如 14B 模型采用 Q4_K_M 时，权重本身约占 7.3GiB。

文章思维导图

Knowledge map

拖拽缩放

AI deep read

AI 深度解读

本地跑 LLM，模型文件能下载，不代表机器能顺畅运行。作者给出了一套估算办法：把模型权重、上下文缓存和运行开销加起来，再与机器实际能分给模型的内存比较。它还能粗略解释：为什么同一台电脑换个模型，输出速度就差了一截。

原文用 osFoundry 在 MacBook M3 16GB 上显示的结果核对估算。最有用的结论是：选模型不能只看参数量，还得一起看量化格式、上下文长度和可用内存。

作者把需求拆成三项，并给出预留余量的判断式：

need = weights + KV cache + overhead
fits if need <= 0.8 × usable memory

注意第二行的 usable memory，它指实际可供模型使用的内存，不是机器包装上的总容量。

先算 weights，也就是模型权重。计算方法是参数量乘以每个权重占用的字节数。Q4_K_M 按每个权重 0.56 字节估算，不能直接按 4 bit 对应的 0.5 字节算，因为 K-quant 还要为小块权重保存缩放系数，实际约为 4.5 bit。

因此，14B 模型的权重是：

14 × 10⁹ × 0.56 = 7.84 × 10⁹ byte，约 7.3 GiB。

作者建议，遇到不认识的量化名称，先按 FP16 做保守估计。这是筛选时的兜底办法，具体大小仍应查看模型信息。

第二项是 KV cache。模型生成时，会保存上下文中各个 token 的 key 和 value，避免后续重复计算。其容量估算如下：

2 × layers × kv_heads × head_dim × context_tokens × bytes_per_element

要看清这里的 context_tokens：缓存会随上下文长度线性增长。

Qwen2.5 14B 有 48 层、8 个 KV head，采用分组查询注意力（grouped-query attention），head dimension 为 128。使用 FP16 缓存、上下文为 4096 token 时：

2 × 48 × 8 × 128 × 4096 × 2 byte = 768 MiB。

所以，4K 时装得下，不代表 32K 也装得下。不说明上下文长度的内存估算，很难直接拿来选模型。

第三项是 llama.cpp 的计算缓冲区和临时工作空间。作者粗略按权重的 10% 再加约 200 MB 预留，14B 模型约为 0.9 GB。三项相加，Q4_K_M 的需求落在 8 到 9 GB，osFoundry 显示为 8.4 GB，截图默认采用 4K 上下文。

硬件架构会改变分母。

独立显卡按完整装入 GPU 的口径估算时，看的是显存（VRAM）。12 GB 显卡不能因为系统还有很多 RAM，就直接按更大的显存容量计算。

Apple Silicon 使用统一内存，但 GPU 不能独占全部容量，操作系统也需要空间。作者取总内存的 75% 作为工作估值，因此 16 GB 机器按约 12 GB 可用内存计算。

在此基础上，需求不超过可用内存的 80%，算有余量；80% 到 100% 属于勉强，建议先关闭其他应用；超过 100%，作者认为会因内存转移到磁盘而严重变慢。

按这套口径，Qwen2.5 14B 的结果是：

对若干 Q4_K_M 模型应用相同算法，这台机器的边界落在 20B 与 27B 之间：20B 需要 11.9 GB，已经很挤；27B 需要 15.9 GB，超过预算。

作者的解释是：生成每个 token，都需要从内存读取一遍模型权重，因此可以用内存带宽除以模型大小，粗估生成速度上限。

基础款 M3 的内存带宽约为 100 GB/s。原文用 8.4 GB 估算约 12 token/s，用 8B 模型的 4.9 GB 估算约 20 token/s，并明确表示实际速度会更低。

这能帮助理解选型代价：更大的模型即使成功加载，也可能让交互等待明显增加。但原文没有给出完整的测速方法，截图对比不能代替系统性的性能测试。

这套方法适合下载前做第一轮筛选。它把权重、缓存、运行开销分开，尤其纠正了「文件大小就是运行内存」的误解。

不过，75% 可用内存、80% 安全线，以及「权重的 10% 加 200 MB」，都是经验估值。原文核对的是应用显示的估算，没有提供覆盖多种硬件和上下文长度的内存实测，不能把这些比例当成通用保证。

速度部分也要留个问号：推导说的是读取权重，但算式用了包含缓存和开销的 8.4 GB 总需求，口径并不完全一致。它适合说明趋势，不能当作准确测速公式。超过预算后是否换页、加载失败或采用其他运行方式，原文也没有区分。

把它当容量预算表，再用目标配置实测，会比只看参数量可靠。