AI编程助手的真实功耗和运营成本

在整个 2025 年，我们对 AI 聊天机器人的用电量和用水量有了更准确的估算。关于这个话题，我可以引用各种各样的文章，但我尤其喜欢 Our World in Data 的 Hannah Ritchie 写的这篇博客文章。关于用电量：

简而言之，“除非你是极端重度用户，否则每天向 AI 提问在你的总用电足迹中仍然只是一个舍入误差。”

用水量方面的情况也类似。下面这段来自 Benjamin Todd：

普通美国人每天使用 1600 升水，因此，即使你每天发出 100 个提示词，按每个提示词消耗 2 毫升水计算，也只占你总用水量的 0.01%。淋浴一秒钟的用水量都要高得多。

总体而言，这些分析影响了我对个人使用 LLM 所造成环境影响的看法；如果我想减少个人碳足迹，那么每周少开几英里车，或者每年少坐一次飞机，效果都要好得多。对于使用 chatgpt.com 或 claude.ai 这类聊天界面的用户来说，这确实是正确的结论。

不过，每天 1 次、10 次或 100 次中位数水平的提示，与我个人使用 LLM 的情况相差了许多个数量级；用 Hannah Ritchie 的话来说，我很可能属于“极端重度用户”。我从事软件行业，大部分工作时间都会同时驱动两三个像 Claude Code 这样的编程智能体。因此，对我而言，更相关的问题是：一次典型的 Claude Code 会话会消耗多少能源？（本文不讨论用水量。）

要回答这类问题，整个过程中必须考虑大量因素、做出许多假设，还要使用各种简化表达。我会尽力在本文中逐一指出这些内容，但请理解，这终究只是某个普通人在周日下午做的餐巾纸估算。

编程智能体与“中位数查询”

简而言之：在这一节中，我会说明一次 Claude Code 会话消耗的能源应该比一次“中位数查询”高出许多个数量级。

Hannah Ritchie 引用的 Gemini 论文、Sam Altman 的博客文章，以及 Epoch AI 对 ChatGPT 4o 的分析，都提到了类似“中位数查询”或“典型提示词”的概念。这些来源对这类提示词用电量的粗略估算都在 0.3 Wh 左右——分别为 0.24、0.34 和 0.3。那么，什么是中位数查询？

Gemini 团队是这样说的：

为了计算某一天 Gemini Apps 文本提示词中位数的能耗，我们首先确定每个模型的平均单提示词能耗，然后按照这些模型的单提示词能耗值对其排序。接下来，我们沿着这份按能耗排序的列表构建文本提示词的累积分布，以找出承载第 50 百分位提示词的模型。

所以，他们取了第 50 百分位数来得到中位数。没错。至于 Sam Altman，完全没有提供任何细节。1

Gemini 团队的论文和 Sam Altman 的博客文章——这两个（理论上）能够接触真实数据的来源——有什么共同点？几乎都没有提供什么细节。“中位数”这个词在这里承担了太多解释工作。输入 token 有多少？系统提示词算进去了吗？核心系统提示词呢？输出 token 有多少？使用的是哪个模型？是否包括 Web Search 或 Deep Research 之类的系统？这是仅限 Web、仅限 API，还是两者都包括？给出 0.24 Wh 或 0.34 Wh 这样的数字，却不提供任何导致该数字的因素细节，让人感觉像是在刻意营造一种“已经给出了答案”的印象，同时又尽可能少地回答真正的问题。

无论如何，下面是一个“中位数查询”可能的样子：

USER: Tell me a joke about statisticians

ASSISTANT: A statistician is someone who, when their head is in the oven and their feet are in the freezer, says “on average, I feel fine.”

用户输入一些内容，模型作出响应。底层数千 token 量级的系统提示词大概已经被缓存，并且也被计入了这次“中位数查询”。

Claude Code 与此有何不同？

首先，是系统提示词以及对 Claude Code 可用工具的描述。刚刚在 Claude Code 中执行 /context 后，我看到的是：

⛀ ⛁ ⛁ ⛁ ⛁ ⛁ System prompt: 3.1k tokens (1.6%)

⛁ ⛁ ⛁ ⛁ ⛶ ⛁ System tools: 16.4k tokens (8.2%)

所以，甚至在用户输入查询之前，我们的上下文长度就已经接近 20,000 个 token。这些内容大概也已经在 Anthropic 那边完成了缓存或预填充。

除此之外，还有用户定义的工具和提示词。除了 CLAUDE.md 中大约 200 个 token 的内容之外，我还通过 Model Context Protocol 注册了 5 个工具。这 5 个工具的描述同样会消耗数千个 token：

⛶ ⛶ ⛶ ⛶ ⛶ ⛁ MCP tools: 2.6k tokens (1.3%)

好了，你明白了——使用 Claude Code 时，等到第一次请求真正开始执行，我们面对的已经是一个相当长的查询。

那么，Claude Code 是如何做事的？它会调用工具。例如，如果我说“Familiarize yourself, please!”，这条消息会连同系统提示词和所有工具描述一起发送到 Anthropic 的 API，然后模型会说“好的，我来看看”，并调用几个工具收集信息：

❯ Familiarize yourself, please!

⏺ I’ll take a look at the project structure to get oriented.

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

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

随后，我的笔记本电脑会自动处理这些请求，并代表我将包含工具调用结果的这条消息发回去：

⏺ Bash(ls -la /Users/simoncouch/Documents/rrr/website) ⎿ total 240 drwx——@ 3 simoncouch staff 96 Nov 11 13:59 _extensions … +60 lines (ctrl+o to expand)

⏺ Search(pattern: “**/*.qmd”) ⎿ Found 35 files (ctrl+o to expand)

接着，模型会看到这些结果（以及我的第一条消息、系统提示词和工具描述），然后再发起几个工具请求。这些请求返回结果后，又会形成一条用户消息（同时还会附带全部对话历史），如此循环，直到模型认为自己已经充分了解代码仓库，并向我总结它的发现。因此，我虽然只发送了一条消息，实际上却触发了一系列 5 到 10 次非常庞大的查询。

每当我读到“中位数查询”时，就会想到这一点。在我的 Claude Code 会话中，我可能会发送十几条消息，而每条消息又可能伴随大约 5 次工具调用（这些调用本身也是查询，所需的计算量与我亲自输入的查询相同），并且所有这些消息都极其庞大。一次 Claude Code 会话的计算密集程度似乎应该比一次“中位数查询”高出许多个数量级。

为了估算一次 Claude Code 会话的能源成本，我需要以某种方式，将中位数查询的瓦时数据扩展到一次 Claude Code 会话中数百次长度超过中位数的查询规模。我可以先反向拆解，估算不同类型 token 的单位 token 能耗。然后，我会分析自己的真实 Claude Code 会话数据（其中记录了每种 token 的实际用量），再把这些单位 token 数据放大到编程智能体的规模。

估算每个 token 的用电量

我从 Claude Code 中获得了大量数据，涵盖数百万个输入 token、缓存输入 token 和输出 token。我想根据自己使用该工具时实际消耗的 token 数量，对那些中位数查询的估算进行“缩放”。为此，我们会结合 Epoch AI 的一篇博客文章和 Anthropic 的 API 定价数据，得出一个推测值。

下面是 Anthropic 的定价数据，按每百万 token（MTok）计价：

我们重点来看 Epoch AI 给出的中等上下文长度情形，即输入 7,500 个单词，这大约相当于完整 Claude Code 系统提示词和工具描述的一半。他们估计，向 ChatGPT 4o 发出一次长查询（约 7,500 个单词，按每个 token 0.75 个单词计算，约为 10,000 个 token），并生成典型长度的输出（400 个单词，约为 530 个 token），会消耗 2.5 Wh。因此，将输入和输出 token 混合计算，总计为 10,530 个 token，即 0.01053 MTok。2.5 Wh / 0.01053 MTok 约为 240 Wh/MTok，这是混合计算的结果。

这些估算针对的是 GPT-4o。在过去一个月里，我使用 Claude Code 时几乎全部采用 Opus 4.5，它是 Anthropic 最大的模型（因此大概也是能耗最高的模型）。GPT-4o 发布时，输入价格为每 MTok 5 美元，输出价格为每 MTok 15 美元。Opus 4.5 的价格分别为 5 美元和 25 美元。Opus 可能是一个更大的模型，但其服务效率也很可能比 2024 年 5 月时所能实现的水平高得多。我会假设两者的单位 token 能耗大致处于同一数量级。

现在，我们实际上希望将其进一步拆分，分别得到输入 token 和输出 token 的 Wh/MTok。Anthropic API 对输出 token 的定价是输入 token 的 5 倍。这里我要做出的假设是：不同类型 token 的能耗，可以根据这些 token 的计费费率按比例缩放，从而得到合理的估算。2 我们有 (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

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

对短上下文和最大上下文两种情况进行上述计算，可以得到：

需要注意的是，输出与输入的能耗比不可能在不同输入长度下保持恒定。随着上下文增长，生成输出 token 的成本确实会增加（每个输出 token 的成本大致与上下文长度成正比），但处理提示词的成本增长得更快（大致与上下文长度的平方成正比）。这意味着，随着输入变长，“真实的”输出/输入每 token 瓦时比应该逐渐减小。这正是我们基于 Anthropic 定价所作的 5 倍假设发挥作用的地方。

在本文中，我会采用 100,000 token“最大”上下文情况下的数据来生成偏悲观的估算——Claude Sonnet 和 Opus 4.5 的上下文窗口都是 200,000 token，而我经常会触及这个上限。因此，输入约为 390 Wh/MTok，输出约为 1950 Wh/MTok。

不过，Claude Code 消耗的 token 中有很大一部分来自缓存命中和缓存刷新，而 Anthropic 对这部分的定价是输入 token 的十分之一。因此，我们粗略估算缓存输入约为 39 Wh/MTok。缓存写入也用同样的粗略算法；其定价比输入 token 高 25%，因此约为 490 Wh/MTok。我完全不知道这些猜测是否合理。

Claude Code 将会话日志存储在 ~/.claude/projects/ 中，每个会话都保存为一个 JSONL 文件，其中包含每次 API 调用的用量数据。每条日志记录都包含 input_tokens、output_tokens、cache_creation_input_tokens、cache_read_input_tokens，以及用于标识 HTTP 请求的 requestId。同一个请求会记录多个流式事件，且 token 数量完全相同，因此我们按 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,…

绘制每个会话中各类 token 的分布：

中位数会话包含 24 个请求，共消耗 592,439 个 token——其中有 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 Wh，是“一次典型查询”的 138 倍。

在一个典型工作日里，我通常会编程几个小时，并在这些时间里同时驱动两三个 Claude Code 实例。那么，我每天的能耗分布是怎样的？

据我估算，在能耗中位数对应的那一天，我通过 Claude Code 消耗了 1,300 Wh——相当于 4,400 次“典型查询”。（如果你想知道，这相当于一个典型工作日花费 15～20 美元的 token。）

所以，与耗电 0.3 Wh 的“一次典型查询”相比，我的 Claude Code 中位数会话大约耗电 41 Wh；而在一个使用 Claude Code 编程的典型工作日里，我大约会消耗 1,300 Wh。这与我每天从事的其他活动相比如何？

使用 Epoch AI 的同一组数据：

只展示 Claude Code 的“每日”用量，而不按相同时间尺度展示其他用途，多少有些不公平。下面是一张类似的图，其中加入了更多“每日”数据：

因此，如果要类比我使用编程 AI 智能体的能耗，它大致相当于每天多运行一次洗碗机、多开一台冰箱，或者少开一次车去杂货店，改骑自行车前往。对我来说，这与 Benjamin Todd 所说的，能源消耗是避免这种程度 AI 使用的“一个糟糕透顶的理由”，非常不同。这些确实会让我三思。

这里有几个非常重要的注意事项：

这些全都是基于其他研究人员估算结果的粗略计算，因为前沿实验室并未公布完整数据。他们理应公布。

用于为这些算力供电的能源结构，在很大程度上决定了这件事有多严重。如果算力主要由化石燃料驱动，那就是个问题；但如果主要由可再生能源驱动，我就不太介意。³ Hank Green 有一个很棒的视频讨论了这个问题。

正如 Benjamin Todd 所说：“从一开始，削减个人排放就是一种低效的气候变化应对方式。”如果我们想减少使用 LLM 对气候造成的影响，更有效的方式可能是支持推动绿色能源转型的倡议等。就这一点而言，我的处境确实有些微妙，因为我编写的软件让其他人更容易使用 LLM，而且我还会做相关演讲、撰写相关博客文章，诸如此类。不过，对本文的大多数读者来说，这一点可能并不适用。

就这一点而言，我的处境确实有些微妙，因为我编写的软件让其他人更容易使用 LLM，而且我还会做相关演讲、撰写相关博客文章，诸如此类。不过，对本文的大多数读者来说，这一点可能并不适用。

就我个人而言，我不确定这种规模的能源消耗（以及表面看来相应的用水量）是否大到足以让我减少对编程 AI 智能体的使用。⁴ 不过，它的规模确实足以促使我向那些致力于加速绿色能源转型、尤其关注 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 会话日志的解析是合理的，我决定同时根据 token 数据估算美元成本，并将结果与 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 报告的数字相差不到 1 美元。对我来说已经足够接近了。

附录：基础设施侧的合理性检查

相关文章的作者 Josh You 在回复本文时指出了另一个分析方向：从我的使用量外推 Anthropic 的推理总功率。按每天约 17.50 美元、每天约 1,300 Wh 计算，相当于每美元 75.5 Wh。以 Anthropic 每年约 100 亿美元的营收规模推算，推理功率约为 85 MW。

Anthropic 的数据中心总容量超过 1 GW，而 Josh 估计推理占比超过 8%（即超过 80 MW）。因此，85 MW 大致处于合理范围内，不过也可能偏低——订阅用户每美元获得的 token 可能比 API 定价所暗示的更多，这意味着实际推理能耗可能更高。（如果情况相反，也可能更低。）

根据 Epoch AI 的数据，他们假设一次查询包含 500 个输出 token 和少于 100 个输入 token，并且也明确说明了其他所有假设。谢谢你，Josh You。↩︎

根据 Epoch AI 的数据，他们假设一次查询包含 500 个输出 token 和少于 100 个输入 token，并且也明确说明了其他所有假设。谢谢你，Josh You。↩︎

这个做法其实相当草率。首先，输出 token 与输入 token 能耗的“真实”比率实际上并不存在，因为前者相对于上下文长度呈线性增长，而后者呈二次增长。此外，各家公司定价中的比率反映的是商业策略，而非真实比率。SemiAnalysis 的一项数据分析估算，在几千 token 的规模下，输出 token 的计算密集程度约为输入 token 的 15 倍。这让我认为，在数万 token 的规模下，5 倍是一个合理的估算。↩︎

这有点荒谬。首先，输出与输入 tokens 能耗的"真实"比率并不真的存在，因为前者相对上下文长度呈线性增长，而后者呈二次增长。此外，各家公司定价中的比率反映的是商业策略而非真实比率。SemiAnalysis 的数据分析估计，在几千个 tokens 的规模下，输出 tokens 的计算密集度约为输入 tokens 的 15 倍。这让我认为，在数万个 tokens 的规模下，5 倍是合理的。↩︎

如果这些能耗既由可再生能源驱动，又由本地电源而非完全从本地电网汲取，我就尤其不在意。在本地电网的情况下，基础设施改进往往更多由当地居民资助，而不是由 AI 公司资助。↩︎

如果这些能耗既由可再生能源驱动，又由本地电源而非完全从本地电网汲取，我就尤其不在意。在本地电网的情况下，基础设施改进往往更多由当地居民资助，而不是由 AI 公司资助。↩︎

对许多人来说，从 Anthropic 平台因超出 Max 计划用量而收到的账单金额，可能比这些能耗数据本身更能有效地影响用户决策。↩︎

对许多人来说，从 Anthropic 平台因超出 Max 计划用量而收到的账单金额，可能比这些能耗数据本身更能有效地影响用户决策。↩︎