看到“7B”“32B”或“70B”时，你可以快速算出模型权重的理论占用，但这不等于运行时显存。真正的峰值还取决于 Quantization 格式、Context Window、KV Cache、Batch Size、推理引擎以及是否将部分层卸载到内存。本文的目标，是把“一个数字”拆成可检查的预算。
先看结论：权重只是显存起点
最常用的快算是：参数量 × 每个参数的字节数。例如，FP16 每参数理论上是 2 Byte，INT8 是 1 Byte，INT4 是 0.5 Byte。因此，同一个模型从 FP16 换成理想的 INT4，权重体积约变为四分之一。
重要：“理论权重占用约 X GiB”只是下限估算，不能推导出“X GiB 显存的显卡一定能跑”。
参数量、bit 与权重公式
模型名中的 B 通常表示 billion，即十亿个参数。显存通常用二进制单位 GiB，而下载页面有时用十进制 GB：1 GiB = 1,073,741,824 Byte。两种单位混用，会造成约 7% 的观感差异。
| 数值类型 | 7B 理论权重 | 14B 理论权重 | 32B 理论权重 | 70B 理论权重 | 说明 |
|---|---|---|---|---|---|
| FP32 | 26.1 GiB | 52.2 GiB | 119.2 GiB | 260.8 GiB | 高精度，本地推理少见 |
| FP16 / BF16 | 13 GiB | 26.1 GiB | 59.6 GiB | 130.4 GiB | 常见半精度权重 |
| FP8 | 6.5 GiB | 13 GiB | 29.8 GiB | 65.2 GiB | 需要软硬件链路支持 |
| INT8 | 6.5 GiB | 13 GiB | 29.8 GiB | 65.2 GiB | 整数量化，与 FP8 不是同一表示法 |
| INT4 | 3.3 GiB | 6.5 GiB | 14.9 GiB | 32.6 GiB | 常见低比特量化目标 |
FP8 和 INT8 在表中都是 8 bit，所以理论字节数相同；但它们的可表示范围、量化方法和硬件执行路径不同，不能只看体积就当成互换。同样，模型名的“7B”也可能是取整值，最终文件大小应以具体 checkpoint 为准。
Quantization 改变了什么
Quantization（量化）把高精度权重映射到更低 bit 的表示，用较小存储和内存带宽换取可接受的近似误差。“INT4”不是唯一格式：实际文件可能按 group 保存 scale、zero-point、高精度层或其他 metadata。因此，4 bit 的算术下限不等于磁盘文件大小，更不等于运行峰值。
为什么同为 4 bit，大小和速度仍会不同？
- Group size 不同：分组越细，辅助 scale 数据通常越多。
- 部分层保留高精度：embedding、output head 或对误差敏感的层未必都是 4 bit。
- 引擎与硬件支持不同：某种格式能被加载，不代表它能用当前 GPU 的高效 kernel 执行。
- 质量取舍不同：同一 bit 数下，量化算法、校准数据和模型架构都会影响误差。
KV Cache 为什么会吃显存
自回归生成每个新 Token 时，如果重算所有历史上下文会非常慢。KV Cache 保存每层 Attention 的 Key 和 Value，用显存换取速度。它大致随上下文长度和 Batch Size 线性增长，并受 KV heads、head dimension、层数与 Cache 精度影响。
举一个只用来理解量级的假设：32 层、8 个 KV heads、head dimension 128、FP16 Cache、Batch 1、8,192 Tokens，KV Cache 约为 1 GiB；上下文增到 32,768 Tokens 时约为 4 GiB。这不是对任何具体模型的承诺；GQA/MQA、滑动窗口、Cache 量化和引擎预分配都可能改变结果。
实际运行还有哪些开销
权重和 KV Cache 之外，运行时还需要 Activations、临时张量、Attention workspace、量化 metadata、图编译或算子 workspace、CUDA/Metal 上下文以及引擎本身缓冲区。不同后端的内存池和预分配策略也会让监控数字不同。
对于多用户服务，还要特别看并发序列数；Batch 或并发越高，KV Cache 和部分临时开销越大。对于 Apple Silicon，“统一内存”也不是全部可供模型独占：macOS、桌面应用和推理程序仍需要共用。当系统开始频繁压缩或 Swap，即使“能加载”，交互体验也可能已不理想。
三个实际估算案例
案例一：7B INT4，不要把 3.3 GiB 当结论
7B × 4 bit 的理论权重约为 3.3 GiB。接下来应查实际量化文件大小，再加上目标上下文的 KV Cache、引擎开销和操作系统余量。只用“权重小于显存”判断，最容易在长对话或首次加载时失败。
案例二：32B INT4，要预算上下文
32B INT4 的理论权重约为 14.9 GiB。这个数字已经没有包含任何 Cache 与 Runtime 余量。如果计划用大量代码、整本资料或多路并发，应先用目标 Context Window 做压测，而不是只测一句短 Prompt。
案例三：70B 分层卸载，能跑不等于跑得值
70B INT4 的算术下限约为 32.6 GiB。某些引擎可把部分层放在系统内存，但数据往返会受 PCIe、内存带宽和调度影响。这能扩大“可加载”范围，不代表首 Token 延迟或每秒 Tokens 符合你的使用目标。
选硬件前的检查清单
- 确认具体 checkpoint：记录实际参数量、量化方法、分片数和文件大小。
- 冻结使用条件：单用户还是多用户？目标 Context Window 和并发数是多少？
- 检查软硬件兼容：显卡架构、驱动、引擎和量化格式是否有高效实现。
- 保留非权重余量：余量应由具体引擎压测决定，不宜对所有模型套一个固定百分比。
- 测试峰值而非闲置值：记录加载、Prompt Prefill、长文生成和并发请求中的峰值。
- 同时检查性能：可加载、不爆显存、延迟可接受，是三个不同的验收条件。
用 VRAM 计算器建立第一版预算
在 LLM VRAM 计算器 中输入参数量和 FP32、FP16、FP8、INT8 或 INT4，可得到与上述公式一致的理论权重占用。把这个结果当作筛选器：如果权重下限都超过可用内存，就需要更低 bit、分层卸载或更小模型；如果权重能放下，则继续加上 KV Cache 与 Runtime 开销并实测。
如果你还在“买显卡还是直接用 API”之间比较，可继续阅读本地大模型与云端 API 成本对比，把显存、购置成本、电费、时间和隐私要求放在同一个决策中。