本文是 [ecocompute-mlcube](https://github.com/hongping-zh/ecocompute-mlcube) 能耗测量系列的实战篇。我们此前的测量协议（[EcoCompute Protocol v1.1](https://doi.org/10.5281/zenodo.22958675)）里一直写着一条原则："冷态和稳态是两种不同的测量，只在同一模式内比较，不要跨模式比。"——这条原则挂了很久，但它一直没有**自己的数字**。这次实验就是给它补上那个数字。
## 一、问题：能耗比较到底在比什么

做 GPU 能耗基准测试的人都有一个默契：跑之前先 warm up。CUDA kernel 首次编译、显存分配、频率爬升，都会让前几轮数据虚高——warmup 之后测，天经地义。
但这个默契里藏着一个没被量化过的假设：**warmup 之后，卡的热状态就"稳定"了，不同批次之间的热状态差异可以忽略**。
真的可以忽略吗？温度对芯片功耗的影响在体系结构层面是老常识（漏电流随温度上升、热节流降频），但"老常识"在具体工况下值几个百分点，很少有人给过受控条件下的实测数。而对能耗基准来说，几个百分点恰恰是要害——我们平时在论文和技术报告里争论的量化节能幅度，很多时候也就 8%–35% 的量级。**如果热状态本身就能贡献 4%，那一个不披露热状态的能耗对比，误差预算就已经用掉一小半了。**
所以问题收敛成一个可测的命题：同卡、同模型、同软件栈，只变热状态，每 token 能耗差多少？
## 二、实验设计：六臂对照，外加一支"外部温度计"

在一台租用的 RTX 4090 实例上（AutoDL，驱动 580.105.08），用测量容器跑 TinyLlama-1.1B（NF4 量化，batch 1，greedy 解码，每次 10 轮 × 256 token 生成，进程内 10 Hz 直读 NVML 功率，梯形积分）。设计很简单，六臂：

| | | | |
|:-:|:-:|:-:|:-:|
|组|臂数|起跑条件|warmup|
|**cold**|3|等温度回到 37–39 °C 基线再起跑|0（就是要测冷启动）|
|**steady**|3|warmup 120 轮把卡推到稳态平台|120|
关键设计有两个，都值得展开：
**外部温度日志。** 工具自己报告的 `temperature_start_c` 是**起跑瞬间的单点读数**，而测量过程中卡会持续升温、负载尖峰会冲出测量段边界。所以全程另挂了一个独立的 `nvidia-smi` 5 秒间隔日志（温度、功率、SM 频率三列），作为整场实验的"外部权威温度计"——工具的瞬时读数用来交叉验证，外部连续日志用来判定冷却是否充分、稳态是否真的稳。
**冷却纪律要写成硬标准，不能凭感觉。** "等卡凉下来"不是标准。我们定的判定是：起跑温度回到基线值（本场实验为 37 °C）± 2 °C 以内，或连续 3 分钟不再下降。下一节你会看到这条硬标准救了数据集一次。
顺带一个工程细节：steady 臂的 warmup 是 120 轮真实生成，实测约 12–13 分钟才把卡推到平台；外部日志显示 steady-2 臂连续 7 分钟温度 min=max=54 °C——这是教科书级的稳态证据。**"稳态"不是"跑了一会儿"，是有数字背书的平台。**
## 三、结果：+4.1%，而且梯度单调

六臂数据（全部 `source=direct-nvml`，实测采样率 9.9–10.0 Hz，零丢样）：

| | | |
|:-:|:-:|:-:|
|臂|每 token 能耗 (mJ)|温度轨迹|
|cold-1|2042.4|37 → 46 °C|
|cold-2|2005.5|38 → 47 °C|
|cold-3|2053.6|39 → 48 °C|
|steady-1|2091.0|38 → 54 °C（warmup 后）|
|steady-2|2153.9|52 → 54 °C|
|steady-3|2105.0|53 → 53 °C|
- **cold 组：2033.8 ± 25.2 mJ/token（CV 1.2%）**

- **steady 组：2116.3 ± 33.0 mJ/token（CV 1.6%）**

- **Δ(steady vs cold) = +4.1%**

更有说服力的是梯度单调：37–39 °C 起跑 ≈ 2034，47 °C 起跑 ≈ 2070（下一节会讲这个 47 从哪来），53–54 °C 稳态 ≈ 2116——**每高约 10 °C，每 token 能耗多 3–4%**，中间没有拐点，方向自洽（漏电流与热节流的合力）。
另一个对实践者有用的量级感：batch 1 单流生成下，4090 的平均功率约 85 W，其中待机底噪就有约 24 W——近 30% 的功率跟"算什么"无关，纯粹是卡开着。这就是为什么小模型单流的每 token 能耗高得反直觉：闲置功率主导，量化 kernel 的 dequant 开销摊不平。
## 四、被扔掉的那一臂：数据最危险的时刻，是它看起来还漂亮的时候

cold-3 第一次跑的时候，起跑温度是 47 °C——上一臂刚结束没几分钟，冷却不充分。看数值：2069.9 mJ/token，组内 CV 1.6%，**漂得很**。如果只看数值一致性，这一臂毫无问题。
但它违反了起跑温度标准（47 °C vs 基线 37 °C，超了 10 °C），判定为"不冷"——废弃重跑。判定标准里数值一致性和起跑温度是 **AND 关系**，不是 OR：一条红线不过就整臂作废。
这件事的教训值得写下来：**违规数据最擅长的伪装，就是数值漂亮**。47 °C 那一臂恰好落在冷热两组中间，如果混进 cold 组，会把组均值抬高约 2%，而且 CV 几乎不变——没有任何统计信号会报警。温度标准必须硬执行，因为数据自己不会坦白。
同一场实验里还有一次更隐蔽的事故：一个 pip 安装把 bitsandbytes 从 0.50.2 静默降回 lock 钉的 0.43.3，而这个版本在 CUDA 13 的 torch 下缺二进制——工具没有报错，而是**静默降级**为引用已发布数据集的参考值，照样写出一份 schema 合法的 JSON。发现它靠的不是运气，是跑批后逐份检查 `measurement_source` 字段：真测量的报告写 `direct-nvml`，fallback 写 `ecocompute-dataset`。**跑批脚本必须打印 source，"文件存在 + schema 合法"不等于"数据是真的"。**
## 五、意外的第三发现：cold-start 是协议的盲区

实验收尾时，用自家协议校验器（Protocol v1.1 core profile）跑了六份报告：
- steady 臂：回填热学字段后 **0 违规，protocol-conformant**；

- cold 臂：**恰好剩 1 条违规**——§4.3.4 "warm-up MUST precede measurement"。

这条违规我们**故意保留，不修**。因为 cold 臂的设计就是 warmup=0（测冷启动），而协议假定测量前必有 warmup——也就是说，**cold-start 场景在现行协议下没有合法的表达路径**。可真实世界的 serverless 推理、首次查询、冷启动容器，恰恰就是无 warmup 的工况。一个只给稳态测量发通行证的协议，等于给半个真实世界开了白名单。
这条"违规"连同 +4.1% 的数字，现在都进了 [MLCommons 的能耗指标讨论线程](https://github.com/mlcommons/inference/issues/2558)，作为"热状态必须是能耗报告强制字段"的实证论据。
还有一处诚实披露要交代：实验用的 bitsandbytes 是 0.50.2，不是容器锁定的 0.43.3（CUDA 13 内核可用性问题），每份报告都带 `differs_from_reference_pins` 标记；工具对三个热学字段（稳态温度、冷却秒数等）输出 null，这些值是从外部温度日志**事后回填**的，回填版旁边保留了工具原始输出的 `*.orig.json`——原始产物一个字节没动。这台 4090 也和主研究的 4090D 不是同一张物理卡，所以**绝对值不并入已发布曲线，本实验的发现是"温差的大小"，不是绝对能耗**。
## 六、给实践者的四条温度纪律

把这次实验的全部教训压缩成四条可执行的纪律：
1. **能耗声明必须随附热状态。** 起跑温度、结束温度、warmup 轮数、冷却时长——没有这些字段的每 token 能耗数，在几个百分点的精度上是不可比的。

1. **只在同一模式内比较。** 冷态和冷态比，稳态和稳态比。跨模式比较等于把 4% 的系统偏差混进结论。

1. **外挂一支独立温度计。** `nvidia-smi --query-gpu=temperature.gpu,power.draw,clocks.sm --format=csv -l 5` 后台挂全程，几 KB 的日志，换来的是"冷却充分吗 / 稳态真稳吗"两个问题的客观答案。工具的瞬时读数做交叉验证，不做唯一依据。

1. **判定标准用 AND，逐份查 source。** 数值 CV 过了不等于臂合格；文件存在、schema 合法不等于数据是真的。

## 数据与工具

- 实验数据集（六臂完整 JSON + 功率轨迹 + 外部温度日志 + 回填脚本，CC BY 4.0）：[Zenodo 24046432](https://doi.org/10.5281/zenodo.24046432)

- 测量容器（Apache-2.0）：[ecocompute-mlcube](https://github.com/hongping-zh/ecocompute-mlcube)，软件记录 [Zenodo 23974826](https://doi.org/10.5281/zenodo.23974826)

- 测量协议：[EcoCompute Protocol v1.1](https://doi.org/10.5281/zenodo.22958675)

- 研究主站与结论页：[quantenergy.tech](https://quantenergy.tech)

测量工具的可信度不是一次校准出来的，是"明明可以蒙混过关却选择废弃重跑"一次次攒出来的。温度这条线，我们打算继续这么走。


----

本文是 ecocompute-mlcube 能耗测量系列的实战篇。我们此前的测量协议（EcoCompute Protocol v1.1）里一直写着一条原则："冷态和稳态是两种不同的测量，只在同一模式内比较，不要跨模式比。"——这条原则挂了很久，但它一直没有自己的数字。这次实验就是给它补上那个数字。

同一张卡，冷跑和热跑，每 token 能耗差 4.1%——一次六臂对照实验的完整复盘

摘要：同一张 RTX 4090、同一个模型、同一套软件栈，只因为起跑温度不同（37 °C 冷启动 vs 53–54 °C 稳态），每 token 能耗差 +4.1%——组内 CV 却只有 1.2–1.6%，也就是说：两组数据各自看都非常"稳"，放一起却系统性错位。本文完整复盘这次六臂对照实验：为什么要在测量协议里给"热状态"留一个强制字段、外部温度日志如何充当权威温度计、一臂因起跑温度超标 2 °

硬件

人工智能

运维

能耗基准测试需量化热状态影响：同卡同负载下，稳态较冷态每token能耗高4.1%，温度每升10°C能耗增3-4%。冷却纪律与温度字段必须硬性要求，跨模式比较不可信，外部温度日志和source字段核查是数据质量的关键防线。

容器

Kernel

JSON

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

腾讯云双十一大促

serverless-catalog

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

同一张卡，冷跑和热跑，每 token 能耗差 4.1%——一次六臂对照实验的完整复盘-腾讯云开发者社区-腾讯云

同一张卡，冷跑和热跑，每 token 能耗差 4.1%——一次六臂对照实验的完整复盘

同一张卡，冷跑和热跑，每 token 能耗差 4.1%——一次六臂对照实验的完整复盘

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐