AI 编码代理的电力使用

编码代理与“中位查询”

Gemini 论文 、Sam Altman 博客文章和 Epoch AI 对 ChatGPT 4o 的分析 （Hannah Ritchie 引用）都提到类似“中位查询”或“典型提示”的概念。这些不同来源都将此类提示的电力使用量估算在约 0.3 瓦时——分别为 0.24、0.34 和 0.3。什么是中位查询？

来自 Gemini 团队：

为了计算某一天中位数 Gemini 应用文本提示的能耗，我们首先确定每个模型的平均每条提示能耗，然后按每条提示能耗对这些模型进行排序。接着我们沿着按能耗排序的模型列表构建文本提示的累积分布，以识别处于第 50 百分位的提示所使用的模型。

所以，他们用第 50 百分位来得到中位数。没错。来自 Sam Altman 的说明，完全没有细节。¹

Gemini 团队的论文和 Sam Altman 的博客文章——这两个（假设上）掌握真实数据的来源——有什么共同点？极少的细节。“中位数”在这里承担了非常大的作用。输入令牌是多少？我们是否计入 system prompt？核心系统提示？输出令牌是多少？使用的是哪个模型？这是否包括像 Web Search 或 Deep Research 这样的系统？这是仅限网页、仅限 API，还是两者都包括？给出像 0.24 Wh 或 0.34 Wh 这样的数字，却对导致该数字的各种因素只字不提，感觉像是故意“给了一个答案”，同时尽量少回答实际问题。

我在发牢骚。

无论如何，下面是一个“中等查询”的示例印象：

用户：给我讲一个关于统计学家的笑话

助手：统计学家就是那种头伸进烤箱、脚放进冰箱时会说“平均来看，我感觉很好”的人。

用户输入内容，模型回应。可以推测，底层的系统提示（大约数千个标记）被缓存，并包含在这个“中位查询”中。

Claude Code 与此有何不同？

首先，Claude Code 有系统提示和对可用工具的描述。刚才在 Claude Code 中对 /context 的响应，我看到的是：

⛀ ⛁ ⛁ ⛁ ⛁ ⛁ 系统提示：
3.1k 令牌（1.6%）

⛁ ⛁ ⛁ ⛁ ⛶ ⛁ 系统工具：
16.4k 令牌（8.2%）

所以，在用户甚至输入查询之前，我们的上下文长度已经接近 20,000 个标记。这些大概也已在 Anthropic 端被缓存/预填。

然后，还有用户自定义的工具和提示。我通过协议注册了 5 个工具，此外我的 CLAUDE.md 大约有 200 个标记。这 5 个工具的工具描述也消耗了数千个标记：

⛶ ⛶ ⛶ ⛶ ⛶ ⛁ MCP 工具：2.6k 标记（1.3%）

好，你明白了——使用 Claude Code 时，在我们启动第一个请求时，查询已经相对较长。

那么，Claude Code 是如何工作的？它 调用工具 。例如，如果我说“请熟悉一下！”，该消息会连同系统提示和所有工具描述一起发送到 Anthropic 的 API，然后模型会说“好的，我会去做”，并调用几个工具来收集信息：

❯ 请熟悉一下！

⏺ 我会查看项目结构以便熟悉环境。

⏺ Bash(ls -la /Users/simoncouch/Documents/rrr/website)

⏺ Search(pattern: “**/*.qmd”)

作为回复，我的笔记本电脑会自动处理这些请求，并代表我将带有工具调用结果的这条消息发回

⏺ Bash(ls -la /Users/simoncouch/Documents/rrr/website)
⎿ 总计 240
drwx——@ 3 simoncouch 五线谱 96 11 月 11 13:59
_extensions
… +60 行（按 Ctrl+O 展开）

⏺ 搜索(pattern: “**/*.qmd”)
⎿ 找到 35 个文件（按 Ctrl+O 展开）

然后模型会看到这些结果（除了我的第一条信息、系统提示和工具说明之外），接着再发起另外几次工具请求。这些请求会返回结果，成为另一条用户消息（以及全部会话历史），如此反复，直到模型认为它已充分查看代码仓库并向我汇报它所发现的内容。所以， 在发送一条信息的同时，我实际上触发了一系列 5 到 10 次非常大的查询 。

每当我看到“中位查询”这个词时，我就会想到这点。在我与 Claude Code 的会话中，我可能会发送十来条消息，而每条消息通常伴随着大约 5 次工具调用（这些调用也是查询，需要与我自己输入的查询同等的计算），而且所有这些消息都非常长。似乎一次 Claude Code 会话的计算强度应该比“中位查询”高出好几个数量级。

为了尝试估算一次 Claude Code 会话的能耗，我需要以某种方式将中位查询的瓦时数放大到 Claude Code 会话中数百条长于中位的查询的规模上。我可以先通过向后缩放来尝试，估算各种类型 token 的每个 token 的能耗。然后，我会分析我真实的 Claude Code 会话数据（其中包含每类 token 的真实使用量），并将这些每 token 的数值放大到编码代理的规模。

估算每个 token 的用电量

来自 Claude Code，我有大量关于数百万输入、缓存输入和输出令牌的数据。我想把那些中位查询估计值“缩放”到我实际使用该工具时消耗的令牌数。为此，我们将使用 Epoch AI 的一篇博文和 Anthropic 的 API 定价数据来拼凑一个估算。

这是图表：

这是 Anthropic 的定价数据，按百万令牌（MTok）定价：

让我们关注 Epoch AI 报告的中等上下文长度情况，即 7,500 个输入词，大约相当于完整 Claude Code 系统提示和工具说明的一半。他们估计对 ChatGPT 4o 的一次长查询（约 7,500 词，或按每 0.75 词/代币计算约 10,000 代币），在典型输出长度（400 词，或约 530 代币）下消耗 2.5 瓦时。因此，将输入和输出代币合并计算，总计约 10,530 代币，或 0.01053 MTok。2.5 瓦时 / 0.01053 MTok 大约为 240 瓦时/MTok（合并）。

现在，我们实际上想把输入令牌和输出令牌分别按 Wh/MTok 拆分开来。Anthropic 的 API 将输出令牌的价格定为输入令牌的 5 倍。我在这里假设，不同类型令牌的能耗可以通过按这些令牌的计费比率进行缩放来合理估算。² 我们有 (input_tokens × input_rate) + (output_tokens × output_rate) = total_Wh 且 output_rate = 5 × input_rate，可以把第二个代入第一个得到：

input_rate = 2.5 / (0.01 + 5 × 0.00053)
input_rate = 2.5 / (0.01 + 0.00265)
input_rate = 2.5 / 0.01265
input_rate ≈ 198 Wh/MTok

因此，输入约为 200 Wh/MTok，输出约为 990 Wh/MTok。

对短上下文和最大上下文情形进行同样计算后，我们得到：

现在请注意， 输出与输入的能耗比在不同输入长度下保持不变是没有道理的。 随着上下文增长，生成输出令牌的成本确实会上升（大致与每个输出令牌的上下文长度成正比），但处理提示词的成本增长更快（大致随上下文长度的平方增长）。这意味着“真实”的每令牌输出/输入瓦时比率应当随着输入变长而缩小。这就是我们基于 Anthropic 定价的 5 倍假设在起作用。

在本文中，我将使用来自 100,000“最大”——Claude Sonnet 和 Opus 4.5 的上下文窗口均为 200,000 令牌，我也经常碰到这个限制——的数据来生成悲观估算。因此，约为每百万令牌输入 390 瓦时，输出约每百万令牌 1950 瓦时。

现在，Claude Code 消耗的大部分令牌是缓存命中和刷新，而 Anthropic 将其定价为输入令牌成本的十分之一 。所以，我们把缓存命中大致估算为每百万令牌约 39 瓦时。缓存写入做同样的粗略计算；他们对缓存写入定价比输入令牌溢价 25%，所以约为每百万令牌 490 瓦时。我不知道这些估算是否合理。

我的 Claude Code 数据

Claude Code 将会话日志存储在 ~/.claude/projects/，每个会话以 JSONL 文件保存，包含每次 API 调用的使用数据。每个日志条目包括 input_tokens、output_tokens、cache_creation_input_tokens、cache_read_input_tokens，以及标识该 HTTP 请求的 requestId。每个请求会记录多个流式事件且代币计数相同，因此我们按 requestId 去重。

library(tidyverse)

usage_raw <- read_csv("sessions/calls.csv", show_col_types = FALSE)

usage <-
  usage_raw |>
  distinct(request_id, .keep_all = TRUE)

glimpse(sample_n(usage, nrow(usage)))

Rows: 8,825
Columns: 10
$ project               <chr> "-Users-simoncouch-Documents-rrr-revie…
$ session_id            <chr> "d080a7ee-9a32-4c70-b545-fe73ffbc509c"…
$ request_id            <chr> "req_011CWvAd2XAozayRf1h5EwWC", "req_0…
$ timestamp             <dttm> 2026-01-08 15:43:02, 2026-01-08 15:40…
$ model                 <chr> "claude-opus-4-5-20251101", "claude-op…
$ input_tokens          <dbl> 1, 1, 1, 4075, 63, 1, 8, 1, 10, 7, 1, …
$ output_tokens         <dbl> 90, 90, 84, 2, 4, 24, 1, 90, 7, 1, 88,…
$ cache_creation_tokens <dbl> 148, 148, 142, 0, 4843, 147, 761, 148,…
$ cache_read_tokens     <dbl> 56388, 52628, 31827, 0, 39901, 69360, …
$ cost_usd              <dbl> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,…

绘制每种代币类型在每次会话中的分布：

中位会话有 24 次请求，总计消耗 592,439 个代币——5 条用户消息和 19 次工具调用响应。应用我们的粗略能耗估算：

wh_per_mtok <- c(
  input = 390,
  output = 1950,
  cache_creation = 490,
  cache_read = 39
)

median_energy_wh <-
  median_session$input_tokens * wh_per_mtok[["input"]] / 1e6 +
  median_session$output_tokens * wh_per_mtok[["output"]] / 1e6 +
  median_session$cache_creation_tokens * wh_per_mtok[["cache_creation"]] / 1e6 +
  median_session$cache_read_tokens * wh_per_mtok[["cache_read"]] / 1e6

我的估计是，我的中位 Claude Code 会话消耗 41 瓦时，是“典型查询”的 138 倍。

在一个典型的工作日里，我通常会编程几个小时，并在这些时间里同时运行 2 到 3 个 Claude Code 实例。我的每日能耗分布是怎样的？

在一个中位数的日子里，我估计通过 Claude Code 消耗了 1,300 瓦时——相当于 4,400 次“典型查询”。（供好奇者参考，这在典型一天里大约相当于 15 到 20 美元的代币开销。）

语境说明

所以，与每次“典型查询”0.3 瓦时相比，我的中位 Claude Code 会话大约是 41 瓦时，在一个典型的 Claude Code 编程日里，我消耗大约 1,300 瓦时。这与我每天做的其他事情相比如何？

使用 来自 Epoch AI 的相同数据 :

把 Claude Code 的“每日”使用量单独拿出来展示而不给其他用量同样的时间尺度，有点不公平。下面是一个类似的图表，加入了更多“每日”数据：

所以，如果我想把我使用编码代理的能源消耗做个类比，那大概相当于是每天额外多开一次洗碗机、多养一台冰箱，或者把一次开车去超市改为骑自行车。对我而言，这与 Benjamin Todd 所说的“避免”这种程度的 AI 使用的“可怕理由”截然不同。这些才是会让我三思的事情。

有几点非常重要的注意事项：

1. 这些只是基于其他研究者估计的粗略计算，因为前沿实验室并不公布全面数据。他们应当公布这些数据。
2. 为这些计算供能的能源结构在很大程度上决定了问题的严重性。如果这些计算主要由化石燃料驱动，那就是个问题；但如果主要由可再生能源驱动，我就不太担心。³ Hank Green 有一个很棒的视频讨论这个话题。
3. 正如 Benjamin Todd 所言 ，“单纯削减个体排放本身就是一种低效的抗击气候变化方式。” 如果我们想减少使用 LLM 对气候的影响，可能更有效的做法是例如支持绿色能源转型的倡导工作。
   • 我对这一点确实有种奇怪的关系，因为我编写的软件让其他人更容易使用 LLMs，我也就此做演讲、写博客等等。不过对本文的大多数读者而言，这可能并不适用。

就我个人而言，我并不认为这种规模的能源（以及表面看来可能的用水）消耗足以让我减少使用编码代理的频率。⁴ 话虽如此，这确实足以促使我向致力于加速绿色能源转型的组织捐赠，特别是与 AI 相关的，比如 ClimateAction.tech、Green Web Foundation、Clean Grid Alliance、Sierra Club、Natural Resources Defense Council (NRDC)、Earthjustice、RMI (Rocky Mountain Institute)、350.org 和 Clean Energy States Alliance。

附录：成本核查

为了确认我对 Claude 会话日志的解析是否合理，我还决定用我们的代币数据估算美元成本，并将结果与 ccusage 报告的进行比较。

pricing <- tribble(
  ~model,                        ~input, ~output,
  "claude-opus-4-5-20251101",    5,      25,
  "claude-sonnet-4-5-20250929",  3,      15,
  "claude-haiku-4-5-20251001",   1,      5
) |>
  mutate(
    cache_creation = input * 1.25,
    cache_read = input * 0.10
  )

estimated_cost <-
  usage |>
  filter(as_date(timestamp) >= "2025-12-19") |>
  left_join(pricing, by = "model") |>
  summarize(
    cost_usd = sum(
      input_tokens * input / 1e6 +
      output_tokens * output / 1e6 +
      cache_creation_tokens * cache_creation / 1e6 +
      cache_read_tokens * cache_read / 1e6,
      na.rm = TRUE
    )
  )

estimated_cost

# A tibble: 1 × 1
  cost_usd
     <dbl>
1     481.

我估计过去一个月的费用为 480.64 美元，与 ccusage 报告的数额相差不到一美元。对我来说已经足够接近。

附录：基础设施端的直觉检验

链接到 Epoch AI 帖子的作者 Josh You 在对这篇文章的回复中指出了另一种可从该角度切入的方法 ：从我的使用量外推到 Anthropic 的总推理算力。以大约 17.50 美元/天和约 1,300 瓦时/天计算，约为每美元 75.5 瓦时。按 Anthropic 约 100 亿美元的年收入推算，推理耗电约为 85 兆瓦。

Anthropic 的数据中心总容量超过 1 吉瓦，Josh 估计推理占比超过 8%（即超过 80 兆瓦）。因此 85 兆瓦在大致范围内，尽管可能偏低——订阅用户每美元可能获得的 token 比 API 定价显示的更多，这意味着实际推理能耗可能更高。（相反情况则可能更低。）