下载模型之前先算一笔账：它到底进不进得来内存。估算方式是把三样东西加起来，再拿去和机器实际能给模型的内存比一比。 公式很直白： 需求 = 权重 + KV 缓存 + 额外开销 ，判断条件是 需求 ≤ 可用内存的 80% 。下面这组数字来自桌面应用 osFoundry 的本地模型浏览器所用的同一套估算，并已用 16GB M3 MacBook 上应用显示的数字做过核对。 权重：量化方式决定字节数 权重体积等于参数数量乘以每个权重占的字节，而字节数取决于量化。Q4_K_M 之所以用 0.56 而不是 0.5，是因为 K-quants 会为权重的每个小块额外存一个缩放系数，算下来大约每个权重 4.5 比特。 以 Q4_K_M 下的 14B 模型为例：14 × 10⁹ × 0.56 = 7.84 × 10⁹ 字节，约合 7.3 GiB。如果认不出量化名称，就按 FP16 估——这是最悲观的算法，好处是你不会把实际装不下的东西当成"能装下"。 KV 缓存：上下文越长越吃内存 生成时模型要保留上下文中每个 token 的 key 和 value，体积由层数、KV 头数、头维度、上下文长度和每元素字节共同决定。Qwen2.5 14B 有 48 层、8 个 KV 头（用了分组查询注意力）、头维度 128，配 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。三项相加，Q4_K_M 的 14B 模型落在 8 到 9 GB 之间，应用显示的是 8.4 GB。 可用内存：最容易算错的一步 独立显卡：显存就是上限。12 GB 的卡就是 12 GB，系统内存再大也没用。 Apple Silicon：内存是统一的，但 GPU 用不满全部，系统也要留自己的一份。按总内存的 75% 算是个能用的数字，16 GB 约合 12 GB。 然后做比较：需求不超过可用内存的 80%，算装得下，还给系统和其它应用留了余地；80% 到 100% 之间是紧张，能加载，但得先关掉别的应用；超过 100% 就开始往磁盘上换页，慢到没有使用价值。 在 16GB 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 个。实际数字会低于这个值，但模型之间的比例关系相当准。 也就是说，体积估算一次回答两个问题：模型能不能加载，以及加载之后大概写得多快。 特别
分享给更多关注行业变化的朋友。
