ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Meta力推的风助液冷AALC:AI高功耗机柜的散热务实方案

Meta力推的风助液冷AALC:AI高功耗机柜的散热务实方案 做数据中心基础设施这行最近两年最绕不开的话题就是AI训练集群的功耗。单块GPU从H100的700W一路涨到B200的1000W以上一个机柜塞满加速卡功耗轻松突破50kW。传统风冷在这个密度下不是说不能用而是散热代价高到不划算。这时候回头看Meta在开放计算项目OCP框架下力推的风助液冷方案AALCAir-Assisted Liquid Cooling会发现它根本不是赶时髦而是在实打实解决一个工程经济性问题在风冷和全液冷之间找到一条既能压住高功耗、又不用把整个机房推倒重来的中间路线。这篇文章我就结合自己接触到的液冷改造经验把AALC的原理、选型逻辑、落地细节和运维注意点拆开讲清楚适合正在评估液冷方案的数据中心工程师、机房运维团队以及做算力基础设施规划的朋友参考。1. 风冷和全液冷各卡在哪AALC解决的其实是经济性问题1.1 单机柜功率密度爬升后风冷先撞上“不经济”的天花板很多人有个误区觉得风冷散不掉热是物理极限。实际上风冷的散热能力没有绝对上限只要你愿意把风机加大、把机房送风温度降低总能带走更多热量。真正的问题在于代价风扇功耗和风量之间近似是三次方关系风量翻倍风机功耗要翻八倍。一个50kW的机柜如果全靠风冷机柜尾部那几排风扇的耗电会高到让整个机房的PUE电能利用效率变得很难看。另一方面气流组织也会出问题。传统机房设计按10kW到15kW每柜来做冷通道送风地板下静压箱、架空地板开孔率都是按这个量级算的。到了30kW以上要么送风温度压得很低要么风量巨大导致冷通道风速高得像吹风机局部热点和气流短路接踵而来。我见过不少机房在单柜功率拉到20kW以上后靠调低空调设定温度来硬撑结果压缩机功耗飙升机房PUE从1.3一路涨到1.6以上电费账单非常难看。更麻烦的是风冷散热能力还受环境温度制约。在亚热带地区夏季极端工况下冷却塔或干冷器能提供的冷源温度有限机房回风温度稍高一点空调系统就要开压缩机制冷。这就陷入了一个恶性循环负载越高的机柜越需要更低的风温而更低的风温意味着更高的制冷能耗。所以风冷不是“不能做”而是“不划算”。对于超大规模数据中心而言电费是运营成本的大头任何散热方案如果让PUE恶化0.1乘以数万台服务器的基数全年电费差就是千万级。风冷在20kW/柜以下还有存在价值再往上就必须找更高效的热量搬运手段这就是液冷登场的原因。1.2 全液冷部署的账算完也没有想象中那么美既然风冷扛不住那就直接上全液冷市面上浸没式和全冷板方案确实能把PUE做到1.1以下但代价也摆在明面上。首先是改造成本。全冷板方案要求几乎每个节点的CPU和GPU都贴冷板管路、快接头、冷板数量巨大。以一个1000机柜的机房为例冷板覆盖率做到80%以上意味着数千个快接头和数不清的潜在漏液点。浸没式更夸张整个服务器要泡在氟化液里现有x86服务器几乎都不能直接用需要定制硬件设备采购成本和维护复杂度直线上升。其次是运维门槛。全液冷机房对运维团队的要求完全不一样要懂水力平衡、要会处理管路冲洗、要掌握水质管理甚至连机房漏水报警的响应流程都要重写。很多传统IDC运维团队根本不具备这些技能强行上线全液冷出了问题检修窗口会非常长。还有一个容易被忽略的点全液冷会形成“单点依赖”。如果CDU冷量分配单元出了故障高压冷水送不进去整个机柜的IT设备只能靠自然冷却硬扛几分钟内就可能过热宕机。为了保证可靠性你得做CDU的N1冗余、泵组冗余、管路环网设计这些都要花钱。所以Meta的思路很清楚不是所有热量都需要液体来搬。液冷负责搞定功耗最大的CPU和GPU剩下那些功耗不高的部件比如存储盘、网卡、电源模块完全可以让风冷继续管。这样一来冷板覆盖范围大幅缩小漏液风险点减少管路成本下降液冷系统设计容量也可以按“承担主要热负荷”而不是“承担全部热负荷”来配置。这就是AALC的出发点。2. 理解AALC的核心液冷为主、风冷善后而不是简单堆叠2.1 先把它和传统冷板式液冷区分开AALC的全称是Air-Assisted Liquid Cooling直译过来是“空气辅助液体冷却”但从中文“风助液冷”的语序来看它的实际含义更接近以液冷作为主力散热手段风冷作为辅助和兜底。这和传统冷板液冷有个本质区别。传统冷板式液冷的设计目标是“液冷全覆盖”只要条件允许所有主要发热芯片都上冷板风冷只负责电源、网卡等边角部件。AALC则刻意不追求全覆盖。它让液冷承担大约六成到七成的热量搬运剩下的三到四成依然靠风冷带走。冷板只覆盖功耗密度最高的几个点位比如训练服务器的GPU和CPU模块其他部件继续沿用风冷散热设计。我理解这个思路有点像夏天家里开空调的同时还开着风扇。空调是主力冷源负责把房间温度压下来但风扇的作用是搅动气流、让冷量分布更均匀也让空调不必顶着最低温度猛吹。两者配合比单开空调更舒服也比单开风扇有效得多。这个设计还有个附带好处服务器本体不需要做颠覆性改动。现有2U/4U服务器只要在CPU和GPU上方预留冷板安装位其余结构和风冷机型几乎一致硬件供应链不用重来。2.2 算一笔热量分配的账为什么液冷承担主要负荷是划算的我们拿一个典型的50kW AI训练机柜来算一笔账。假设液冷系统承担其中35kW的散热风冷承担剩下的15kW。先看风冷侧。传统全风冷方案里这50kW全部要由机房空调和机柜风扇搬走风扇功耗可能要占到机柜总功耗的8%到10%。AALC把风冷负荷压到15kW以后机柜风扇转速可以大幅下调。根据风机功耗与转速的三次方关系转速降一半风扇功耗降到原来的八分之一。这意味着机柜风扇的耗电从几千瓦降到几百瓦对PUE的贡献是实打实的。再看液冷侧。35kW的散热量用中温冷水比如供水温度30到35℃就能轻松带走不需要传统风冷空调那种7℃到12℃的冰水。冷源温度越高自然冷却可用的时间越长。在大部分温带地区30℃以上的冷却水几乎全年都能靠干冷器或冷却塔自然散热压缩制冷机组基本可以停掉。这就是为什么液冷方案能做到PUE 1.1以下核心不是液冷本身有多神奇而是它允许你用更接近环境温度的冷源完成散热把压缩机的电耗省掉了。这里有一个很多初次接触液冷的人容易忽略的点液冷散热能力强靠的是水的比热容和密度远大于空气。同样搬走1kW热量水需要的流量和温差远小于空气需要的风量和温差。AALC只需要把液冷系统设计成覆盖高功耗芯片就能以较小的管路规模获得大部分液冷收益这是一笔很划算的买卖。2.3 系统构成和关键部件AALC的硬件架构和传统冷板液冷基本同构区别主要在覆盖率和控制策略上。典型系统分两级回路。以机柜为界机柜内部叫二次侧回路冷却液从机柜入口歧管流入经过冷板吸收芯片热量再从出口歧管流回CDU。机房外部叫一次侧回路CDU通过板式换热器把热量传给外界冷源冷源可以是干冷器、冷却塔或者厂区冷水管网。两级回路之间用换热器隔离目的很明确——把一次侧的水质问题和二次侧完全分开避免外界冷却水里的杂质、微生物直接进入服务器冷板降低堵塞和腐蚀风险。关键部件包括冷板、快接头、歧管、CDU和室外散热设备。冷板直接贴装在芯片顶盖上方内部有微通道或翅片结构靠液体流过带走热量。快接头是冷板进出水的连接点可靠性要求极高插拔时不能漏水。歧管负责把CDU送来的冷却液分配到各个服务器节点同时收集回水。CDU里面是循环泵、板换、过滤器、仪表和控制阀相当于整个二次侧回路的心脏。从实践来看这些部件的选型质量直接决定系统长期可靠性。尤其是快接头和冷板内部的微通道一旦水质控制不好或者安装不到位后期处理非常痛苦。这个我在后面运维部分再展开。3. Meta为什么押注这条路从风冷标杆到液冷务实派3.1 Meta的风冷基因和AI负载带来的转折Meta前Facebook在数据中心行业一直是风冷路线的坚定实践者。早年它在瑞典Luleå和俄勒冈Prineville的数据中心都把风冷和蒸发冷却做到了极致利用当地寒冷气候直接引入室外空气冷却几乎不依赖压缩制冷。可以说Meta的工程团队在“用风冷解决大规模散热”这件事上积累了非常深的技术护城河。但AI负载改变了游戏规则。训练集群的机柜功率密度远超传统Web服务器风冷方案在单柜50kW以上的场景已经完全不具备经济性。Meta在公开资料里展示过自己大规模AI集群的散热演进从最开始的风冷改造到引入液冷再到提出AALC其实是一个被负载倒逼的过程。Meta在OCP峰会上分享AALC方案时有一个观点很打动我他们不认为液冷是所有场景的银弹也不认为传统风冷应该被立刻淘汰。恰恰因为自己在风冷领域有大量存量资产和运维经验所以更倾向于设计一个能兼容两者的中间方案。这个思路和很多老牌数据中心厂商不谋而合——存量机房不是不想改是改造成本太高需要一个渐进路径。3.2 AALC和全液冷、浸没式的工程权衡我给身边朋友做方案对比时习惯用下面这个表对比维度传统风冷全冷板液冷AALC风助液冷单机柜散热能力约20-30kW以上不经济100kW可支撑50-80kW改造复杂度低高需全面改造中冷板仅覆盖高功耗部件漏液风险点无多少只有局部冷板运维技能要求传统暖通即可高需液冷专长中可逐步过渡PUE潜力1.4-1.61.1以下1.15-1.25对现有服务器兼容性高低中等偏高AALC最大的工程价值在于容错性和部署速度。全液冷方案里液冷系统是唯一散热通道一旦失效就是整柜宕机。AALC则保留了风冷兜底能力——液冷系统检修或者故障时风冷虽然带不走全部热量但至少能给运维争取时间不至于几分钟内就触发过热保护。漏液风险也是大规模部署时必须考虑的。ESD静电放电和漏水是电子设备的两大天敌。全冷板方案几千上万个接头任何一个漏液都可能造成整柜甚至整排服务器报废。AALC把冷板数量控制在一个相对小的范围风险暴露面小了很多。3.3 “够用就好”的设计哲学才是超大规模工程的常态很多技术文章喜欢把“极限PUE”当作唯一追求但在真实的超大规模数据中心运营里比PUE更重要的是整体TCO总拥有成本和可用性。追求PUE 1.05意味着你要为那零点零几的电费投入巨大的设备冗余和运维复杂度。而AALC的思路是用液冷把大部分热量高效搬走剩下的交给风冷整机PUE做到1.2左右就已经是非常好的成绩了。省下来的钱可以用来做更完善的监控、冗余和运维体系让整个集群的可用性更高。从我接触的机房运营方来看这个逻辑越来越被接受。大家慢慢意识到AALC不是液冷的“低配版”而是针对当前硬件功耗和存量设施条件做的最优工程解。它在合适的位置用合适的技术而不是为了炫技把所有鸡蛋都放进液冷一个篮子里。4. 部署AALC真正要盯紧的几个工程细节4.1 水温设定是全局的关键别再把液冷当冰水系统用液冷系统一个最常见的错误是沿用空调系统的思路把冷却水温度设得很低。AALC的场景里完全没有必要把供水温度压到15℃以下。GPU和CPU的允许结温通常都在85℃到100℃以上冷板入口水温在35℃到45℃完全能够满足散热需求。水温每提高几度一次侧自然冷却的可用时间比例就显著上升。在温带地区40℃的冷却水几乎全年都可以直接用干冷器散热无需启动压缩机组。这不仅省电还能减少压缩机维护成本。高温水还有两个容易被忽略的好处。第一供水温度和机房露点温度差距小冷板表面不易结露自然也就不用担心冷凝水滴到主板上引起短路。第二高温水进入冷板后出口水温可以做到50℃甚至更高这种温度的热水未来还可以做余热回收利用。我建议部署时重点监测四个温度点CDU二次侧供水温度、二次侧回水温度、冷板入口温度、冷板出口温度。前两个决定了系统整体换热效率后两个直接反映芯片散热是否正常。任何一组数据偏离设计范围都要及时查原因而不是等告警出来再处理。4.2 风液协同的控制逻辑风扇和水泵不能各干各的AALC既然同时保留风冷和液冷就必然面临协同控制的问题。最简单的实现方式是各自独立控制水泵根据液体温度变频风扇根据CPU温度调速。但这种“各自为政”的做法在负载突变时很容易出问题。举个实际场景AI训练任务在凌晨开始跑大批量数据CPU和GPU功耗瞬间拉满。此时液体温度还没升上来水泵不会立刻提速CPU温度却已经飙升风扇开始猛转。如果风扇转速上限设得足够高短时间内也能压住温度但代价是噪音和能耗飙升而且液体侧的散热能力没有被充分利用。更好的做法是以IT负载作为前馈信号。服务器BMC上报当前CPU/GPU功耗机房控制系统根据总功耗预估需要的液体流量提前调整水泵频率和阀门开度。随后再以实际液体温度作为反馈信号做修正形成“前馈反馈”的闭环控制。同时给风扇转速设置一个合理的上下限和速率变化限制避免温度在设定值附近震荡时风扇忽快忽慢。在实际调参时我见过不少团队把死区设得太小导致控制系统频繁动作。建议冷却水温度控制死区设在±2℃左右风扇转速调整速率限制在每秒几个百分点这样系统稳定性会好很多。4.3 漏液防护和水质管理的实操经验漏液是液冷系统最让人头疼的问题。AALC虽然冷板数量少但一旦漏液影响范围同样不小。我的经验是至少做三层防护第一层选用可靠的快接头和冷板。安装时要求插拔到位并做色标确认避免“看着插上了、实际没卡紧”。第二层在冷板正下方部署漏液检测绳或检漏托盘一旦检测到液体立即联动服务器告警同时关断对应支路的电磁阀。第三层在机柜底部和地板下布置分布式漏液传感器防止漏液沿着管路流到其他区域而无人发现。水质管理同样是日常运维的重头戏。二次侧冷却液通常使用去离子水加缓蚀剂需要定期监测电导率、pH值、缓蚀剂浓度和微生物含量。电导率过高说明离子污染在累积容易引起电化学腐蚀pH值偏离正常范围会导致冷板内部铝制微通道腐蚀微生物则可能在管路内壁形成生物膜降低换热效率甚至堵塞微通道。如果机房所在地区水质偏硬一次侧回路还要考虑加装软化或过滤设备防止水垢在换热器板片上沉积。我建议运维团队建立水质台账每月至少做一次全面检测关键指标形成趋势曲线一旦发现异常尽早干预。5. 上线之后的运维观察数据怎么看故障怎么扛5.1 评估AALC效果别只盯着PUE一个数AALC上线后肯定要拿数据说话。PUE是最直观的指标但它只能反映整体能效无法告诉你液冷系统是否在高效工作。我更建议关注一组组合指标IT设备功耗、风扇功耗占比、CDU水泵功耗、一次侧散热设备功耗、冷却水供回水温度差。冷却水供回水温差是一个很灵敏的信号。正常工况下设计温差通常在5℃到10℃之间。如果温差明显小于设计值说明液体流量过大或者冷板换热不充分存在“大流量小温差”的低效运行状态如果温差明显大于设计值则要警惕流量不足或者某个支路堵塞。风扇功耗占比的变化是AALC效果的直接体现。从全风冷切到AALC后机柜风扇功耗降幅通常会非常可观这部分省下来的电会直接反映在PUE上。5.2 液冷故障和局部失效时风冷兜底到底能撑多久运维中必须提前想清楚一个问题如果某个冷板支路故障或者CDU停摆风冷系统能独立顶多久。这决定了故障处理的缓冲时间。在AALC设计里风冷是“善后”角色它的散热能力按承担三到四成总热量来配置。一旦液冷失效风冷要独立面对全部热负荷散热能力肯定不够。我建议做一套明确的降载策略液冷故障告警触发后自动降低机柜内AI任务负载或迁移业务给运维争取至少30到60分钟的处置窗口。如果没有降载策略单纯指望风冷硬扛大概率会触发服务器过热关停。另一个容易被忽视的点是冷板覆盖范围是有边界的。有些新出的加速卡功耗很高但当初部署AALC时还没被纳入冷板覆盖范围。如果后续硬件升级引入了这类高功耗部件一定要重新评估风冷侧能否兜住必要时补充冷板覆盖别让一个小热点拖垮整个系统的可靠性。5.3 混合布局机房的气流管理和水力平衡很多机房不是一次性全部改成AALC而是先改造一部分机柜这就形成风冷机柜和液冷机柜混合布局。此时要特别注意气流组织液冷机柜因为风扇转速降低自身排风量变小如果冷通道压力设计还是按全风冷机房来可能会出现气流短路导致隔壁风冷机柜送风不足。水力平衡同样重要。二次侧管路是并联结构支路长短不一会导致流量分配不均——靠近CDU的冷板流量大、远端冷板流量小。安装平衡阀并做好初调试是标准做法。我见过一些项目为了赶工期跳过这一步结果远端机柜芯片温度比近端高十几度最后还得返工。6. AALC在行业里会怎么演化6.1 哪些场景最适合AALC从适用性来看AALC最契合三类场景一是已经建成的风冷机房想要升级改造但又不能整机房停机的场景二是单柜功率密度在50kW到80kW的AI训练和推理混合负载三是预算有限、不想一次性投入全液冷基础设施的团队。对于新建的超大规模机房如果从零开始设计可能还是会考虑更激进的全液冷方案毕竟一次性部署可以少很多兼容性包袱。但对于存量机房来说AALC是当前性价比最高的散热升级路径。你可以先改一部分机柜积累运维经验再逐步扩大液冷覆盖范围风险可控。6.2 再往后看液冷比例大概率继续走高AALC不会是一个静止的终点。随着单芯片功耗继续往上走液冷需要承担的热量占比大概率会从60%继续向80%、90%爬升。到时候冷板覆盖范围会扩大风冷在系统中的角色会进一步弱化但完全消失的可能性不大——总有那么一些部件值得用风冷来处理可靠性设计也需要风冷作为最后一道防线。同时AALC的高温水回水也为余热回收创造了条件。数据中心余热利用过去受限于热量品位低AALC把回水温度做到50℃以上之后通过热泵提升就可以用于办公供暖或生活热水。未来数据中心从“耗电大户”变成“热电联产”的一部分也不是不可能。我自己在机房改造项目里的体会是AALC带给这个行业最大的价值不是某个具体参数多好看而是证明了一条“稳扎稳打”的演进路径不用推翻一切重来也能让散热系统跟上算力发展的步伐。对于大多数正在犹豫要不要上液冷的团队来说这是一条值得认真考虑的路。
返回列表