在关于 Microsoft Fairwater 数据中心的一次公开讨论中Satya Nadella 用了“年耗水不高于一家本地餐厅”这个类比来说明项目的影响。这个说法很有画面感也让很多没接触过数据中心基础设施的人松了口气既然耗水不多那问题应该不大。但我在行业里看过太多把“取水量、循环水量、补水量和蒸发量”混在一张表里的报告所以更关心另一件事这样一句“看起来很低”的耗水表述背后到底需要满足哪些工程条件才能成立边界是什么口径是什么如果换成不同气候、不同负载、不同运维水平结论还成立吗这篇文章不打算论证这条声明是真是假因为仅凭一个类比无法做技术判断。我想做的是把数据中心“省水”这件事拆开来看为什么过去的数据中心那么耗水为什么现在有些园区确实能把补水量压得很低以及作为一个工程技术人员面对类似宣称时应该按什么顺序去验证。1. “不高于一家本地餐厅”这句话工程上需要先问边界1.1 为什么数据中心会被单独“查水表”过去几年数据中心对环境的影响最先被关注的是“电”。大型互联网公司、云厂商和 AI 算力项目都在公布自己的可再生能源采购量、碳排放强度、PUE 等指标。后来大家慢慢发现只谈电不够还有一个容易被忽略的变量是“水”。水在传统数据中心里不是可有可无的消耗品。大量服务器的热量需要通过空调系统搬运到室外其中最常见的散热路径是把热量交给冷却水再由冷却塔喷淋、蒸发把热量排入大气。冷却塔工作的时候白烟一样的水蒸汽会持续飘散那个过程看起来不显眼累积到一整年就是很大的补水量。在缺水地区数据中心的取水许可、用水成本和社区关系都会成为现实约束。过去很多园区选址把电放在第一位哪里便宜、哪里可再生资源丰富就往哪里去但现在“水”已经变成和第二电价并列的选址因素。Fairwater 项目这个话题能引起讨论是因为它把数据中心这种“工业耗水大户”的形象和“一家本地餐厅”放在一起形成了反差。问题在于公众沟通里的类比需要一个共同经验前提。餐厅的用水大家有感受——后厨、洗碗、卫生间、拖地、食客洗手。数据中心的用水则超出了大多数人的日常经验冷却塔蒸发量、排污量、加湿量这些词只要一出现理解门槛就抬高了。用餐厅类比是降低理解门槛但不等于输出了一份技术验证报告。1.2 公众沟通用的是类比工程验证用的是边界同样说“耗水”可以有很多种口径。如果说的是“市政自来水补水”那么冷却塔排污回到市政管网的水算不算消耗如果园区用了中水水表数字是不是完整如果夏季极端高温时冷却塔满负荷运行补水量会不会大幅上升如果员工办公、卫生间和厨房用水也算进去那“一家本地餐厅”的餐厅本身是谁、有多大客流也会影响这个类比的分母。所以我的习惯是遇到一句漂亮的工程宣传语先不要急着夸奖或否定而是把它翻译成边界清楚的问题。时间边界是设计估算还是连续 12 个月的实际运行数据空间边界只算核心机房还是算整个园区用水类型冷却塔补水、加湿用水、办公生活用水分没分开损耗去向水是被蒸发到大气还是排到市政污水管道对比基准餐厅的经营规模、客流、后厨方式是什么只有当这些问题都有了答案“不高于一家本地餐厅”才从传播话术变成可以核对的技术指标。这并不意味着 Fairwater 的说法一定有问题。从工程现实来看确实存在一些冷却系统设计能够把现场补水压到很低的量级。问题只是我们有没有能力在信息不足时保持审慎而不是被类比带着走。2. 数据中心的水不是必需品真正的必需品是“把热排出去”2.1 先看热量是怎么走的才知道水从哪来服务器运行时消耗的电能几乎全部会变成热量。这些热量如果不排走机柜内部温度会持续上升电子元器件寿命和稳定性都会受影响。数据中心的冷却系统本质上做的是把 IT 设备产生的热量从室内搬运到室外。搬运热量的方式有三种基本载体空气、水、制冷剂。空气最方便直接吹风就行但空气的比热容小同样体积下能带走的热量有限。水的比热容大而且蒸发时会吸收大量汽化潜热所以同样水量能搬运的热量远高于空气。制冷剂则可以通过相变把热量从低温端搬到高温端适合精确控制冷量但系统复杂。于是过去的主流方案里水成为重要的搬运介质。冷冻水系统把冷水送到机房空调末端空调末端把室内热空气吹过冷水盘管水变热后回到冷机重新降温冷机再把热量排给冷却水冷却水进冷却塔喷淋蒸发。整个过程里服务器产生的热量最终有很大一部分是通过水的蒸发散到大气中的。这就是传统数据中心耗水的物理由来。水不是被消耗在设备内部而是作为散热介质在冷却塔里以水蒸气形式离开系统。要让系统继续运行就需要不断补充水量。2.2 冷却塔在湿热天气很高效也是耗水大户冷却塔不是一种低效设备它反而是散热效率极高的方案。水蒸发带走热量的能力很强所以才能用相对较小的建筑面积处理巨大热量。但它有一个绕不开的代价需要补水并且需要排污。补水不光是补蒸发掉的水。冷却水在循环过程中水里的钙镁离子、盐分、杂质会不断浓缩。如果一直不排污水质会恶化管道会结垢喷头会堵塞换热效率下降。为了控制水质运维团队必须排掉一部分浓缩后的循环水同时补充新水。这部分叫排污损失同样会出现在水表上。在夏季高温高湿天气下冷却塔需要长时间运行补水量和排污量都会明显上升。一个中等规模数据中心如果完全依赖冷却塔散热一个夏天的耗水量会非常可观。这也是为什么很多园区在宣传时强调“自由冷却小时数”因为只要冷却塔少开耗水量就能降下来。值得注意的是运维目标往往不是“最少耗水”而是“稳定供冷”。冷却水系统的结垢、菌藻滋生、设备腐蚀都会威胁制冷连续性。为了防结垢有的团队宁可多排一点水为了控制军团菌风险还要定期投加杀菌剂并排放一定量的水。这些运行策略都会影响年度总用水。所以做运维的人都知道省水不能靠拍脑袋关阀门而是在水质、结垢、制冷效率和水量之间找平衡。2.3 低耗水的技术路线通常是跳过了蒸发这一步一家现代数据中心的年耗水如果低到和餐厅同量级从技术上讲几乎可以确定它没有依赖传统的开式冷却塔作为常年主力散热路径。它可能走的是下面某条路线或者多条路线组合风侧经济器直接把室外冷空气引入机房或让室外空气与机房回风换热不经过水回路。冬天冷的时候冷却水系统可以停机补水量趋近于零。干冷器/封闭式冷却塔冷却水在盘管内流动不直接与室外空气接触靠风扇强制通风散热。虽然换热效率比蒸发冷却低但几乎不消耗水。冷板液冷用冷却液直接给芯片散热再通过干冷器把热量排到室外。热量搬运有更高能效而且冷却液在封闭回路里可以长期使用年补水量很小。热回收系统把机房余热送到办公区、温室或其他热用户。热量被利用而不是排掉水源侧的需求也随之降低。这几条路线有一个共同特征主要散热路径不再依赖“水蒸发带走热量”。空气是免费介质把它加热本身不消耗水资源冷却液在封闭系统里循环只存在渗漏、检修排水等少量水量蒸发只存在于极端的备用场景或加湿环节。这也是为什么一个数据中心确实有可能把年补水量做到很低。只是要注意能做到并不代表所有地方都能做到。它需要气候、负载、建筑、运维和能源成本多方面的配合。3. 威斯康星的气候能帮忙但低耗水不是天然属性3.1 气候库是一本先天的“冷却日历”任何懂数据中心制冷的人在评估一个项目时都不会只看当地年平均气温。真正要看的是全年逐时的干球温度、湿球温度、湿度分布以及哪些时段可以直接利用室外空气或干冷器。威斯康星州位于美国中北部冬天气温低、寒冷时间长。这种气候对低耗水设计非常有利。只要设计团队把风侧或冷媒侧的“自由冷却”能力做足一年中可能有大量小时数不需要启动冷却塔和冷水机组。那几个月里数据中心的水表可能在很大程度上只反映加湿用水、生活用水和设备维护排水。从这个角度看“在威斯康星州实现低耗水”比在全年高温高湿的新加坡或沙漠地区更容易这是地理位置给的基础条件。不过气候只是提供了可能性。能不能真正把这种可能性落地取决于建筑里的空调系统选型、控制策略、过滤系统、加湿方案和运维团队的执行力。设计得再漂亮如果控制逻辑没有按季节切换设备也不会自动节省。3.2 真正拉高水耗的是过渡季和极端高温一年里最难处理的并不是深冬。冬天室外冷空气充足自然冷却效率高冷却水系统可以停掉。最麻烦的往往是两个时间段一个是春秋过渡季室外温度不高不低机房无法完全靠自然冷却又没热到必须开冷机的程度另一个是夏季极端高温日系统必须全力运行。在过渡季风侧经济器可能会因为室外温度、湿度接近回风状态而“不省不费”有时候还要开冷机来除湿冷机再开冷却塔水耗自然上去。更麻烦的是如果园区维持两个数据中心模块一个靠水冷一个靠风冷夏季切换时控制策略没有优化冷却塔很容易在同一时段集中启动造成补水高峰。所以验证一个项目是否真正低耗水不能只挑天气最舒服的月份看数据而要把最热的一周、连续高负载运行的时段都包含进分析范围。年耗水量的可信度来自最不利工况下依然能得到控制而不是靠过渡季节水的。3.3 这个案例能复制到全世界吗不能直接复制。低用水的设计思路可以复制但每个地方的气候、水价、电价、排放要求和水资源禀赋差异会让最终方案完全不同。有些地方水资源丰富使用冷却塔反而是更经济的选择有些地方虽然缺水但水质很差直接把冷却塔作为主力散热也许还能避免把有限优质水资源消耗在“洗热量”上。真正聪明的数据中心不会追求“绝对低水”而是追求当地约束下的经济、碳排放与稳定运行平衡。还有一种常见误区是把低水耗和低环境影响划等号。如果“省水”是通过大量增加耗电实现的比如把冷机功率拉高、把风机转速调超标、把机房温度压得很低那么总环境影响需要重新计算。水账单独看很好看放到“水-电-碳”三条线里未必最优。这也是我希望读者在看案例时保持的第三个视角省水是目标之一但不是唯一目标。4. 把“一家本地餐厅”翻译成一张可检验的清单4.1 拆解口径取水、排水与消耗真正做工程评估时第一步就是区分几个概念从市政管网取了多少水。有多少水又排回了市政污水系统。有多少水通过蒸发、漂水、绿化、渗漏真正损失掉。有多少水在封闭系统里循环本身并没有被“消耗”。很多争议来自“取水量”和“耗水量”的混用。取水量高不一定代表消耗高如果冷却塔排出的浓缩水进入中水系统二次利用那部分水并没有消失。反过来如果取水量不高但大量水通过蒸发进入大气那它就是真正的消耗。在“一家本地餐厅”的类比里“耗水”通常指向“取水后没有回到水体系统的量”。对这个量做对比需要把现场所有用水末端分清楚。如果没有分项计量那就只能靠估算而工程验收最忌讳的就是用估算代替表计。4.2 一份低耗水声明需要交代哪些关键项我通常建议把“宣称低耗水”的数据拆成一张检查表需要交代的项目 | 为什么需要关注 数据中心总 IT 负载与规模 | 不知道规模数字之间没有可比性 统计周期 | 设计估算、试运行数据、整年运行数据可信度完全不同 现场用水边界 | 是否包含冷却塔、加湿、办公、绿化、消防测试 冷却系统形式 | 开式冷却塔、干冷器、风侧经济器、液冷的比例 冷却塔运行小时数 | 低耗水主要来自冷却塔少开而不是水处理技巧 补水水源 | 市政自来水、中水、再生水、雨水回收来源不同 排污与水处理方式 | 排污水去了哪里、浓缩倍数是多少、是否进入中水系统 加湿用水量 | 冬季低湿或采用风侧经济器时可能额外加湿 最不利工况 | 夏季极端高温、连续满载时水耗是否仍然受控 维护检修排水 | 系统清洗、阀门检修、消防检测用水是否计入年度总量这张表的核心作用是防止人们拿着一个孤零零的年度总数字去评价一套复杂系统。4.3 独立验证最快的方式不是看宣传页而是看月度补水表对一个技术人员来说如果只能看到一个指标我倾向于选“连续 12 个月的补水计量曲线”而不是某个月的 PUE 或水耗汇总。补水计量曲线能反映出很多问题冬季是否有异常高峰夏季高温日是否出现阶梯式上升有没有连续几天停车后再启动导致的跳变补水量和气象温度之间是否成比例。如果数据是按模块分路统计的那信息量会更大冷却塔模块的补水量曲线能直接判断它的运行控制是否合理。很多项目不是设计得不好而是运行团队没有足够精细化地表计和分析。水表放在哪个位置也影响结论如果园区总水表和分路水表之间的沿程存在渗漏总量和分量对不上如果分表故障运维人员只能靠总表差值猜模块用水。一旦出现这种情况对外宣称的低耗水就会变得不可审计。因此在看到话术之前我会先看有没有可靠的计量基础设施。没有计量就没有后续讨论。5. 到了运维阶段省水设计很容易被细节毁掉5.1 水表位置决定一切如果数据中心只有一个市政总水表那它无法区分冷却塔、加湿、办公、消防各用掉多少水。假设总水表年读数很低看起来好像很省水但实际可能是办公人员少、绿化面积小核心冷却系统反而占了大头。做好运维的第一步是在设计阶段就把计量点分清楚。每个补水系统、每组冷却塔、加湿器、生活用水主立管都应该有独立的计量能力。其次运维软件要按时记录这些表计的读数并且关联当时的负载率、室外温度、湿度、机组运行状态。只有建立了这种关联才能回答“某个耗水变化到底是操作失误还是天气变化导致的”。水表本身也会漂移。超声波流量计需要稳定管段电磁流量计需要导电流体机械水表在低流量时误差很大。如果一个项目日常流量很小说明它进入了“低耗水模式”但恰恰在这个状态下小流量误差会被放大。要让低耗水数据可信计量的量程和精度也要在选型时被认真对待。5.2 冷却塔即便不常开水质管理也不能放假低耗水数据中心不一定完全没有冷却塔。很多系统会把冷却塔保留下来作为高温备用冷源平时不启动只有在极端天气或干冷器能力不足时才接手。这种“备而不常用”的冷却塔反而需要更多关注。长期静置的循环水里容易滋生微生物管道内壁会出现腐蚀和生物膜。为了保持水质合格运维团队必须定期排水、补水、投加药剂。哪怕一年只启动几小时为了那几小时的可靠性全年也可能要维持一个最低循环水量并周期性换水。所以不能想当然地认为“有冷却塔就耗水没冷却塔就绝对省水”。系统里即使有冷却塔如果被设计成备用且合理停用年度补水量也能做到很低但要保证在需要它时能稳定顶上去每年花在水质保养上的水量是躲不掉的。5.3 季节切换与加湿器是隐藏用水点还有一种情况是冷机停用了水表却还在走。这通常来自空气加湿系统。在北方的寒冷季节室外空气很干燥。数据机房如果使用风侧经济器把大量室外干燥空气引入室内的相对湿度可能下降。相对湿度太低会增加静电风险某些设备或工艺也可能对湿度有硬性要求。为了维持湿度空调系统会开启加湿器。蒸汽加湿需要把水加热成蒸汽送入风管这个过程会持续消耗水和电。因此可能出现一个反直觉的结果最冷的冬天冷却塔已经停了但水表动量反而来自加湿器和生活热水系统。如果运维团队只看“水冷系统是否运行”会漏掉这部分消耗。解决这个问题没有捷径。控制策略需要根据室内外湿度、焓值和设备允许范围决定自然冷却和加湿之间的平衡点。为了提高一点湿度去开冷机还是不主动加湿但接受温度波动每个园区都需要结合设备耗材和运行成本自己测试。低耗水不是把水阀一关了事而是让每一滴水都花在维持安全运行所必需的地方。6. 这件事对做云、自建机房和搞基础设施的人意味着什么6.1 选机房时“水电双控”会进入常规评估如果你负责公司内部基础设施选型可能已经感受到变化很多地区对新建数据中心的用水指标提出了明确要求甚至会把水耗纳入项目审批。这在过去并不常见。过去看一个机房核心指标主要是电力容量、链路质量、PUE、碳排协议。现在越来越多的评估表里加入了“水资源压力指数”也就是项目所在地的水资源紧张程度。一个用大量冷却塔的数据中心可能在缺水地区面临取水许可限制一个几乎没有补水的园区在水费、排污费和处理工艺上则会有更多主动权。未来选址逻辑会变成先看电再看水再看网再看人。电决定了能不能建水决定了可持续发展上限网和人决定了业务体验和运维效率。6.2 训练负载不是只耗电也决定水耗曲线的形状如果你做的是大规模训练、渲染或数据分析任务可能以为云端资源调度只关注 GPU 型号和价格。但从数据中心基础设施角度看不同类型的任务对散热系统产生的压力完全不同。短时高爆发任务会让冷机频繁启停增加过渡季冷却塔运行时间平稳长时间负载更容易让系统进入稳定供冷模式也更容易让运维团队做负载和水耗的匹配优化。高功率密度机柜如果用液冷总耗水量取决于液冷回路是否封闭、板换冷却侧是否使用开式冷却塔同样是“液冷”不同架构对水资源的依赖可以差出几十倍。这给使用者带来的启示是在要求算力资源时也可以关注所在区域的能源和水约束。你能做的最直接的事是评估长任务是否需要多区域容灾。如果两地机房一个缺水、一个富水调度系统把训练任务切换到水资源相对宽松的区域对整体环境影响是更友好的。6.3 给自己的项目留一套低水设计备选方案即便你现在做的只是一个私有云、一个边缘节点或者一个实验室机房也可以从 Fairwater 这个案例里带走一套思路省水不是最后给冷却塔加一个节水器而是从设计最前端就决定是否依赖蒸发散热。在自己项目里先做三件事画一张水系统图标出所有进水点和出水点把蒸发、排污、加湿、维护排放区分开。为每个主要用水末端配上独立计量先积累一个月以上的补水量数据。在模拟夏季最热日负载的情况下看系统是否可以不依赖冷却塔完成散热。如果必须依赖就要明白你的设计是有水耗底线的。这套小流程不复杂但它给你的团队提供了一种稳定、可复用的评估语言。否则每次内部评审都只靠猜测和宣传口径几个月后根本不会有人知道实际水耗是多少。7. 与其争辩数字不如先建立一套省水系统的“解释框架”说回 Fairwater。有人在评论区讨论“一家餐厅到底一年用多少水”也有人在争论微软是不是在做公关。我倒觉得这则表述真正有价值的信息不是数字的大小而是它成功让公众开始关注一个以前很少有人感知的变量数据中心的散热可以不需要那么多水只要系统设计选择了一条不以蒸发为核心的路径。但这种转变不是自动发生的。它需要当地气候的配合需要冷却架构选型需要从进水管到冷却塔、加湿器、污水管的所有计量点都被仔细定义还需要运维团队能在全年不同季节里把控制逻辑执行到位。任何一个环节失守号称很低的年耗水都可能变成纸面数字。下次看到某个数据中心说自己的水耗低于一家餐厅、低于一个游泳池、低于一栋办公楼时我建议你不要只问“是不是真的”而是问三个问题它统计的边界是什么它的最不利时段数据是否符合预期它有没有分项计量能支撑这个结论这三个问题问下来绝大多数宣传话术都会露出真实形状。只有那些自己做过水系统设计、对全年运行数据有信心的项目才经得起这种追问。这就是技术人和公众沟通的区别公众听到结论工程师打开边界、先找水表再对照一张全年气温曲线决定自己要不要相信。 
长河君 · 2026/9/5 23:28:35 · 阅读 1.2k 数据中心年耗水低于一家餐厅？拆解低耗水背后的工程条件与验证边界
在关于 Microsoft Fairwater 数据中心的一次公开讨论中Satya Nadella 用了“年耗水不高于一家本地餐厅”这个类比来说明项目的影响。这个说法很有画面感也让很多没接触过数据中心基础设施的人松了口气既然耗水不多那问题应该不大。但我在行业里看过太多把“取水量、循环水量、补水量和蒸发量”混在一张表里的报告所以更关心另一件事这样一句“看起来很低”的耗水表述背后到底需要满足哪些工程条件才能成立边界是什么口径是什么如果换成不同气候、不同负载、不同运维水平结论还成立吗这篇文章不打算论证这条声明是真是假因为仅凭一个类比无法做技术判断。我想做的是把数据中心“省水”这件事拆开来看为什么过去的数据中心那么耗水为什么现在有些园区确实能把补水量压得很低以及作为一个工程技术人员面对类似宣称时应该按什么顺序去验证。1. “不高于一家本地餐厅”这句话工程上需要先问边界1.1 为什么数据中心会被单独“查水表”过去几年数据中心对环境的影响最先被关注的是“电”。大型互联网公司、云厂商和 AI 算力项目都在公布自己的可再生能源采购量、碳排放强度、PUE 等指标。后来大家慢慢发现只谈电不够还有一个容易被忽略的变量是“水”。水在传统数据中心里不是可有可无的消耗品。大量服务器的热量需要通过空调系统搬运到室外其中最常见的散热路径是把热量交给冷却水再由冷却塔喷淋、蒸发把热量排入大气。冷却塔工作的时候白烟一样的水蒸汽会持续飘散那个过程看起来不显眼累积到一整年就是很大的补水量。在缺水地区数据中心的取水许可、用水成本和社区关系都会成为现实约束。过去很多园区选址把电放在第一位哪里便宜、哪里可再生资源丰富就往哪里去但现在“水”已经变成和第二电价并列的选址因素。Fairwater 项目这个话题能引起讨论是因为它把数据中心这种“工业耗水大户”的形象和“一家本地餐厅”放在一起形成了反差。问题在于公众沟通里的类比需要一个共同经验前提。餐厅的用水大家有感受——后厨、洗碗、卫生间、拖地、食客洗手。数据中心的用水则超出了大多数人的日常经验冷却塔蒸发量、排污量、加湿量这些词只要一出现理解门槛就抬高了。用餐厅类比是降低理解门槛但不等于输出了一份技术验证报告。1.2 公众沟通用的是类比工程验证用的是边界同样说“耗水”可以有很多种口径。如果说的是“市政自来水补水”那么冷却塔排污回到市政管网的水算不算消耗如果园区用了中水水表数字是不是完整如果夏季极端高温时冷却塔满负荷运行补水量会不会大幅上升如果员工办公、卫生间和厨房用水也算进去那“一家本地餐厅”的餐厅本身是谁、有多大客流也会影响这个类比的分母。所以我的习惯是遇到一句漂亮的工程宣传语先不要急着夸奖或否定而是把它翻译成边界清楚的问题。时间边界是设计估算还是连续 12 个月的实际运行数据空间边界只算核心机房还是算整个园区用水类型冷却塔补水、加湿用水、办公生活用水分没分开损耗去向水是被蒸发到大气还是排到市政污水管道对比基准餐厅的经营规模、客流、后厨方式是什么只有当这些问题都有了答案“不高于一家本地餐厅”才从传播话术变成可以核对的技术指标。这并不意味着 Fairwater 的说法一定有问题。从工程现实来看确实存在一些冷却系统设计能够把现场补水压到很低的量级。问题只是我们有没有能力在信息不足时保持审慎而不是被类比带着走。2. 数据中心的水不是必需品真正的必需品是“把热排出去”2.1 先看热量是怎么走的才知道水从哪来服务器运行时消耗的电能几乎全部会变成热量。这些热量如果不排走机柜内部温度会持续上升电子元器件寿命和稳定性都会受影响。数据中心的冷却系统本质上做的是把 IT 设备产生的热量从室内搬运到室外。搬运热量的方式有三种基本载体空气、水、制冷剂。空气最方便直接吹风就行但空气的比热容小同样体积下能带走的热量有限。水的比热容大而且蒸发时会吸收大量汽化潜热所以同样水量能搬运的热量远高于空气。制冷剂则可以通过相变把热量从低温端搬到高温端适合精确控制冷量但系统复杂。于是过去的主流方案里水成为重要的搬运介质。冷冻水系统把冷水送到机房空调末端空调末端把室内热空气吹过冷水盘管水变热后回到冷机重新降温冷机再把热量排给冷却水冷却水进冷却塔喷淋蒸发。整个过程里服务器产生的热量最终有很大一部分是通过水的蒸发散到大气中的。这就是传统数据中心耗水的物理由来。水不是被消耗在设备内部而是作为散热介质在冷却塔里以水蒸气形式离开系统。要让系统继续运行就需要不断补充水量。2.2 冷却塔在湿热天气很高效也是耗水大户冷却塔不是一种低效设备它反而是散热效率极高的方案。水蒸发带走热量的能力很强所以才能用相对较小的建筑面积处理巨大热量。但它有一个绕不开的代价需要补水并且需要排污。补水不光是补蒸发掉的水。冷却水在循环过程中水里的钙镁离子、盐分、杂质会不断浓缩。如果一直不排污水质会恶化管道会结垢喷头会堵塞换热效率下降。为了控制水质运维团队必须排掉一部分浓缩后的循环水同时补充新水。这部分叫排污损失同样会出现在水表上。在夏季高温高湿天气下冷却塔需要长时间运行补水量和排污量都会明显上升。一个中等规模数据中心如果完全依赖冷却塔散热一个夏天的耗水量会非常可观。这也是为什么很多园区在宣传时强调“自由冷却小时数”因为只要冷却塔少开耗水量就能降下来。值得注意的是运维目标往往不是“最少耗水”而是“稳定供冷”。冷却水系统的结垢、菌藻滋生、设备腐蚀都会威胁制冷连续性。为了防结垢有的团队宁可多排一点水为了控制军团菌风险还要定期投加杀菌剂并排放一定量的水。这些运行策略都会影响年度总用水。所以做运维的人都知道省水不能靠拍脑袋关阀门而是在水质、结垢、制冷效率和水量之间找平衡。2.3 低耗水的技术路线通常是跳过了蒸发这一步一家现代数据中心的年耗水如果低到和餐厅同量级从技术上讲几乎可以确定它没有依赖传统的开式冷却塔作为常年主力散热路径。它可能走的是下面某条路线或者多条路线组合风侧经济器直接把室外冷空气引入机房或让室外空气与机房回风换热不经过水回路。冬天冷的时候冷却水系统可以停机补水量趋近于零。干冷器/封闭式冷却塔冷却水在盘管内流动不直接与室外空气接触靠风扇强制通风散热。虽然换热效率比蒸发冷却低但几乎不消耗水。冷板液冷用冷却液直接给芯片散热再通过干冷器把热量排到室外。热量搬运有更高能效而且冷却液在封闭回路里可以长期使用年补水量很小。热回收系统把机房余热送到办公区、温室或其他热用户。热量被利用而不是排掉水源侧的需求也随之降低。这几条路线有一个共同特征主要散热路径不再依赖“水蒸发带走热量”。空气是免费介质把它加热本身不消耗水资源冷却液在封闭系统里循环只存在渗漏、检修排水等少量水量蒸发只存在于极端的备用场景或加湿环节。这也是为什么一个数据中心确实有可能把年补水量做到很低。只是要注意能做到并不代表所有地方都能做到。它需要气候、负载、建筑、运维和能源成本多方面的配合。3. 威斯康星的气候能帮忙但低耗水不是天然属性3.1 气候库是一本先天的“冷却日历”任何懂数据中心制冷的人在评估一个项目时都不会只看当地年平均气温。真正要看的是全年逐时的干球温度、湿球温度、湿度分布以及哪些时段可以直接利用室外空气或干冷器。威斯康星州位于美国中北部冬天气温低、寒冷时间长。这种气候对低耗水设计非常有利。只要设计团队把风侧或冷媒侧的“自由冷却”能力做足一年中可能有大量小时数不需要启动冷却塔和冷水机组。那几个月里数据中心的水表可能在很大程度上只反映加湿用水、生活用水和设备维护排水。从这个角度看“在威斯康星州实现低耗水”比在全年高温高湿的新加坡或沙漠地区更容易这是地理位置给的基础条件。不过气候只是提供了可能性。能不能真正把这种可能性落地取决于建筑里的空调系统选型、控制策略、过滤系统、加湿方案和运维团队的执行力。设计得再漂亮如果控制逻辑没有按季节切换设备也不会自动节省。3.2 真正拉高水耗的是过渡季和极端高温一年里最难处理的并不是深冬。冬天室外冷空气充足自然冷却效率高冷却水系统可以停掉。最麻烦的往往是两个时间段一个是春秋过渡季室外温度不高不低机房无法完全靠自然冷却又没热到必须开冷机的程度另一个是夏季极端高温日系统必须全力运行。在过渡季风侧经济器可能会因为室外温度、湿度接近回风状态而“不省不费”有时候还要开冷机来除湿冷机再开冷却塔水耗自然上去。更麻烦的是如果园区维持两个数据中心模块一个靠水冷一个靠风冷夏季切换时控制策略没有优化冷却塔很容易在同一时段集中启动造成补水高峰。所以验证一个项目是否真正低耗水不能只挑天气最舒服的月份看数据而要把最热的一周、连续高负载运行的时段都包含进分析范围。年耗水量的可信度来自最不利工况下依然能得到控制而不是靠过渡季节水的。3.3 这个案例能复制到全世界吗不能直接复制。低用水的设计思路可以复制但每个地方的气候、水价、电价、排放要求和水资源禀赋差异会让最终方案完全不同。有些地方水资源丰富使用冷却塔反而是更经济的选择有些地方虽然缺水但水质很差直接把冷却塔作为主力散热也许还能避免把有限优质水资源消耗在“洗热量”上。真正聪明的数据中心不会追求“绝对低水”而是追求当地约束下的经济、碳排放与稳定运行平衡。还有一种常见误区是把低水耗和低环境影响划等号。如果“省水”是通过大量增加耗电实现的比如把冷机功率拉高、把风机转速调超标、把机房温度压得很低那么总环境影响需要重新计算。水账单独看很好看放到“水-电-碳”三条线里未必最优。这也是我希望读者在看案例时保持的第三个视角省水是目标之一但不是唯一目标。4. 把“一家本地餐厅”翻译成一张可检验的清单4.1 拆解口径取水、排水与消耗真正做工程评估时第一步就是区分几个概念从市政管网取了多少水。有多少水又排回了市政污水系统。有多少水通过蒸发、漂水、绿化、渗漏真正损失掉。有多少水在封闭系统里循环本身并没有被“消耗”。很多争议来自“取水量”和“耗水量”的混用。取水量高不一定代表消耗高如果冷却塔排出的浓缩水进入中水系统二次利用那部分水并没有消失。反过来如果取水量不高但大量水通过蒸发进入大气那它就是真正的消耗。在“一家本地餐厅”的类比里“耗水”通常指向“取水后没有回到水体系统的量”。对这个量做对比需要把现场所有用水末端分清楚。如果没有分项计量那就只能靠估算而工程验收最忌讳的就是用估算代替表计。4.2 一份低耗水声明需要交代哪些关键项我通常建议把“宣称低耗水”的数据拆成一张检查表需要交代的项目 | 为什么需要关注 数据中心总 IT 负载与规模 | 不知道规模数字之间没有可比性 统计周期 | 设计估算、试运行数据、整年运行数据可信度完全不同 现场用水边界 | 是否包含冷却塔、加湿、办公、绿化、消防测试 冷却系统形式 | 开式冷却塔、干冷器、风侧经济器、液冷的比例 冷却塔运行小时数 | 低耗水主要来自冷却塔少开而不是水处理技巧 补水水源 | 市政自来水、中水、再生水、雨水回收来源不同 排污与水处理方式 | 排污水去了哪里、浓缩倍数是多少、是否进入中水系统 加湿用水量 | 冬季低湿或采用风侧经济器时可能额外加湿 最不利工况 | 夏季极端高温、连续满载时水耗是否仍然受控 维护检修排水 | 系统清洗、阀门检修、消防检测用水是否计入年度总量这张表的核心作用是防止人们拿着一个孤零零的年度总数字去评价一套复杂系统。4.3 独立验证最快的方式不是看宣传页而是看月度补水表对一个技术人员来说如果只能看到一个指标我倾向于选“连续 12 个月的补水计量曲线”而不是某个月的 PUE 或水耗汇总。补水计量曲线能反映出很多问题冬季是否有异常高峰夏季高温日是否出现阶梯式上升有没有连续几天停车后再启动导致的跳变补水量和气象温度之间是否成比例。如果数据是按模块分路统计的那信息量会更大冷却塔模块的补水量曲线能直接判断它的运行控制是否合理。很多项目不是设计得不好而是运行团队没有足够精细化地表计和分析。水表放在哪个位置也影响结论如果园区总水表和分路水表之间的沿程存在渗漏总量和分量对不上如果分表故障运维人员只能靠总表差值猜模块用水。一旦出现这种情况对外宣称的低耗水就会变得不可审计。因此在看到话术之前我会先看有没有可靠的计量基础设施。没有计量就没有后续讨论。5. 到了运维阶段省水设计很容易被细节毁掉5.1 水表位置决定一切如果数据中心只有一个市政总水表那它无法区分冷却塔、加湿、办公、消防各用掉多少水。假设总水表年读数很低看起来好像很省水但实际可能是办公人员少、绿化面积小核心冷却系统反而占了大头。做好运维的第一步是在设计阶段就把计量点分清楚。每个补水系统、每组冷却塔、加湿器、生活用水主立管都应该有独立的计量能力。其次运维软件要按时记录这些表计的读数并且关联当时的负载率、室外温度、湿度、机组运行状态。只有建立了这种关联才能回答“某个耗水变化到底是操作失误还是天气变化导致的”。水表本身也会漂移。超声波流量计需要稳定管段电磁流量计需要导电流体机械水表在低流量时误差很大。如果一个项目日常流量很小说明它进入了“低耗水模式”但恰恰在这个状态下小流量误差会被放大。要让低耗水数据可信计量的量程和精度也要在选型时被认真对待。5.2 冷却塔即便不常开水质管理也不能放假低耗水数据中心不一定完全没有冷却塔。很多系统会把冷却塔保留下来作为高温备用冷源平时不启动只有在极端天气或干冷器能力不足时才接手。这种“备而不常用”的冷却塔反而需要更多关注。长期静置的循环水里容易滋生微生物管道内壁会出现腐蚀和生物膜。为了保持水质合格运维团队必须定期排水、补水、投加药剂。哪怕一年只启动几小时为了那几小时的可靠性全年也可能要维持一个最低循环水量并周期性换水。所以不能想当然地认为“有冷却塔就耗水没冷却塔就绝对省水”。系统里即使有冷却塔如果被设计成备用且合理停用年度补水量也能做到很低但要保证在需要它时能稳定顶上去每年花在水质保养上的水量是躲不掉的。5.3 季节切换与加湿器是隐藏用水点还有一种情况是冷机停用了水表却还在走。这通常来自空气加湿系统。在北方的寒冷季节室外空气很干燥。数据机房如果使用风侧经济器把大量室外干燥空气引入室内的相对湿度可能下降。相对湿度太低会增加静电风险某些设备或工艺也可能对湿度有硬性要求。为了维持湿度空调系统会开启加湿器。蒸汽加湿需要把水加热成蒸汽送入风管这个过程会持续消耗水和电。因此可能出现一个反直觉的结果最冷的冬天冷却塔已经停了但水表动量反而来自加湿器和生活热水系统。如果运维团队只看“水冷系统是否运行”会漏掉这部分消耗。解决这个问题没有捷径。控制策略需要根据室内外湿度、焓值和设备允许范围决定自然冷却和加湿之间的平衡点。为了提高一点湿度去开冷机还是不主动加湿但接受温度波动每个园区都需要结合设备耗材和运行成本自己测试。低耗水不是把水阀一关了事而是让每一滴水都花在维持安全运行所必需的地方。6. 这件事对做云、自建机房和搞基础设施的人意味着什么6.1 选机房时“水电双控”会进入常规评估如果你负责公司内部基础设施选型可能已经感受到变化很多地区对新建数据中心的用水指标提出了明确要求甚至会把水耗纳入项目审批。这在过去并不常见。过去看一个机房核心指标主要是电力容量、链路质量、PUE、碳排协议。现在越来越多的评估表里加入了“水资源压力指数”也就是项目所在地的水资源紧张程度。一个用大量冷却塔的数据中心可能在缺水地区面临取水许可限制一个几乎没有补水的园区在水费、排污费和处理工艺上则会有更多主动权。未来选址逻辑会变成先看电再看水再看网再看人。电决定了能不能建水决定了可持续发展上限网和人决定了业务体验和运维效率。6.2 训练负载不是只耗电也决定水耗曲线的形状如果你做的是大规模训练、渲染或数据分析任务可能以为云端资源调度只关注 GPU 型号和价格。但从数据中心基础设施角度看不同类型的任务对散热系统产生的压力完全不同。短时高爆发任务会让冷机频繁启停增加过渡季冷却塔运行时间平稳长时间负载更容易让系统进入稳定供冷模式也更容易让运维团队做负载和水耗的匹配优化。高功率密度机柜如果用液冷总耗水量取决于液冷回路是否封闭、板换冷却侧是否使用开式冷却塔同样是“液冷”不同架构对水资源的依赖可以差出几十倍。这给使用者带来的启示是在要求算力资源时也可以关注所在区域的能源和水约束。你能做的最直接的事是评估长任务是否需要多区域容灾。如果两地机房一个缺水、一个富水调度系统把训练任务切换到水资源相对宽松的区域对整体环境影响是更友好的。6.3 给自己的项目留一套低水设计备选方案即便你现在做的只是一个私有云、一个边缘节点或者一个实验室机房也可以从 Fairwater 这个案例里带走一套思路省水不是最后给冷却塔加一个节水器而是从设计最前端就决定是否依赖蒸发散热。在自己项目里先做三件事画一张水系统图标出所有进水点和出水点把蒸发、排污、加湿、维护排放区分开。为每个主要用水末端配上独立计量先积累一个月以上的补水量数据。在模拟夏季最热日负载的情况下看系统是否可以不依赖冷却塔完成散热。如果必须依赖就要明白你的设计是有水耗底线的。这套小流程不复杂但它给你的团队提供了一种稳定、可复用的评估语言。否则每次内部评审都只靠猜测和宣传口径几个月后根本不会有人知道实际水耗是多少。7. 与其争辩数字不如先建立一套省水系统的“解释框架”说回 Fairwater。有人在评论区讨论“一家餐厅到底一年用多少水”也有人在争论微软是不是在做公关。我倒觉得这则表述真正有价值的信息不是数字的大小而是它成功让公众开始关注一个以前很少有人感知的变量数据中心的散热可以不需要那么多水只要系统设计选择了一条不以蒸发为核心的路径。但这种转变不是自动发生的。它需要当地气候的配合需要冷却架构选型需要从进水管到冷却塔、加湿器、污水管的所有计量点都被仔细定义还需要运维团队能在全年不同季节里把控制逻辑执行到位。任何一个环节失守号称很低的年耗水都可能变成纸面数字。下次看到某个数据中心说自己的水耗低于一家餐厅、低于一个游泳池、低于一栋办公楼时我建议你不要只问“是不是真的”而是问三个问题它统计的边界是什么它的最不利时段数据是否符合预期它有没有分项计量能支撑这个结论这三个问题问下来绝大多数宣传话术都会露出真实形状。只有那些自己做过水系统设计、对全年运行数据有信心的项目才经得起这种追问。这就是技术人和公众沟通的区别公众听到结论工程师打开边界、先找水表再对照一张全年气温曲线决定自己要不要相信。