4bit 量化省下 11GB 显存，账单只降了 34%：一次量化的成本账

引言

上个季度我们把一套 7B 的文档抽取服务从 FP16 迁到 4bit。这套服务每天处理约 3000 条工单抽取，跑在按小时计费的独占实例上，账单只有两块：机器费加人工复核。动机很朴素——一台 24GB 的卡扛不住 32K 上下文的并发，扩容要真金白银，而预算批不下来。迁完显存从 24GB 压到 13GB，单卡吞吐从 42 tok/s 涨到 78 tok/s，机器小时单价从 3.2 元掉到 1.7 元。

所有人都以为这事结了，直到财务把月度账单发过来：总成本只降了 34%。省下 11GB 显存，没换来 47% 的降本。中间那十几个点去哪了，值得按钱和时间两本账摊开算一次。

一、11GB 里有多少是白省的

• 7B 参数在 FP16 下权重约 14GB，换成 4bit 后约 4GB，账面砍掉 10GB 出头。这是所有人算量化收益时唯一算对的一项，也是最容易被当成全部的一项。
• 注意力激活、KV cache、CUDA context 和框架常驻内存不会跟着变成 4bit。32K 上下文、batch 8 的配置下，KV cache 稳定吃掉 6 到 7GB，权重腾出来的空间有一半被它吃了回去；batch 再往上加，这个比例还要涨。
• 于是 24GB 的卡实际可分配余量不到标称的一半，扩容从非做不可降级为再撑一个季度。对业务方来说是好事，对成本表来说这只是把支出挪到了下个季度，不是消失。
• 量化压缩的是权重，不是上下文。上下文越长，4bit 的边际收益越薄。 我们真正缺的那部分并发能力，一个 token 都没多出来。

二、三种 4bit 方案，分水岭不在算法而在校准

• AWQ 按激活分布挑显著通道，配合 per-channel scale，对票据号、金额这类长尾字段最稳；代价是上线前必须准备一批真实校准样本，多一道工序。
• GPTQ 逐层做误差补偿，收敛快、生态成熟、现成脚本多，但对校准集规模相当敏感。同一套评测，128 条校准时字段抽取准确率 88.4%，补到 512 条回到 89.6%，差的这 1.2 个点几乎全落在长尾字段上。
• bitsandbytes NF4 免校准，改一行配置就能跑，验证阶段最省事；进了正式环境它的输出格式崩坏率明显更高，准确率停在 86.7%，我们最终只把它留在离线实验里。免校准省下的是准备样本的时间，不是长期的维护成本。
• 同一批 3000 条工单，FP16 基线 91.3%，AWQ 配 512 条校准 90.1%，GPTQ 配 512 条 89.6%，NF4 86.7%。差 4.6 个点，落到人工复核上就是每天多 40 条。校准集的边际收益掉得很快：128 条到 512 条值 1.2 个点，512 条到 1024 条只值 0.3 个点，512 是这套业务的经验拐点。

三、per-channel scale 与那个 19% 的重跑率

• 第一批上线用的是 per-tensor 量化。某个高频模板的激活值有极端 outlier，scale 被单点拉爆，其余通道全被压进低位宽，输出开始出现半截 JSON、重复字段和错位括号，解析器直接抛异常。那次故障只回滚了 3 个批次，但排查花掉两个人各一天。
• 换成 per-channel scale 后大部分塌陷消失，但仍有三个通道反复溢出，最后把这几个通道单独留在 FP16，权重多占 0.2GB。per-channel scale 修的是溢出，不是稳定性，把异常通道摘出来保精度，是这套方案里性价比最高的一步。
• 精度回来了，代价是夜间批量任务的重跑率从 4% 涨到 19%。不是准确率掉了，是偶发溢出触发解析失败后整批回滚——一个批次里只要有一条崩，整批就得重来。
• 这一项在模型指标上完全看不见，在账单上看得清清楚楚：夜里多跑的那批算力，把白天省下的机器费吃掉一截，而且没人会在周报里写它。回滚的成本按批次算、不按条算，这是重跑率被放大的原因。

四、钱和时间，两本账分开算

• 钱：单卡小时价 3.2 元降到 1.7 元，按 720 小时每月算，一台机器月省 1080 元；但重跑率从 4% 到 19%，夜间批处理多耗约 15% 算力，实际的机器费降幅只剩三成出头。
• 时间：吞吐 42 到 78 tok/s，单条 2K 输出的抽取从 48 秒压到 26 秒。省下的这 22 秒给不了公司利润，但给得了值班同事一个不用盯着进度条的下班时间，体感改善比账单改善明显得多。在以人机协同为主的场景里，这类收益折算不成钱，但是它真实存在。
• 质量：准确率从 91.3% 降到 90.1%，复核量随之上升。把复核工时按 0.8 元一条折算，正好吃掉省下来那部分的四成。这笔钱进的是人力账，不进云账单，最容易漏。
• 三项相抵，综合净省 34%。这个数字比显存减半、成本减半那类说法难看得多，但它对得上财务的账。

小结

• 量化不是一键降本的开关，是把显存预算重新分配：权重让出的空间，被 KV cache 和更大的 batch 立刻花掉，账面上看不见，运行时一分不少。
• 选方案先看手里有没有 512 条真实校准样本。有就上 AWQ 或 GPTQ，没有就先用 NF4 把链路跑通，别把免校准当成免维护。挑样本时按业务模板分层抽样，比随机抓 512 条更管用。
• 长上下文业务要单独算 KV cache 的账。KV cache 不量化，4bit 的收益会一直打折，必要时先上 KV 量化再谈权重位宽。
• 如果重算一次，我会先做 KV cache 量化评估，再决定权重压到几位。顺序反了，省下的是显存，付出去的是重跑。