


## 为什么再写一篇

「GPU 能耗测量入门」系列写到今天，已经聊过怎么读瓦特、怎么设计测量协议、crossover 曲线怎么读、为什么把结论拆成六个可引用的工件。但有朋友反映：单篇都看得懂，拼起来不知道全貌——这个项目到底长什么样，我能从哪里进来？
这篇文章就是那张地图。顺便交代一下这一年发生了什么：一个单人项目，怎么从一条反直觉的功耗曲线，走到被 HuggingFace 官方文档引用、被 MLCommons 邀请讨论、被 torchao 维护者独立复现。
## 两分钟版：我们到底测出了什么

一句话：**量化省不省电，取决于模型规模 × 硬件 × 软件栈的组合，而且这个"交叉点"会漂移。**
NF4（4-bit）相对 FP16 的每 token 能耗交叉点，在四代架构上的实测位置：

| | | |
|:-:|:-:|:-:|
|GPU 架构|交叉点（旧栈）|同卡换新栈后|
|Turing（T4）|~2.1B|—|
|Ampere（A800）|测量范围内无|—|
|Ada（RTX 4090）|~3.7B|—|
|Blackwell（RTX 5090）|≈4.8B|**≈1.8B**（bitsandbytes 0.50.2，跨重启 A/B 双轮；1.1–1.5B 实测点仍为正值，7B 处已到 −32%）|
三条对部署最有用的结论：
1. **交叉点以下，量化是净亏的**：Blackwell 小模型上 NF4 多耗 12–29% 的能量。省显存，不省电。

1. **INT8 有个隐藏陷阱，也有解法**：`load_in_8bit=True` 默认配置比 FP16 多耗 17–147%；但把 `llm_int8_threshold=0.0` 设上，吞吐恢复 +79%、能耗反降 36%。一行参数的事，前提是你要知道。

1. **能耗符号是"卡 + 栈"的属性，不是硅片的属性**：同一张 RTX 5090，一次软件栈升级把交叉点从 ≈4.8B 挪到 ≈1.8B，位移幅度是跨重启一致性差异的二十倍。升级驱动/框架之后，昨天的能耗结论今天要重新测。

FP8 我们在 RTX 5090 上单独做了深测（A/B 双轮 + torchao 0.18 稳定版复现，两个代码路径分开刻画）：weight-only 路径的能耗惩罚随模型尺寸**上升**（+187% → +816%），dynamic-activation 路径反而随尺寸**下降**（+323% → +82%）。同一个"FP8"三个字母，底下是两条完全不同的能耗曲线。
全部数据 360+ 配置、四代架构、n=2、变异系数 < 2%，CC BY 4.0 开放在 Zenodo：主数据集 `10.5281/zenodo.19647290`（v1.1.0）、RTX 4090 深测 `10.5281/zenodo.22037483`、RTX 5090 深测 `10.5281/zenodo.22855133`。引用哪张卡上的结论，就引哪一份，三者不可互换。
## 生态四件套：四种门槛，随你选

这个项目现在有三个入口，按上手成本从低到高排：
** 查表（0 门槛）**：打开 [quantenergy.tech](https://quantenergy.tech)，选 GPU、输入模型大小，直接看量化建议。每个数字都标注了 measured / interpolated / extrapolated——是外推的我会明说这是外推。
**
** 跑容器（有 GPU 就行）**：[ecocompute-mlcube](https://github.com/hongping-zh/ecocompute-mlcube) 是一个 MLCube 格式的测量容器——NVML 10Hz 采样、冷却期、随机化、分相统计，协议要求的坑都内置了。在你自己的卡上跑一遍，输出的报告和数据集同 schema，可以直接提 issue 变成数据集的一个新点。
** CI 里自动盯（团队适用）**：[ecocompute-action](https://github.com/hongping-zh/hongping-zh-ecocompute-action) 在 CI 里 lint 大模型推理任务的能耗浪费——同一个思路，从"事后测"提前到"合并前拦"。
另外还有一个 Accuracy × Cost × Carbon 的交互式面板（[hongping-zh.github.io](https://hongping-zh.github.io/)），把精度、成本、碳排放在一张图里比。
## 这一年，被认真对待的三个瞬间

单人项目最难的不是测量，是被听见。回头看，有三个瞬间让我确认"这条路是对的"：
**HuggingFace Optimum 把我们的量化能耗发现写进了官方文档**（[optimum PR #2410](https://github.com/huggingface/optimum/pull/2410)）——不是引用论文，是写进文档给用户看的那种。
**MLCommons 邀请讨论量化能耗指标怎么进 MLPerf Inference**（[inference #2558](https://github.com/mlcommons/inference/issues/2558)）。能耗指标要不要进基准、以什么口径进，这是整个行业正在补的课。
**torchao 维护者独立确认了我们报告的 RTX 5090 FP8 能耗异常**（[ao #4094](https://github.com/pytorch/ao/issues/4094)），我们随后在稳定版 0.18 上完成了复现和双路径刻画。一个社区报的异常，走完了"报告 → 维护者确认 → 稳定版复现 → 根因分层"的全流程。
顺带一提，这个项目也往上游提过 PR：bitsandbytes #1882、transformers #44407。测别人的库测出问题，最好的谢礼是把修丁也递过去。
## 比引用更珍贵的：三份来自陌生人的贡献

但说实话，比被官方引用更让我踏实的，是三份来自陌生人的贡献：
**@gkgoing 完成了第一次完全独立的复现**（2026 年 8 月，[提交在此](https://github.com/hongping-zh/ecocompute-mlcube/issues/15)）：TinyLlama-1.1B，NF4，一张 RTX 3050 Ti 笔记本卡。结果非常有意思——**困惑度和我们 RTX 4090 上的测量对到了小数点后四位，能耗没有对上。**
这个反差，恰恰是这个项目存在的理由：精度是模型的属性，搬到哪张卡都跟着走；能耗是"卡 + 栈"的属性，换个环境就要重新测。一次复现，比我写十篇文章更能说明这件事。
**@amarjithkumar2007-wq** 给容器加了 AMD GPU（ROCm）的检测与回退（PR #20），让测量路径在 A 卡上也能走通（PR #22），后来又以"没有 A 卡、mock 先行"的方式补上了 ROCm 功耗采样器（PR #31）——他现在是容器 Zenodo 软件记录的共同作者。**@yesheng-oss** 写了后端贡献指南（PR #21）——怎么把 llama.cpp、vLLM、TensorRT-LLM 接进来当推理引擎。
## 你能怎么参与

- **跑一遍容器**：[ecocompute-mlcube](https://github.com/hongping-zh/ecocompute-mlcube)。你的 GPU + 模型 + 精度组合，很可能正好补上数据集里的一个空格——一次独立复现是单人项目能收到的最贵重的礼物。

- **提交一个测量点**：[贡献指南](https://github.com/hongping-zh/ecocompute-mlcube/blob/main/CONTRIBUTING.md)，CC BY 4.0 进数据集。



- **设计伙伴**：想做碳感知 CI/CD 的团队，欢迎聊。

系列写到这里，地图应该齐了。接下来项目自己也会继续往前走：arXiv 预印本、VS Code 实时能耗 lint 插件、企业试点。有不同测量结果的朋友——尤其是 Blackwell 之后的卡——评论区见，我特别想知道这个结论的边界在哪。
## 本系列其他文章

- [写给非硬件背景开发者的 GPU 功耗测量入门](https://cloud.tencent.com/developer/article/2767851)

- [从一次测量到一组可信数据：测量协议设计入门](https://cloud.tencent.com/developer/article/2768621)

- [小模型量化反常识：为什么 4-bit 推理可能更费电？](https://cloud.tencent.com/developer/article/2740195)

- [一张图读懂：量化到底什么时候省电](https://cloud.tencent.com/developer/article/2744777)

- [量化 LLM 推理真的省电吗？我在五张 GPU、四代架构上直接测了测](https://cloud.tencent.com/developer/article/2753511)

- [量化的 LLM 不一定省电：我把结论拆成了六个可单独引用的工件](https://cloud.tencent.com/developer/article/2753111)

- [LLM 量化到底省不省电？我造了一个实测专家替你算](https://cloud.tencent.com/developer/article/2739220)


----


「GPU 能耗测量入门」系列写到今天，已经聊过怎么读瓦特、怎么设计测量协议、crossover 曲线怎么读、为什么把结论拆成六个可引用的工件。但有朋友反映：单篇都看得懂，拼起来不知道全貌——这个项目到底长什么样，我能从哪里进来？这篇文章就是那张地图。顺便交代一下这一年发生了什么：一个单人项目，怎么从一条反直觉的功耗曲线，走到被 HuggingFace 官方文档引用、被 MLCommons 邀请讨论、被 torchao 维护者独立复现。

# 别假设，去测：一个单人 LLM 能耗实测项目的这一年

GPU 能耗测量入门」系列写到今天，已经聊过怎么读瓦特、怎么设计测量协议、crossover 曲线怎么读、为什么把结论拆成六个可引用的工件。但有朋友反映：单篇都看得懂，拼起来不知道全貌——这个项目到底长什么样，我能从哪里进来？
这篇文章就是那张地图。顺便交代一下这一年发生了什么：一个单人项目，怎么从一条反直觉的功耗曲线，走到被 HuggingFace 官方文档引用、被 MLCommons 邀请讨论

人工智能

运维

测试

量化省不省电取决于模型规模×硬件×软件栈组合，交叉点会漂移。NF4相对FP16在Turing至Blackwell四代架构实测：T4约2.1B、Ada约3.7B、RTX5090从≈4.8B新栈移至≈1.8B。INT8默认配置多耗17-147%，设llm_int8_threshold=0.0可反降36%。360+配置、四代架构数据CCBY4.0开放。提供查表、MCP、MLCube容器、CI四入口。

大模型推理

容器

GitHub

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

量化省不省电取决于模型规模×硬件×软件栈组合，交叉点会漂移。NF4相对FP16在Turing至Blackwell四代架构实测：T4约2.1B、Ada约3.7B、RTX5090从≈4.8B新栈移至≈1.8B。INT8默认配置多耗17-147%，设llm_int8_threshold=0.0可反降36%。360+配置、四代...

# 别假设，去测：一个单人 LLM 能耗实测项目的这一年-腾讯云开发者社区-腾讯云

# 别假设，去测：一个单人 LLM 能耗实测项目的这一年

# 别假设，去测：一个单人 LLM 能耗实测项目的这一年

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐