推理 Span 中缺失的 kWh 列：单次请求的碳归因

你的推理火焰图（inference flame graph）有一个成本轴，但没有能源轴。这种差距在某天早上之前都没问题，直到客户的采购团队给你发来一份包含 23 列供应商可持续性披露信息的电子表格，其中一列是 每 1,000 次推理的 kgCO2e。你没办法填那一格，你的供应商给出的答案是一篇方法论论文，而交易将在 9 天内关闭。你的平台团队磨练了两年的 token 成本仪表盘突然看起来像是解决了一个错误的问题。

这里的转变并非抽象的。可持续性披露正在从公司层面的汇总转向产品层面的颗粒度。第一波浪潮于 2025 年进入了 CSRD 和 ESRS，而第二波浪潮现在正冲击着 B2B 采购合同。构建了成本可观测性的工程组织即将发现，他们需要针对碳排放的可观测性，而这两者在同一个 span 上并非同一列。

它在 span 级别（而不仅仅是月度账单级别）之所以重要，是因为汇总的碳足迹对于工程决策毫无用处。CFO 的汇报线告诉你问题有多大；它不会告诉你哪个检索调用、哪个重排序器（reranker）、哪个投机草稿（speculative draft）或哪个推理努力层级是你智能体中耗能巨大的子树。如果你的唯一碳数据存在于季度的 PDF 中，优化对话就永远无法触及真正能改变这个数字的团队。

为什么成本列不能替代能源列

人们很容易认为 token 就是 token，美元追踪 token，因此美元追踪能源。事实并非如此，而且这种差距还会扩大。

第一个原因是硬件异质性。一旦计入 8-GPU 机箱内的宿主服务器，一块 H100 在芯片层面的功耗约为 700W，每块 GPU 的功耗则接近 1,275W。而 A100 的功耗为 400W。在不同代际硬件上运行的同一模型，对于相同的 token 输出，消耗的功率大不相同。推理工作负载通常受内存限制，因此芯片往往运行在峰值的 70% 左右，而不是满负荷的 TDP。这些变化都不会体现在你供应商的每 token 价格中，那是根据竞争压力和利润策略设定的，而不是由运行你批处理任务的硅片的物理特性决定的。

第二个原因是推理模型。来自 o3 或 DeepSeek-R1 的 500 个可见 token 的回答，可能隐藏了模型为了得出结论而消耗的数千个内部推理 token。最近的基准测试发现，在 o3 和 DeepSeek-R1 上处理长提示词的单次请求消耗超过 33 瓦时（watt-hours）——是单次 GPT-4.1-nano 调用的 70 多倍。这些推理成本有的按输出 token 计费，有的则不计费，从计费美元到消耗千瓦时的映射在单个供应商内部不再是线性的，更不用说跨供应商了。

第三个原因是电网。在夜间风力发电区域处理的请求，其碳强度仅为中午燃气调峰电厂处理的相同请求的一小部分。你的每 token 成本合同根本不知道批处理运行时 GPU 物理位置在哪，而供应商的可持续性页面报告的是年度平均值，掩盖了实际驱动边际排放的小时级波动。

成本是一种可观测指标。能源是另一种。碳排放是第三种，由能源、地点和时间推导而来。将其中任何一个视为其他指标的代名词只能帮你度过下个季度，而一旦客户提出精确的问题，这种做法就会失效。

你今天真正能给出的估算值

你无法从封闭 API 供应商那里获得单次请求的准确千瓦时。但你可以获得一个合理的估值，而合理的估值正是审计员、客户和内部产品团队真正需要的。

估算的构成非常直观。单次请求的能源是模型类别（决定了每 token 的瓦特系数）、token 数量（输入、输出，以及你能检测到的推理 token）、数据中心效率开销（PUE，超大规模运营商通常为 1.10 到 1.20）以及请求运行小时内的区域电网碳强度的函数。这些因素没有一个是精确的。但所有因素都在一定范围内，因此产生的估算具有实用的不确定区间，而不是胡乱猜测。

对于模型类别系数，现在已有 30 多个生产模型的公开基准测试，其数量级是清晰的：GPT-4.1-nano 在长提示词下约为 0.0005 kWh，中层对话模型在 0.001 到 0.003 kWh 之间，像 o3 这样的推理模型在处理难题时超过 0.03 kWh。选择一个系数，记录来源，并每季度复核一次。不要假装这个数字比实际情况更准确，也不要因为它是近似值就拒绝发布。采购电子表格里没有“我们还在研究方法论”这一格。

对于电网碳强度，主要依靠两个 API。Electricity Maps 提供全球电网区域的小时平均碳强度。WattTime 提供边际运营排放，它回答了一个不同且可能更相关的问题：如果不运行这个请求，可以避免多少排放？平均强度是合规披露的保守选择。边际强度则是碳感知调度（carbon-aware scheduling）的正确信号，在这种调度中，你可能会将非紧急的批处理任务移至更清洁的时段。选择一个，记录是哪个，不要在没说明的情况下切换。

对于供应商区域碳数据，Google Cloud 发布了每个区域的小时级无碳能源百分比，并将足迹数据导出到 BigQuery。Microsoft Azure 于 2025 年在门户中发布了 Carbon Optimization，提供 CSV 和 REST API。AWS 仍然没有提供真正的 API，仅报告基于市场的数据，这意味着你托管在 AWS 上的推理将需要第三方强度数据源，才能生成基于电网的数值。

应该与成本并列的 Span 属性

将能耗放在 Span 上而不是月度汇总中的重点在于，工程师是通过火焰图来寻找浪费的。如果一个追踪显示了 gen_ai.usage.input_tokens 和 gen_ai.usage.output_tokens 但没有能耗属性，那么优化讨论就是不完整的。你可以看到哪个子树花了钱，但你看不到哪个子树消耗了瓦时（watt-hours）。

OpenTelemetry 的 GenAI 语义规范在 2025 年围绕 Token 使用和模型识别属性趋于稳定。可持续性属性仍处于积极提案阶段——在 semantic-conventions 仓库中有一个公开的 Issue（#835）正在追踪硬件层面的能耗和碳指标，且 GenAI 规范尚未采用推荐的能耗属性。这正是你在标准跟进之前，在自己的收集器中需要填补的空白：在发送 Token 计数的同时，将 gen_ai.usage.energy_kwh 和 gen_ai.usage.co2e_g 作为 Span 属性发送，注明它们是估算值以及生成它们的方法论，然后发布。

收集器管道负责计算。你已经通过 gen_ai.request.model 知道了模型。你已经通过路由层知道了区域。你已经从供应商响应中知道了 Token 数量。乘以模型系数，乘以请求发生时的区域碳强度，然后附加到 Span 上。估算是有界限的，方法论是可审计的，现在火焰图拥有了可持续性问题所需的第三个维度。

这在实践中解锁了：一个检索 12 篇文档、通过重排序器运行并使用推理模型进行综合的查询，现在在智能体运行中明显是一个高能效消耗的子树。一个节省了 30% CPU 时间的 500ms 延迟优化，现在也是一个可衡量的碳足迹改进，而不仅仅是一个脚注。一个将平均推理 Token 减少 40% 的提示词修订，现在有了一个相关数字，可持续性团队可以将其放入下一份披露草案中。

不可或缺的采购对话

这一点的 B2B 侧是大多数工程团队低估的部分。CSRD 的第一个报告周期涵盖 2024 财年，报告于 2025 年提交，该指令的价值链条款将“范围 3”（Scope 3）披露义务下压至供应商——包括你的 AI 供应商，并传递到你的 AI 功能。2025 年年中的 ESRS 修订将强制性数据点减少了 57%，但保留了适用公司的“范围 3”气候披露。给供应商的信号是明确的：受监管市场的客户即将询问“使用你们服务的单次调用足迹是多少？”，而“我们稍后回复你”将不是一个可以接受的答案。

供应商的反应从“这是一个 API”到“这是一篇方法论论文”再到沉默。截至 2026 年初，OpenAI 和 Anthropic 都没有发布单次查询的能耗数据。OpenAI 的 CEO 在 2025 年年中表示 ChatGPT 的平均能耗为 0.34 Wh；紧接着 Google 给出 Gemini 文本提示的中位数为 0.24 Wh，每次请求 0.03 克二氧化碳当量（CO₂e）。这些只是公关辞令，不是工程输入——它们是没有前置条件的平均值，不会根据模型大小、提示词长度或区域而变化。如果你的客户审计师要求提供特定功能的单次调用足迹，“我们根据 CEO 的一条推文认为大约是 0.34 瓦时”绝不是他们所期待的证据。

随后的合同谈判有两种失败模式。第一种是工程团队承诺了平台无法产生的披露粒度，因为采购团队在签署合同前没有询问数据是否存在。第二种是平台团队等待供应商发布官方的单次调用数据，但这可能永远不会发生，因为供应商将模型架构和基础设施利用率视为商业秘密。摆脱这两者的出路是发布你自己的估算值并附带记录在案的方法论，将其视为采购团队可以引用的公开接口，并对其进行版本控制，以便方法论的改进不会追溯性地使之前的披露失效。

“以后再加”的实际代价

现在不做这件事的理由显而易见：估算是近似的，标准不成熟，法规仍在完善中，而且还有更高投资回报率（ROI）的工程投资。所有这些都是事实，但这些都无法改变截止日期。

“以后再加”在实践中的样子是：一份面向客户的可持续性调查问卷送达，平台团队有一周时间估算 40 个产品层面的单功能足迹，结果数字是从账单 CSV 中手动提取的，并且是由一个从未读过云碳足迹方法论的人匆忙完成的粗略 Token 估算。这些数字会出现在客户的供应商评分卡上。它们不会被修改。它们成为了衡量明年所谓改进的基准。

另一种选择是现在就在推理 Span 上添加一个 kWh 列，注明这是一个误差在 ±30% 以内的估算值，并按季度修订系数。这个数字在细节上可能不准确，但在大趋势上是正确的。这足以应付采购披露，足以推动内部优化讨论，也足以向审计师证明公司拥有一套测量方案，而不仅仅是一份新闻稿。在这个领域，正确的答案在今天是近似的。错误的答案是沉默，随后是临时拼凑，而在截止日期前的临时拼凑往往会让团队交出以后会后悔的数字。

kWh 列并不是什么复杂的底层架构。它只是你已经在发送的 Span 上的一个属性，根据你已有的数据计算得出，并连接到一个每月成本比小型云虚拟机还低的公开 API。它之所以还没有投入生产，是因为还没有人被迫这样做。这种情况正在改变，先行一步的团队将在明年完善方法论，而等待的团队将在明年解释为什么他们的答案是一段话而不是一个数字。