AI基础设施碳核算：你的团队尚未衡量的可持续发展成本

每个正在基于LLM构建系统的工程团队，都在做基础设施决策时忽视了一项隐性成本。你会追踪token数量、延迟和API开支，但几乎没有人追踪其运行的推理工作负载的碳排放——而这个缺口正在迅速收窄，来自监管和市场两个方向的压力都在增加。

AI系统现在占全球温室气体排放的2.5–3.7%，已正式超过航空业2%的贡献，且每年增长15%。仅2024年，运行AI专用服务器的美国数据中心就消耗了53–76 TWh的电力——足以为720万户家庭供电一年。这种规模已不再是假设，工程团队需要了解自身贡献的预期正成为真实的组织压力。

好消息是，测量工具已经存在，方法论已经标准化，而且最高杠杆的干预措施是你的团队今天就可以做出的软件决策。本文介绍如何按模型调用来测量碳排放、是什么在基础设施层面驱动了排放，以及监管时间线应如何校准你的紧迫感。

为什么推理才是你真正的问题，而非训练

大多数工程师持有的心智模型——训练运行是AI环境故事的主角——在很大程度上是错误的。Meta、AWS和谷歌的研究一致发现，LLM整个生命周期中60–90%的排放来自推理，而非训练。一旦你仔细想想，这很有道理：一个模型只训练一次，但在其运营生命周期内要处理数十亿次查询。

每次查询的数字小到感觉可以忽略，但乘以倍数后就不一样了：

• 单次GPT-4o查询约消耗0.42 Wh——比一次谷歌搜索多约40%
• Claude 3 Opus每次请求约消耗4.05 Wh（在典型电网上约为1.80克CO₂）
• Claude 3 Haiku每次请求消耗0.22 Wh——比Opus少94%，使用的是同一底层提供商基础设施
• 高效的小型模型（GPT-4.1 nano、LLaMA-3.2 1B/3B）每次查询不到0.3克CO₂

在同等任务下，效率最高和最低的模型之间差距为10–40倍。每天一百万次查询时，这一差距每周会产生数吨CO₂的差异。模型选择是你架构图上杠杆最高的环境决策，而大多数团队在做这一决策时，根本没有考虑排放数据。

测量技术栈

衡量AI推理碳排放现在确实是可行的。有三个层次需要正确处理。

硬件级测量是CodeCarbon等工具提供的功能。它以可配置的间隔（默认：每15秒）监控GPU、CPU和RAM的功耗，获取硬件所在地理位置的电网碳强度，并输出运行代码的CO₂当量数值。如果你是自托管模型，这是最直接的方法。CodeCarbon以Python上下文管理器形式集成——你只需包裹推理调用即可获得测量结果，无需重构代码。

API调用级归因是One-Token Model（OTM）方法论所解决的问题，适用于调用托管提供商的团队。核心洞察：token是跨文本、音频、图像和多模态输入的通用测量单位。转换链为：token数量→该模型的硬件功耗配置→每token消耗的能量→提供商数据中心区域的电网碳强度→CO₂e。EcoLogits等工具无需任何提供商内部数据，即可为OpenAI、Anthropic和其他主要提供商API实现这一功能。你传入API调用，就能得到排放估算。

基础设施级归因是Cloud Carbon Footprint的用武之地。它从AWS、GCP和Azure账户提取使用数据，重建每项服务的能耗，并应用各区域的电网强度数据。这是归因报告的正确层次——将哪个团队、产品功能或客户群负责你的AI碳支出的哪部分进行映射。

新兴的共识标准是绿色软件基金会的AI软件碳强度（SCI）规范，它扩展了现有的ISO/IEC 21031:2024标准。它定义了提供商评分（涵盖训练和部署）和消费者评分（涵盖推理使用），以token作为语言模型的功能单位。实际意义在于：如果你的组织被ESG团队或企业客户要求报告AI排放，SCI for AI就是你将使用的框架。

真正有效果的措施

一旦建立了测量机制，值得优先考虑的干预措施可分为三类。

模型路由是杠杆最高的手段。 模型层级之间10–40倍的碳差距意味着，将查询路由到合适的模型层级——而不是万能的前沿模型——比大多数优化工作更有价值。这种模式类似于成本感知路由：首先对查询复杂性进行分类，然后将其分派给能够可靠处理它的最便宜的模型。摘要和分类用Haiku，推理任务用Sonnet，真正需要高能力的工作才用Opus或等效模型。排放减少与成本减少直接挂钩。

批处理被低估了。 研究表明，从批量大小4增加到8，每个提示的能耗可减少约45%。从8增加到16，再减少43%。对于任何非真正交互式的工作负载——文档处理、分类管道、夜间数据丰富作业——请求批处理是单一最简单的基础设施变更，具有最大的环境回报。对于同步工作负载，延迟权衡是真实存在的，但对于异步管道，这通常是免费的。

量化比大多数团队使用得更多。 INT8量化将模型大小减少75%，在大多数基准测试中精度损失不到1%。q4变体（4位量化）与FP16相比可实现高达79%的能耗减少。AWQ（激活感知权重量化）等高级技术保护了导致精度下降的关键权重通道，使激进量化在生产中可行，而不会遭遇早期方法遇到的质量悬崖。如果你是自托管，量化决策是你尚未优化的最高杠杆配置之一。

一个值得重新思考的数据点：生产系统在2024年5月至2025年5月之间实现了每提示能耗33倍的降低。拆解下来大约是模型架构改进带来的23倍和更好的硬件利用率带来的1.4倍。教训是：软件级优化比硬件采购决策有多一个数量级的空间。碳优化工作主要是工程工作，而非基础设施支出。

组织内部的归因问题

API边界的测量很简单。更难的问题是归因——回答哪个团队、功能或客户负责排放的哪部分。

这个问题的组织版本看起来像这样：你有一个共享的推理API网关。十五个产品团队通过它路由流量。季末，你的可持续发展团队要求提供AI排放明细。如果没有请求级别的归因，你只有总量，没有分解。

正确的监控层级将碳像成本一样对待。就像你通过请求标记将token支出归因于团队一样，你以同样的方式归因排放。每个推理请求都应携带团队、功能和环境标签。碳计算在收集时针对token数量和模型ID运行。Cloud Carbon Footprint或类似工具在账户级别汇总；请求级别的标记提供该级别以下的分解。

谷歌内部的方法很有启发性：团队有明确的计算和存储配额，这迫使优先级排序，并使计算成本信号在开发者工作流中可见。碳是一个滞后信号，相比于成本，但配额机制是相同的。早期建立这种监控的组织在需要它之前就把它作为可查询的指标。没有这样做的组织将面临一场混乱。

监管时间线，诚实地说

当前的监管形势比可持续发展社区呈现的更为混乱，也比"一切都在回滚"的叙事所暗示的更为清晰。

在美国，SEC的气候信息披露规则（于2024年3月发布）本将要求大型加速申报人从FY 2025申报开始披露范围1和2的温室气体排放。该规则目前因法律挑战而处于自愿暂停状态，SEC于2025年初宣布不会在法庭上为该规则辩护。简而言之：对美国上市公司强制SEC披露目前确实存在不确定性。

在欧盟，AI法案包括关于能效和环境可持续性自愿行为准则的要求，首份进展报告于2028年8月提交。实际的执法标准尚不存在，还需要多年才能制定。这不是迫在眉睫的监管压力。

更强的近期信号是行业标准采用。AI的SCI规范是AI碳测量的第一个共识标准，扩展了现有的ISO标准。当企业客户开始询问AI供应商的排放足迹时——这在采购问卷中已经发生——这就是团队将被要求报告的框架。2027年SBTi方法论更新将收紧拥有经过验证的基于科学目标的公司需要展示的内容。投资者驱动的ESG压力比监管授权移动得更快。

实用框架：将碳测量实施为基础设施可观测性，而非合规表演。工具已经成熟，标准已经足够清晰，拥有数据的组织效用（用于容量规划、成本优化和供应商谈判）已经足够高，值得为其自身的优点而去做。合规要求将跟随实践，而非反过来。

下周从哪里开始

最小可行测量设置需要三样东西：每次推理调用触发的token计数器、模型到碳强度的查找表（EcoLogits或DitchCarbon为主要提供商维护这些），以及接受carbon_gCO2e字段与现有延迟和成本指标一起的指标接收器。

从那里，最有价值的第一个查询是：你过去30天推理流量中按模型层级的碳排放明细是什么？答案几乎总是揭示，大量前沿模型调用正在处理更便宜、低排放模型就能够充分处理的任务。这一分析在可持续发展报告写出之前，就已经通过API成本节省来偿还自身了。

领先于这一变化的团队，不是那些等待法规强制进行测量的团队——而是那些早期建立监控、将其纳入正常容量规划、并建立组织词汇来讨论AI效率作为环境和财务指标的团队。