第 6 章 量化：先救容量，不必然救延迟

只有一张 24GB 的卡

第 2 章算过：24GB 卡配 7B、8K、FP16，只能并 1 条。二十个同事，一个在跑，十九个在等。

换卡是最直接的答案，但假设现在只有这张卡。

两个能压的地方：权重、缓存。它们不是一回事，压其中一个不会顺带压另一个。

权重先压：13 GiB 变成 3.25

FP16 每参数 2 字节，7B 是 13 GiB。INT8 每参数 1 字节，6.5 GiB。INT4 每参数半字节，3.25 GiB。

账立刻变了：

22 可用 − 3.25 权重 − 3 余量 = 15.75 GiB
15.75 / 4（每条 8K 缓存） = 3 条

从 1 条到 3 条。这是权重量化单独能做到的。

再把缓存也压到 INT8，每条从 4 GiB 变成 2 GiB：

15.75 / 2 = 7 条

从 1 条到 7 条，这才是把这张卡用起来。

注意两个数是分开放的：只压权重是 3 条，只压缓存是 3 条（22−13−3=6，6/2=3），两个都压才是 7 条。只做一半，效果就是一半。

延迟不一定跟着变好

decode 每步读 13 GiB 权重，这是它慢的原因。压到 3.25 GiB，理论上每字从 8.3 毫秒降到 2 毫秒出头，四倍。

实际通常只有两到三倍，三个原因。

反量化要算。权重存成 INT4，搬进计算单元之后还得变回 FP16 才能做矩阵乘，这一步是额外运算。

低比特的矩阵乘未必快。GPU 的强项是高精度矩阵运算，INT4 的加速只在特定硬件和特定算子上成立。

prefill 可能变慢。prefill 是算力瓶颈，量化带来的反量化开销在这里是纯亏，长 prompt 的首字反而更差。

所以量化的收益要先问一句：这张卡现在是容量不够，还是带宽不够？容量不够，量化直接赢；带宽不够，量化小赢；算力不够，量化可能输。

精度：越靠近缓存越敏感

权重量化到 INT8，多数模型几乎无损。INT4 就必须要校准：拿一批代表性文本跑一遍，找出哪些通道更重要，权重大的通道少压一点。GPTQ、AWQ 都是这类做法，差别在怎么挑。

缓存量化更敏感。缓存里存的是运行时算出来的值，分布比权重野，少数通道的数值特别大，一刀切会把它们削平。SmoothQuant 这类工作就是把这种不均匀先摊平再量化。

实践上的顺序是：先权重 INT8，观察质量；再 INT4，重点看你的任务；缓存量化放最后，因为它的风险最高、排查最难。

评估不能只看困惑度。代码、数学、长链推理对量化最敏感，通用问答反而不容易看出来。

什么时候别压

容量本来就够，压了只是给精度添风险。

任务对细节极度敏感，比如逐字引用合同条款。

你的卡支持 FP8，那优先用 FP8，不必一步跨到 INT4。

还有一个容易忽略的前提：量化模型要有人替你做好并验证过。自己从头校准一个 INT4，成本比换一张卡高。

经验：先定目标，再选比特

量化之前把目标写成一句话："我要在 24GB 上并 5 条 8K。"

然后算：权重压到几比特、缓存压到几比特，才够 5 条。只压够用的那部分，不要顺手全压。

目标不清就压，最后得到的是一个精度下降、并发也没达到预期的版本。