4 bit模型为何不等于显存缩小四倍？量化账单这样算

看到“4 bit模型”，很多人会把原模型显存直接除以四。通俗答案是：4 bit通常只压缩权重，运行时还要装比例因子、缓存和临时张量。读完你会算出模型权重的理论下限、分组量化开销，并知道为什么能下载不等于能顺利推理。

量化解决什么问题

训练好的模型权重常用16位浮点数保存。一个70亿参数模型只算权重，大约需要70亿×2字节，也就是14 GB的十进制容量。把权重变成4 bit，理想值变为每个参数0.5字节，约3.5 GB。更小的权重减少存储、内存带宽和显存压力，让消费级硬件有机会运行更大的模型。

生活类比是把一张地图的海拔从“精确到毫米”改成“分成16个高度档”。文件会小很多，路线大致仍可判断；但悬崖附近的细节更容易失真。类比的边界是：真实量化不是简单给所有权重套同一把尺。工程上通常按一组权重分别保存缩放比例，有时还保存零点，并用校准数据或优化算法减少误差。

准确地说，量化是把高精度数值映射到有限离散等级，并保存把整数近似还原到计算尺度所需的参数。以对称量化为例，可近似写成q = round(w / scale)，推理时使用q × scale参与计算。bit越低，可表示的等级越少，存储更省，但舍入误差通常更大。

最小实践：先估再下载

下面的纯Python脚本估算权重本体和每组比例因子的容量。它不加载模型，因此不能替代真实峰值显存测试，但适合筛选硬件。

def estimate(params_b, bits, group_size=128, scale_bytes=2):
    params = params_b * 1_000_000_000
    weight_bytes = params * bits / 8
    groups = params / group_size
    scale_overhead = groups * scale_bytes
    total_gib = (weight_bytes + scale_overhead) / 1024**3
    return weight_bytes / 1024**3, scale_overhead / 1024**3, total_gib

for bits in (16, 8, 4):
    weight, scales, total = estimate(7, bits)
    print(f"7B {bits:>2}-bit: weight={weight:.2f} GiB, "
          f"scales={scales:.2f} GiB, total={total:.2f} GiB")

运行方法：保存为estimate_vram.py，执行python3 estimate_vram.py，无需安装依赖或配置密钥。本次已在本机Python 3实际运行：16、8、4 bit的权重本体分别为13.04、6.52、3.26 GiB，比例因子均约0.10 GiB，合计分别为13.14、6.62、3.36 GiB。

关键代码只有三步：参数量乘位宽得到权重字节；参数量除以group_size得到分组数；每组再加一个2字节比例因子。若格式还保存零点、填充或索引，实际文件会更大。模型加载后还要加KV Cache（键值缓存）、激活、工作区和框架开销。

四个常见误区

第一，4 bit不是整机显存除以四。它通常只描述权重；长上下文的KV Cache仍可能占据数GB。第二，文件能装进显存不代表能运行，后端必须支持对应打包格式和内核。第三，bit越低不总是越快；如果硬件需要频繁解包或回退到慢内核，延迟可能上升。第四，同为W4A16也不代表质量相同，分组大小、对称或非对称方案、校准集和算法都会影响误差。第五，模型参数量不等于文件里每一项都能量化，词表、归一化层、输出头或多模态编码器可能保留更高精度，某些格式还会做对齐填充。