## 概述

这个项目此前所有上网格的能耗数据都是我自己测的。2026-11-10 早上，一位用 Tesla V100S-PCIE-32GB 的开发者在不到半小时里连提三条复现报告（issue #42/#43/#44，1.1B / 3B / 7B 三个尺寸的 NF4 量化，对同一张卡各跑一遍 FP16 基线），三条都零违规通过协议校验，成为整个数据集里第一批由外部产生的 `protocol-conformant` 报告，也是第一个 Volta 架构类的数据。
这篇想讲的不是"项目收到了贡献"这种好消息，而是这三条数据进来之后被迫处理的四件具体的事：（1） `n=1` 的单点数据在报表上能说什么、不能说什么；（2） Volta（`sm70`）上 bitsandbytes 的量化内核缺失会如何把一次失败悄悄变成"看起来测过了"，以及贡献者为什么必须显式改掉 pin 掉的 torch 版本；（3） 一个 `\bv100\b` 正则为什么认不出 `Tesla V100S-PCIE-32GB`；（4） 当第一格社区数据进来时，网站的覆盖率口径、统计卡、文件名、贡献认定政策为什么必须一起改，改一半就会自相矛盾。


----
## 一、先摆数据：三格新数据长什么样

三件事先说清楚：同一张卡、同一套采样方式（NVML 设备侧 10 Hz）、每个尺寸各一次（`n = 1`），量化臂和 FP16 基线臂在同一次会话里跑，能量只在生成窗口内积分（模型加载、量化、warmup 全部排除）。

|字段|TinyLlama-1.1B-Chat|Qwen2.5-3B|Qwen2.5-7B|
|:-:|:-:|:-:|:-:|
|量化方式|NF4（bitsandbytes）|NF4|NF4|
|相对 FP16 能耗|−1.7%|−7.9%|−3.6%|
|NF4 每 token 能耗|2843.769 mJ|5183.774 mJ|7719.712 mJ|
|FP16 每 token 能耗|2891.662 mJ|5625.761 mJ|8011.411 mJ|
|吞吐|29.2 tok/s|16.2 tok/s|20.9 tok/s|
|平均功率|83.0 W|84.1 W|161.5 W|
|困惑度 NF4 / FP16|10.1017 / 9.6200|5.8004 / 4.5472|2.6580 / 2.1701|
|困惑度变化|+5.01%|+27.56%|+22.48%|
|热状态|cold，44℃ → 49℃|cold，39℃ → 49℃|cold，55℃ → 55℃|
|采集时间（UTC）|2026-11-10T05:31:46|2026-11-10T05:43:13|2026-11-10T06:00:31|
平均功率 83～161 W，对一张标称 300 W 级的卡来说远低于上限——典型的访存受限形态。
最有意思的一点：三个尺寸全部是省能耗的，没有出现拐点。 项目自己在消费级卡上拟合出的结论是 weight-only NF4 有个"断点尺寸"，小于它量化反而更费电：Turing ≈2.1B、Ada ≈3.7B、Blackwell ≈4.8B。而在 Volta 上，连 1.1B 都是负的（−1.7%，虽然很小）。这个形态和 Ampere 更接近，和消费级卡相反。
一个候选解释是：NF4 这类 weight-only 量化在生成阶段主要是省下权重搬运，卡越是被带宽卡住，这笔收益越难被反量化开销吃掉；而消费级卡在 1B～2B 这个尺寸上，收益很容易被反量化和 kernel launch 的固定成本抹平。但这仍然只是解释假设——Volta 每个尺寸只有一次测量，不足以拟合任何曲线，所以网格里这三格只作为单点存着，没有为 Volta 画任何断点曲线，也不会向未测尺寸外推。协议里 `basis` 字段存在的意义就在这里：`measured` / `interpolated` / `extrapolated` 必须区分，数据集派生的参考值永远不进覆盖率网格。


----
## 二、`n=1` 的边界：一处不该被解释的排序

同一张卡、同一套栈，7B 的吞吐（20.9 tok/s）反而高于 3B（16.2 tok/s），平均功率还高近一倍。这不合常理，而且单次测量没法判断它是一次偶发的后台任务、一次频率回退，还是别的。
所以这次给自己定的处理规则是：`n=1` 的格子只允许支撑"能耗方向"的结论（每 token 能耗随参数单调上升：2843 → 5183 → 7719 mJ，这条稳），不允许支撑任何吞吐排序或功耗效率比较。要讲效率，得等同配置补测到 `n ≥ 3`。
第二处要留白的是困惑度。惩罚随参数增大反而变大（+5.01% → +27.56% → +22.48%），和"小模型对量化更敏感"的常见经验方向相反。所以更可能是测量侧的问题（chat template 拼接、token 边界切分、或 Volta 上那条特殊的 bitsandbytes 反量化路径），而不是量化本身。这类怀疑要落成结论，需要贡献者补一发用同一切分配置的 FP16 臂，目前先作为待办挂着。
顺带说一句质量探针的设计，这套 schema 里我觉得最实用的部分：探针固定在功率采样停止之后用 teacher forcing 打分，所以困惑度计算不会污染能量窗口；语料是 pinned 的——`eval_text.txt`，60600 字节，`sha256` 写死在报告里，`seq_len = 1024`、14 个窗口、14123 个 token。以 3B 那份为例的完整字段长这样：
yaml

```
quality:  metric: perplexity  basis: measured  mean_nll: 1.75793          # exp(1.75793) ≈ 5.80，对应表中 NF4 值  tokens_evaluated: 14123  windows: 14  seq_len: 1024  corpus:    name: eval_text.txt    bytes: 60600    sha256: 22ac091a6383740d30f8e41ae144032c873c772db5e1c901112c1c330fdc5504
```
没有 `sha256` 的困惑度没有可比性——两次跑用了不同切分，数字差 20% 也说不清是谁的锅。


----
## 三、技术上最值钱的一条：`sm70` 上的静默降级

这是三条报告里我最想抄进自己检查清单的部分。贡献者主动偏离了 `reference_pins`，并在报告里写了原因：
- 容器 pin 的 torch 是 `2.13.0`（CUDA 13.0）；
- 但 CUDA 13 的 bitsandbytes wheel 只为 `sm75+` 编了内核，V100 是 `sm70`，没有可用的量化内核；
- 于是他显式降到 `torch 2.6.0+cu124`，并在报告里把这条偏离写成正文，同时给出 `matches_reference_pins: true`（因为 `reference_pins` 有意不包含 torch，这条偏离不违反 pin，但必须被看见）。

为什么这件事重要？因为如果他不写，这条路径更常见的表现不是报错，而是量化臂悄悄退化成"用数据集里的参考值补上"。那种报表上每一格都填满了，`basis` 却已经从 `measured` 变成了别的东西，而读者从数字上一点都看不出来。这是我认为能耗类工具最危险的一类失效：失败的形态是"数据看起来更好了"。
对应的三条设计，现在看清楚了它的用处：
1. `basis` 是必填字段，不是注释；
2. 数据集派生的参考值不参与覆盖率网格的填充（一格要么是实测，要么是空的）；
3. `reference_pins` 故意不含 torch——写死一个跨架构的 torch 版本，只会把"你的卡跑不了"变成"你被迫造假"。宁可让版本偏离以文字形式暴露出来，也不要让它在 pin 面前被压平。

这也是上游 [mlcommons/inference#2558](https://github.com/mlcommons/inference/issues/2558) 里我提的那个方向的具体形态：能耗报告要能被机器判定可信度，靠的不是更长的 README，而是把这类"测量到底发生没有发生"的字段规范化。


----
## 四、一个正则的 bug：`\bv100\b` 认不出 `Tesla V100S-PCIE-32GB`

第二条技术产出是个真 bug。贡献者报告：`--gpu_arch auto` 认不出他的卡，他必须显式传 `--gpu_arch volta`。
原因很蠢也很典型。NVML 上报的字符串是 `Tesla V100S-PCIE-32GB`，而识别模式写的是 `\bv100\b`。`\b` 是单词边界，`V100S` 里 `100` 后面紧跟字母 `S`，不是边界——所以这个模式永远匹配不到 V100S 系列。V100（无 S）能匹配，带 S 的不能，这种"一半能用"的 bug 比完全不认卡更难被发现。
修复是一个字符的事：


```
-\bv100\b+\bv100s?\b
```
同时补了一条回归用例，故意用 NVML 的原样字符串 `Tesla V100S-PCIE-32GB` 而不是手写一个"看起来像"的名字。改动在 `a2c7ff7`，测试从 148 条变 149 条，全绿。
这里有个可以泛化的教训：凡是拿正则去匹配硬件上报的名字，测试用例就必须来自设备本身的原样输出，不能来自你对它的印象。`nvidia-smi -L`、`torch.cuda.get_device_name()`、NVML 三者给的字符串经常不一样。


----
## 五、数据进来以后，口径必须跟着一起改

这三格数据带来的下游改动比数据本身多。列一下，因为"接受贡献"的实际成本就在这些地方：

|位置|改动前|改动后|为什么|
|:-:|:-:|:-:|:-:|
|覆盖率网格|26 / 56|29 / 64|多一个架构类、三格实测|
|架构类计数|5 + 1 这种混着说的写法|5（口径：网格上至少有一格直测的架构类；借来的曲线族不算）|"5+1" 读者无法判断 1 是什么身份|
|独立复现者|1 / 5|2 / 5|按"不同的人"计数|
|热状态说明|"每一格都是 t=u"|不再是；新增 `t=c` 与 `t=u` 的分区说明|三条 Volta 全是 cold|
|CSV 文件名|`coverage_matrix_2026-09-09.csv`|中性名 + 头部 `generated_at` / `source_commit` / `schema_version`|内容重写后名字还带着旧日期，等于自己造了个假历史|
|CSV 新增列|—|`provenance`（`@handle` + issue 链接）|谁的测量、在哪个 issue，必须随行可查|
其中热状态这条是最"方法论"的一条。协议 §4.6.3 写的是同一热状态内比较，不要跨状态比，§4.6.5 写的是 `unknown` 不等于 `cold`。此前网格上所有实测格都恰好是 `t = u`，所以这条规则从未真正生效过；`t=c` 的格子一进来，才第一次逼出"这张表的默认读法变了"——图注也据此重写了。
还有一处故意留的空：网格的困惑度列，这三格是空的。要么从 FP16 臂把对应值补进去，要么在图注里说明为什么空。留空比填一个来路不明的数好。


----
## 六、贡献者怎么被记住：三档认定，和"归档即收录"

最后是这次真正的治理产出。
新数据进来后，README 的 Acknowledgments 多了两个名字：第一位独立复现者（RTX 3050 Ti Laptop，2026-08），和这位 Volta 复现者（三条实测 + 那个正则 bug）。CONTRIBUTING 里也第一次给"数据集"下了明确定义：
>"进入数据集"只意味着一件事：被复现画廊归档。 归档后的复现会喂给覆盖率网格。

这条定义是被逼出来的，因为出现了两个必须一致的说法：一边在网格上用人家的数据（`provenance` 列里写着 @handle 和 issue 号），一边在作者资格政策里含糊地讲"只有进主数据集才算"——那这三条数据到底算不算数？如果算进网格但不算进数据集，等于一边用贡献一边否认贡献。所以选择了宽口径并让它贯穿：归档即收录，收录即满足数据路径。
在此之上是三档认定，全部以贡献者意愿为准：
1. 仅致谢（默认，不需要同意）——留在这里是一个完整、最终的选择，不是"等待升级"的中间状态；
2. 数据集贡献者——需要明确同意，因为署名会随每次发布再分发；
3. 论文作者——需要达到门槛并且同意。数据路径的门槛是一次合格的实测提交。

而这次的实际走向值得写下来：@OliverYanghoo 三条协议合规的 V100S 复现达到了数据门槛，他选择保持仅致谢。 所以 CONTRIBUTING 里那个"达标 worked example"用的就是他，并且明写"达到门槛只是有资格，处在哪一档永远是贡献者自己的选择"。这条规则如果只写在墙上、第一次遇到就绕开，那它等于没有。


----
## 七、如果你想用自己的卡复现一次

把流程里真正有约束力的部分说清楚，避免别人踩我踩过的理解成本：
1. 跑容器里的测量入口，得到一份 `ecocompute-energy/1.3` 的 JSON；
2. 先自己校验再提交：`tools/validate.py --profile v1.1-core`。校验分三级台阶，别混着说——`schema-valid`（结构合法）→ `protocol-conformant`（符合协议 v1.1 核心条款）→ `dataset-eligible`（够格进数据集）。这次三条报告是 0 违规到 `protocol-conformant`；
3. 报告必须写清：测量窗口（只积分生成段）、热状态标签、双臂顺序、解码策略、以及任何与 pin 的偏离及原因；
4. 不确定的字段留空并说明，不要从公开数据集里找一个数填上。这是同一件事的两面：静默降级最诱人的时刻，就是那一格看起来只差一个数字。

报告里还有两个标签我很喜欢，因为它们把"边界"写在了机器可读的位置：`scenario: SingleStream` 配一条 `scenario_note`，明写这里并没有套用 LoadGen 的度量口径——这是一套补充性能耗方法学，不是一次认证基准；以及 `certified_benchmark_result: false`。


----
## 小结

三条 `n=1` 的数据，价值不在于回答了"Volta 上量化省多少电"（它没回答，一次测量也回答不了），而在于它同时压测了一个测量体系的四条边：
- 方法学的边：全 cold 的第一批外部数据，逼出了"同热状态内比较"这条规则的第一次真实生效；
- 诚实性的边：`sm70` 内核缺失这件事证明 `basis` 字段和"参考值不进网格"不是官僚要求，而是会让结果整体反转的机制；
- 工程的边：一个 `\b` 的位置错误，让一整代卡在 auto 模式下隐形，而测试从没覆盖过设备上报的原样字符串；
- 治理的边：数据一旦进网格，认定政策就必须承认它，而且承认的方式由贡献者选。

如果要提炼成一句可迁移的经验：接受外部实测数据的成本，绝大部分不在"跑一遍"，而在让"这格是谁测的、在什么状态下测的、算不算数"这三件事在代码、报表和政策里得到同一个答案。

这个项目此前所有上网格的能耗数据都是我自己测的。2026-11-10 早上，一位用 Tesla V100S-PCIE-32GB 的开发者在不到半小时里连提三条复现报告（issue #42/#43/#44，1.1B  3B  7B 三个尺寸的 NF4 量化，对同一张卡各跑一遍 FP16 基线），三条都零违规通过协议校验，成为整个数据集里第一批由外部产生的 protocol-conformant 报告，也是第一个 Volta 架构类的数据。这篇想讲的不是"项目收到了贡献"这种好消息，而是这三条数据进来之后被迫处理的四件具体的事：（1） n=1 的单点数据在报表上能说什么、不能说什么；（2） Volta（sm70）上 bitsandbytes 的量化内核缺失会如何把一次失败悄悄变成"看起来测过了"，以及贡献者为什么必须显式改掉 pin 掉的 torch 版本；（3） 一个 \bv100\b 正则为什么认不出 Tesla V100S-PCIE-32GB；（4） 当第一格社区数据进来时，网站的覆盖率口径、统计卡、文件名、贡献认定政策为什么必须一起改，改一半就会自相矛盾。

第一次收到别人的实测数据：三条 Tesla V100S 复现报告的技术复盘

这个项目此前所有上网格的能耗数据都是我自己测的。2026-11-10 早上，一位用 Tesla V100S-PCIE-32GB 的开发者在不到半小时里连提三条复现报告（issue #42/#43/#44，1.1B / 3B / 7B 三个尺寸的 NF4 量化，对同一张卡各跑一遍 FP16 基线），三条都零违规通过协议校验，成为整个数据集里第一批由外部产生的 protocol-conformant

硬件

人工智能

大数据

此项目首次迎来外部实测的Volta架构NF4量化能耗数据（n=1），显示1.1B至7B模型均比FP16基线省电，但单点数据仅支撑能耗方向结论，不涉吞吐排序。贡献者修复了正则匹配bug及sm70内核静默降级问题，推动了覆盖率口径、CSV格式与贡献认定政策的同步更新，凸显能耗数据在方法学、工程与治理上的边界规范。

代码解释

容器

JSON

腾讯云双十一大促

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

第一次收到别人的实测数据：三条 Tesla V100S 复现报告的技术复盘-腾讯云开发者社区-腾讯云

第一次收到别人的实测数据：三条 Tesla V100S 复现报告的技术复盘

第一次收到别人的实测数据：三条 Tesla V100S 复现报告的技术复盘

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐