计算集群走出国家实验室，加速AI规模化扩张

核心要点：

集群由跨多个机架的互联服务器（即节点）组成，通过以太网连接，光链路的应用也在持续增加，适用于计算需求极大、单机架服务器无法完成的超大规模工作负载。

设计挑战涵盖网络拥塞、延迟与掉队节点、电力供应、散热限制、软件调度、性能与可扩展性，以及能耗管理等多个维度。

集群已在国家实验室中用于全球天气模拟等场景，而AI的大规模普及正推动这一技术向制造业、药物研发、金融风险建模、EDA（电子设计自动化）、自动驾驶等更多领域延伸。

圆桌专家阵容：Semiconductor Engineering近日召集多位业界专家，围绕计算集群的定义、设计挑战与应用场景展开深度探讨。参与者包括：Arm全球云与AI基础设施芯片负责人Satadal Bhattacharjee、Axiomise首席执行官Ashish Darbari、Cadence杰出工程师Moshiko Emmer、Expedera首席科学家Sharad Chole、Siemens EDA高性能计算开发负责人Cameron Brunner，以及Synopsys战略营销总监Sumit Vishwakarma。以下为对话摘录。

计算集群的定义与架构师须知

Bhattacharjee：谈到计算集群，通常是指跨多个机架的互联服务器组，目前主要通过以太网连接，光互联也在逐步引入。其核心逻辑在于：所承载的工作负载规模庞大、计算需求极高，单台服务器或单个机架根本无法胜任，因此需要将多台服务器整合在一起。多个集群进一步组合，便形成所谓的"Pod"。计算集群的关键在于低延迟——当工作负载跨机架传输时，网络延迟不能急剧攀升，这一点至关重要。数据在服务器间、机架间流转时，需要大量优化措施来维持性能效率。

从芯片架构师的视角来看，思考维度必须从单台服务器扩展到整个集群，确保更快组件带来的效率提升不会因机架间通信的网络瓶颈而白白消耗。架构师需要统筹考虑网络拥塞、电力供给、散热上限、软件调度等方方面面。

Brunner：从软件管理的角度出发——我长期负责管理多个工作负载管理器，在大规模环境下执行EDA工作负载——计算集群本质上是一批机器的集合，这些机器以特定方式互联，共同满足某个站点运营者的特定需求。这个需求方可能是希望快速设计迭代的芯片设计团队，也可能是运行大规模并行仿真的生命科学、制造业或CAE（计算机辅助工程）企业。

正如Satadal所说，高速互联在大规模MPI（消息传递接口）作业中极为关键。集群的规模可以远超任何单台机器，能够承载超大工作负载，或同时处理海量小任务。在EDA领域，芯片设计流程中往往涉及数十万乃至数百万个任务，单台机器根本无法应对。计算集群的价值，正是将网络、存储与算力整合为一套并行的大规模资源，再辅以软件层的高效调度，实现硬件资源的最优利用。因此，计算集群是一个完整生态——硬件与软件协同构建，共同服务于运营方的业务需求。

Vishwakarma：工作负载的形态正在深刻改变集群的设计逻辑。人类大脑的进化历程，与AI大脑的演进轨迹高度相似——从最初只能完成简单任务，到如今承担越来越复杂的工作，而人脑的功耗始终维持在约20瓦。对比2018年前后的AI能力，再看今天，差距已是天壤之别。如今，仅凭一段文字提示，就能生成一分钟的视频，甚至有人用AI制作完整电影。这背后涉及极为复杂的计算过程：大语言模型需要逐像素生成内容，再由帧连接成视频，绝非单块GPU所能承担。

再看智能体工作流——大家都在谈论智能体AI，其中的任务并非孤立的单一指令，而是由多个智能体协同完成的链式流程。比如"生成一份研究报告并制作演示文稿"这样一个任务，智能体需要访问网站、检索数据、分析筛选、导入Excel、生成图表、再嵌入PowerPoint并优化视觉效果——整个过程涉及复杂的智能体协作链路。正是这些需求，驱动计算从单GPU、单服务器、单节点，扩展到多节点组成的Pod，再到完整的计算节点集群，共同作为一个"大脑"完成一项复杂任务。

Chole：我更倾向于从应用视角来理解这个问题。可以将计算集群视为一个完整的计算平台，涵盖所有硬件、连接能力和软件栈。在此基础上，平台决定应用如何部署、如何通过网络白名单/黑名单和访问端口实施访问控制，并以服务的形式对外提供。这里说的"服务"，不仅仅是云服务商的概念——即便在企业内部，当员工需要访问大规模机器或硬件资源时，同样需要通过某种服务化方式来实现，从而确保应用的简便部署、有效管理与编排。此外，故障切换、弹性扩缩容、无缝部署与安全保障，都是不可或缺的能力。在此框架内，还可以进一步定义应用级集群——例如，将一套大语言模型的预填充与解码阶段分开部署在若干GPU节点上，这一子集本身也可以被视为一个独立的集群。

Emmer：从芯片架构师的视角来看，计算集群不仅仅是服务器的集合，更是一套层次化的通信域体系——从芯片内互联、封装间通信、加速器与CPU的协同，到节点间通信，再到机架间通信，每一层都有其独特的性能特征。如果底层设计时没有将集群整体纳入考量，软件层就不得不为延迟、同步开销和功耗付出代价。在我看来，集群架构的起点在于封装边界，而不仅仅是网络边界——封装本身就应该被视为第一跳网络节点。架构师要追问的不只是"计算有多快"，更要问"数据在产生有效计算之前，需要跨越多少边界"。Chiplet架构之所以举足轻重，正是因为它能够在优化本地带宽密度的同时，保持对外扩展的灵活性。

Darbari：从我的角度来看，计算集群是一组相互连接并统一管理的机器，从工作负载的视角来看，它们共同构成一台规模更大的计算系统。每个节点拥有各自的处理器、内存和软件栈，高速网络与集群软件则将它们协调整合为一个统一的逻辑资源池。因此，系统的正确性不仅取决于本地微架构，还依赖于整个系统在通信、顺序保证、数据可见性以及故障恢复方面所提供的保障。作为形式化验证领域的从业者，我们的工作就是将这些系统行为建模，并将其转化为硬件、固件与系统软件之间明确的契约，而不是任由其隐式存在。

阿里巴巴万卡集群的启示：扩展规模能否弥补芯片差距？

Chole：阿里巴巴所发布的万节点集群面临极为严峻的工程挑战。就当前而言，除训练任务外，几乎没有任何单一作业能够充分利用如此规模的集群。训练任务通常需要大型集群全力投入，而推理层面也鲜有公司拥有如此量级的需求。在思考这一问题时，关键在于并行化策略——如何合理分解任务、设计数据管道、协调节点间通信、处理输出渲染、状态保存与存储访问。如此大规模节点之间的全量互联，本身就是极具挑战性的关键瓶颈。

Darbari：阿里巴巴的万卡集群，是在器件层面存在差距时给出的系统层面解答。当单块芯片性能不够领先时，通过激进的横向扩展、以及能让众多设备协同运作的互联架构与软件栈，同样可以构建出具有竞争力的AI平台。这一策略本身无可厚非，但并非阿里巴巴的专利。事实上，美国超大规模数据中心早已构建了同等量级的系统：微软已公开披露了为OpenAI建设的Azure超算，连接约1万块GPU；AWS提供专为AI训练设计的EC2 UltraCluster，支持万卡级部署；谷歌同样为前沿模型训练构建了拥有数千块TPU的大型Pod系统。

因此，"利用大规模紧密互联集群提升有效算力"这一核心思路在美国早已付诸实践。两者之间更值得关注的差异，不在于节点数量的多寡，而在于周边生态的成熟度。中国的案例更多强调通过系统架构和网络设计弥补单芯片性能的不足；而美国的大规模集群，则通常植根于更为成熟的工具链、软件框架、运维体系，以及长期积累的分布式基础设施运营经验。

权衡取舍的逻辑因此十分清晰：横向扩展可以弥补单体设备的性能短板，但也会在性能调优、故障处理、软件编排和安全保障等方面急剧提升复杂度。如果系统层面的行为没有经过严格的规范与验证，更大的规模只会放大不确定性；反之，若规范完善、验证充分，规模扩展便能成为一种有纪律的架构优势，而不是脆弱的权宜之计。

计算集群走向大众化：从国家实验室到各行各业

Brunner：当前驱动集群发展的主要动力来自AI应用，但集群服务正呈现出一种混合形态——AI工作负载与传统HPC集群的深度融合。以我们的重要客户阿贡国家实验室为例，其Aurora集群部署了6.5万块GPU，整个系统会被集中用于单一大型任务，例如全球尺度的气象模拟。这类"领导级计算设施"的建设初衷，就是承载那些在其他任何地方都无法完成的任务。与EDA等商业场景相比，使用模式截然不同。美国目前已有三套E级超算集群投入运行，科学计算是其核心使命。

Bhattacharjee：这与我早年在HPC领域的亲身经历高度吻合。过去，HPC系统主要部署在国家实验室，服务于天气模拟、计算流体动力学等需要海量算力的高强度数学计算场景。而今，AI的兴起让这一切进入了主流视野。正因如此，数据中心正在经历深刻变革——传统超大规模数据中心惯用的30至50千瓦机架，如今正扩展至数百千瓦，风冷系统已无法满足散热需求，液冷技术随之全面普及。这场变革不再局限于国家实验室，超大规模云服务商正在全球范围内大规模建设数据中心，其他行业也在加速跟进。与此同时，算力主权意识的崛起——各国都希望拥有本国的大语言模型，服务于政府和安全需求，而不愿依赖他国的云基础设施——也在推动全球范围内的算力基础设施大规模建设，带动土地收购、系统集成和软件部署等方面的高额资本支出。

未来，计算集群将深刻渗透到制造、药物研发、金融风险建模、EDA、自动驾驶等几乎所有行业。我们目前所看到的生产力跃升，不过是这场变革的序章——完成同等工作所需的时间正在大幅压缩。这将是一段至少延续十年的长期旅程，届时各类系统将全面建成，而模型本身也将变得越来越智能，承担起过去需要耗费大量时间才能完成的工作。

Vishwakarma：我完全认同。在过去十年里，高性能计算的主要工作负载是气象预测等科学计算任务。而AI计算的根本性转变在于：其工作负载高度依赖矩阵乘法这一核心运算，即MAC（乘加）操作。这正是整个行业向GPU转型的根本原因——不仅是单块GPU，而是八块GPU组成的单节点服务器，再到多节点集群。

从底层逻辑审视，数据中心为何消耗如此巨量的电力？根本原因在于GPU间的大量数据传输，以及GPU与内存之间的密集数据交换——这些都源于训练过程中对权重参数的反复加载与更新，所有前沿模型的竞争都在这里展开。如今，功耗已与带宽、延迟一道，成为首要技术瓶颈：当前数据中心的电力消耗，已相当于一座城市的用电总量。这些新挑战是前所未有的，亟待创新性的解决方案。

Emmer：我认同集群将走向主流，但不会形成单一统一的架构形态。随着应用范围不断拓展，我们将看到更多面向特定领域的差异化集群组合——不同的内存占用需求、不同的延迟容忍度、控制密集型与张量密集型工作负载的不同比例。从架构角度来看，这指向模块化设计路线，而这正是Chiplet架构走向战略高地的核心原因所在。

Darbari：当越来越多的行业在性能、内存容量或服务可用性方面触及单台大型服务器的极限时，横向扩展架构便成为顺理成章的下一步选择。这一模式正从超大规模与高性能计算领域向外扩散，越来越多地被正在引入AI、大规模分析和全天候数字服务的企业所采用。集群架构的吸引力在于：支持算力的渐进式扩展、通过节点级容错规避单点故障，并且通常比持续采购更大规格的单体系统具有更优的性价比。随着集群技术的广泛普及，形式化验证的重要性愈发凸显——跨团队、跨厂商的复杂系统，需要对一致性、故障切换和隔离机制有精确的定义，从而确保各方实现都能被验证为符合共同的设计意图。

Q&A

Q1：计算集群和普通服务器集群有什么区别？

A：计算集群是将多台服务器跨机架互联，形成一个统一的大规模计算系统，专门用于单台服务器或单个机架无法完成的超大规模工作负载。它不只是硬件的堆砌，还包括高速互联网络、软件调度系统和完整的运维生态。从芯片架构师的角度来看，集群架构涵盖从芯片内互联到机架间通信的完整层次体系，设计时需要统筹考虑网络拥塞、延迟、散热、电力供给和软件调度等多重因素，是一套软硬件协同的完整生态系统。

Q2：阿里巴巴的万卡计算集群能弥补芯片性能的差距吗？

A：在一定程度上可以。当单块芯片性能不够领先时，通过大规模横向扩展和优化的互联架构，仍然可以构建出具有竞争力的AI算力平台。但这种策略并非阿里巴巴独创，微软、AWS、谷歌等美国超大规模云服务商早已部署了同等量级的万卡集群。更关键的差异在于周边生态的成熟度，包括工具链、软件框架和运维经验。此外，规模扩大也会急剧提升系统复杂度，在性能调优、故障处理和安全保障等方面带来新的挑战。

Q3：计算集群未来会在哪些行业大规模应用？

A：随着AI需求的爆发式增长，计算集群正从国家实验室和超大规模数据中心加速向各行各业渗透。制造业、药物研发、金融风险建模、EDA（电子设计自动化）、自动驾驶等领域都将深度受益。驱动因素包括：AI工作负载的持续扩张、算力主权需求的上升（各国希望建设本国大语言模型基础设施），以及智能体AI等新型复杂工作负载对多节点协同计算的迫切需求。业内专家预计，这将是一段至少延续十年的长期建设周期。