batch 大于 1 的那一半：量化能耗数据里最大的空白，和它为什么难填

先摆一个事实

如果你想知道"在 batch 1 下、单流解码、NF4 相对 FP16 的每 token 能耗变化"，我们能给你一张有数字的表：Turing、Ada、Blackwell 几代卡都有测量，交叉点分别落在 2.1B、3.7B、4.8B 附近，每个数字都能追到 n、窗口和 DOI。

但如果你问的是同样的事在 batch 4、8、16、32 下是什么样——过去两年里，公开的受控测量是零。

这不是我们偷懒。把已发布的数据按"精度 × batch size"摊开成一张 3×5 的网格：FP16、NF4、INT8 三行，batch 1 / 4 / 8 / 16 / 32 五列，一共 15 个格子，3 个有数据，12 个从没人测过。有数据的那 3 格全部挤在 batch 1 那一列。

而且这是个连锁效应。因为量化数据必须配一张同一次会话、同一张卡上的 FP16 基线才能算出 ΔE%，基线格空着，量化格也就填不了。所以真正空缺的不止 12 格——是整个右半张表。

为什么 batch 1 不足以支撑一个部署决策

这里要说清楚，我们做 batch 1 不是随便挑的。单流解码是最不掺水的场景：一个请求、一次生成、没有并发调度干扰，能耗归因最干净。作为方法论起点，它是对的。

问题在于，绝大多数真实部署不长这样。

公开服务几乎都跑连续批处理（continuous batching），batch size 从几到几十不等。而 batch size 恰好是决定"量化 kernel 能不能回本"的那个变量，原因是物理层面的：

• batch=1 时，GPU 在两个 decode step 之间基本是闲的。kernel 启动开销、权重加载、固定开销被完全摊薄在极小的计算量上，利用率低。
• batch 变大后，同一份权重被复用于更多样本，GPU 利用率上升，kernel 的固定开销被摊薄。
• 量化省下来的两个东西——显存带宽和存储占用——在低利用率时省不出时间，省不出时间就省不出能量。它真正开始起作用，是在 kernel 变成 memory-bound 且被持续喂饱之后。

换句话说：batch 1 上的量化能耗结论，外推到生产 batch size 上，方向可能不变，也可能翻转，而现在没有任何人的数据能告诉你哪种。 包括我们自己的。

这不是危言耸听。同一个软件包里就有现成的反例：在 batch 1 下，bitsandbytes 的 LLM.int8() 相对 FP16 是清一色的惩罚（+50% 到 +473%，八个已测格全为正）；而 llama.cpp 的 GGUF Q4_0 在 8B 上是 −61.9%。同格式、不同 kernel、符号相反。如果连 kernel 融合度都能翻转符号，凭什么认为 batch size 不行？

为什么这 12 格一直没人填

不是没人关心，是填它的成本结构和填 batch 1 不一样。

第一，它需要一个"你已经有的卡"加上一次参数改动——听起来最容易，但它要求贡献者真的跑一遍完整的受控流程，而不是引用别人的数。第二，它需要同会话的 FP16 基线，也就是一个配置要跑两条轨迹，成本翻倍。第三，也是最有意思的一条：大 batch 测量的目的，其实是和另一套基准对齐。

数据中心能效榜（MLPerf Power 这类）报的是整机墙插功率、大并发、真实服务栈下的结果，署名是 J/sample 这类归一化指标。我们这个数据集目前全是 batch 1、GPU package 功率（NVML）。两套数字之间没有可比性，中间缺的正是 batch 这一维。 只要右半张表是空的，我们就没法把自己的数放进主流能效讨论里，只能站在门外说"边界不同"。

补齐 batch 4 那一列，就是这个数据集从"单流现象学"走向"能和别人对话"的第一步。

顺便说清三个容易混淆的口径

写这类内容最怕被误读，所以把三个常被搞混的地方钉在这：

一、空白不等于结论。 矩阵里是空格的，一律写"未测量"，不写"大概差不多"。空格是数据集的纪律，不是耻辱——56 格的覆盖矩阵有 30 格是空的，照样挂在证据页上。同理，batch 4 是空的，就是空的，不是"应该省"或"应该费"。

二、测量数不等于会话数。 同一张卡上同一个配置测三次记 3，重复五次记 5。FP16 那格看起来是最满的（72 次），但那是 72 次量化测量各带一次自己的基线叠出来的——我们自己的 RTX 4090 INT8 那格，在同一个配置的三次重复之间移动了 12.5 个百分点。 这正是为什么一个格要 ≥3 个点才算饱和：单点只是某张卡某个下午的轶事。

三、热状态和软件栈是变量，不是背景。 已发布的所有格当前热态标记都是 unknown，按规范 unknown is not cold，不能和未来的 cold/steady 运行直接比。软件栈同理：交叉点会随库版本漂移，同一张 5090 在九个月里，随着 kernel 版本往前走，盈亏平衡点就挪了大约 3B。填右半张表时，如果不同时记热态和栈版本，填出来的还是不可比的数字。

怎么把这一格填掉

如果你手上已经有一张 NVIDIA 卡，最省力的一格是 batch 4 那一列的任意一格：不需要换硬件，只需要一次参数改动，加上一个同会话的 FP16 基线。

流程上没有门槛：

• 一条命令跑容器，无需配置；租来的、不能嵌套容器的实例就装进 venv；
• 没有 GPU 的话，免费 Colab 上的 T4 也能跑同一套 NVML 测量，产出同样的报告文件（模型上限约 3B）；
• 测量顺序随机化，每次测量前等卡回到 idle；
• 结果写成一个按 schema 校验过的报告文件，带 vs_fp16_energy_pct（ΔE%）和 basis（measured / interpolated / extrapolated）两个关键字段。

提交要成立，需要两样东西：同一次会话、同一张卡上的 FP16 基线，以及一份 schema 合法的报告。和已发布曲线不一致的结果，会和一致的结果印在同一页上——分歧观测不上锁。

顺便，这也是对论文里六条空白的一次直接回应：跨后端受控对比稀缺、batch>1 无人测量、热状态无人报告、软件栈版本不被当实验因子、重积分窗口能让数字挪 12.5 个百分点——这六条里，有一半可以在你自己的卡上、用一个下午的容器运行补上。

结尾

三年前，"量化到底省不省电"连"需要实测"都还没形成共识。三年后我们至少知道答案是一个函数，不是常数：

f(kernel 融合度, 测量边界, 负载形态, 模型规模)

而 batch size 恰好是"负载形态"里最粗、最有解释力、也最缺数据的那一维。左半边我们有一张表，右半边是 12 个空格。空格不是坏消息——它意味着"我的栈上、我的并发下、量化到底花多少电"仍然是一个必须自测、无法外包给论文的问题。

窗口之外无事实。batch 1 之外的窗口，现在还是空的。