量化 LLM 推理真的省电吗？我在五张 GPU、四代架构上直接测了测

做 LLM 部署的人大多有个默认假设：量化降低了显存占用和内存带宽压力，所以推理更省电。这个假设在论文和工程实践里被反复引用，但真正直接测过的很少——大部分"量化省电"的结论，要么是拿 FLOPs 或 TDP 估算的，要么测的是整机功耗而非 GPU 本身。

我用 NVML 接口做了一轮受控测量，把结果整理成了这篇短文。先说结论：量化是否省电，取决于一张卡、一个软件栈、一个模型规模的具体组合，不取决于位宽本身。

怎么测的

• 指标：生成窗口内 GPU package 能耗（10Hz 采样 NVML 功率积分），按每个生成 token 归一化。模型加载、量化过程、预热全部排除在窗口外。
• 对比：FP16 基线 vs bitsandbytes NF4（weight-only 4-bit）vs LLM.int8()（混合精度 8-bit），batch size 1，同一 session 内配对测试，另加一组 llama.cpp GGUF（Q4_0）对比。
• 硬件：五张 NVIDIA 卡，覆盖 Turing、Ada、Ampere、Blackwell 四代架构，模型从 0.5B 到 14B。

发现一：测量窗口本身就是个变量

同一份 100Hz 功率轨迹，用三种不同的窗口定义重新积分，64-token 的能耗数字能差出 12.5 个百分点；换成 576-token 输出，差异缩到 2 个点以内。

这意味着：凡是看到"量化省电 X%"的结论，先看它测的是什么窗口、输出多长。预热算不算、加载算不算、输出 token 数是多少，这些口径不动，跨论文比较基本没有意义。

发现二：NF4 的节能符号会翻转

这是最有意思的结果。NF4 相对 FP16 的能耗差异，符号随模型规模和平台变化：

• 在 Ada 卡上，0.5B–3.0B 的小模型区间，NF4 更费电，最多 +56%；
• 在 Turing 和 Blackwell 卡上，7B 模型 NF4 反而省电；
• 在一张 Blackwell 卡上，我用实测点把"翻转点"夹在了 3.0B–7.0B 之间；同一张卡升级一次软件栈之后，翻转点移到了 0.5B–3.0B 之内——位移幅度是该 session 重启一致性差异的二十倍。

换句话说，"这张卡量化省电"这句话，可能过一次驱动/框架升级就不成立了。能耗交叉点是卡 + 软件栈的属性，不是硅片的属性。

发现三：LLM.int8() 没有一个配置省电

在我测的所有配置里，LLM.int8() 相对 FP16 全部是更耗电的：RTX 4090 上 +106% 到 +581%，A800 上 +107% 到 +131%。

机制上值得注意的是：功率没有明显上升，是 decode 吞吐崩了——单位时间产出的 token 变少，同样多的 token 要烧更长时间的电。混合精度路径的额外开销吃掉了量化省下的带宽收益。

（这个现象和 kernel 级分析的结论能对上：bitsandbytes 的反量化路径融合度不高，dequant 开销在 kernel 能耗里占比可观。换成 kernel 融合好的推理后端，画风完全不同——我测的 llama.cpp Q4_0 相对 FP16 省了 62–63%。）

对实际部署的启示

1. 别假设，去测。 你那张卡 + 那个框架版本 + 你部署的那个模型规模，能耗符号可能和任何论文说的都不一样。
2. 升级软件栈之后，重新测。 我的数据里，一次栈升级移动能耗交叉点的幅度，远超测量噪声。
3. 选量化方案时看后端，不只看位宽。 同样是 4-bit，kernel 融合差的实现可能比 FP16 还费电；融合好的（GGUF 这类）才有稳定收益。
4. 汇报能耗时把口径写全：测量窗口、输出长度、排除项。否则数字没法比。

我把这个关系总结成一个公式：∆E = f(N, B, H, Q, R, M)——模型规模、batch、硬件、量化格式、运行时（软件栈）、测量方法，六个变量，缺一个都可能在换环境后翻车。

全部测量数据、生成每张表的脚本、以及跑实验用的容器都已开源（EcoCompute 项目，GitHub 搜 hongping-zh 可找到），原始功率轨迹也在内，有兴趣可以拿自己的卡复测一遍——特别是 Blackwell 之后的卡，我很想看看这个结论的边界在哪。

有不同测量结果的朋友，欢迎评论区交流。