能耗与质量的双账本：怎么在同一个实验框架里同时测量

为什么要把两本账放在一起

前三章我们聊了怎么测功耗、怎么让数据可信、怎么跨 GPU 和跨负载比较。所有这些讨论都建立在一个隐含假设上：我们只关心能耗。

但现实不是这样的。

当你决定要不要对一个模型做量化时，你关心的不是"量化省不省电"这个抽象问题，而是"在我的场景下，量化带来的能耗变化是否值得它带来的质量损失"。这是一个 trade-off 问题，不是单目标优化问题。

如果你分开测——一次实验测能耗，另一次实验测质量——你会遇到两个问题：

1. 环境差异：两次实验的软件栈版本、驱动状态、温度条件可能不同，你没法确定差异来自量化还是来自环境漂移。
2. 归因困难：如果你发现 NF4 省电 30% 但困惑度上升 5%，你无法判断这个 trade-off 是否可接受，因为两个数字来自不同的运行。

正确的做法是：在同一次运行里，同时记录能耗和质量指标。 两列数字来自同一份权重、同一个进程、同一次推理。

质量指标怎么选

LLM 的质量指标有很多：下游任务准确率、人工评分、BLEU、ROUGE……但在量化对比实验里，最实用的是困惑度（perplexity）。

原因很简单：

• 困惑度是模型级别的指标，不依赖具体下游任务
• 计算成本低，不需要跑完整的推理服务
• 和下游任务表现有相关性（困惑度越低，通常下游任务越好）
• 可以在同一次推理过程中顺便计算

具体来说，你在测量能耗的同时，让模型对一组标准文本做 next-token prediction，计算交叉熵损失，然后取指数得到困惑度。

关键纪律：困惑度的计算窗口必须和能耗的测量窗口对齐。 如果你测能耗时只算了 decode 阶段，那困惑度也应该只基于 decode 阶段的 token 预测，不要混入 prefill。

实验设计：一次运行，两本账

把能耗和质量放在同一个实验框架里，实验设计需要做一些调整。

1. 配对测量

每个配置（模型规模 × 精度 × batch size）只跑一次，但这一次运行里同时记录：

• 能耗时间序列（NVML 功率采样）
• 困惑度（基于同一批 token 的预测损失）
• 推理延迟（可选，但对生产场景有用）

不要分开跑。分开跑意味着两次运行的环境条件可能不同，你无法确定差异来自配置变化还是环境漂移。

2. 基线配对

FP16 基线和量化测量必须在同一次会话里完成。具体来说：

• 先跑 FP16，记录能耗和困惑度
• 清空显存，加载 NF4（或 INT8）
• 跑 NF4，记录能耗和困惑度
• 计算 ΔE% 和 Δppl（困惑度变化百分比）

这样你得到的是配对数据：每个量化配置都有一个同会话的 FP16 基线，两个数字的环境条件完全一致。

3. 报告格式

最终报告应该是一张表，每行一个配置，列包括：

• 模型规模
• 精度（FP16 / NF4 / INT8）
• 每 token 能耗（J/token）
• ΔE%（相对 FP16）
• 困惑度
• Δppl（相对 FP16）
• n（重复次数）

以及一个关键的可比性声明："所有 FP16 基线和量化测量在同一次会话内完成，环境条件一致。"

解读双账本：trade-off 分析

有了配对数据，你可以做 trade-off 分析。核心问题是：能耗节省是否值得质量损失？

1. 筛选规则

一个常见的做法是设置一个质量阈值。比如：

• 如果 Δppl ≤ 1%，认为质量损失可接受
• 在这个前提下，看 ΔE% 是正还是负

我的数据里有一个有意思的现象：

• NF4 在 7B 模型上省电 39%，但困惑度上升 12%
• INT8 在几乎所有配置上质量损失 ≤ 1%，但从不省电

如果你用 Δppl ≤ 1% 作为筛选条件，你会拒绝几乎所有 NF4 配置，但接受几乎所有 INT8 配置。这和纯能耗排序的结论完全相反。

这说明：单独看能耗或单独看质量，都可能得出错误的部署决策。 你必须同时看两个数字。

2. Pareto 前沿

更严谨的做法是画 Pareto 前沿：横轴是 ΔE%，纵轴是 Δppl，每个配置是一个点。

• 左下角（省电 + 质量损失小）是理想区域
• 右上角（费电 + 质量损失大）是绝对不能接受的
• 左上角（省电但质量损失大）和右下角（费电但质量好）需要 trade-off

Pareto 前沿上的点是那些"在不增加质量损失的前提下无法进一步省电"的配置。你的部署决策应该从 Pareto 前沿上选，而不是从整个集合里选。

3. 场景化权重

不同场景对能耗和质量的权重不同：

• 边缘设备：能耗权重高（电池有限），质量可以稍微妥协
• 云端服务：质量权重高（用户体验），能耗可以稍微妥协
• 批处理任务：两者都重要，但延迟可能更重要

你的 trade-off 分析应该明确说明场景权重，而不是给出一个"普适"结论。

常见陷阱

1. 困惑度窗口不对齐

如果你测能耗时只算了 decode 阶段，但困惑度是基于整个序列（包括 prefill）计算的，两个数字就不可比。prefill 阶段的困惑度计算和 decode 不同（一个是并行预测，一个是自回归预测），混在一起会污染结果。

规则：困惑度的计算窗口必须和能耗的测量窗口严格对齐。

2. 基线不同会话

如果你用今天的 FP16 困惑度比昨天的 NF4 困惑度，你比较的不是量化效果，是"今天和昨天的差异"。模型版本、分词器版本、评估数据集的随机种子，这些都可能引入噪声。

规则：FP16 基线和量化测量必须在同一次会话内完成。

3. 评估数据集不标准

困惑度依赖于评估数据集。如果你用 WikiText-2，我用 C4，我们的数字不可比。

规则：报告困惑度时，明确说明使用的评估数据集和分词器版本。建议使用标准数据集（如 WikiText-2、C4 validation set），以便跨研究比较。

4. 单次运行下结论

困惑度和能耗都有随机波动。单次运行的困惑度可能恰好偏高或偏低。

规则：每个配置至少跑 3 次重复，报告均值和标准差。如果两次运行的困惑度差异小于标准差，不能认为有显著差异。

一个可操作的模板

把上面所有内容落地，一个"能耗 + 质量"配对实验的最小设计如下：

实验准备

• 选定评估数据集（建议 WikiText-2 validation）
• 选定模型家族和规模梯度（0.5B / 1B / 3B / 7B）
• 选定精度配置（FP16 / NF4 / INT8）
• 锁定软件栈版本

测量流程

对每个配置：

1. 加载模型
2. 对评估数据集跑推理，同时记录：
   • NVML 功率时间序列（10Hz 采样）
   • 每个 token 的预测损失
3. 计算：
   • 总能耗（功率积分）
   • 每 token 能耗
   • 平均困惑度
4. 清空显存，等待 GPU 回到空闲状态

数据分析

• 对每个量化配置，计算相对 FP16 的 ΔE% 和 Δppl
• 画散点图：横轴 ΔE%，纵轴 Δppl，每个点一个配置
• 标注 Pareto 前沿
• 报告均值和标准差（至少 3 次重复）

报告格式

每张表包括：

• 模型规模
• 精度
• 每 token 能耗（J/token）± 标准差
• ΔE% ± 标准差
• 困惑度 ± 标准差
• Δppl ± 标准差
• n（重复次数）
• 评估数据集
• 软件栈版本
• 测量日期

下一步

这篇聊的是怎么把能耗和质量放在同一个实验框架里。这是系列里最接近"部署决策"的一篇——因为现实中的决策从来不是单目标优化。

但还有一个问题没有解决：如果你的测量环境不是你自己的卡，而是 Colab 或租用实例，怎么办？ 这些共享环境有自己特有的噪声源，需要额外的处理。这是下一篇的话题。

这是"GPU 能耗测量入门"系列的第五章。系列文章：

• 第零章：写给非硬件背景开发者的 GPU 功耗测量入门
• 第一章：从一次测量到一组可信数据：测量协议设计入门
• 第二章：怎么做跨 GPU 的对比实验
• 第三章：跨负载条件对比——batch size、并发与混合工作负载
• 第四章：能耗与质量的双账本——怎么在同一个实验框架里同时测量（本文）
• 第五章（预告）：共享环境下的测量——Colab、租用实例的噪声处理