本地大模型内存预算如何计算
文章将推理内存拆分为权重、KV 缓存与运行开销，并建议按可用内存的八成估算容量。它列出不同量化格式的每参数字节数，解释量化元数据开销，并给出模型容量计算示例。
AI 深度解读
本地跑 LLM，下载前该算的不是模型文件有多大，而是运行时一共要占多少内存。作者给出的办法是：把权重、KV cache 和运行开销加起来，再对照机器实际能分给模型的内存，给系统和其他应用留出余量。
这套估算与 osFoundry 在 16GB M3 MacBook 上显示的数字做过核对。它适合用来筛选模型，也能解释一个常见疑问：同一个模型，为什么短对话能跑，塞进长代码后就吃不消？
模型文件装得下，为什么运行时还会超？
作者的计算入口只有两行：
need = weights + KV cache + overhead
fits if need <= 0.8 × usable memory
它解决的是运行内存预算问题。要留意第二行的 usable memory：比较对象是实际可用内存，不能直接拿整机标称容量代入。
第一项是权重，也就是模型参数。体积取决于参数量和量化格式。Q4_K_M 不能直接按每个参数 0.5 字节计算，因为 K-quants 还会为小块权重保存缩放因子。作者采用每个参数约 0.56 字节，即约 4.5 bit。
因此，14B 模型的权重约为：
14 × 10⁹ × 0.56 = 7.84 × 10⁹ 字节 ≈ 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 heads、128 的 head dimension，使用分组查询注意力（grouped-query attention）。缓存采用 FP16 时，每个元素占 2 字节：
- 4K 上下文，即 4096 token，缓存为
2 × 48 × 8 × 128 × 4096 × 2字节，也就是 768 MiB。 - 32K 上下文，缓存增长到 6 GiB。
不说明上下文长度的内存估算，很难直接拿来选模型。
第三项是 llama.cpp 的计算缓冲区和临时空间。作者粗略按权重的 10% 再加约 200 MB 计算，14B 模型约需 0.9 GB。三项相加，Q4_K_M 的 14B 模型约占 8～9 GB，应用显示为 8.4 GB；截图采用的是 4K 上下文。
16GB 内存，到底能选多大的模型？
作者先区分了两种硬件条件：独立显卡按显存预算，12 GB 显卡就先按 12 GB 算；Apple Silicon 使用统一内存，但 GPU 和模型不能独占全部容量，还要给系统留空间。
文中把 Apple Silicon 总内存的 75% 当作可用预算，因此 16GB Mac 按约 12 GB 计算，再分三档：
- 占可用预算不超过 80%，归为能放下。
- 占用在 80%～100%，归为紧张，建议先关闭其他应用。
- 超过 100%，作者判断会出现磁盘换页，速度可能失去实用价值。
按这个口径，Qwen2.5 14B 的 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/s，4.9 GB 的 8B 模型约为 20 token/s，并明确表示实际速度会更低。
我的判断
我赞成先算预算，再下载模型。尤其是把 KV cache 单独列出来，对需要塞入源码、错误日志和多轮对话的 AI 编程场景很有用。参数量相同，不代表运行占用固定。
但这些数字应当视为筛选依据。作者核对的是应用显示值，没有提供完整的峰值内存测量、测试过程或跨硬件对照。75% 可用预算、80% 安全线，以及「权重的 10% 加 200 MB」，都是经验口径。
单位也要留神：原文混用了 GB、GiB、MB 和 MiB，适合估算，不宜拿小数点后的差别判断一定能否运行。
独显部分讨论的也是显存预算。把「超过显存」直接理解为「完全无法运行」过于绝对，原文没有展开其他加载方式。
速度估算还有一个口径问题：前面强调读取的是权重，计算时却用了包含缓存和开销的 8.4 GB。再加上作者没有给出系统性的速度对照，「模型之间的速度比例相当准确」仍属于经验判断，不能当作性能承诺。
能拿来做什么
- 给本地 AI 编程选模型时，同时记录模型名称、量化格式和上下文长度，别只比较 8B、14B 这些参数量。
- 把源码和日志放进上下文前，先重算 KV cache。文中的 14B 示例从 4K 增至 32K，缓存就从 768 MiB 增到 6 GiB。
- 在 16GB M3 Mac 上，可以把文中的 Q4_K_M 8.4 GB 当作初筛参照，再用自己的编辑器、浏览器和实际提示词验证剩余空间。
- 比较 8B 与 14B 时，用带宽估算判断速度的大致量级，再用相同提示词测试生成速度与答案质量，决定是否值得多占内存。