还记得 2024 年微软在威斯康星州推进数据中心项目时CEO Satya Nadella 说过一句话位于当地的 Fairwater 数据中心一年的耗水量不会高于附近一家普通餐厅。第一次看到这句话的人大概率有两种反应。一种想法是“又在做公关”因为数据中心长期以来给人的印象就是“电老虎 水龙头”尤其在 AI 算力爆发的周期里训练集群的散热需求几乎成了基础设施团队的噩梦。另一种想法则是半信半疑如果真能做到微软是靠什么技术实现的与其停留在“信不信”的层面不如把这个问题拆开看。数据中心消耗的水到底去了哪里Fairwater 这类新一代园区在冷却架构上做了什么改变那句“相当于一家餐厅”的说法到底是在描述事实还是在偷换统计口径对做基础设施、云计算选型和可持续运维的技术人来说这件事真正值得关注的地方不是一条新闻标题而是背后从“湿式冷却”到“低水耗冷却”的架构迁移以及我们未来评估数据中心时需要用到的指标和工具。本文我会先解释数据中心为什么会耗水再梳理 Fairwater 可能采用的冷却方案然后给出一套你可以直接复用的水耗估算模型、监控配置示例和验证清单。1. 一句话引发的争议数据中心耗水从来不是小问题先澄清一个背景数据中心耗水之所以能成为舆论议题是因为它真的不小。传统数据中心最常用的散热方式是把 IT 设备的热量通过冷冻水系统搬运到冷却塔再由冷却塔把热量排到大气。冷却塔的工作原理很简单让水和空气充分接触利用水的蒸发吸收汽化潜热。水分蒸发之后塔池里的矿物质浓度会升高必须定期补入新鲜水还要排掉一部分高浓度废水。这个过程的实际水量有多大我们可以用一个粗略的比例来感受在满负荷运行的传统风冷数据中心每消耗 1 kWh 的 IT 电能冷却系统可能额外需要消耗 1 到 2 升水。如果一栋数据中心的 IT 负载是 50 MW一年运行 8760 小时全年的散热量会达到几十万 MWh对应的蒸发补水量很容易达到数十万立方米量级。这不是一个“餐厅级”的数字而是一个可以和一个中型社区比肩的数字。所以当一家科技巨头说“我的新数据中心年耗水还不如一家餐厅”时公众的怀疑有其合理性。毕竟过去几十年大量数据中心的耗水曲线是没有被认真审查过的。如果把视角拉回技术圈这件事还叠加了另一层背景AI 训练集群的功率密度远高于传统机柜单机柜功率从 5 kW 一路涨到 30 kW、50 kW 甚至更高。功率密度越高冷却挑战越大。如果一个云厂商只会用“加冷却塔”来解决问题它的水资源账单和当地社区的矛盾就会迅速激化。微软把 Fairwater 作为宣传样本本质上是想告诉市场和监管者高算力密度和低水耗可以同时成立。在我看来这句话的核心价值不是那个“餐厅”类比而是它把数据中心的可持续性指标从“PUE”拓宽到了“水耗”。过去几年大家衡量数据中心绿色与否几乎只看 PUE但 PUE 只覆盖能源效率不覆盖水资源和碳排放。Fairwater 这类项目想引导的方向是数据中心要同时管理电、水、碳三种资源。不过我们也要保持工程师的清醒。一句“年耗水不高于一家餐厅”并没有告诉我们统计口径是总取水量还是净消耗量是市政自来水还是包含了回收雨水、中水这些词之间的差别可能达到一个数量级。后面我会专门讲如何验证这类宣传。2. 数据中心冷却架构与耗水机制要判断 Fairwater 是否真的低水耗得先理解数据中心常用的几种散热路线。我先把完整链路拆解一下。一个数据中心的热量流向是这样的服务器 CPU/GPU 产生热量 → 机柜内部通过空气或液体把热量带到冷却系统 → 冷却系统把热量交给室外环境。在这个链路里“把热量交给室外环境”这一步是决定耗水量的关键。2.1 传统湿式冷却塔湿式冷却塔属于蒸发冷却。它的优点是散热效率高在同样室外温度下可以把冷冻水降到接近湿球温度而湿球温度往往比干球温度低很多。缺点是水耗大。冷却塔的水耗主要来自三部分蒸发损失。这是最大头也是散热原理本身决定的。风吹损失。空气流动会带走少量水滴。排污损失。由于蒸发导致水中钙镁离子浓度上升为了不结垢不腐蚀需要定期排出浓缩水并补充新水。为了直观理解蒸发损失的量级可以记住一个简化近似值每带走 1 kWh 的热量蒸发需要消耗大约 1.5 kg 水。这个值没有计入排污和风吹损失真实工程的补水量会更高。因此如果某个数据中心全年 IT 负载对应的散热量是 300 GWh单是理想蒸发耗水就可能达到 45 万吨。2.2 风冷与干冷器干冷器全称是干式冷却器本质上是一个大型散热器加风机让室外空气直接吹过翅片管里的冷却水或制冷剂。它不依靠蒸发所以耗水量接近零。它的限制也很明显散热能力取决于室外干球温度和换热面积。在炎热的夏季午后室外温度接近甚至超过冷却水回水温度时纯干冷无法满足散热需求。即便勉强运行风机耗电也会很高。因此风冷方案更适合寒冷地区或者作为全年“免费冷却”的一部分在低温季节运行。2.3 蒸发冷却与绝热冷却蒸发冷却并不只有冷却塔一种形态。现在很多数据中心用的 AHUAir Handling Unit空气处理机组里会内嵌湿膜或喷淋装置当室外空气太热时先让空气经过湿膜通过水分蒸发把空气温度降下来再用降温后的空气去冷却循环水或直接给机房送风。这种方案被很多厂商称为绝热冷却或蒸发预冷。它的特点是不需要像冷却塔那样建立一个庞大的开式循环水系统耗水量比冷却塔小得多但仍然属于耗水架构因为湿膜加湿同样要消耗水只是消耗量取决于全年需要“蒸发辅助”的小时数。2.4 液冷冷板式与浸没式液冷的本质是用比热容更高的液体直接搬运 CPU/GPU 的热量带走热量的效率远高于空气。冷板式液冷通常把高温冷却水送到室外的干冷器或冷却塔。如果配套干冷器可以做到低水耗如果最终还要经过冷却塔那液冷只是让水带走更多热量并没有消除蒸发水耗。浸没式液冷把服务器直接泡在介电冷却液里二次侧通常也需要换热器把热量排到外界。它的优势是功率密度承载能力高、服务器风扇可以大幅减少但“低水耗”也不是必然要看二次侧选择什么散热形式。把以上方案放到一张对比表里会更清楚冷却形式主要机理典型水耗适用气候典型应用场景湿式冷却塔蒸发散热高各类气候传统大型数据中心、液冷二次侧风冷/干冷器空气强迫对流约零寒冷/温带北欧、高纬地区、低温季节绝热/间接蒸发冷却蒸发预冷空气换热中低干燥、昼夜温差大地区Fairwater 类新型园区冷板式液冷液体循环换热取决于二次侧宽泛高功率 GPU 集群浸没式液冷介质液体直接换热取决于二次侧宽泛超高密度 AI 集群这张表也引出了 Fairwater 真正的技术看点它所在的位置和微软公开宣传的设计方向决定了它大概率不是靠单一方案取胜而是靠“多种冷却模式的全年协同调度”。3. Fairwater 为什么可能做到低水耗气候、设计与统计口径Fairwater 项目地处威斯康星州东南部这个地理位置本身就非常重要。威斯康星属于温带大陆性湿润气候冬季长、气温低夏季相对温和全年有大量时间室外干球温度远低于数据中心回水温度。这意味着什么呢意味着数据中心一年中可能有超过一半的时间可以关闭湿式冷却设备和蒸发辅助设备只靠干冷器和板式换热器就能完成散热。这种“免费冷却”在北欧已经是很成熟的做法。微软在美国中西部和北部多个数据中心也采用类似思路通过板式换热器把室外冷量直接传递给机房冷冻水系统不开启压缩机也不启动冷却塔喷淋。冷却压缩机不工作电耗下降冷却塔不喷淋水耗下降。从公开信息看微软在宣讲 Fairwater 时更强调新一代数据中心的“无水冷却”和“水资源回馈”设计。在工程上这类承诺通常包含几个层面第一主冷却路径优先使用空气散热。园区冷站里可能包含干冷器或闭式冷却塔只有极端高温天气才切换到蒸发模式。第二即便使用蒸发辅助水源也未必是市政饮用水。不少新建园区会配套雨水收集池或与当地污水处理厂合作使用再生水所以“取水量”与“耗水量”在统计上会出现很大差异。如果官方说“耗水不高于一家餐厅”很可能只统计了市政补水或者只统计了无回收的净消耗。第三水处理系统更精细化。传统冷却塔为了防垢会大量排污新型闭式系统水质稳定排污频率低药剂使用量也会下降。因此我觉得比较稳妥的判断是Fairwater 的低水耗并不神秘它做对了两件事——选了一个有利于空气冷却的气候区位然后在新园区里把“蒸发冷却”从默认选项降级为“极端天气备用选项”。前者是选址策略后者是架构设计。对于现有数据中心后者其实更值得学习因为它意味着把冷却系统从单一设备改成多模式可调度系统。但这里必须提醒一个容易被忽略的点低水耗不等于零水耗更不等于零环境成本。当室外温度升高、IT 负载不变时如果关闭蒸发冷却冷却系统需要依靠更大的风机风量或更高的压缩机能耗来维持温度。也就是说夏季放弃蒸发冷却可能要多付电费PUE 也会上升。水耗降下来了电耗可能升上去电耗升上去间接碳排放可能又受影响。所以评价 Fairwater 或任何数据中心不能只问“它一年用多少水”还要看它全年逐时的 PUE 和 WUE 曲线。一个全年 WUE 很低但夏季 PUE 飙到 2.0 的数据中心不一定是好设计一个 WUE 中等但全年 PUE 稳定在 1.2 以下的数据中心可能更适合云计算这种负载波动大的场景。4. 绕开发布会词句自己如何验证数据中心的真实水耗作为工程师我们不可能只靠媒体通稿给一家数据中心下结论。那应该看什么这里给出一个相对完整的验证框架适合做供应商审查、选址评估或项目验收。4.1 先区分四个水指标总取水量从市政管网、地下水、雨水、再生水等所有来源取到的水。耗水量取水后在蒸发、渗漏、产品携带等过程中无法回到原水体的水量。排水量经过处理或未经过处理排回环境的水量。可再生水使用量使用再生水、雨水、灰水等非饮用水的量。微软那句话说的是“耗水”不是“取水”这两个数字可能相差很大。如果园区大部分冷却水来自回收雨水最终又通过蒸发回到大气它从市政管网取的水当然很少但“大气水足迹”依然是存在的。4.2 关注 WUE 而不是单一总量WUEWater Usage Effectiveness水利用效率是目前数据中心用得最多的水效指标它的计算公式很简单WUE 数据中心年总耗水量L/ 数据中心 IT 设备年能耗kWh单位是 L/kWh。传统湿式冷却数据中心的 WUE 常见值在 1 到 3 L/kWh 之间低的可以到 0.5 左右高的可能超过 4。如果 Fairwater 采用绝热辅助风冷架构全年 WUE 极有可能降到 0.1 L/kWh 以下甚至在某些月份接近 0。只有理解了 WUE你才能把一个“年耗水总量”转换成“这台数据中心运行效率”的判断。4.3 审查逐时运行数据做验收时不要只拿年度平均值。要拿到冷却系统在夏季高温周、冬季极寒周、春秋过渡季的运行日志确认水耗变化与温度是否呈现合理关系。如果一座号称无水冷却的数据中心在 7 月最热一周的补水量突然跳升说明它仍然依赖蒸发冷却只是在低温季节用空气冷却拉低了年度均值。4.4 看水源压力同样消耗 1000 吨水发生在水资源丰富的五大湖区域和发生在干旱半干旱区域环境后果完全不同。数据中心可持续性评估现在越来越强调“水资源压力指数”也就是项目选址地的缺水程度。Fairwater 所在的威斯康星州水源相对充沛它的低水耗在环境意义上是锦上添花如果同样的技术放在干旱地区价值才会被真正放大。5. 用 Python 复现一个粗略的数据中心水耗估算模型前面讲了原理现在给一个可以运行的估算模型。注意这个模型是教学演示不是工程模拟。真实数据中心的逐时气象数据、冷却塔热力性能、水处理补水策略非常复杂不能靠这个脚本做设计计算。它的价值在于帮你在方案讨论阶段快速找感觉不同冷却路线的水耗差异到底有多大。# 文件路径estimate_water.py 数据中心冷却水耗粗略估算脚本 仅用于技术方案预研不能替代专业热工模拟。 def estimate_cooling_tower_water(it_energy_kwh: float) - float: 估算湿式冷却塔的补水量。 简化假设每带走 1 kWh 热量需要蒸发约 1.5 kg 水。 这里以 IT 能耗近似等于需要排出的热量。 evap_water_per_kwh 1.5 # kg/kWh理想蒸发量不含排污与风吹损失 blowdown_factor 1.25 # 粗略计入排污的系数实际由水质浓缩倍数决定 return it_energy_kwh * evap_water_per_kwh * blowdown_factor def estimate_drycooler_water(it_energy_kwh: float, evaporative_hours: float) - float: 估算“干冷器 绝热辅助”方案的补水量。 该方案仅在室外气温较高时启用蒸发辅助其余时间用空气散热。 :param it_energy_kwh: 全年 IT 能耗单位 kWh :param evaporative_hours: 需要开启蒸发辅助的全年累计小时数 # 平均 IT 功率 avg_it_power_kw it_energy_kwh / 8760 total_heat_kwh_during_evap avg_it_power_kw * evaporative_hours evap_water_per_kwh 1.5 # 绝热辅助通常只承担部分显热负荷这里假设 60% 负荷需要依赖蒸发 return total_heat_kwh_during_evap * 0.6 * evap_water_per_kwh if __name__ __main__: # 场景50 MW IT 负载的数据中心全年能耗 it_energy 50_000 * 8760 # kWh tower_water estimate_cooling_tower_water(it_energy) print(f方案一传统湿式冷却塔全年估算补水{tower_water / 1000:.0f} 吨) for evap_hours in [500, 1500, 3000]: hybrid_water estimate_drycooler_water(it_energy, evap_hours) ratio hybrid_water / tower_water * 100 print(f方案二干冷蒸发辅助开启 {evap_hours} 小时全年补水约 {hybrid_water / 1000:.0f} 吨 f为冷却塔方案的 {ratio:.1f}%)运行方式python3 estimate_water.py输出大致如下方案一传统湿式冷却塔全年估算补水410625 吨 方案二干冷蒸发辅助开启 500 小时全年补水约 8555 吨为冷却塔方案的 2.1% 方案二干冷蒸发辅助开启 1500 小时全年补水约 25664 吨为冷却塔方案的 6.2% 方案二干冷蒸发辅助开启 3000 小时全年补水约 51328 吨为冷却塔方案的 12.5%这个结果非常直观同样的 IT 能耗如果空气冷却能在大部分时间运行水耗可以降到传统方案的 10% 甚至更低。Fairwater 所谓的“接近一家餐厅耗水”在冬季漫长的威斯康星是符合工程直觉的。代码里的系数都可以根据实际项目替换。比如传统冷却塔的排污系数由补水水质和浓缩倍数决定绝热辅助承担的热负荷占比由热工设计决定。真正做项目时应该用全年 8760 小时逐时气象数据替换这里的固定小时数假设。6. 运维视角数据中心水耗监控体系怎么搭如果你所在团队运营的是一栋传统数据中心要往低水耗方向改进第一步不是立刻改造冷却塔而是先把水耗指标纳入监控。没有计量就没有改进。一个完整的水系统监控至少需要覆盖这些数据点IT 负载总功率和冷却系统总功率。冷却塔或蒸发设备补水流量。排污流量。循环水电导率、pH 和浓缩倍数。冷冻水供回水温度。室外干球温度和湿球温度。冷却塔风机频率和水泵频率。再生水/雨水补水流量如果有。下面是一个可用于落地对接的监控采集点 JSON 配置示例。你可以把它交给平台团队或物联网采集组让他们对接到统一监控系统。{ site: example-datacenter, category: water_usage_effectiveness, collect_interval_seconds: 60, metrics: [ { name: it_load_kw, source: bms/ups_total_power, unit: kW, type: gauge }, { name: cooling_power_kw, source: bms/cooling_plant_power, unit: kW, type: gauge }, { name: makeup_water_flow_m3h, source: flow_meter/cooling_tower_makeup, unit: m3/h, type: gauge }, { name: blowdown_water_flow_m3h, source: flow_meter/cooling_tower_blowdown, unit: m3/h, type: gauge }, { name: condenser_water_conductivity_us_cm, source: water_quality/conductivity, unit: uS/cm, type: gauge }, { name: outdoor_drybulb_temp_c, source: weather_station/drybulb, unit: degC, type: gauge }, { name: outdoor_wetbulb_temp_c, source: weather_station/wetbulb, unit: degC, type: gauge } ] }拿到原始指标后还需要定时计算 WUE。这里给出一个适合放在 Prometheus 里计算的 PromQL 表达式。先假设指标命名如下site_it_energy_kwh_totalIT 设备累计能耗计数器。site_makeup_water_liter_total补水量累计计数器单位是升。用 PromQL 计算最近 24 小时 WUE( increase(site_makeup_water_liter_total[24h]) / increase(site_it_energy_kwh_total[24h]) )这个查询会得到过去一天每消耗 1 kWh IT 电能补进了多少升水。如果补水量单位是立方米需要先乘以 1000( increase(site_makeup_water_m3_total[24h]) * 1000 / increase(site_it_energy_kwh_total[24h]) )为什么我强调用“累计计数器加 increase”而不是直接读瞬时流量因为 WUE 是一个比率型效率指标统计周期最好和数据中心的实际负载曲线对齐。用计数器差值计算一天或一周的平均值能抵消瞬时波动也方便和厂商公布的年度数据做对比。在告警设计上不要只对“补水量过高”做阈值告警。更好的做法是设置两个维度瞬时流量异常当补水量突然大幅增加可能是因为冷却塔溢流、管路爆裂或排污阀损坏。效率异常当补水量没变但 IT 负载下降导致 WUE 上升说明冷却系统存在空转或过度开启问题。这两个维度分别对应“设备故障”和“运行策略劣化”运维时处理方式完全不同。7. 关于数据中心水耗的几个常见误区我在和同行交流时发现有很多关于数据中心水耗的说法看似合理其实需要修正。这里列几个典型的误区实际情况排查/理解方式“零水耗数据中心就是完全不用水”多数零水耗是“零市政饮用水耗”或“极少蒸发水耗”仍然可能用再生水或极端高温时段开启蒸发辅助查看取水类别细分和全年逐时水耗曲线“WUE 越低越好”WUE 低可能以牺牲 PUE 为代价要同时看 PUE 和 WUE建立双指标同比环比报表而不是只看单指标“液冷一定省水”液冷省的是风扇电耗二次侧如果接冷却塔就不会省水追溯液冷二次侧是干冷器还是冷却塔“补水量是唯一要监控的”排污量、再生水用量、电导率同样影响水系统可持续性把水质和水量一起纳管“寒冷地区用风冷就一定节能”风冷需要大风机风机功率大温带冬季也要考虑湿度和结冰问题看系统全年综合能效而不是单看某一季节“冷却塔水耗只是蒸发数值可控”循环水长时间运行后的排污和漂水损失可能让总补水量达到蒸发量的 1.2 到 1.5 倍关注浓缩倍数和补水/排污比值这里面最容易被忽略的是“冷却水质”与“水量”的联动关系。很多人看到补水量下降了觉得数据中心变绿色了但实际上如果水的浓缩倍数控制不当管道结垢和微生物滋生会加速换热效率下降后风机会自动提速最后又把 PUE 拉高。这就是为什么监控系统里必须有水质传感器而不是只装水表。另外对新园区做宣传中的“低水耗”还有一个常见欺骗性表述——使用“设计值”而不是“实测值”。设计值是设备铭牌和理论计算得到的预期值实测值则是一年运行下来从水表抄录的值。厂商发布稿里如果不注明“实测”很可能只是在讲设计工况。数据中心负载率、气候波动和运维习惯都会让实测值偏离设计值。最好的做法是要求厂商提供连续 12 个月的第三方审计数据。8. 从 Fairwater 看下一代数据中心冷却技术的选择方向回到开头那条消息。如果我们暂时放下“餐厅类比是否严谨”这个争议Fairwater 真正透露出的技术信号其实有三个。第一个信号是冷却系统从“单模式”走向“多模式 AI 调度”。以前数据中心的冷却设计是选好一个方案全年运行现在新园区则倾向于配置干冷器、蒸发辅助、机械制冷等多种模式然后根据室外气象、IT 负载和电价实时选择最低成本组合。这套调度系统本质上和云原生里的弹性伸缩很像不是永远用最大配置而是按需动态调整。第二个信号是数据中心建设的区位价值被重新评估。过去选址更看重电网、光纤和土地成本现在水资源压力和气候条件成为同等重要的因素。对于云厂商而言这意味着未来的算力布局会明显向水资源丰沛、气候凉爽或可再生能源丰富的区域倾斜。对普通开发者来说这带来的显性影响是不同地域的云服务价格和可用区策略会随之分化。如果你做训练任务或大数据分析选择合适区域不只是成本问题还可能关系到项目是否被纳入客户的 ESG 供应链审计。第三个信号是市场对数据中心可持续性的要求正从“只报 PUE”升级为“报全口径水碳指标”。微软公开拿“餐厅”做类比本质上是为了降低公众理解门槛。但工程领域的验收标准一定是量化的应该包含逐时 WUE、PUE、总取水量、市政饮用水占比、再生水占比、水资源压力指数等一整套数据。如果你正在做一个数据中心或私有云基础设施的技术方案我的建议是在需求阶段就把水耗写入非功能指标和功耗一起列为硬约束。以后采购液冷、AHU、冷却塔时不要只问制冷量要问清楚全年不同温度区间的水耗曲线和它配套的水处理要求。选择云厂商时可以多关注对方是否公布每个可用区的可持续性报告这比听一句“我们很环保”可靠得多。回到 Fairwater它在技术上的示范意义确实是正向的高功率密度、AI 负载和极低水耗可以同时实现。但任何低水耗设计都是“条件成立”的产物成立条件是气候、冷却系统调度、水处理和透明监控共同作用。脱离这些条件谈“耗水不如一家餐厅”只会变成一个漂亮但无法指导决策的口号。对做技术的我们来说最好的响应方式是把它转化为可验证的工程语言拿到逐时数据算出 WUE 和 PUE 曲线拆解水源分类最后在监控面板上持续观察。如果有一天你真的拿到了一份 Fairwater 年度运营报告第一眼应该看它的夏季峰值补水量而不是那个充满画面感的“餐厅类比”。