让 AI “少渴一点”：揭示并应对模型的隐性用水足迹
加入技术交流群
摘要
我们揭示了 AI 的用水足迹（water footprint）这一长期被忽视的环境维度，并给出一套可复现的定量估算方法。以 GPT‑3 为例，我们显示：大型模型训练可能消耗百万升量级的水。进一步地，数据中心就地（scope‑1）与电网链路（scope‑2）的水效率具有显著的时空差异，因此**“何时、何地”运行 AI会极大影响其用水足迹。我们建议提升透明度并在可持续报告中系统纳入 scope‑2 水耗**，同时以整体方法共同优化碳足迹与水足迹，推动真正可持续的 AI。
1. 引言：AI 的“隐性用水账”
随着大模型在云端训练与推理的繁荣，业界主要关注能耗与碳排；然而，水资源影响同样深刻。水足迹不仅来自数据中心冷却系统的现场取水与消耗（scope‑1），还来自为 IT 负载供电的电力系统上游（scope‑2），以及硬件制造（scope‑3）的“嵌入式用水”。过去由于数据缺失与核算口径不一，AI 的水足迹长期“雷达下飞行”。本文旨在正本清源：提出方法、给出量化，并讨论工程层面的缓解与政策建议。
2. 定义与核算：范围、口径与公式
为避免概念混淆，先厘清术语：
取水（withdrawal）：从水体中取走的水量；
消耗（consumption）：取走后不返回原水体的部分（例如蒸发损失，或排入不同水体）；
PUE（电源使用效率）：衡量数据中心非 IT 能耗开销；
WUE（水使用效率）：单位能耗或单位 IT 负载对应的取水/消耗强度（可分现场与链路两类）。
AI 的水足迹通常拆分为三部分：
2.1 运营水足迹（Operational / Scope‑1 + Scope‑2）
采用时间分槽模型，记时隙 (t=1,2,dots,T)。在时刻 (t)，某 AI 负载的IT 能量消耗为 (e_t)，其所在数据中心的 PUE 为 (theta_t)。令 (rho_{s1,t}) 为现场（scope‑1）水强度，(rho_{s2,t}) 为链路（scope‑2）水强度（均可按“取水”或“消耗”分别定义）。则在区间 ([1,T]) 的总运营水足迹可写为：
[
text{Water}{text{Operational}}
= sum{t=1}^{T} e_t,big[,rho_{s1,t} + theta_t,rho_{s2,t},big].
]
该式将IT 负载能量与非 IT 开销（通过 PUE）、两类水强度耦合，从而给出可逐时评估的运营水耗。需要注意：(rho_{s1,t}) 与外界气象条件（温度、湿度）相关，(rho_{s2,t}) 与电网燃料结构（如火电、核电、可再生）及其时变调度相关，二者都具有显著时空多样性。
2.2 链路水足迹（Scope‑2）与时空差异
不同地区与不同时段的电网燃料组合不同，导致为同样的 IT 负载“供电”而间接造成的链路用水差异巨大。峰热时段和干旱地区往往具有更高的 WUE；反之亦然。这意味着：把负载迁往/调度到“水效率更高”的地点/时段，可以在不改变模型结构的前提下显著降低用水。
2.3 嵌入式水足迹（Scope‑3）
与“嵌入式碳”（制造期温室气体）相似，服务器与芯片制造会产生嵌入式用水。若制造期总用水为 (W)，设备预计服役 (T_0)，则在评估窗口 (T) 的摊销量可写成相应的时间加权项（随设备数量/利用率变化）。当前公开数据仍然稀缺，缺口主要在芯片制造环节，需要行业与学术界进一步披露与建模。
小结：运营水足迹关注“用电 + 冷却”；链路水足迹随电网燃料结构与时段变化；嵌入式水足迹需跨供应链核算。三者合并才能得到 AI 的“真实用水成本”。
3. 案例：大型模型训练的“百万升”量级
以 GPT‑3 等大型训练为例，按上式逐时累积并结合实际数据中心的 PUE 与地区/时段的 WUE，估算显示：单次大规模训练可达到百万升量级的取水/消耗。这还未计入范围三（制造）端的不完全统计。值得注意的是：
链路占比不容忽视：正如碳足迹需要考虑 scope‑2，水足迹同样需要把发电侧的用水计入。部分公司（如 Meta）已在可持续报告中开始纳入 scope‑2 水耗。
美国 2028 年的预测表明，若数据中心用电持续增长，仅美国范围内与 AI 相关的取水与消耗就可能超过此前给出的全球估算。由此可见该议题的紧迫性。
4. “何时/何地”与“跟随/背离太阳”：碳–水的调度冲突
为了降低碳足迹，数据中心负载常被建议“跟随太阳（follow the sun）”，即在光伏更充足的时段/地域运行；而为了降低水足迹，我们却可能需要“背离太阳（unfollow the sun）”，避开高温高 WUE的日间时段（例如夜间更优）。
图2（a）（b）显示了一个关键事实：水强度与碳强度在时间/空间上并不总是对齐，最小化其一可能会增大另一个。因此，“水‑碳协同”的整体策略才是正解：在站点选择、能源采购、冷却方式与负载调度上联动优化，在满足服务目标的同时统筹两条曲线。
5. 工程应对：从基础设施到调度与披露
5.1 数据中心侧：冷却与水源管理
冷却技术选择：在满足 IT 热设计的前提下，优先选择低水强度的方案（例如强化空气侧自由冷却、干式/闭式冷却、热通道/冷通道封闭降低需水量），必要时采用再生/回用水替代淡水；
站点与水源：新建/扩容应优先考虑水资源承载力与再生水可得性，并与地方再生水/污水回用设施对接；
监测与控制：布设细粒度水表与气象–能耗耦合模型，实时估计 (rho_{s1,t}) 与 (rho_{s2,t})。
5.2 负载侧：水感知训练与推理调度
时段选择：在夜间/降温时段训练，或在水效率更高的园区运行；
跨站点迁移：基于实时/预报的 WUE 与碳强度，进行**“水–碳双目标”**的跨区域编排；
服务界面：向用户公开水效率时段/站点，鼓励“水意识”的推理调用（例如在 UI 或 API 中标记“水高效时段”）。
5.3 透明度与核算标准
将 scope‑2 水耗纳入报告：像碳一样，把发电侧用水作为标准披露项，提升开发者与用户的可见性；
统一口径：在取水 vs 消耗、现场 vs 链路、边界与时空分辨率等方面形成行业一致性；
数据与模型开放：推动公共数据集与基准，支撑研究社区复现与比较。
5.4 供应链与政策
范围三研究：面向芯片制造/封装/测试的用水清单、地域差异与工艺改进（化学品循环、超纯水回用）；
政策协同：在缺水地区设置水足迹阈值/价格信号，鼓励需求侧弹性与再生水；
企业治水：将“企业水资源管理（water stewardship）”纳入 ESG 核心指标，与减碳并行推进。
6. 方法落地：如何做一份“AI 用水账单”
确定边界：训练/推理任务的服务级别、站点/区域、评估窗口 ([1,T])；
采集参数：逐时的 (e_t)、(theta_t)、(rho_{s1,t})、(rho_{s2,t})（后两者需结合气象与电网燃料结构）；
计算与分解：按式（1）求得运营水足迹，并与站点/时段分解展示；
加入范围三摊销：依据可得的制造用水数据，按设备寿命 (T_0) 做摊销，给出整体用水足迹；
情景比较：夜间 vs 日间、站点 A vs 站点 B、“跟随太阳”vs“背离太阳”，形成水–碳二维对比，支持决策。
7. 讨论：数据缺口、模型—设施协同与用户行为
数据缺口：范围三的芯片制造用水仍缺公开高分辨率数据；
协同优化：把模型规模、训练节奏、并行策略与设施侧水–能–冷联动；
用户偏好：当平台透明披露水效率后，部分用户愿意在水高效时段或水高效站点进行推理（以价格/绿标签等激励），这将形成需求侧弹性，反过来降低系统总水耗。
8. 结论
AI 的水足迹不应再处于“隐形状态”。本文给出一套原则化估算方法，并以大型模型为例展示其现实量级；进一步指出水效率的时空多样性以及与碳优化的潜在冲突。我们呼吁：
在报告口径上系统纳入 scope‑2 水耗并推动范围三研究；
在工程实践上开展水感知调度与设施侧降耗；
在策略层上采用水–碳协同的整体方法，面向可持续 AI 的共同目标。
致谢（据原文）：作者部分工作受到 NSF CCF‑2324916、NSF ECCS‑2152357、CCF‑2324915 资助。
附录：符号与缩略语
(e_t)：时隙 (t) 的 IT 能量消耗
(theta_t)：时隙 (t) 的 PUE
(rho_{s1,t})：现场（scope‑1）水强度（取水/消耗）
(rho_{s2,t})：链路（scope‑2，发电侧）水强度
PUE / WUE：电源/水使用效率
Scope‑1/2/3：现场/供电链路/供应链（制造）
注：本文译稿用于学习与工程参考；如需学术引用，请以原文为准。
评论