Sam Altman 谈 AI 用水量Satya Nadella 称微软威斯康星数据中心年用水约等于一家餐厅。这两条信息被放在一起时大多数人的第一反应是到底谁说得对如果仔细想这其实不是一个能靠一句话回答的问题。AI 数据中心用水量从来不是一个“固定数字”它取决于冷却方式、选址、气候、供水来源、计量口径甚至取决于你把“用水”定义到哪一层。我先说一个判断AI 的水足迹争议本质不是“AI 会不会把水喝光”而是我们是否拥有足够清晰、统一、可验证的指标来评估数据中心的资源使用。如果把讨论停留在“一年等于几家餐厅”或者“一年用了几万吨水”这种单一数字上很容易被带偏。真正值得关注的是水从哪里来用了多少新鲜水用完之后去了哪里以及能不能循环再用。1. AI 算力变成大众话题后水为什么也被拎出来了1.1 算力密度上升散热需求跟着变大过去聊数据中心大家最关心的通常是电费。CPU 功耗在几十瓦到一两百瓦时传统风冷就能解决问题。后来 GPU 加速卡普及单台服务器的功耗从几百瓦升到几千瓦一个机柜的功率密度从几个千瓦向几十千瓦甚至更高走发热量也跟着几何级数上升。在这个背景下散热就不再只是“开空调”那么简单。风冷效率有限尤其是在高密度算力场景下想靠冷风把密集排列的芯片温度压住需要极大风量噪声、风道、能耗都很难看。于是水冷、冷却塔、间接蒸发冷却这些方案被更多采用。水因为比热容高导热效率好能比空气带走更多热量。这本来是一个纯工程问题。但当“AI 需要大量算力”成为大众话题后公众开始顺着能源链条往下问训练大模型要多少电发电要多少水数据中心自己又要多少水于是“AI 用水量”从运维指标变成了新闻标题。1.2 从 PUE 到 WUE行业开始换一把尺子数据中心行业过去最常用的能效指标是 PUEPower Usage Effectiveness用来衡量总能耗中有多少是真正用在 IT 设备上。PUE 越低说明基础设施消耗越少。但 PUE 回答不了水的问题。一个风扇狂转的风冷数据中心可能 PUE 不低但用水量接近零一个使用开式冷却塔的数据中心PUE 可能很好看但每年补水会是一笔可观的量。所以近年 WUEWater Usage Effectiveness也被更多人提到。它通常表示每消耗一度 IT 设备用电量对应消耗了多少升水。单位看起来简单实际口径很多有人用总取水量有人用蒸发耗水量有人把发电侧用水也算进去。口径不同结果可能差出好几倍。从这里就能看出Sam Altman 谈 AI 用水量和 Nadella 谈威斯康星数据中心用水量完全可能是在用不同口径说不同层面的问题。一个在讲行业趋势一个在讲具体站点情况。把它们放在同一个擂台上去比较本质上就是错位的。2. 数据中心的每一吨水到底花在哪里2.1 冷却塔蒸发是最主要的耗水环节要理解数据中心“水费账单”先看水从哪些管道出去。一个典型的大型数据中心用水环节大致有这么几类冷却塔或蒸发冷却设备的蒸发耗水。这是最大头也是公众讨论“AI 喝水”时最常想到的部分。系统排污。为了让冷却水里的矿物质浓度不要过高需要排掉一部分浓缩后的水再补入新鲜水。漂水。冷却塔顶部风机带出的小水滴如果没有收水器这部分水会随风散失。加湿。北方冬季或干燥地区机房湿度太低会产生静电需要加湿设备补水。生活用水。办公区、卫生间、食堂等相对占比较小。其中蒸发和排污通常被称为“耗水”因为这部分水没有回到系统里直接再次利用。冷却塔内部其实有很大一部分水在闭式管路里循环真正需要补的只是蒸发掉和排掉的那部分。但偏偏就是这部分补水量会被计入数据中心的年用水量。如果你只看冷却塔容量会觉得“循环水量很大是不是很费水”。实际上循环水量和补水量是两个概念。循环水在管道和塔里反复跑补水量只是其中被蒸发、被排污、被漂掉的部分。这个区别是入门评估数据中心用水时最容易踩的第一个坑。2.2 不同冷却方案用水差异很直观为了看清楚不同方案可以简化成一个表格冷却方式是否蒸发耗水用水强度特征常见适用场景传统风冷CRAC/CRAH基本不耗水低小型机房、干旱缺水地区、低密度机柜间接蒸发冷却取决于室外温湿度中等干燥、凉爽气候地区兼顾能效和水耗开式冷却塔 水冷机组高蒸发耗水高大型数据中心水源充足夏季炎热地区液冷 干冷器液冷回路本身不蒸发干冷器只靠空气散热耗水极低低高密度算力、GPU 集群、新建园区这个表格里的“高”“低”是相对概念不是绝对数值。同样是开式冷却塔在凉爽地区蒸发量小在湿热地区蒸发量大。同样是风冷在极端高温天气下压缩机全力运行耗电变大但依然不直接耗水。所以工程上最怕的不是“用了某一种冷却方式”而是“不根据气候做选择”。一个明明可以全年使用自然冷风的北方城市如果照搬南方方案上了大量蒸发冷却用水量会被无谓抬高。2.3 为什么不能只看总量要看新鲜水比例还有一个容易被忽略的问题数据中心补进去的水不一定是市政自来水。在不少城市工业用水、冷却补水可以使用中水或再生水。也就是说数据中心的“年用水量”里有一部分是原本就要处理或回用的非饮用水。如果这部分占比很高那么它对自然水资源的压力远低于“同样吨数的自来水”。这也是我建议不要拿单一总量去跟“餐厅用水”对比的原因。两家餐厅可能一天用几百升水也可能一天用几十吨水数据中心可能用中水也可能用自来水。只比较“一年多少吨”或“等于几家餐厅”完全没法判断这个用水量在当地水资源条件下是紧张还是宽松。3. 威斯康星那个“一家餐厅”的类比为什么不能直接用3.1 类比有冲击力但没有给出估值基准用“一家餐厅”来形容年用水量确实很容易让人产生画面感。可一旦较真问题就来了什么餐厅面积多大客流量多少是快餐店、咖啡馆还是每天几百人用餐的大型宴会厅餐厅之间的用水量差异可以非常悬殊。有的餐厅后厨有洗碗机、制冰机、直饮水系统一天几百上千加仑很正常有的小餐饮店可能只靠洗手间和洗碗用水量低一个量级。所以“等于一家餐厅”这组类比如果没说明基准严格来说不是一个清晰的工程指标更像一种公关表达。我没有办法从这个类比反推出这个数据中心的绝对用水量因为缺少“是哪家餐厅”这个关键参数。公众看到这句话最合理的反应应该是这个数字听起来不大但我无法验证。3.2 同一个数字放在威斯康星和凤凰城是两回事数据中心选址对水资源评价影响极大。威斯康星地处五大湖区附近整体属于水资源相对丰沛的地区。如果一个数据中心年用水量在当地供水系统里只占很小比例那么它对当地水资源的压力可能确实不高。但如果同样的年用水量放在亚利桑那州凤凰城这类干旱地区或者放在一个地下水位持续下降的城市它就需要被重点审视。相同的绝对数字在不同地区代表完全不同的环境压力。这也是为什么水资源评估不能只看“用了多少”还要看“在当地够不够用”。数据中心选址时很多团队会把 WRI 水资源压力地图当作早期筛选工具优先避开极高水压力区域。这种做法比事后争论“一家餐厅等于多少吨”更接近问题本质。3.3 沟通可以用类比工程评估要用完整指标我理解为什么会有类似“一家餐厅”的沟通方式。公众对“数据中心年用水量几十万吨”缺乏直观感受换成生活场景更容易听懂。但工程评估使用这种类比很容易丢失关键信息甚至会误导决策。如果一定要做一个通俗类比更合理的做法是同时给出三个信息年取水量是多少。其中多少是再生水多少是自来水。单位算力对应的耗水量是多少。把这三项放进上下文里再决定要跟什么生活场景类比。只丢出一个“餐厅”等于只给了结论没给条件。4. 从工程入手怎么一步步把数据中心的水足迹压下去4.1 先做用水基线不要急着换设备很多团队一说到节水第一反应是上液冷、换闭式冷却塔。但实际操作中如果没有建立用水基线改造前后根本无法评估效果。要做的事情其实很朴素在冷却塔补水管、加湿补水管、排污管上分别装计量表。记录日补水量、循环水电导率、浓缩倍数。把冷却塔风机、水泵的功率和补水量同步到监控系统。在气象数据里记录湿球温度和干球温度。这些数据跑一两个月之后你才能知道真正的耗水大户是蒸发、排污还是漂水。很多时候问题不是技术选型不对而是设备运行策略不合理。比如冷却塔浓缩倍数长期偏低排污量太大补水量被无谓抬高。这种问题靠调参数就能解决不需要大规模改造。4.2 按负荷和环境动态调整冷却策略数据中心 IT 负载不是恒定的室外气候也不是。合理做法是根据实时负荷和气象条件让冷却系统跟着需求走。冷却塔的蒸发量主要取决于空气湿球温度、风量和喷淋水量。在夜间或春秋季节室外温度下降可以降低冷却塔风机转速减少风带走的水分。要是室外湿球温度已经很低甚至可以直接切换到自然冷却模式让冷水机组停机只靠冷却塔或干冷器提供冷量。类似的运行策略很多但核心原则只有一个不要让冷却系统在全速状态下空转。高密度集群按功率调度空调末端按送风温度反馈调节补水泵按液位和电导率联动。自动化做得越细水和电的浪费就越少。4.3 落地时最值得优先做的几件事针对具体站点我一般建议按下面顺序评估落地优化给冷却塔加装高效收水器减少漂水损耗。这个成本低见效快。提高冷却水浓缩倍数降低排污量。但要同步做好水质阻垢和腐蚀控制不能为了省水把管路搞坏。接入中水或再生水作为补水来源。前提是当地再生水管网和政策允许。回收冷凝水和雨水用于冷却塔补水或场地浇灌。提高冷冻水供水温度让冷水机组在更高效率区间运行。对高密度区域采用液冷服务器把核心热量直接引到干冷器或热回收系统减少对蒸发冷却的依赖。这些不是一站式方案而是可以逐步叠加的工程手段。小规模验证后再扩展到整个园区比一次性大改造稳妥得多。4.4 遇到补水量异常怎么排查如果某个月补水量突然升高不要先怀疑设备坏了。按这条链路排查能省很多时间首先看补水表数据是不是真的异常。如果只是抄表周期不一样导致日均值变化那是统计口径问题。确认数字真实后再看冷却塔浓缩倍数是否下降。如果浓缩倍数突然降低说明排污阀可能卡在常开状态或者补水浮球阀失灵导致大量新鲜水不断涌入又排走。接下来看室外气象。如果遇到高温高湿天气蒸发量升高是正常现象需要对比去年同期数据判断是否偏离太多。再往后检查冷却塔收水器有没有破损或脱落风机转速是不是被人为调到了高挡。最后还要确认计量表本身是否漂移。很多站点把水表和电表一起接入监控平台但水表机械部件磨损后读数会偏高或偏低。工程经验里这类问题反而最容易被忽视。5. 下次看到“AI 用了多少水”先问三个问题5.1 问题一口径是什么“用水量”至少有三种常见口径取水量、耗水量、排水量。取水量从市政或自然水体抽了多少进来。耗水量因蒸发、排放、产品带走等原因没有回到原水体的量。排水量用完之后排进下水道或处理厂的水量。同一个数据中心这三个数字差别可能很大。别人说“今年用了十万吨水”时你得先确认他指的是哪一个。如果拿取水量和耗水量对比结论很容易失真。5.2 问题二水从哪来水源决定影响范围。市政自来水直接关系居民用水地表水可能影响河流生态中水和再生水则更多是“废物利用”环境含义完全不同。如果一家数据中心主要使用再生水哪怕年取水量听起来不小它占用的优质水资源也很有限。反过来如果它地处干旱地区用的全是自来水即使总量不大也需要认真评估。5.3 问题三用完之后去了哪进入数据中心的水一部分蒸发进入大气一部分变成污水排走一部分可能经过处理后循环回到冷却系统。蒸发掉的水很难再被直接利用。但如果污水经过处理、中水回用数据中心对环境的净影响会低很多。这也是评估可持续性时最容易被忽略的一环不是“用了多少”而是“净消耗了多少污染了多少又留下了什么”。5.4 判断数据中心水足迹是否合理的简易框架基于上面三个问题可以沉淀成一个四步评估框架澄清计量范围取水、耗水、排水分别是多少。识别水源类型自来水、地表水、再生水各自占比。计算水利用强度用 WUE 或单位算力耗水量来横向比较。结合区域水资源压力判断这个数字在当地是否构成压力。这四个步骤做完再去看“AI 用水量”“数据中心耗水”之类的标题你就不会轻易被一个孤立数字带节奏了。5.5 适合与不适合的边界也要说清楚适用边界。这套评估思路适合新建数据中心选址时的水资源影响评估。已运行站点做用水优化和节水改造。行业分析或公开讨论中对不同厂商数据做横向比较。政府或园区做供水和排水规划。不太适合的场景包括在没有明确口径时直接拿两个数据中心的“年用水量”比大小。用某一家数据中心的用水情况推导整个 AI 行业的“总水足迹”。不同站点差异太大外推容易失真。以“用水少”作为唯一选择标准而忽略能耗、碳排放和运营成本的综合权衡。片面追求低 WUE 可能导致 PUE 升高整体环境影响反而变大。从长期看数据中心行业需要的不是一个“更低的总水量”宣传话术而是一套更透明、更一致的披露方式。大家把取水来源、水质等级、耗水去向、单位算力耗水量放到台面上公众才有机会做真正的判断。如果你下次再看到类似“AI 数据中心一年用水等于几家餐厅”这样的说法不用急着站队。先想清楚口径统一吗水源可靠吗废水去哪了在同一个水资源条件下可不可比这些问题的答案往往比新闻标题里的那个数字更有价值。