碳排放明细：对推理能耗进行预算管理

这里有一个事实打破了大多数工程仪表盘的逻辑：两个完全相同的推理请求，返回相同的 token，按相同的 API 费率计费，但其碳足迹（Carbon Footprints）可能相差五倍。相同的模型，相同的提示词，相同的花费。唯一改变的是由哪个数据中心响应以及当时的时间。如果你的可持续发展指标是根据支出金额推导出来的——几乎所有人都是这么做的，因为支出是唯一被真正追踪的数字——那么你的可持续发展指标就是错误的，而且当你越是努力优化成本时，这种错误就越严重。

美元和焦耳看起来应该是一致变动的。更多的 token，更多的计算，更多的钱，更多的能源。对于在单一瞬间、单一地点处理的单个请求，它们确实大致一致。但是，当你开启那些能实现大规模廉价推理的杠杆——激进的批处理（Batching）、模型路由（Model Routing）、非高峰期调度、多区域故障转移——这两个指标就会脱钩。成本是合同的函数，而碳排放是物理学和电网的函数。它们不是同一种函数，将其中一个作为另一个的代用指标，最终会导致你在可持续发展报告中填入一个审计员可以证伪的数字。

这篇文章讨论了为什么这两个指标会产生分歧，分歧在何处最大，以及如何将能源指标与延迟、支出一起放在同一个仪表盘上，而不是每年为了 ESG 幻灯片才临时修补。

单次推理的焦耳成本究竟是多少

从单位经济效益开始，因为大多数团队从未衡量过这些。对前沿级模型的简短查询大约消耗 0.3 瓦时（Watt-hours），根据对 GPT-4o 级模型的实测估算，典型交互的能耗接近 0.3 Wh，较长的交互则升至 0.4 Wh。按每个输出 token 计算，大约是 0.0003 Wh——也就是说，生成你阅读的每个 token 大约需要 2 焦耳的功。

这个数字看起来微不足道，对于单个请求来说确实如此。一次查询消耗的能量大约相当于点亮一个 LED 灯泡几分钟。问题从来不在于单个请求。问题在于，一个稍具规模的产品每天会处理数千万次此类请求，而每 token 的数值乘以一个增长速度超过任何效率增益的规模。在这种规模下，每 token 能源消耗 25% 的波动，就决定了你是否需要额外增加 1 兆瓦的合同容量。

要将瓦时转化为碳排放，你需要乘以电网的碳强度（Carbon Intensity），而这正是“能源就是能源”这一便利假设破灭的地方。在主要运行水电和核电的地区，消耗 1 千瓦时电能可能产生 100 克二氧化碳。而同样的 1 千瓦时，如果来自依赖燃气调峰电厂的电网，则会产生 400 到 500 克。据测算，美国超大规模数据中心的电力加权平均值约为 545 gCO2/kWh——明显高于国家电网平均水平，因为选址通常是为了廉价电力和税收优惠，而非清洁能源。碳排放计算中有一个美元计算所没有的第二个乘数：电子来自哪里。

为什么批处理有助于省钱和省能——直到它失效为止

批处理是这两个指标最初表现一致，随后悄然分歧的第一个地方。当你将更多请求批量处理到 GPU 上时，固定成本——内核启动、内存传输、已驻留在 VRAM 中的模型权重——会被分摊到更多的 token 上。测量显示，当批处理大小从 32 增加到 256 时，效率提升最快。在此区间，随着 GPU 利用率从不足 50% 趋于饱和，大模型可以减少约四分之一的单 token 能耗。超过 256 后，曲线趋于平缓：功率消耗保持大致恒定，而每个新增 token 带来的边际效率收益递减。

对于成本来说，这是一个明显的胜利——更高的利用率意味着每百万 token 消耗更少的 GPU 小时，而 GPU 小时正是你所支付的费用。对于碳排放来说，由于同样的原因，这也是一个胜利。到目前为止，这两个指标是一致的。

分歧在于没人放在同一张图表上的第三个维度：延迟（Latency）。 更大的批处理意味着请求需要等待更长时间才能被调度。那个既能改善单 token 成本又能改善单 token 碳排放的杠杆，却降低了你的 P99 延迟。为了优化尾部延迟，团队会运行较小的批处理并让 GPU 处于低负载状态，这同时提高了单 token 的能源消耗和单 token 的美元成本——在这里，成本和碳排放同步向错误的方向变动。重点不在于批处理的好坏。重点在于，单凭成本数字无法告诉你你处于哪种状态，因为在它平衡的三种力量中，有两种对它而言是不可见的。

模型路由：支出与碳排放完全脱钩之处

模型路由——将简单的请求发送给廉价的小模型，将复杂的请求发送给昂贵的大模型——被推崇为通用的效率提升方案，对于支出而言通常确实如此。但在路由环节，美元和焦耳会因为三个独立的原因而彻底失去相关性。

首先，价格是由供应商的利润率决定的，而不是由物理学决定的。 供应商可以将小模型定价为大模型的十分之一，而实际的能源比例可能是三分之一甚至二分之一，这取决于架构以及它们在集群中的批处理效率。你正在优化的是供应商选择的一个数字，而不是芯片消耗的焦耳。账单减半并不代表能源消耗也减半。

其次，路由改变了工作运行的时间和地点。 较便宜的模型可能位于不同的区域，或被调度到具有不同电网组合的不同机群。你可能会为了选择更便宜的方案而增加了碳排放，因为这个便宜方案恰好运行在更脏的电网。支出下降了，排放却上升了。美元数字对此无法提供任何预警。

第三，隐含碳（Embodied Carbon）核算与折旧核算不同。 最新的加速器在单 token 能耗上更高效，通常在单 token 成本上也更高效——但它携带了巨大的制造排放，这些排放在它建成的那一刻就已经产生了。你的财务系统将硬件摊销为平滑的折旧线。碳排放的摊销方式不同；无论你最终服务了多少个 token，它都在前期排放了。如果一个机群为了追求效率而频繁更换硬件，那么在折旧表上看起来是成本最优的机群，在碳排放上可能是次优的。

绿色软件基金会（Green Software Foundation）的软件碳强度（Software Carbon Intensity, SCI）规范——现已成为 ISO 标准——准确地描述了这一结构：碳评分等于能源乘以该地点和时间的电网碳强度，加上硬件的隐含排放，最后除以有用工作单位。三个项。你的成本模型只有其中的一项半。这种差距就是分歧，它被写成了一个等式。

将能源作为一等指标

解决方案并非一项宏大的测量工程。而是像对待延迟和支出那样对待能源与碳排放：持续监测、关联到每个请求、在同一个仪表盘上展示，并进行预算管理。

通过以下几个步骤，你就能完成大部分工作：

• 在调用端估算每个请求的能源消耗。 你不需要在每台 GPU 上安装瓦特表。模型大小、输入和输出 Token 数量，以及每个模型的“焦耳/Token”系数（在你的推理栈上测量一次即可）——这些能为你提供一个可用的估算值，并将其关联到每个请求，就像你关联 Token 数量和美元成本一样。

• 乘以实时的电网信号，而不是年度平均值。 大多数电网的碳强度都有实时或近实时的反馈。使用边际强度（即为了响应你增加的负载而实际运转的发电厂产生的碳排放）比使用那种让每个人都觉得体面的电网平均值更诚实。这就是归属核算（attributional accounting）与结果核算（consequential accounting）的区别，也是你能否辩护这个数字的区别。

• 利用时间和空间的灵活性，但要诚实面对上限。 批处理和异步工作负载——如评估（evals）、嵌入回填（embeddings backfills）、离线摘要——可以转移到更清洁的时段或区域。这确实有帮助。但关于碳感知调度（carbon-aware shifting）的研究表明，现实中的收益是有限的，通常只有较低的双位数百分比，而且简单的策略就能捕获其中的大部分。无法等待的交互式流量几乎无法移动。不要承诺电网无法实现的 50% 减排。

• 包含 PUE 和隐含排放，否则你会少算。 你的 IT 负载不等于设施负载。即使是顶级的超大规模数据中心，其 PUE 也在 1.1 左右，而行业内大部分都在 1.5 附近——这意味着在接触芯片之前，每焦耳能量都有 50% 的额外开销。而且，无论你的折旧计划是否注意到，硬件制造过程中的排放都是真实存在的。

将其放入仪表盘

在大多数组织中，碳排放数据之所以错误，并不是因为难以测量。而是因为它存在于工程师关注的系统之外，由不同的团队管理，并以不同的频率报告。支出之所以出现在仪表盘上，是因为财务部门将其作为一等指标；延迟之所以在，是因为 SRE 这么做了。在有人给予能源同样的待遇之前，它将一直是一年一度的估算：即每个请求的价值、预算、退化时的警报，以及在屏幕上与那两个经常被混淆的数字并列的位置。

做对这件事的团队并不是为了 ESG 报告。他们这样做是因为能源被证明是一个他们此前无法察觉的成本领先指标——那些未被充分利用的 GPU、路由到不洁且并不便宜的区域的请求、在纸面上看起来效率很高但实际上造成的硬件损耗。碳排放和美元经常会产生分歧并误导你，但它们重叠的频率也足以让你通过同时观察两者来变得更加专业。这个条目一直都在那里，只是此前没被放在仪表盘上。