算力基础设施这两年的热度说实话有点超出很多从业者的预期。以前我们聊数据中心聊的无非是机柜数量、带宽峰值、机房等级现在再谈满屏都是“万卡集群”“液冷密度”“绿电比例”“故障域爆炸”。表面上看是设备升级本质上是一场从电力、网络、散热到调度、运维的全链路重构。这篇文章想借“他山之石”这个角度把近期观察到的算力基础设施面临的新挑战系统梳理一遍也聊聊我们在实际落地过程中踩过哪些坑、有哪些值得借鉴的解法。适合正在做IDC建设、算力平台、集群调度的朋友也适合想从宏观层面理解算力行业困局的技术决策者。1. 算力基础设施的挑战正在更换赛道过去十年数据中心的核心矛盾很简单容量。机柜不够就加机柜带宽不够就扩容功率预算不够就优化一下供电参数。整个行业靠着“堆硬件、扩规模”走过了黄金十年。但到了大规模GPU集群普及的今天这套打法明显失效了。1.1 从“容量焦虑”转向“电力焦虑”早期建设机房最常用的一句话是“按需扩容”意思是土建、电力、制冷都留出余量业务上来了再逐步上设备。这个模式在今天遇到一个特别现实的问题GPU集群的电力需求不是线性增长而是像过山车一样陡增。举个实际数据传统CPU机柜单柜功率通常在4到8千瓦一两百台服务器放在一起惬意得很。到了GPU时代单机柜8卡H系列服务器轻松突破30到40千瓦甚至面向下一代芯片设计时单柜功率已经按100千瓦以上做预留。一个1000机柜规模的传统机房满打满算大概能承载6到8兆瓦IT负荷但换成高密度GPU机房后同样的机柜数量功率需求直接干到30到40兆瓦。这种跳跃式增长把供电系统的余量瞬间吃干榨净。很多新建项目的选址逻辑已经从“哪里有机房资源”变成“哪里有电”电网接入容量成了真正的稀缺资源。1.2 单机柜密度飙升带来的连锁效应功率密度提高不是换个大电源那么简单它把整个基础设施的逻辑都打乱了。机柜内部首先得改原来1U或2U服务器随便插现在8卡GPU服务器动辄10到15千瓦需要专门的电源分配单元、汇流条甚至机柜级母线。电力从机房侧引入到服务器端的路径上每一个节点都在触碰容量上限。更麻烦的是高密度机柜对楼板承重、空调送风方式、消防分区都有连锁影响。很多存量机房想改造升级结果现场一勘测承重梁不够、层高不够、冷冻水管径不够最后只能推倒重建。这也是为什么现在行业里经常说“新建为主、改造为辅”因为改造的成本和难度比想象中大得多。2. 电力与能源算力扩张的第一道硬约束电力是整个算力基础设施里最基础、也最容易被低估的环节。很多团队在项目早期把精力放在芯片选型和网络架构上等设备进场了才发现配电系统成了瓶颈这时候再改代价极其高昂。2.1 供电架构如何从“够用”走向“撑不住”传统数据中心大多采用2N或DR冗余的供电架构10千伏进线经变压器、UPS、列头柜到机柜。这个架构的特点是稳定故障时能无缝切换但缺点是效率偏低、扩容困难。尤其在GPU集群这种功率波动极大的场景下传统UPS的响应速度和过载能力都会吃紧。另一个隐藏问题是谐波和冲击电流。GPU服务器电源在启动瞬间会产生较大的电容充电电流几十台甚至上百台设备同时上电瞬间电流可能引发配电开关误跳闸。我们实际项目中就遇到过一批新的GPU服务器接入后第一次批量开机直接跳了楼层配电间的总闸排查半天才发现不是设备故障而是启动电流叠加超过了断路器瞬动整定值。解决思路是分层上电、分批启动同时在配电设计阶段就要把“冲击系数”考虑进去而不是简单地按额定功率累加。这一点很多有经验的电气工程师会提醒但项目协调不到位就容易漏掉。2.2 绿电与储能绕不开的双重考验碳中和的大背景下算力基础设施的用能结构和碳足迹已经从“加分项”变成“必答题”。但对运维团队来说绿电带来的最大挑战不是“有没有绿电”而是“绿电不稳定怎么扛”。风电和光伏都存在明显的间歇性白天出力高、晚上出力低多云天和晴朗天的发电量差异巨大。算力负载虽然可以错峰调度但GPU训练任务一旦中断损失的可不只是几个小时的电力费用而是整轮训练的状态和进度。如何在电网波动和算力稳定之间找到一个动态平衡是基础设施和平台调度团队必须共同面对的课题。储能是目前比较现实的缓冲手段但电池系统的容量规划、充放电策略、安全消防都跟传统机房完全不同。锂电池的能量密度确实高但热失控风险也呈数量级上升消防设计需要单独考量这又是一笔隐性成本。3. 散热与制冷液冷不再是可选项而是必选项两年前聊液冷很多人的态度还是“再等等看看”觉得风冷加高风量就够用了。到了今天几乎所有的算力基础设施项目在规划阶段就已经把液冷作为默认方案。原因不复杂——风冷的散热天花板就在那里功率密度一上去风冷无论怎么优化都压不住。3.1 风冷极限在哪里什么时候必须上液冷风冷散热能力理论上可以做到单机柜20到30千瓦但这是以巨大的风量和噪音为代价的。机房为了维持环境温度需要极大提升空调系统的循环风量这本身就是一笔不菲的能耗开销。更麻烦的是GPU芯片的热流密度越来越高芯片表面单位面积的热量远超空气的换热能力光靠吹风很难把核心温度压到合理范围。从实际经验来看单机柜功率超过15到20千瓦以后液冷的经济性就明显优于风冷。液体的比热容是空气的几十倍换热效率高出一大截而且可以把热量直接带到机房外面避免机房内部的热岛效应。很多新建项目直接按“全液冷”设计不是激进是务实。3.2 冷板、浸没与喷淋三种液冷路线的选型逻辑液冷并不是单一技术冷板式、浸没式、喷淋式各有适用场景。冷板式是目前最主流的方案发热器件通过冷板与冷却液换热冷却液不直接接触电子元件安全性高对现有服务器形态改动也最小。主要瓶颈在于冷板只能覆盖CPU、GPU等高发热器件其他元器件仍需要风冷辅助所以严格来说冷板式是“液冷为主、风冷为辅”的混合方案。浸没式散热效果最彻底服务器整体泡在绝缘冷却液里不需要风扇安静、高效PUE可以压得非常低。但短板也明显维护不方便更换硬件要停机排液服务器定制化程度高整机成本上浮明显。它适合超高功率密度和对噪音敏感的特殊场景大规模商业部署还在爬坡。喷淋式是把冷却液直接喷淋到芯片和主板表面技术上介于冷板和浸没之间但目前生态还不成熟商用案例较少。我个人的建议是如果做通用算力平台优先选冷板式因为对现有应用生态最友好运维团队的可控性最高。如果是超算或专用训练集群可以评估浸没式但一定要把维护流程跑通再批量上。3.3 液冷带来的运维新问题液冷不是“装了就不操心”相反它给运维团队带来了一整套全新的管理课题。冷却液的电导率会随着时间变化水质管理做不到位短期没事长期会引发腐蚀和堵塞。系统里的阀门、快接头、软管任何一个环节泄漏轻则宕机重则烧毁硬件。我们在实际部署中专门加装了一套漏液监测系统在机柜底部和管线连接处部署传感器哪怕一丁点液体渗出都能立刻告警并联动关断。很多第一次上液冷的团队会觉得这是小题大做但真等到漏水再反应损失就不是一个传感器能弥补的了。4. 网络与互联算力集群的“血液循环系统”芯片算力再强如果网络传输跟不上整个集群的效率照样被拉垮。大规模GPU训练场景下网络已经从“辅助设施”变成了“核心性能组件”。千卡级别的训练任务每损失一点点带宽或增加一点点时延都会直接反映在训练时间和成本上。4.1 东西向流量爆炸式增长传统三层架构失效传统数据中心以南北向流量为主用户请求进来业务响应出去网络设备的核心能力在于大缓存、高并发连接。但AI训练集群的流量绝大多数是东西向的也就是服务器和服务器之间的数据交互。以一个千卡集群为例训练过程中需要频繁做梯度同步每迭代一次数百张卡之间就要交换海量数据。这种流量模式有几个特点突发性强、持续时间长、对丢包极其敏感。传统的核心-汇聚-接入三层架构在网络汇聚层很容易出现拥塞一旦出现微突发丢包整个分布式训练的性能立刻断崖式下跌。现在主流方案是采用胖树或类Clos组网所有交换机层级都承担转发任务东西向带宽可以做到线性扩展。同时多路径负载均衡技术把流量分摊到多条链路上避免单条链路打满导致丢包。4.2 Scale-Up与Scale-Out之争GPU互联的博弈GPU互联存在两种思路一种是走NVLink这种高速私有协议把多张卡像一台大设备一样紧密耦合也就是Scale-Up另一种是走RoCE或InfiniBand以太网络把更多服务器扩展进来也就是Scale-Out。两种思路各有优劣。Scale-Up方案延迟低、带宽高但扩展规模受物理接口数量限制Scale-Out方案扩展灵活但网络通信开销大延迟和数据同步成本更高。现在的行业趋势是两者结合机内和机间通过高速互联组成一个大的“逻辑GPU”再通过网络把多台这样的设备连接起来。这种混合架构对网络设计提出了更细的要求到底哪些流量走总线、哪些流量走网络、网络拓扑如何匹配计算图都需要精细规划不是简单买一堆交换机就能解决的。4.3 无损网络的真相PFC风暴与流控难题RoCE要跑出高性能理论上需要“无损网络”支撑也就是网络不能丢包。为了做到这一点业界普遍开启PFC优先级流控机制。PFC的本意是当接收端拥塞时向上游发送暂停帧让上游设备暂停发送数据从而避免丢包。理想很丰满现实很骨感。PFC有一个著名的副作用叫“PFC风暴”或“拥塞扩散”一个端口的拥塞可能逆流而上把暂停信号扩散到整个网络导致所有流量都停下来。很多团队第一次跑大规模RoCE集群时都遇到过这种情况结果就是分布式训练任务性能剧烈抖动甚至挂死。解决这个问题没有银弹。常规做法是精细化监控拥塞队列、合理设置PFC阈值、启用ECN显式拥塞通知、在负载均衡策略上做文章。但说实话这些非常考验网络工程师的功底一个参数配错集群性能就上不去。5. 异构算力与调度硬件堆上去软件跟不上基础设施不只是电、冷、网这些“物理层”的东西还有一层看不见但同样要命的“逻辑层”——资源调度。GPU集群的算力调度比传统的CPU服务器调度复杂得多这也是很多团队在算力基础设施落成之后才真正面临的hard模式。5.1 资源池化的困境GPU不能像虚拟机一样随意切分传统云计算里CPU、内存、磁盘可以非常灵活地池化一台机器上开几十个虚拟机毫无压力。但GPU不一样一张显卡的显存和算力是固定的要么整卡分配要么通过MIG或vGPU做有限切分。切分粒度粗、切分后有性能隔离问题而且很多AI框架对“单卡独享”有隐性强依赖。这导致算力基础设施的利用率天然低于传统云计算。服务器CPU可能到50%利用率已经很不错了但GPU集群要是利用率低于60%整个项目的投资回报率就会非常难看。如何提高GPU利用率很多时候不是硬件问题而是调度策略和应用改造的问题。5.2 调度器真正要解决的是“装箱”和“碎片”问题算力调度听起来高大上本质上还是一个装箱问题把不同的训练任务放到合适的GPU上尽量提高集群利用率同时保证任务之间的隔离和公平。现实中的难点在于任务形态千差万别。有跑几分钟的小任务有跑几周的大任务有需要单卡的任务有需要跨节点多卡的任务有对延迟敏感的在线推理有追求吞吐的离线训练。调度器要在这些复杂需求之间找到平衡既要避免碎片化浪费又要防止大任务“饿死”小任务。业界比较常见的做法是双层调度加共享队列先用“过滤-打分”机制选出一个候选节点集合再基于真实资源容量进行精确判断。比简单的FIFO队列要灵活得多但配置起来也有门槛。5.3 故障域扩大后如何做断崖式容错GPU集群规模越大故障发生的频率就越高。一块显卡故障、一个交换机端口异常、一根光纤光衰过大都有可能导致整个训练任务中断。传统分布式应用通常有自己的容错机制比如参数服务器可以容忍个别节点掉线。但大规模GPU训练经常是全同步模式任何一个节点落后整个集群都要等它任何一块卡故障所有节点都要停下重来。这就产生了一个新需求checkpoint频率和故障恢复策略的平衡。checkpoint太频繁训练效率下降checkpoint太少故障后恢复成本太高。需要结合GPU集群的历史故障数据和任务重要程度找到最优策略。这块目前还没有特别成熟的现成方案更多是靠运营团队在实战中不断调参、积累经验。6. 绿色低碳与全生命周期运营算力基础设施的绿色化已经不是一句口号它直接关系到项目能不能获批、融资能不能到位、客户愿不愿意买单。越大的算力集群碳账本越复杂绝不能简单用PUE一个指标糊弄过去。6.1 PUE之外CUE和WUE的隐性压力PUE衡量的是“数据中心总能耗除以IT设备能耗”这个指标只能反映机房层面的能效水平无法反映算力本身的碳排强度。一个PUE做到1.1的机房如果用的全是火电单位算力的碳排放依然很高。现在很多项目在评估阶段就开始关注CUE碳利用效率和WUE水利用效率。CUE关注的是单位IT能耗对应的碳排放量这需要把绿电比例、电网排放因子等因素纳入核算WUE关注的则是数据中心耗水量尤其是蒸发冷却和闭式冷却塔方案在缺水地区的项目里是个非常大的制约条件。我在实际项目里发现很多团队在方案初期不重视水资源消耗等到环评阶段才发现当地取水指标不够只能临时改方案。建议任何新项目在选址阶段就把电、水、碳三本账都拉出来一起算别等到设计阶段再救火。6.2 算力碳效从设备级走向全链路全生命周期的碳足迹算起来比想象中复杂。芯片制造环节的碳排放、服务器生产的材料碳足迹、机房建设过程中的建材碳排放、运行期间的电力和水消耗、设备退役后的电子废弃物处理每一个环节都有碳数据。从设备级来看芯片能效比是决定算力碳效的核心。同等算力下新制程芯片的功耗可能比老一代低30%到50%但换设备本身也是巨大的成本和碳投入。什么时候“汰旧换新”在经济和碳账本上划算需要做全生命周期评估而不是只看单台设备的能效参数。6.3 老旧机房改造的“包袱”算力需求的爆发并不意味着所有老机房都能跟上时代。大量存量机房面临一个尴尬局面建筑面积不小但承重、层高、配电容量、制冷能力都不满足GPU集群的需求。改造一盘算成本甚至比新建还高最后只能闲置或做低算力业务。行业里有一个说法叫“汰旧建新”但汰旧不是说拆就能拆的。机房里还有很多跑着的业务迁移需要时间窗口设备处置需要合规流程机房所在建筑的产权和租赁合同也要处理。这中间的运营协调难度完全不亚于技术方案的复杂度。7. 他山之石从传统行业翻新出来的解法标题里写“他山之石”是因为很多算力基础设施的问题其实在其他行业早就遇到过。关键是别闭门造车要把成熟行业的一些思路拿过来消化。7.1 电网的“源网荷储”与算力调度的暗合电力系统很早就提出了“源网荷储”一体化的概念核心思想是把发电、输电、用电、储能放在一个体系里统筹管理而不是各管各的。算力基础设施的资源调度其实也面临同样的问题——发电侧对应算力供给电网侧对应网络传输负荷侧对应业务需求储能侧对应数据缓存和调度缓冲。借鉴这个思路算力调度不应该只看某一个集群的资源而应该站在“算力网络”的高度做全局规划。哪些任务适合在西部绿电富集地区跑哪些任务必须放在数据中心密集地区做低延迟推理可以通过数据缓存和任务迁移实现整体最优。这种“算力跟着能源走”的思路行业里讨论很多但真正落地的不多主要是跨域协同的机制还不成熟。7.2 通信网络的分层容灾经验电信网络在容灾架构上有一套非常成熟的方法论核心层、汇聚层、接入层各司其职设备级、板卡级、链路级、路由级都有冗余保护故障自动倒换时间可以做到毫秒级。算力基础设施在这方面还有明显的差距。很多GPU集群的网络架构是按性能最优设计的追求的是最大带宽和最低延迟但在容灾和故障隔离方面考虑不足。一旦发生故障影响面很容易扩散到整个集群。建议可以参考通信网络的思路在网络架构上预留流媒体通道在关键链路上启用保护切换机制在集群层面做故障域的物理隔离。这么做会牺牲一点点极限性能但换来的稳定性和运维效率是值得的。7.3 超算中心的运维制度沉淀国内超算中心在算力运维上的经验比普通的商业数据中心丰富得多。超算中心长期运行大规模并行计算任务对系统稳定性、队列调度、用户管理、故障处理都有非常细致的规范和制度。很多玩过超算的老师傅都知道超算中心的作业调度系统比如Slurm、PBS有一套非常严格的排队策略、账户配额、任务优先级机制。这些机制在大规模GPU集群上同样适用而且应该更进一步把配额管理、成本核算、作业回填都纳入平台能力。商业算力平台如果直接照搬互联网公司的容器调度思路很容易在任务多样性和稳定性上翻车。8. 现实中的几个“坑”与应对思路理论知识讲了一堆最后说说实际操作中我们踩过的一些坑希望能帮准备做算力基础设施的团队少走点弯路。8.1 液冷系统漏液检测与部署教训第一次部署液冷集群的时候我们对漏液风险的认识严重不足只按厂商建议在机柜底部放了几个漏水报警器结果巡检时发现一个快接头处有轻微渗液由于位置隐蔽传感器没能第一时间捕捉到。后来我们改变了部署策略所有液冷管路接头统一加装防水托盘和独立传感线机柜内部署高灵敏度光电传感线配合监控平台远程实时查看。同时规定液冷系统每两周必须做一次电导率检测和管路外观巡检虽然运维成本略增但换来的是安心。8.2 电力容量核算中的一个隐蔽陷阱前文提到批量GPU服务器启动时的冲击电流问题这里再展开说一个更隐蔽的坑GPU服务器不仅启动电流大还容易出现负载大幅波动。AI训练任务的功耗并不是平稳的每个step的峰值功耗和空闲功耗差距很大某些场景的峰值可能是平均功耗的两倍。如果按平均功耗去核算总负载能力市电线路的容量可能没问题但变压器和UPS在瞬时峰值叠加时就会过载。我们的做法是在机柜入口侧部署智能PDU实时采集每台服务器的功耗曲线积累一段时间的数据后再调整配电容量分配和限额策略。这个数据驱动的思路比单纯靠计算器估算靠谱得多。8.3 网络拥塞排查的一个真实案例有一次训练集群性能突然下降监控面板上看GPU利用率不到30%网络吞吐也远低于预期。排查链路、端口、光模块全部正常最后追到问题出在一台交换机上——它的PFC暂停帧计数异常高说明有持续的PFC风暴发生。进一步排查发现原因是集群里有几台机器在做大量的多播通信把某个队列的缓存打满了触发了上游交换机持续发送暂停帧。解决方式包括开启RED/WRED拥塞避免、在流量大的队列上提高缓冲比例、对多播流量做动态限速。这个案例让我意识到RoCE无损网络的运维门槛确实很高团队里必须有人真正理解拥塞控制的底层原理否则出了问题只能干瞪眼。最后一点体会算力基础设施的挑战本质上是算力从“通用计算”向“智能计算”迁移引发的连锁反应。电力、散热、网络、调度、运维每一个环节都因为GPU集群的特性被重新定义。做这个领域的项目最重要的不是迷信某一项新技术而是要有全局视角——从电力引入到芯片选型从网络架构到调度平台把每一环都当成一个整体去设计和运营。实际操作中踩过的坑多了才会越来越意识到算力基础设施的“基础”两个字分量有多重。