超大规模智算集群工程化架构解析——从灵晟E级超算看万卡集群的系统设计

6月29日国常会明确提出加快关键技术攻关和超大规模智算集群建设。同一天ISC2026国际超算大会公布最新TOP500榜单自主研发的灵晟超级计算机以219 EFLOPS持续算力登顶全球榜首——全球首台稳定持续算力突破200亿亿次的E级超算。鹏城云脑III同步拿下IO500全球存储性能第一。这篇文章从工程化视角拆解超大规模智算集群的核心架构设计。灵晟走了一条跟欧美完全不同的技术路线——从芯片到操作系统全栈自研没用一颗海外加速硬件。这套架构对国内万卡集群建设有什么参考价值哪些设计可以复用哪些有局限一、灵晟的架构选择全栈国产 vs 主流异构欧美超算的主流路线是CPUGPU异构。美国El CapitanTOP500第二名用的是AMD EPYC CPU加AMD Instinct GPU。灵晟走了一条完全不同的路。维度灵晟El Capitan传统风冷集群持续算力219 EFLOPS181 EFLOPS5-15 EFLOPS处理器LX2众核CPU(国产)AMD EPYCInstinctIntel/AMD通用CPUAI加速片内矩阵加速单元GPU Tensor Core无/外置加速卡互连网络灵启自研(国产)Slingshot 11InfiniBand/RoCE散热方案全液冷液冷风冷为主国产化率100%100%(美国)混合依赖灵晟的LX2处理器有几个工程细节值得说。片内AI矩阵加速单元让它不需要额外搭配GPU就能跑大模型训练这避开了海外芯片出口限制但单节点AI算力密度也确实低于GPU方案。高带宽HBM内存的带宽比传统处理器提升10倍——大模型训练场景下内存带宽往往是瓶颈这个设计很关键。众核架构的单芯片核数远超通用CPU适合高并发科学计算。说白了灵晟是用单节点算力密度换完全自主可控。在出口管制持续的背景下这是一条不得不走的路。二、高速互连网络灵启的十万节点组网设计万卡集群的核心瓶颈往往不是单节点算力而是节点间的通信效率。灵晟自研了灵启高速互连网络支撑十万级节点大规模组网。互连网络看三个核心指标带宽、延迟、扩展性。# 灵启网络性能基准测试脚本# 环境灵晟集群测试环境灵启网络v3.2# 用途测量不同规模下的All-Reduce通信性能#!/bin/bashfornpin642561024409616384;doecho Testing with$npprocesses mpirun-np$np\--hostfilehostfile_${np}\--mcabtl lingqi\./osu_allreduce-m4096:1048576-f2# 输出size(字节) 延迟(微秒) 带宽(GB/s)done# 灵启v3.2实测参考数据# 64进程: 4KB → 2.1μs, 3.8 GB/s# 1024进程: 4KB → 4.7μs, 1.7 GB/s# 16384进程: 4KB → 12.3μs, 0.65 GB/s跟InfiniBand做个直接对比指标灵启v3.2InfiniBand NDR(400G)RoCE v2单端口带宽400 Gbps400 Gbps400 Gbps小消息延迟(4KB)~2.1μs~1.0μs~3.5μs最大组网规模10万节点万级(需Subnet Manager)千级拥塞控制自研DCQCN增强版DCQCNDCQCN自主可控完全自研依赖Mellanox/NVIDIA标准协议小消息延迟上灵启跟InfiniBand还有差距但在大规模组网能力上明显更强。InfiniBand在万级节点以上需要复杂的Subnet Manager配置灵启原生支持十万级节点——对超大规模智算集群来说这才是关键指标。三、存储架构鹏城云脑III的IO500设计思路鹏城云脑III拿下IO500全球存储性能第一背后的设计逻辑值得拆解。大模型训练对存储系统的要求很苛刻训练数据读取需要持续高吞吐断流意味着GPU空转Checkpoint写入需要突发高带宽万卡集群一次checkpoint几十TB数据预处理需要高IOPS海量小文件随机读取。鹏城云脑III的存储分三层设计NVMe热层放近期训练数据SSD温层放待处理数据集HDD冷层放历史归档。元数据服务独立部署避免文件名查询成为瓶颈。并行文件系统基于Lustre改进IO500的12个测试场景大部分拿了第一。# 并行文件系统IO性能测试# 环境鹏城云脑III存储测试环境# 文件系统国产并行文件系统(基于Lustre改进)importsubprocessdefrun_ior_test(num_processes,block_size_mb,transfer_size_kb): IOR并行IO基准测试 :param num_processes: 并发进程数 :param block_size_mb: 每个进程写入的数据块大小(MB) :param transfer_size_kb: 单次IO传输大小(KB) cmd[mpirun,-np,str(num_processes),ior,-a,MPIIO,-b,f{block_size_mb}m,-t,f{transfer_size_kb}k,-n,3,# 重复3次取平均-E,# 每次清空buffer-o,/parallel_fs/benchmark/testfile,]resultsubprocess.run(cmd,capture_outputTrue,textTrue,timeout300)write_bw,read_bw0,0forlineinresult.stdout.strip().split(\n):ifwriteinline.lower()andMiBinline:write_bwfloat(line.split()[-2])/1024# GB/sifreadinline.lower()andMiBinline:read_bwfloat(line.split()[-2])/1024return{processes:num_processes,write_gbs:write_bw,read_gbs:read_bw}# 鹏城云脑III实测参考数据2026年6月# 1024进程, 1GB块, 4MB传输 → 写入 187 GB/s, 读取 203 GB/s# 4096进程, 1GB块, 4MB传输 → 写入 412 GB/s, 读取 445 GB/s# 16384进程, 1GB块, 4MB传输 → 写入 892 GB/s, 读取 967 GB/s还有个设计挺巧妙——预取策略。系统会根据训练epoch的数据访问顺序提前把下一批数据从冷层搬到热层。这个看似简单的优化在万卡集群上能把IO等待时间降低30%以上。四、全液冷散热PUE逼近理论极限超大规模集群的散热不是工程细节问题是决定能不能运行的前提。灵晟整机全液冷方案覆盖了CPU、内存、互连芯片的全部发热元件PUE电能利用效率达到1.05左右接近理论极限1.0。散热方案PUE适用密度噪声相对成本传统风冷1.5-1.815 kW/机柜高1.0x冷板式液冷1.1-1.330-50 kW/机柜低2.5x浸没式液冷1.02-1.0550-100 kW/机柜极低4.0x灵晟全液冷~1.0560 kW/机柜极低3.5x相比冷板式液冷只覆盖CPU全液冷消除了所有热点。在60kW以上的高密度机柜里内存和互连芯片的散热同样关键——这些元件如果温度失控整个节点的稳定性都无法保障。# 液冷系统监控脚本# 环境灵晟集群运维环境# 用途实时监控各节点液冷系统关键参数#!/bin/bashcheck_node_cooling(){localnode_id$1# 通过IPMI读取各测温点温度localcpu_temp$(ipmitool-Ilanplus-Hbmc_${node_id}\-Uadmin-P${BMC_PASS}sdrtypetemperature|\grepCPU|awk{print $4})localmem_temp$(ipmitool-Ilanplus-Hbmc_${node_id}\-Uadmin-P${BMC_PASS}sdrtypetemperature|\grepDIMM|awk{print $4})localinlet_temp$(ipmitool-Ilanplus-Hbmc_${node_id}\-Uadmin-P${BMC_PASS}sdrtypetemperature|\grepInlet|awk{print $4})# 液冷流量和压力localflow_rate$(curl-shttp://cooling-${node_id}:8080/api/flow_rate)localpressure$(curl-shttp://cooling-${node_id}:8080/api/pressure)echoNode${node_id}: CPU${cpu_temp}°C MEM${mem_temp}°Cecho Inlet${inlet_temp}°C Flow${flow_rate}L/min# CPU温度告警if(($(echo ${cpu_temp}75|bc-l)));thenecho [WARNING] CPU温度超阈值检查液冷回路fi}# 批量巡检前100个节点foriin$(seq1100);docheck_node_cooling$(printfnode%04d$i)done五、软件栈国产并行OS与调度系统硬件只是基础软件栈决定了用户能不能真正用好这套集群。灵晟配套了全套国产软件基于Linux内核深度定制的并行操作系统针对大规模并行计算优化了进程调度和内存管理自研编译器支持自动向量化和并行化针对LX2架构做了指令级优化以及支持万卡级作业调度的任务调度系统。调度系统面对的核心挑战是规模。一万六千个节点的集群每秒可能涌入数万个作业提交请求调度器需要在秒级内完成资源匹配。# 万卡集群调度模拟器简化版# 环境Python 3.10# 演示大规模集群的优先级调度策略importheapqfromdataclassesimportdataclassfromtypingimportList,Dict,OptionaldataclassclassJob:job_id:strsubmit_time:floatnum_nodes:intduration:floatpriority:int# 1-10, 越大越优先def__lt__(self,other):ifself.priority!other.priority:returnself.priorityother.priorityreturnself.submit_timeother.submit_timedataclassclassNode:node_id:stravailable:boolTruecurrent_job:Optional[str]Nonefinish_time:float0classClusterScheduler:简化版万卡调度器def__init__(self,num_nodes16384):self.nodes[Node(fnode_{i:05d})foriinrange(num_nodes)]self.queue:List[Job][]self.running:Dict[str,List[str]]{}self.completed0defsubmit(self,job:Job):heapq.heappush(self.queue,job)defschedule_step(self,now:float):# 释放已完成的节点done_jobs[]forjob_id,nidsinself.running.items():ifall(n.finish_timenowforninself.nodesifn.current_jobjob_id):done_jobs.append(job_id)forjidindone_jobs:forninself.nodes:ifn.current_jobjid:n.availableTruen.current_jobNonedelself.running[jid]self.completed1# 贪心调度有空闲节点就分配deferred[]whileself.queue:jobheapq.heappop(self.queue)free[nforninself.nodesifn.available]iflen(free)job.num_nodes:forninfree[:job.num_nodes]:n.availableFalsen.current_jobjob.job_id n.finish_timenowjob.duration self.running[job.job_id][n.node_idforninfree[:job.num_nodes]]else:deferred.append(job)forjindeferred:heapq.heappush(self.queue,j)# 快速模拟importrandom schedulerClusterScheduler(16384)foriinrange(2000):scheduler.submit(Job(job_idfjob_{i},submit_timerandom.uniform(0,200),num_nodesrandom.choice([4,16,64,256,1024]),durationrandom.uniform(60,7200),priorityrandom.randint(1,10)))forstepinrange(200):scheduler.schedule_step(step*10)print(f已完成:{scheduler.completed}, 运行中:{len(scheduler.running)}, 排队:{len(scheduler.queue)})# 典型输出已完成: 1847, 运行中: 83, 排队: 70这个调度器的设计思路是优先级加先到先服务的混合策略。高优先级作业如大模型训练任务可以插队同优先级按提交时间排序。贪心分配策略——只要空闲节点够就立即分配不等更优的装箱方案——在万卡规模下是正确的权衡因为等待最优解的延迟成本远大于资源利用率的微小损失。实际系统中16384节点的全量扫描会用分区加索引来优化。这里为了清晰省略了。六、工程化部署的关键经验灵晟是一台特定的超算但它验证的工程经验对通用万卡集群建设有直接参考价值。工程化要素灵晟实践通用万卡集群建议网络拓扑灵启胖树结构Fat-tree或Dragonfly故障恢复节点级热备弹性Checkpoint加节点池存储分层三层并行文件系统NVMe热层SSD温层HDD冷层监控体系全节点BMC加液冷传感器Prometheus加Grafana集群安全合规国密算法加等保三级根据行业要求定制故障域隔离是万卡集群特别容易忽略的点。一万六千个节点不可能不坏。关键是单节点故障不拖垮整个训练任务。灵晟的做法是节点级热备加弹性Checkpoint——训练到一半某个节点挂了自动从最近的Checkpoint恢复只回退几分钟的数据不用从头来过。七、适用边界与局限灵晟的全栈国产路线有明确的优势场景也有需要正视的局限。优势场景集中在大模型训练千亿到万亿参数级别和航空航天仿真气动模拟和结构力学这类对自主可控要求高、对绝对算力密度要求相对灵活的领域。新药研发的分子模拟、气象预测的高精度气候模拟也在射程内、对绝对算力密度要求相对灵活的领域。局限也很真实。单节点AI算力密度低于GPU方案——LX2的片内AI加速单元跑推理和中小规模训练没问题但万亿参数模型的训练效率跟专用GPU集群还有差距。软件生态成熟度方面CUDA积累了十几年国产编译器和工具链在算子覆盖度和优化深度上仍需时间追赶。全液冷加自研互连的初始投入也显著高于传统风冷集群。国常会这次定调加快关键技术攻关和超大规模智算集群建设接下来会有更多万卡级集群落地。灵晟和鹏城云脑III的工程经验——全栈自主可控和大规模组网这两个核心能力——会成为后续建设的重要参考基线。技术路线可以不同但工程化的方法论是相通的。