2024年我参与梳理过好几份智算中心相关方案也跟同行交换过不少关于“国内超大型智能算力中心建设白皮书 2024”的讨论。严格来说市面上流传的各种版本更多是站在厂商视角讲自身产品和路线的优势真正从甲方、建设方、运营方角度讲清楚“怎么把一个超大型智能算力中心从0到1建起来”的公开内容依然很少。这一篇我就试着把这类项目的核心脉络、关键技术决策和容易踩的坑梳理一下当作一份经验笔记。如果你也在做智能算力中心的前期规划、中期建设或后期运营应该会有不少共鸣。这个领域最大的特点是看起来是在做数据中心实质上是在做一台以GPU/NPU为核心、横跨电力、暖通、网络、存储、调度平台和算法框架的超大计算机。任何一个环节掉链子最终都会变成算力利用率的损失而算力利用率就是钱。1. 智能算力中心到底是什么为什么绕不开1.1 传统数据中心和智能算力中心的本质区别很多人以为智能算力中心就是“把CPU换成GPU”实际远没那么简单。传统数据中心的核心指标是虚拟机密度、网络带宽、存储IOPS、可用性等级负载模型是大量小型业务互相错峰对单点算力要求不高机柜功率密度也低通常6到10千瓦就算不错了。智能算力中心的负载模型完全不一样。一个大模型训练任务动辄占满几千张加速卡任务内部存在大量的集合通信也就是GPU和GPU之间随时在交换梯度数据。这种负载对三件事极其敏感芯片之间互联带宽、网络延迟、存储读取带宽。与此同时单机柜功耗从10千瓦直接跳到30到50千瓦甚至更高传统风冷方案根本压不住散热。我见过不少项目前期规划时还是按老数据中心的思路做机柜功率按8千瓦预留、网络按25G/100G规划、空调用精密空调。结果设备一进场就傻眼供电不够、制冷不够、网络端口不够只能边施工边改造进度和成本全线失控。所以做智能算力中心第一件事就是把“传统思维”丢掉。1.2 “超大型”的规模到底怎么量“超大型”听起来很虚但放到具体参数上是可以量化的。以目前比较常见的万卡集群为例一万张AI加速卡按单台8卡服务器计算大约需要1250台AI服务器加上管理节点、存储节点、网络设备总体机柜数量在200到300个之间机房面积通常上万平米IT负载10兆瓦以上整体投资几十亿元级别。为什么大家最近都在聊“万卡”因为训练当前主流的大语言模型万卡几乎是入门门槛。简单估算一下假设要训练一个7000亿参数模型训练数据量5万亿token按大模型训练的理论计算量公式总算力需求大约在2×10^25 FLOPs这个量级。一万张主流加速卡峰值算力约10^19 FLOP/s就算训练效率做到35%也得连续跑差不多两个月。想在更短时间内完成或者模型规模再往上走就得往几万卡的方向堆。所以规划智能算力中心时第一个问题不是“我要建多大”而是“我要在多长时间内训练出多大的模型”。这个问题的答案直接决定加速卡数量、网络架构、存储容量和电力指标后边所有设计都是从这个数字倒推出来的。2. 总体架构与关键技术选型2.1 分层架构一览智能算力中心可以分成五个层次计算层、网络层、存储层、平台层和基础设施层。这五层不是简单堆叠而是协同关系。我习惯用一个表格把每层的核心组件和关键指标列清楚项目组对齐需求时非常有用。层级核心组件关键指标2024年主流趋势计算层AI服务器、加速卡总算力、单卡显存、卡间互联8卡服务器为主显存向80GB以上演进网络层数据中心交换机、RDMA网卡端口速率、收敛比、时延400G逐步普及800G开始试点存储层并行文件系统、对象存储、NVMe缓存聚合带宽、IOPS、容量单集群带宽TB/s级容量5到20PB起步平台层调度系统、镜像仓库、监控告警调度效率、GPU利用率、故障恢复时间Kubernetes批量调度器逐步成为主流基础设施层供配电、制冷、机柜、综合布线PUE、可用性、冗余等级液冷渗透率快速提升HVDC更受关注这张表最大的价值是让所有人看到智能算力中心不只是一堆GPU网络和存储往往是性能瓶颈所在。很多项目把绝大部分预算砸在加速卡上结果网络收敛比做得太差、存储带宽不够训练时GPU有一半时间在等数据算力利用率上不去那才是最亏的。2.2 计算层服务器形态与加速卡选型计算层的核心是AI服务器。2024年主流形态还是8卡服务器也就是一台2U或4U机器里插8张加速卡卡之间通过高速互联组成一个高带宽域域内通信带宽远高于跨服务器网络。这个设计很关键因为大模型训练有多种并行策略张量并行要求卡间通信极其频繁甚至每几次计算就要同步一次如果卡间走外部网络性能会断崖式下降。加速卡选型上要区分训练、推理和科学计算三种场景。训练场景看重峰值算力、显存容量、卡间互联带宽和软件生态成熟度推理场景更看重单卡吞吐、批量处理能力和功耗科学计算则看重双精度算力和大规模并行能力。很多智算中心规划时想“一块卡全搞定”实际很难因为三者的需求模型差异很大。更务实的做法是先明确主要负载类型再决定配置比例。举个例子如果一个项目主要做大模型训练单卡显存就应该优先考虑80GB以上的型号不然哪怕算力够显存放不下模型参数和中间激活值也得做更重度的并行切分通信开销会吃掉大量性能。如果主要是推理场景那可以选显存稍小但推理吞吐更高、单位功耗更优的型号没必要为用不上的训练特性买单。2.3 网络层从百G到400G收敛比是灵魂网络层是超大型智能算力中心最容易被低估、也最影响训练效率的部分。大模型训练普遍采用数据并行、张量并行、流水线并行的组合每隔很短时间就要做一次全集群梯度同步。这种通信模式的特点是瞬时流量极大、对时延极度敏感网络一旦拥塞训练速度就会被最慢的那条链路拖住。2024年主流的组网方案还是两层或三层CLOS架构服务器接入层用200G或400G核心层用400G规模再大的项目开始试点800G。这里有一个核心概念必须搞清楚收敛比。收敛比指接入带宽与核心带宽的比例1:1代表任何时刻所有服务器同时发送数据都不会拥塞这对分布式训练是最理想的。很多传统数据中心为了省钱收敛比做到1:3甚至1:4日常业务无感但跑大模型训练时性能影响非常明显。我强烈建议训练为主的智能算力中心核心网络至少按1:1收敛比设计。预算实在紧张可以把部分用于推理和一般业务的区域收敛比放宽但训练区不要省。网络这部分还有另一个争议点InfiniBand还是RoCE。InfiniBand性能好、生态成熟、运维工具完善但成本高、相对封闭RoCE v2跑在传统以太网上成本低、兼容性好但对无损网络配置要求高PFC和ECN参数调不好容易出现流量风暴。2024年的趋势是RoCE占比越来越高但前提是运维团队懂得怎么调无损网络参数。2.4 存储层并行文件系统与缓存设计存储层在智算中心里经常被忽视但实际影响非常大。模型训练过程中GPU需要持续读取训练数据、周期性写入检查点文件如果存储带宽不够GPU就只能空转等待。我见过一个项目GPU利用率一直在20%以下查了半天发现是数据读取路径上有个对象存储网关成了瓶颈换掉之后利用率直接翻倍。合理的存储架构通常分三层。第一层是高带宽并行文件系统常见的有Lustre、GPFS以及一些国产高性能并行存储产品用来承载训练数据集和检查点要求聚合带宽高。第二层是对象存储容量大、成本低用来做数据长期归档和冷备份。第三层是计算节点本地NVMe盘主要做缓存把热数据提前缓存到本地减少对远端存储的压力。带宽预留方面我习惯按“每张加速卡至少1GB/s聚合读带宽”做初期预估一万卡集群就是10TB/s级别。这个值听起来很夸张实际还有很大冗余空间但至少能保证数据加载不拖后腿。存储容量则要看训练数据量和检查点频率一般按总数据量的5到10倍预留一个万卡集群规划5到20PB并行文件系统容量并不夸张。3. 基础设施电力、制冷与PUE3.1 供配电HVDC还是UPS电力是智能算力中心的“命根子”。一个10兆瓦IT负载的项目加上制冷和辅助设备总用电负荷在12到15兆瓦之间相当于一个小型工业园区的用电量。供配电系统设计直接决定可用性和运营成本。传统数据中心普遍使用UPS也就是不间断电源负责在市电异常时维持供电。UPS技术成熟、可靠性高但存在两次交直流转换效率通常在90%到95%之间。2024年越来越多的智算中心开始采用HVDC高压直流方案特别是240V或336V直流供电省掉逆变环节整体效率能提升3到5个百分点。别小看这几个点对于一年电费几千万的项目3%就是上百万。冗余设计方面训练任务最怕意外掉电一次掉电可能导致几千张卡的计算任务全部中断重新加载检查点又得浪费几个小时。所以至少要做到两路市电引入加上柴油发电机后备核心IT设备供电采用2N冗余。如果预算允许关键网络设备最好再加一路独立电池组保证极端情况下网络不中断避免出现“算力还在、网络断了”的尴尬局面。3.2 从风冷到液冷不是赶时髦是功耗逼的关于散热我先说一个现实主流AI加速卡的功耗已经普遍到300到400瓦一台8卡服务器整机功耗6到8千瓦高密度机柜塞满设备后单柜功耗很容易突破30千瓦传统风冷精密空调在这种热密度下完全扛不住。风冷能做到的极限大概在单柜20到25千瓦再往上要么机柜里的设备降频要么机房局部过热最终受害的还是算力利用率。2024年落地最多的方案是冷板式液冷。原理很简单用冷却液通过金属冷板直接带走CPU、GPU芯片的热量相比空气换热效率高得多。冷板式液冷对现有基础设施改动较小单柜功率可以做到50到80千瓦是风冷的几倍。浸没式液冷散热能力更强但服务器要整体泡在冷却液里设备维护和改造成本高目前更多用在少数高功耗密度场景还没有大规模铺开。做液冷项目要注意几个细节一是二次侧水温要控制在露点以上避免管道凝露二是漏液检测必须部署到位一旦接头老化或密封圈失效漏液轻则损坏单台设备重则造成整排机柜断电三是液冷系统要有备份泵和冗余路径维护时不能影响在线设备。这些细节看似不起眼实际运行中都是大事。3.3 PUE与能耗实例一个万卡集群一年烧多少电PUE是衡量数据中心能效的核心指标等于总用电量除以IT设备用电量越接近1越好。2024年国内新建智能算力中心的PUE目标普遍要求在1.2以下采用液冷加高压直流方案的优秀项目可以做到1.1左右。用数字直观感受一下假设一个万卡集群IT负载10兆瓦PUE 1.2那么总功耗就是12兆瓦一年8760小时总耗电约1.05亿度电。按工业电价每度0.5元算一年电费超过5000万元。如果PUE能再降到1.1总功耗降到11兆瓦一年少用876万度电节省约400万元电费。这就是为什么大型智算中心都在抠能效省下来的每一度电都是直接利润。当然PUE不是越低越好。为了把PUE从1.15压到1.05可能需要投入大量额外成本比如更贵的液冷系统、更复杂的余热回收装置。最佳策略是找到一个性价比平衡点而不是盲目追求指标数字。我见过有项目为了让参观时PUE好看刻意关掉一部分不使用的辅助设备这种做法既欺骗自己也不利于长期运营。4. 从规划到交付关键实施路径4.1 规划与设计阶段把需求吃透再动手项目启动阶段最忌讳的就是边界模糊。很多智算中心项目在规划时只写了“建设XX PFLOPS算力平台”但没写清楚这个平台主要跑什么负载、服务哪些客户、可用性要求多高、未来三五年怎么扩容。这些没想清楚后面所有设计都是拍脑袋。规划阶段需要输出几个核心文件算力规模测算报告、网络架构设计、存储容量规划、供配电和制冷方案、运维组织架构。每个文件都要可追溯。比如算力规模不应该是领导拍一个数字而要从“多少个并发训练任务、每个任务多少卡、预计训练时长”推导出来。基础设施部分同样要量化机柜功率密度定多少、PUE目标多少、冗余等级多少都要有依据。选址也是这个阶段要解决的问题。超大型智能算力中心对电力供应、网络条件、气候环境、水资源、土地成本都有很高要求。电力是最关键的要确认当地能不能提供足够的变电站容量和双回路供电条件网络要靠近骨干节点避免长距离光纤引入额外时延气候偏凉的地方天然有利于降低制冷能耗。这些因素不在一开始锁定后面改起来代价极大。4.2 建设与安装设备进场只是开始土建和机电安装阶段最重要的管理动作是“关键路径识别”。设备采购可能周期很长尤其是AI加速卡和高端网络设备货期经常以月为单位电力外线施工要协调供电部门液冷管路安装要配合土建预埋。这些环节相互依赖任何一个delay都会波及其他工序。我建议项目组每周开一次关键路径对齐会把到货计划、施工计划和调试计划放在一起看不要各管各的。设备安装阶段有几个容易踩的坑。一是服务器上架前一定要核对机柜承重和电源接口类型AI服务器普遍比传统服务器重单个机柜如果计划放10台8卡服务器承重很容易超过普通楼板设计值。二是光纤布线和铜缆布线要分开AI集群的光纤数量非常惊人动辄几千根不做颜色标识和端口标签后期维护就是灾难。三是液冷管路安装完成后要做压力测试和漏液测试管路冲洗不到位杂质进入冷板会堵塞流道造成局部过热。硬件安装完不等于能用还有大量软件层面的工作操作系统镜像制作、GPU驱动安装、容器运行时配置、高性能网络驱动和协议栈调优以及分布式训练框架部署。这个阶段最头疼的是版本兼容问题驱动、CUDA、PyTorch、通信库各有一个版本要求组合起来可能好几套环境要共存没有一套成熟的镜像管理和环境隔离方案后面运维会非常痛苦。4.3 网络联调与压测怎么判断“能跑大模型”联调阶段的目标只有一个证明这套系统真的能高效跑起分布式训练。验收不能只看设备都通电了、GPU都能识别了要照顾到实际训练场景。我一般把联调分为四个层级。第一层单机内多卡通信测试确保8张卡之间的互联带宽和延迟正常。第二层跨节点网络测试选几个代表节点跑RDMA通信测试验证网络配置和路由状态。第三层存储压力测试并行文件系统要在大并发读写下仍然稳定不出现带宽剧烈波动。第四层真实训练任务试跑用一个小规模的模型从1个节点扩展到10个、再扩展到全集群观察加速比和训练吞吐。# 一个简单的跨节点通信测试示例 # 节点1 torchrun --nnodes2 --nproc-per-node8 \ --rdzv-endpoint10.0.0.1:29500 --rdzv-backendc10d \ --master_addr10.0.0.1 \ all_reduce_test.py压测阶段还要专门做故障演练。比如随机拔掉一台服务器电源看调度系统能不能及时重新拉起任务手动断开一条核心链路看网络收敛时间是多少用工具模拟一台存储节点故障确认数据读取不受影响。很多团队忽略故障演练等到真出问题才发现监控告警没配好、系统无法自愈那才叫被动。试运行期间要关注几个核心指标算力利用率MFU、训练吞吐、故障卡数量、网络丢包率、存储带宽稳定性。如果MFU能达到30%以上考虑到真实的通信开销和IO等待这个集群的调优就算及格如果长期低于20%一定存在某个环节拖后腿必须复盘。5. 运营中的常见坑与经验5.1 算力平台日常运维智能算力中心的运维和传统数据中心最大区别在于用户任务的生命周期很长一个训练任务可能跑几个星期中间一旦被中断可能前功尽弃。平台侧必须提供任务优先级管理、检查点自动保存、故障自动迁移这些能力而不能只是简单分配几块GPU。调度系统选型上2024年主流方向是Kubernetes加批量调度器比如Volcano、Kueue再配合GPU虚拟化和显存调度实现更细粒度的资源分配。传统Slurm在排队策略上更成熟适合比较单一的批处理场景但统一管理在线推理和离线训练时K8s生态明显更有优势。很多智算中心会同时部署两套系统中间做一层隔离但调度策略要统一规划避免出现资源碎片化。日常运维重点在监控和告警。GPU卡温度、显存ECC错误、网络丢包率、存储延迟、机房温湿度、液冷系统压力这些指标都要实时采集并设置合理阈值。这里我特别想提醒告警阈值不要设得太敏感否则每天几千条告警运维人员会麻木真正的大故障反而被淹没。我建议把告警分成几个等级只有影响业务的关键指标才走即时通知其他汇总成日报周报人工分析。5.2 训练效率突然变差先查这些运营过程中最痛苦的问题是“任务还在跑但速度变慢了”而且很多情况下没有报错。这种隐形性能劣化非常难排查我整理了一份常见问题速查表基本能覆盖大部分情况。现象可能原因排查手段处理思路训练速度间歇性下降网络拥塞或哈希冲突查看交换机端口丢包计数、RDMA重传统计调整流哈希策略优化ECN和PFC参数某节点训练明显慢单个GPU降频或链路故障查看GPU温度和频率跑通信测试定位更换设备或调整物理链路数据读取频繁阻塞并行文件系统性能不足监控存储带宽和IO延迟增加缓存优化数据预处理流水线任务运行中偶发中断供电波动或设备过热查看机房告警历史检查UPS和空调状态优化负载分布显存不断增长直到OOM训练脚本内存泄漏/碎片化观察显存轨迹和模型配置开启显存碎片整理或调整batch size这些问题的共性特征是“没有明显错误但业务受损”。要快速定位必须有完善的性能基线数据。我强烈建议从项目上线第一天起就把全集群跑标准测试的数据留存下来比如NCCL AllReduce带宽、代表性训练模型的吞吐作为后续排查的参照物。没有基线劣化就无从谈起。5.3 关于国产算力生态的一点心得2024年还绕不开一个话题国产AI加速卡和生态适配。实事求是讲国产加速卡在单卡算力、互联带宽、软件栈成熟度上和国外头部产品仍有一定差距但这个差距正在快速缩小。很多智算中心项目已经明确要求支持多种加速卡混合部署这不仅是供应链安全考量也是实际业务需要。国产芯片落地最大的瓶颈不在硬件而在软件生态。训练框架对加速卡的适配、通信库的优化、常见模型的迁移成本都需要投入大量研发资源。我建议做混合算力平台时优先保证核心模型能在不同加速卡上跑同一个任务哪怕先牺牲一部分性能也要保证可切换能力。算力中心的长期价值不在某一张卡上而在整个平台的调度和适配能力。另外团队配置上一定要有懂网络和懂存储的专业人员不能全是算法工程师。算法工程师能调模型参数但看到“训练速度慢”时很难判断是拥塞还是存储瓶颈。一个智算中心想稳定运行网络工程师、存储工程师、平台开发工程师、算法工程师四类人缺一不可。最后再分享一个小技巧建设超大型智能算力中心前期的规划文档再厚最后执行时拼的其实是无数个细节的落地。我在几个项目里最大的体会是一定要让基础设施工程师尽早介入到算力平台设计中而不是等机房盖好了再来“适配”。电源、散热、网络、存储和调度每个环节都要有人从全局视角盯着否则很容易出现“每个专业自己看都没问题合在一起就出问题”的局面。希望这篇从实战角度梳理的内容能给正在规划或建设智能算力中心的朋友一些参考。
