构建一个有用的开发者工具存在这样一个问题：

如果只有一家公司能使用它，那它只是一个产品功能。

如果不同的系统能够产生和消费相同的信息，它就有潜力成为基础设施。

这就是我在 CarbonLayer 开发 Impact Receipt 概念时一直在思考的问题。

在第 3 部分《AI Impact Receipt 究竟应该包含什么？》中，我们探讨了 AI Impact Receipt 应该包含的内容：工作负载信息、模型身份、延迟、环境指标、方法论、来源和不确定性。

但识别有用的字段只是开始。

当两个 AI 提供商对同一概念有不同的描述时，会发生什么？

当两个系统返回使用完全不同的边界计算得出的碳值时，会发生什么？

当一个提供商根本没有足够的证据来计算一个值时，又会发生什么？

我们能否在不标准化误导性假设的前提下，标准化 AI Impact Receipt？

我认为这就是值得解决的问题。

• 标准化接口——而不一定是计算

让我们从一个区分开始。

我认为首要目标不应该是：

每个 AI 提供商都必须以完全相同的方式计算环境影响。

不同的提供商使用不同的硬件、工作负载、测量系统、数据来源和核算边界来运营。

通用的计算方法需要就仍在研究中的问题达成一致。

但也许我们可以从更实际的地方开始：

我们能否就如何描述我们所知道的、我们不知道的以及我们如何知道这些达成一致？

想象一个未来系统，它有一个可辩护的碳估算值。它可能将结果表示为：

{ "carbon": { "status": "available", "value": 14.7, "unit": "gCO2e", "evidenceType": "modeled", "methodology": { "name": "example-method", "version": "1.0" } } }

这是一个说明性设计，不是实际的 CarbonLayer API（应用程序编程接口） 响应或经过验证的排放结果。

重要的特征不是数字。

而是接收应用程序能够区分值、单位、证据类型和方法论。

一个共享接口可以让这些信息更容易交换，而不必假装每个提供商的计算都是等价的。

• 一致的 JSON 并不能保证结果具有可比性

假设三个假设的提供商返回环境数据：

{ "emissions": 0.0147 }

{ "impact": { "co2e_g": 14.7 } }

甚至在我们讨论测量之前，就已经存在集成问题。

这些是克还是千克？它们是 CO2 还是 CO2 当量？包含了哪些活动？

应用程序必须分别解释每个响应。

一个通用接口可以消除其中一些歧义。

但现在想象一下，每个提供商返回相同的 JSON 结构，却使用不同的核算边界。

一个只包含加速器电力。

另一个包含服务器和冷却开销。

第三类还包括额外的生命周期影响。

数据看起来是标准化的，但结果仍可能无法比较。

标准化语法并不等同于标准化含义。

这就是为什么来源、核算边界和方法论必须成为讨论的一部分。

• 最重要的字段可能是 "unavailable"

环境 API 可能犯的最大错误之一，是返回一个看起来精确的数字，却没有足够的支撑证据。

假设一个系统知道请求了哪个模型，但无法确定有多少电力可归因于该单次推理。

它应该返回一个默认能耗值吗？

它应该仅根据 token 数量推断碳排放吗？

它应该用零填充缺失的水资源数据吗？

一个提议的收据可以改为返回：

{ "impact": { "energy": { "status": "unavailable", "value": null, "unit": "kWh" }, "carbon": { "status": "unavailable", "value": null, "unit": "gCO2e" }, "water": { "status": "unavailable", "value": null, "unit": "mL" } } }

这个示例是一种提议的表示方式，并非 CarbonLayer 当前实现的响应契约。

为什么这很重要？

因为零是一个值；不可用是一种证据状态。

这两者绝不能互换。

一个允许显式缺失值的标准，会比一个迫使每个提供方填充每个字段的标准更值得信赖。

它还开辟了一条前进的道路：系统可以在尚未获得填充每个环境指标所需证据之前，先采用该接口。

• 实测、建模、推导和不可用是不同的东西

一个有用的未来规范应当区分几种证据类型。

实测：由有记录的测量过程支持的值，具有明确定义的边界。

建模：使用假设、系数或计算模型估算的值。

推导：由其他输入计算得出的值，其原始证据类型必须保持可追溯。

不可用：当前无法提供充分支持的值。

这些类别不应被视为可以互换。

考虑一个概念性计算：

归因于工作负载的能源 | v 电网碳强度 | v 计算得出的排放量

即使算术是正确的，结果也取决于输入的质量、覆盖范围和兼容性。

计算得出的排放值不会仅仅因为其某个输入是测量得到的，就变成直接测量。

增加小数位数也不会让估算更准确。

凭证需要保留结果背后的证据。

而当这些证据不足时，它应当明确说明。

• 方法论和版本管理很重要

设想一个组织在1月报告环境影响，并在6月再次报告。

第二个值更低。

工作负载是否变得更高效了？

基础设施是否发生了变化？

核算边界是否发生了变化？

还是方法论发生了变化？

如果没有方法论版本管理，趋势将难以解读。

未来的收据可能包含：

{ "methodology": { "id": "example-impact-method", "version": "1.0", "boundary": "documented-separately", "reference": " https://example.org/methodology " } }

再次强调，这只是一个示例性 schema，并不代表 CarbonLayer 已实施或验证了该方法论。

目标是让变化可见，而不是静默地混合不兼容的结果。

规范还应定义当方法论被弃用、数据源发生变化或历史值被重新计算时会发生什么。

没有方法论的数值难以验证。没有方法论版本的数值难以随时间进行比较。

• 位置很重要——但隐私同样重要

计算基础设施的环境特征可能取决于位置、时间、电力供应和系统边界。

这表明位置上下文在影响回执（Impact Receipt）中可能很有用。

但这里有一个复杂之处。

环境核算所需的位置，并不一定是提供商应向每个 API 消费者披露的位置。

未来的规范可能需要支持不同详细程度：

电网区域

国家级信息

受限或未披露的位置

它还需要识别某个位置代表的是实际执行站点、计费区域、建模假设，还是其他内容。

否则，开发者可能会错误地将路由标签解读为计算实际发生位置的证据。

这是一个很好的例子，说明标准化是一个语义问题，而不仅仅是 JSON 设计问题。

• 最小回执应将已知事实与影响声明分开

与其要求每个环境字段，我会从分离三个层次开始：

AI REQUEST / DECISION
               |
               v
   +-----------------------+
   | Operational context   |
   |-----------------------|
   | Identifier            |
   | Timestamp             |
   | Model / route context |
   | Workload metadata     |
   +-----------------------+
               |
               v
   +-----------------------+
   | Environmental status  |
   |-----------------------|
   | Energy: unavailable   |
   | Carbon: unavailable   |
   | Water: unavailable    |
   +-----------------------+
               |
               v
   +-----------------------+
   | Evidence & semantics  |
   |-----------------------|
   | Data provenance       |
   | Methodology / version |
   | Accounting boundary   |
   | Completeness          |
   +-----------------------+

这是一个提议的架构，并非 CarbonLayer 当前已发布的每次推理收据系统的示意图。

注意一个重要的事情。

即使环境影响值不可用，运营信息仍然可能有用。

开发者或许能够检查路由决策、延迟信息、请求标识符和数据完整性，而无需假装这些字段能够确定碳足迹。

这种分离可以使接口更有用，也更诚实。

• 现有标准能教给我们什么

我们不需要从零开始发明每一个概念。

若干现有工作提供了有用的基础。

OpenTelemetry 的 Generative AI Semantic Conventions 为描述 AI 操作、模型相关属性和遥测提供了有用的参考。

Impact Receipt 提案应研究如何复用兼容的可观测性概念，而不是引入不必要的竞争性术语。

然而，与可观测性约定的兼容性本身并不能验证环境计算。

软件碳强度

绿色软件基金会（Green Software Foundation）的软件碳强度（Software Carbon Intensity）规范提供了一种表达软件碳强度的方法，包括已定义的边界和功能单位。

它提供了关于方法论和归一化的重要经验。

但引用 SCI 并不意味着某个特定的推理凭证就是 SCI 分数，也不意味着某个产品符合该规范。

CodeCarbon 展示了估算与计算工作负载相关排放的方法。

它是一个有用的例子，说明了为什么数据来源、假设和工作负载边界很重要。

但工作负载级别的估算方法并不能自动为每个单独的 API 请求建立可辩护的归因。

这些努力提供了构建模块。

它们并不能自动建立一个通用、可互操作、经过验证的每次推理影响凭证标准。

这仍然是一个开放的设计问题。

• 开发者最终可以构建什么？

如果出现一种有用且可互操作的凭证格式——并且提供商提供了充分的证据——它可以支持多种工作流程。

可观测性：结合模型和路由上下文，检查环境数据的可用性和来源。

模型选择：比较运营权衡，并在存在可辩护的测量或估算时，调查环境差异。

CI/CD 评估：在将环境指标用作自动化决策输入之前，跟踪方法变更、数据完整性和可复现性。

报告：聚合兼容的观测数据，不要将缺失值静默视为零，也不要混合不兼容的边界。

路由：使用受支持的指标和明确声明的约束，为应用层决策提供信息。

这些是未来接口的可能应用。

它们并不声称 CarbonLayer 当前提供经过验证的环境优化、已证明的节省，或每个工作流的生产就绪版本。

任何实现都需要确定哪些指标是实际观测的、哪些是建模的，以及哪些仍然不可用。

• CarbonLayer 目前的定位

CarbonLayer 正在探索 AI 路由决策、运营可观测性和环境责任最终如何协同工作。

目前，CarbonLayer 有两个不同的演示界面。

/api/inference 端点返回模拟的、说明性的路由元数据。它不执行生产推理工作负载，也不提供经过验证的环境影响测量。

另外，Playground 支持成本和延迟场景。配置后，它可能会直接调用 AI 提供商。这并不意味着 CarbonLayer 正在路由生产工作负载或测量其环境影响。

每次推理的能耗、碳排放和水资源消耗数值仍然无法提供，因为 CarbonLayer 没有经过验证的请求到千瓦时归因方法。

生产环境中每次推理的影响回执（Impact Receipt）仍然是未来的能力。

这一区分很重要。

未来的影响回执应保留模拟决策、观测到的运营数据、建模的环境数值以及不可用证据之间的差异。

一个接口应该能够表达：

我们可以描述路由场景。

我们可以识别哪些运营信息是可用的。

我们无法证实这一次推理的环境影响。

这比附上一个看起来可信但无法辩护的碳数值更有用。

而且它提出了一个有趣的可能性：

也许影响回执的第一个真正有用的贡献并不是一个碳数值。

也许它是一种区分证据与假设的共享方式。

• 过早标准化的危险

标准可以使数据更容易交换。

它也可能使薄弱的数据显得更具权威性。

如果每个 AI 提供商都返回一个名为 carbon.value 的字段，开发者可能会认为这些值是可比较的。

但如果一个提供商使用物理测量，另一个使用全舰队平均值，而第三个使用基于 token 的代理值呢？

一个通用的字段名并不能解决这些差异。

因此，一个可信的规范需要回答一些棘手的问题：

什么才算是测量值？

必须披露哪些边界？

建模值和派生值如何标记？

字段何时应该不可用？

为了可复现性，需要哪些信息？

如何在不编造置信度分数的情况下表示不确定性？

如何防止不兼容的结果被聚合？

哪些运营或地理信息可以安全披露？

接口应如何演进而不破坏现有消费者？

在任何人宣布胜利之前，这些问题都值得回答。

• 下一步不是宣布一项标准

而是提出开发者可以质疑的东西。

一个小的、可检查的、机器可读的契约。

一个明确支持不可用环境数据的契约。

一个使证据类型和方法论可见的契约。

一个不会将模拟决策与已验证的物理结果混淆的契约。

一个可以独立于 CarbonLayer 实现的契约。

而不是仅仅因为某家公司发布了它，就宣称其具有权威性。

如果开发者对结构有异议，这是有用的。

如果他们发现了歧义，这是有用的。

如果他们识别出一个会助长误导性比较的字段，那尤其有用。

因为目标不应该是让每个 AI 系统都返回同样令人印象深刻的数字。

目标应该是让每一个返回的声明都可理解、可追溯，并得到适当的限定。

让我们把影响元数据放入一个开放 API 规范中

我们已经探讨了影响回执（Impact Receipt）可以包含什么。

我们已经审视了来源、方法论、缺失值和互操作性方面的问题。

现在是时候把这些问题转化为一个具体的提案了。

在第 5 部分中，我们将概述一个机器可读接口的草案，开发者可以检查、质疑并有可能实现它。

这不是一个已被采纳的行业标准。

并非声称 CarbonLayer 已解决单次推理的环境影响测量问题。

而是开放技术讨论的起点。

因为在 AI 基础设施能够使环境影响具有可比性之前，我们需要在一个更根本的问题上达成共识：

该声明必须附带哪些证据？

帮助塑造 CarbonLayer 的下一步构建方向

我们也在邀请使用 AI 应用程序编程接口（API）、LLM 应用、推理基础设施和开发者工具的开发者分享他们的经验。

AI 集成在哪些地方变得不必要地复杂？

你如何评估成本、延迟和可靠性？

你希望你的 AI 提供商公开哪些信息？

更透明的路由和影响元数据是否真的有助于你的工作流程？

我们准备了一份简短的 7 题开发者调查，以了解在决定下一步构建什么之前，什么最重要。

参与 CarbonLayer 开发者调查

你的反馈将帮助我们理解真实的开发者需求，挑战我们的假设，并优先开发有用的能力。

你不需要使用 CarbonLayer 即可参与。我们有兴趣听取使用不同工具、提供商和视角的开发者的意见。

如果你认为 AI Impact Receipt 是错误的做法——或者认为我们遗漏了一个根本性问题——我们尤其希望听到原因。

更好的基础设施始于更好的问题。

CarbonLayer 探索 AI 路由、决策透明度，以及让环境影响数据可信所面临的挑战。

探索 CarbonLayer | 在 DEV.to 上关注 Impact Receipt 系列 | 开发者调查

第 4 部分，共 5 部分 — Impact Receipt 系列

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：DEV.to

原创地址：https://dev.to/carbonlayer/can-an-ai-impact-receipt-be-standardized-3c7a