所有玩本地大语言模型的人都背过一句经验法则：" 每十亿参数大约需要 0.5GB 显存。" 这个数字用起来似乎很顺手，直到你真正加载了一个 8B 模型，跑了几分钟对话，然后它突然崩溃，终端里跳出一行 "Out of Memory"。模型明明装下了，上下文却把显存吃爆了。问题不在模型本身，而在于两个大多数人都没细查过的数字。 第一个数字：量化权重文件比它听起来要大。Q4_K_M 这个名字会让人误以为平均每个权重只占 4 比特，那么 8B 模型算下来应该是 8 乘以 4 除以 8，也就是 4.01GB。可你去 Hugging Face 下载实际的 bartowski/Meta-Llama-3.1-8B-Instruct-GGUF 文件，Q4_K_M 版本是 4.92GB，比这个 " 理想值 " 重了 23%。这 23% 不是舍入误差。K-quants 在量化权重旁边存了每个块的缩放因子和最小值，而带 "M" 或 "L" 后缀的变体还会把嵌入层、输出层这些敏感张量保留在更高精度。后缀只说明整个文件的主导格式，不代表全文件的平均值。精度越高，这种额外开销就越小。如果你需要一个规划用的数字，直接用 0.61GB 每十亿参数，这才是 Q4_K_M 下的真实比例—— "0.6GB 每十亿参数 " 的说法就是这么来的。 第二个数字：KV cache 会随对话增长，而且永远不缩小。权重是一次性成本，但 KV cache 每个 token 都要增长，直到你开新对话才会重置。它的计算方式是：两个张量（K 和 V），乘以层数、KV 头数、头维度，再乘以每个元素占用的字节数。Llama 3.1 8B 有 32 层，head_dim 是 128，KV 头只有 8 个（不是 32 个），因为分组查询注意力让多个查询头共享键值投影，这比全多头注意力省了 4 倍缓存。如果按 fp16 计算，每个 token 要占用 128KB。换句话说，8192 个 token 的上下文就要吃掉 1GB 显存，131k 上下文会吃掉 16GB ——这已经超过模型本身了。 所以，当你为本地模型规划显存时，别再只盯着模型文件大小。长对话、长文档、多轮交互，真正的显存杀手常常是 KV cache。把模型权重和上下文缓存一起算，才能避免那种 " 模型加载成功，聊到一半突然 OOM" 的尴尬局面。