量化到底省不省电：2023–2025 大模型推理能耗研究综述

原创

四王爷

发布于 2026-10-01 15:33:58

731

一句话版本：这是一个吵了三年的问题，答案从"省"变成了"取决于"——而"取决于什么"，恰好是 2025 年最有意思的进展。本文整理 2023–2025 年约 30 篇实证研究，试图把这场争论的边界画清楚。

0 · 为什么这个问题没有标准答案

如果你在过去两年里搜过"量化省电"，大概率见过两种针锋相对的说法：

一种是"量化显著省电"：有论文报告 4-bit 相对 FP16 最多省 79% 能耗，延迟降 69%；
另一种是"量化反而费电"：有实测显示 INT8 在某些卡上任务级能耗不降反升，惩罚最高超过 100%。

两边的论文都发在正规会议和期刊上，测量都做了，数据都给了。问题不在谁做错了，而在他们回答的根本不是同一个问题。

这篇文章按时间线梳理这三年文献，重点放在最有分歧的"量化能效"上，最后给出一个解释框架：为什么这些矛盾的结论其实可以共存。

1 · 2023 年：问题从"被忽视"变成"可测量"

2023 年之前，LLM 的能耗讨论几乎全部集中在训练侧。转折点是几篇奠基性工作：

工作	贡献
Samsi et al., From Words to Watts（IEEE HPEC 2023）	首批大规模实测 LLM 推理能耗：LLaMA 全尺寸 × V100/A100 两代 GPU，多节点分片到 32 卡。明确指出"推理能耗受到的关注远少于训练，尽管推理被调用的频率高得多"
Luccioni et al., BLOOM 176B 碳足迹（JMLR 2023）	首次系统核算单个 LLM 全生命周期碳排：仅动态功耗约 24.7 t CO₂eq，含设备制造达 50.5 t。并实测了 API 部署侧推理能耗
Chien et al.（HotCarbon 2023）	经典论断出处：ChatGPT 类服务的一年推理碳排可达初始训练的 25 倍——"推理才是长期主要成本"
Wright et al., Efficiency is Not Enough	批判视角：单纯提升效率会因 Jevons 悖论推高总消耗，提出 "Red AI vs Green AI" 判别
Henderson et al.（JMLR 2020，背景文献）	确立"必须报告测量边界"的方法论底线，2023 年后的工作大多引用它

2023 年沉淀的共识：推理能耗是独立、可测量的研究对象；FLOPs 与 TDP 估算不可信；测量边界必须写进每一个能耗声明。

第三条后来被证明是最重要的一条——它正是后面所有"矛盾结论"的钥匙。

2 · 2024–2025 年：系统级优化与碳感知推理

2024 年起，研究分化成两个方向。

2.1 把能效当一等目标的服务系统

工作	关键结论
Zhang et al.（Microsoft）	SLO 约束下刻画能效–延迟–吞吐三方权衡，指出旋钮效果依赖输入、模型与 SLO
DynamoLLM（IEEE HPCA 2025）	集群级联合设计，能耗作为一等优化目标而非事后指标
Kakolyris et al.	decode 是 memory-bound 阶段，峰值性能往往是浪费——SLO 感知的频率调节空间
Wilkins et al.（Cambridge, HotCarbon 2024）	基于负载（输入/输出 token 数）的能耗运行时模型，R²>0.96，profiling 框架开源
Nguyen et al.（Waterloo/Purdue）	同时建模运行碳与隐含碳（按芯片面积与内存），主张二者必须联合优化
EcoInfer（Electronics 2025）	基于 vLLM 的 iteration-level DVFS，最高省电 25.4%，SLO 达成率基本不变
Sánchez-Mompó et al.（Toshiba）	低利用率时，更大的模型未必更耗能——能效取决于规模、复杂度与请求处理能力的平衡

2.2 碳感知推理：把电网碳强度引入决策

这个方向的代表作是 Sprout（EMNLP 2024）：用"生成指令"引导简洁回答 + 线性规划碳感知优化器，真实电网数据下碳排降低超 40%，归一化质量保持 90% 以上。他们还提出了 "bigger is greener" 悖论：13B 配简洁指令比 7B 配默认指令更省碳也更准。

行业侧的佐证也出现了：Mistral AI 2025 年 7 月发布的生命周期环境影响报告显示，其旗舰模型训练+推理占全生命周期碳排的 85.5%——与 Chien 2023 年的 25× 论断形成独立印证。

另一篇值得注意的工作（arXiv:2511.05597）发现：小模型跑在 4×A100 上反而最费能（资源过配）；而 LLaMA 3.1 8B 在单张 L4 上因显存不足导致的开销，使量化带来的节能明显——双 L4 时节能幅度显著缩小。也就是说：量化收益在显存不构成瓶颈时，可能不值得其质量损失。

3 · 核心争论：量化到底省不省电

这是 2023–2025 年结论最不一致的一块。整体图景：早期共识偏向"省电"，2024 年后精细化研究开始反复报告"方法之间差异巨大，低精度不等于高效"。

3.1 报告"量化省电"的阵营

工作	平台	结论
Husom et al.（SINTEF，2025）	Raspberry Pi 4 + Joulescope 外部硬件测量（2 MHz），28 个 Ollama 量化模型	q3/q4 相对 FP16 最多省 79% 能耗；但极低比特反而引入低效
Jang et al.（J-KICS 2025）	Jetson Orin Nano，72 个量化变体、13 种配置	低比特模型大量依赖随机猜测；Qwen 2.5 精度/延迟更优但对量化更敏感
Martínez et al.（IJHPA 2025）	低功耗 CPU（ARM/RISC-V），自研整数混合精度 kernel	量化降低能耗且精度损失极小；定制融合 kernel 是关键
Saad-Falcon et al.（2025）	20+ 本地 LLM × 8 种加速器 × 100 万真实查询	FP16→FP4 可降能耗 3–3.5×，每降一档精度约损失 2.5 个百分点

3.2 报告"未必省电"的阵营

工作	关键发现
Rajput & Sharma（IEEE ICSA-C 2024）	对比 GPTQ / AWQ / GGML / GGUF / bitsandbytes：GGML/GGUF 最省能，各方法能耗画像差异显著，"挑战了低精度普遍提升效率的假设"
Waterloo 硕士论文（2025）	3 个模型 × 4 种卡 × 10 种 PTQ 策略：量化在输入足够长、输出足够短时能效最优；batch 增大时相对更省但增益有限；能耗几乎完全跟随运行时
Dai & Abdelfattah（2025）	本综述里解释力最强的一篇：对 AWQ、Marlin、Flute 三个 SOTA kernel 做功耗剖析，反量化占总 kernel 能耗的 30–45%，尽管墙钟加速接近理想 4×。核心论断："quantization makes inference faster and lighter in memory, but not 'free' in energy"。即使 Blackwell 引入 nvfp4，仍不支持混合精度乘法——每个 kernel 都必须先"缴反量化税"

3.3 他们真的矛盾吗？——四个变量的解剖

把结论相反的论文放在一起，差异集中在四个变量上：

变量	"省电"阵营	"费电"阵营
后端 / kernel 融合度	Ollama / llama.cpp GGUF、自研融合 kernel、AWQ/Marlin	bitsandbytes LLM.int8() 等未融合反量化的实现
测量边界	整机墙插（外部仪器）或板级	GPU package power（NVML）
工作负载	低并发端侧推理 / 微基准	全程单流 decode
模型规模	1B–3.5B 或不适用	0.5B–14B，覆盖能耗交叉点区间

结论：这些工作并不真正矛盾。 而其中最关键的一个变量——反量化开销能否被融合 kernel 摊销——恰好是 Abdelfattah Lab 用硬件级剖析给出的机制解释。

举个具体的例子：同样是 INT8，llama.cpp 的 GGUF 实现把反量化融进了主 kernel，税缴得少；而 bitsandbytes 的 LLM.int8() 走独立的混合精度分解路径，税缴全额。格式相同、kernel 不同，能耗符号可以相反。

还有一条容易被忽略的口径细节：有些论文报告"4× 收益"时的比较基准是 FP32 而非 FP16——如果换算成业界常用的 FP16 基线，收益会显著缩水。读这类论文时，先找它的 baseline 是什么。

4 · 方法学：估算陷阱与测量边界

如果说结论分歧是"表"，测量方法学的分歧就是"里"。

工作	贡献
MLPerf Power（MLCommons，2024）	官方墙插级 AC 功率认证路径。明确指出只有整墙功率是其测量与验证对象，任何 TDP 引用都不被认可。数据点参考：Llama2-70B 达 111.4 J/sample
MLPerf Client v2.0	引入 tokens/Joule 路径：Yokogawa 功率分析仪 + SPEC PTDaemon + 第二台主机。注意：其评测的所有出厂模型均已量化，因此无法回答"量化本身花了多少能耗"
BUTTER-E 数据集（2024）	63,527 次训练运行的节点级瓦特计数据。发现能耗与网络设计之间存在硬件中介的非线性关系，挑战"减参数/减 FLOPs 就是提升能效"的直觉
Yang et al.（2024）	1,200 个模型 × 6 数据集：基于 FLOPs 与 TDP 的朴素估算平均低估实际能耗 3.13 倍，极端情况接近 40 倍；PyTorch → TensorRT 平均降 4× 能耗

3.13 倍低估这个数字值得每个做容量规划的人记住：你拿纸面 TDP 乘以时长算出来的"能耗预算"，可能只有真实值的三分之一。

5 · 三年沉淀下来的共识与未决问题

已形成共识的五条

推理已超过训练成为主要能耗来源——多项研究给出 60–90% 的生命周期占比，Chien 的 25× 与 Mistral 的 85.5% 是两个独立印证；
FLOPs/TDP 估算不可信，必须实测——3.13× 低估是标志性证据；
能耗近似跟随运行时/吞吐——两个独立团队从不同方向得到同一结论。这意味着延迟优化在实践中是能效的可靠代理；
融合度决定量化能效的符号——2025 年最重要的机制性进展，直接解释了同一格式在不同实现上表现完全相反的现象；
资源过配是能耗反模式——4×A100 跑小模型比单 H100 费能得多。

尚未解决的六条

跨后端受控对比稀缺——没有任何一项工作在同一卡、同一 session、同一模型上系统对比 Marlin / AWQ / llama.cpp / bitsandbytes NF4 / GPTQ 的能耗；
batch > 1 与连续批处理下的量化能效——几乎无人测量，而这恰恰是单流结论能否外推到生产 serving 的关键；
测量窗口标准化——模型加载、量化、warm-up、decode 四个阶段的能耗归属，不同论文口径不一，跨论文的"省了多少"往往不可比。重积分同一 session 的数据可使结果移动 12.5 个百分点，量级不可忽略；
热状态几乎无人报告——GPU 降频对能耗的影响是系统性的，但极少有论文记录起始温度与稳态温度；
软件栈版本作为实验因子——几乎没有论文锁定并报告完整依赖栈，而交叉点位置可能随栈版本漂移（同一硬件、不同库版本，交叉点位置可以移动数个 B）。这是一个被系统性低估的变量；
硬件能量计数器 vs 功率轨迹积分——有报告显示两者读数可差 14.9%。哪个更准、该用哪个，目前没有共识。

这六条里，任何一条都是潜在的论文选题。

6 · 给工程师的五条实用结论

如果只带走五句话：

别用 TDP × 时长做能耗预算——平均低估 3 倍起，用 NVML/RAPL 实测或墙插功率计；
选量化方案先看 kernel 融合度——llama.cpp GGUF 类融合实现的"反量化税"远低于未融合路径；同格式不同实现，能耗符号可以相反；
你的场景大概率在文献盲区——batch>1、生产 serving 栈下的量化能效，目前数据极少，重要决策建议自测（协议：同 session FP16 基线 + NVML 采样 + n≥3 次重复）；
报告能耗时写清三件事——测量边界（GPU package 还是整机墙电）、软件栈版本、重复次数与 CV。缺任何一样，你的数字对别人就不可比；
延迟优化约等于能效优化——两者高度相关，实践中可以用延迟指标做能效的代理，成本更低。

7 · 结语

回到开头的问题："量化到底省不省电？"

三年文献给出的答案是一个函数而非一个常数：f(kernel 融合度, 测量边界, 负载形态, 模型规模)。四个变量里任何一个变了，结论都可能翻转。

这不是坏消息。恰恰相反——它意味着"我的栈上、我的负载下、量化到底花多少电"仍然是一个必须实测、无法外包给论文的问题。而三年前，我们连"这个问题需要实测"都还没有共识。

文中提到的文献我都有原始链接（评论区留言可取）

观点归纳如有偏差，以原文为准。如果你也在做同类测量，欢迎在评论区交换数据——尤其是 batch>1 场景，这个盲区比什么都缺数据。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

kernel

nvm

WorkBuddy开发者分享季

gpu