每次运行的能耗与碳排

每条提示的数字是一个边界，而你必须把它说出来。

Google 在 2025 年对自家服务栈做的测量，是目前边界划得最仔细的一份公开数字，也是这个问题最清楚的例证。头条数字是 Gemini Apps 一条中位数文本提示约 0.24 Wh，外加约 0.26 毫升水。同一篇论文里，若只计入活跃加速器，同一条提示是 0.10 Wh——Google 自己把它称作乐观的那个数，因为它扔掉了主机 CPU、空置的已配置容量，以及数据中心的开销。

• 0.24 Wh 排除了什么，和它包含了什么一样重要：网络传输、用户设备、模型训练与数据存储全都在边界之外。它们没有哪一项是零，而其中两项是你的。
• 独立估算落在一个数量级之外。某个第三方计算器把一条 400 词元、发给一个具备推理能力的大模型的提示算到约 14.6 Wh。这不是谁说了假话的证据；这是「每条提示的能耗」在你指明模型规模、输出长度、利用率假设与开销系数之前根本未被充分定义的证据。
• 效率改进比你的电子表格跑得快。Google 报告称十二个月内每条提示的能耗下降了约 33 倍。任何被你硬编码进可持续发展报告的数字，两个季度内就会是错的，而且是朝着有利方向错——这正是「发布方法而不是常数」的理由。
• 推理改变的是算式，不只是余量。延长思考会增加那些既计费又耗电、却不出现在答案里的输出词元，而已发布的、开启推理后的查询估算会跑到几十瓦时的量级。于是你那个实际生效的默认 effort 档位就是一个能耗参数，而多数团队从未刻意设置过它。

你的单位是一次运行，而那个乘数就是故事的全部。

所有公开的「每条提示」数字，量的都是单轮聊天交互。而一个把任务做完的智能体是另一种东西：一圈模型调用，每一次都重新发送一份自上次以来又长大了的上下文，再加上工具调用、重试，以及没人数过的那些子智能体。

# The only unit that means anything

  Wh per completed task
    = (model calls per run)
    x (tokens per call, input + output)
    x (Wh per token, with a stated boundary)
    / (task success rate)

# Why the first line dominates everything else

  chatbot turn        1 call      ~1x
  short agent task    8-15 calls  ~10x
  long agent task     40+ calls   ~40x
  failed run          same cost, divided by zero value
  retry storm         unbounded

# The denominator is not decoration
  a 70% success rate inflates the real per-task
  figure by 1.43x before anything else is counted

• 输入词元才是大头，而且是被重复发送的。在一个二十步的循环里，同一份系统提示、工具 schema 与累积下来的历史，每一次调用都要重新发一遍。所有人测的那条提示是你只发一次的那条；而你重发二十次的那份上下文，才是真正在烧的那份。
• 要除以成功率，就像单位经济学对钱做的那样。花在什么也没产出的运行上的能耗，依然是能耗。一个完成率 70% 的部署，在每一个真正的任务上都在多付 43% 的附加费，而这一项修正比几乎任何换模型省下的量都大。
• 把扇出数进来。子智能体、并行工具调用、评估通路里的评判模型、重排序——它们消耗的模型时间全都被「每条提示的成本」这个心智模型漏掉了。能耗核算与成本归因有同一个盲点，也有同一个解法：要么让它穿过扇出传播，要么就别报总数。

从你自己的追踪里搭这个估算，而不是从厂商页面上抄。

这次测量里难的那一半你本来就有了。每次运行的词元数就在你的追踪里；你缺的是一个换算系数，以及一致地使用它的纪律。

• 从追踪里取「每个已完成任务的词元数」，不要从账单里取。账单聚合在错误的粒度上，并且会以一种掩盖「被重发的上下文」的方式把缓存折扣抹平。你的追踪库里每个 span 都有输入、输出与缓存读取词元；按 run id 求和，并保留 p50 与 p95，因为能耗就在长尾里。
• 挑一个换算系数，并给它做版本。从一个规模可比的模型的、边界划得最仔细的公开数字里推出「每千词元多少瓦时」，记下你用的是哪个数字、哪个边界，并且只在有意为之时才改它。一个一致的、有记录的、略微偏差的系数是可审计的；一个每季度悄悄变好的系数不是。
• 自托管推理是你唯一真能测的情形。如果你自己跑 GPU，这件事就不再是估算了：节点级功率除以已完成任务数是一次直接测量，而这是通向一个站得住脚的数字的唯一路径。这是支持自托管推理那条路线的一个真实论点，并且它随附一项义务：必须把空闲时间算进来——一张预留的 GPU 在两次运行之间也在烧电，而低流量部署的足迹其实就住在那里。
• 不要去建数据中心的模型。PUE、水耗与电网结构是供应方该公布、你该引用的。把你的估算搭成「词元 × 系数」，让系数去承载基础设施假设，这样供应方更新一次披露，对你只是改一行，而不是重新推导一遍。

碳排和能耗是两个不同的数字，而其间的落差是一次核算选择。

把瓦时换成排放会引入第二个边界决定，而对同一份完全相同的工作负载，两种标准答案可以差出好几倍。

• 基于地点的核算用的是算力实际运行所在地的电网强度。它是物理上诚实的那个数，并且会随区域与时段变动。
• 基于市场的核算套用的是供应方采购的可再生能源凭证。它是多数厂商披露会先摆出来的那个数，并且可以在当地电网正在烧天然气时逼近零。
• 两个都报，否则你会被要求补上。任何认真到会来问这个数字的采购或 ESG 流程，都认真到知道这两者的区别，而只给出好看的那一个，是最快失去这场对话的方式。请把它们放在同一张表里，标好名字。
• 选区域是一根你可能拉不动的杠杆。把推理路由到低强度电网能实质削减基于地点的排放——而它会与数据驻留义务、供应方容量以及延迟预算正面冲撞。在它根本可用的那些地方，通常也只对批处理可用而不对交互式运行可用；批处理与异步推理才是真能用上它的那个形状。

各条杠杆，按重要性排序——而模型规模靠近最底下。

一旦单位从提示变成运行，各项干预的排序就与直觉反了过来。线以上的每一项都在打那个乘数；线以下的每一项打的是单次调用成本，而那是较小的那一项。

# Ranked by effect on Wh per completed task

1  raise the success rate        removes whole wasted runs
2  cut retries and loops         retry storms are unbounded
3  stop early, deliberately      a deadline is an energy budget
4  raise the cache hit rate      re-sent context is most of the tokens
5  shrink what you re-send       prune history, shape tool results
6  set the effort level          reasoning tokens are real tokens
7  route the easy tasks down     a small model for the high-volume step
8  choose a smaller model        last, and smallest effect

# The two that look like savings and are not
  shorter answers      output is the minority of tokens
  cheaper provider     a price change is not an energy change

• 提示缓存是一项能耗控制，不只是成本控制。在被重发的上下文上命中缓存会跳过预填充计算，而那正是一圈智能体循环里大部分工作真正发生的地方——这笔账在上下文缓存经济学里算透了，而物理上的节省与金钱上的节省贴合得足够紧，可以共用同一张看板。
• 重试放大是最坏情况，也是最容易漏掉的。一个重发着不断变大的上下文、并在失败时重试的循环，失败所耗的能可以超过十次成功运行；请在截止时间预算已经在执行的地方给它设上限，而不是另造一套机制。
• 把高频步骤路由给小模型。分类、路由、抽取与重排序是你调用得最频繁的那些，也是小模型处理得好的那些。这是唯一一个背后带着真实乘数的「模型规模」决定，恰恰因为它作用在那个频繁的步骤上，而不是那个推理的步骤上。
• 抵制那些做姿态的修法。要求模型把答案写短，几乎挪不动一个由输入词元主导的数字；而换一个更便宜的供应方，改的是你的账单，一焦耳也不会变。这两样之所以流行，是因为它们容易对外宣布。

把披露写成能熬过一份采购问卷的样子。

做上面这一切的理由是：总会有人来问——某个客户的 ESG 附件、一次公共部门招标、一轮内部报告周期——而答案一周内就要交。一套你能复述的方法，比一个你无法辩护的数字值钱。

# The disclosure, five lines

  unit          Wh per completed task (not per prompt)
  boundary      full serving stack: accelerators, host,
                idle capacity, DC overhead. Excludes
                training, network, end-user device.
  method        tokens/run from traces (p50, p95)
                x published Wh/1k tokens, version dated
  carbon        location-based AND market-based, both shown
  caveat        provider efficiency improved ~33x in 12
                months; figure is restated each quarter

• 开头就把单位摆出来。这个领域里一半的混乱，都是两方拿一个「每条提示」的数字与一个「每个任务」的数字相比，然后断定其中一方在说谎。先点明单位，一行就能终结这件事。
• 把训练这个问题单独拎出来，并诚实作答。如果你做微调，那是一笔阶段性成本，你可以按摊销列一行；如果你不做，就说基座模型的训练足迹是供应方该披露的、在你的边界之外。在这里含糊其辞，读起来就是在回避。
• 按季度重述，并预期这个数字会下降。每词元效率在快速改善，而运行次数增长得更快。如果你的每任务数字降了、总量却升了，就把两个都发出来——不然你会落下一个罪有应得的指责：只报了方便的那一半，正是价格通缩与每任务成本在金钱那一侧描述的同一个陷阱。
• 别让这件事变成一个项目。对多数部署而言，能耗这件事是一个段落加一套方法，不是一条工作流。例外是那种乘数很大、品牌又暴露在外的高吞吐部署，而在那里，这次测量会通过它所激发的效率工作把自己赚回来。