智猩猩公开课超节点与智算集群系列第15期由联智科技CEO付鸿雁以视频形式主讲，主题为《从割裂到融合：超智融合一体化算力中心的系统化构建思路》。付鸿雁从算力需求多元化复杂化现状、超智融合的新型异构算力优势以及算力架构的核心要素、从硬件到应用的系统化建设路径四个方面进行了深入分享，并回答了用户提问。现从27个提问中精选12个Q&A特此分享。

（扫描下图二维码观看完整课程回放）

Q1：超算与智算如何区分？

付鸿雁：我们可以从几个维度去看：

一是两者应用领域和应用场景有差异。超算是做科学计算和工程仿真，比如天气预报、材料研究、高能物理、石油勘探、航空航天、汽车设计等等。我本科和硕士学的专业是飞机外形设计，因此我2000年就开始用超算做飞机设计的模拟。智算应用场景有我们经常听到的自动驾驶、图片识别、语音语义识别、智能推荐和搜索等。

二是从架构来看，超算和智算也有差异。比如超算更多用CPU，追求的是双精度。少量的超算也用GPU，像生物信息里其实就能用到GPU，但也主要是用到单精度就可以了。而智算大多需要GPU，且不需要那么高的精度，比如采用单精度、半精度、乃至混合精度。

三是从软件栈来看，超算是各种行业的模拟类应用软件，需要用到一些MPI和openMP等数据库、数学库的环境。智算需要用到TensorFlow、PyTorch这样的框架模型，以及CUDA这样的基础库。这些是我们去区分超算和智算差异的关键。

另外补充一点，今天我们讲超智融合这个主题，是因为从现在看到的场景来说，超算和智算的交集越来越多，它们之间的界限也越来越模糊。前面提到，其实一个大模型的训练是典型的超算架构，还有AI for Science场景，很多科研用户也开始用AI的方式来解决问题。从国外发展和需求来看，未来用户使用算力时，也不会太严格区分超算和智算。

这是我们从超算领域转到超智融合领域的原因，也是近五年来我们在项目中洞察到的算力需求变化，几乎所有用户建设超算CPU集群时都会配置一些GPU来做AI研究，很少有纯超算的集群。所以超算、智算虽有区分，但我们还是要多关注两者的融合。

Q2：请问目前算力集群运行中最棘手的问题有哪些？

付鸿雁：主要有两个：第一个是应用上，怎样运行各种各样的应用软件、怎样优化用户的应用软件，最终让应用跟底层算力资源达到最佳匹配。以及在调度策略上，也需要持续优化。如果集群运行过程中，出现了应用软件跟集群的适配兼容问题，很难在既有集群的运行过程中去解决，只能是在现有设备的情况下，看看是否可以去做一些诊断、分析、优化和应用的调优，来保障应用性能达到极致。所以集群建设初期对用户要使用的各种应用软件进行深度调研，就很有必要。

第二个是管理上，怎样优化管理策略、怎样在运维时持续把集群性能发挥到最佳。举例来说，已经运行的集群如果出现了算力受限情况，很可能是前期方案设计的架构就不合理，也可能是建设过程中部署环节有问题，又或者是调度平台没有设置合理的管理限制。解决以上问题的关键是，要从集群建设初期就站在用户角度以全局观规划、设计整套架构，在部署环节诊断、分析、优化集群性能和应用软件，并在后期运维中实时排查、解决用户难题，保证整套集群性能持续最优。而基于现在的已有算力受限问题，那只能去尽量做一些应用和管理上的优化和调整，把性能损失将至最低。

Q3：请问超算集群主要搭建主体是谁？

付鸿雁：第一个是国家级超算中心，一般是政府主导、政企/校企协同建设，现在全国有十几个国家级超算中心，北京、天津、广州、深圳、济南等地都有；第二个是科研机构，比如中科院各研究所，还有国家级实验室、省市级实验室、高校内实验室、教育部直属实验室等科研实验室；第三个是高校，比如清华、北大、中科大、上交、西交等这些头部高校，都有自己的超算中心。

另外，也有企业会自建超算。比如石油石化、能源、风电、电力等央国企，钢铁、汽车、芯片设计等制造企业，在产品开发、设计环节基本都需要超算进行工程仿真，提高设计效率、加快产品上市。还有军工单位，航空航天、船舶、武器装备、核模拟等领域都会用到仿真和超算。还有就是政府机构，像气象局、地震局、测绘局、消防局等政府机构里有研究职能的部门，也会建超算做科学研究。还有医疗体系里的医院、医学院、基因公司、药企等，也都是超算搭建的主体。

Q4：不同时间建设的多套集群，如何在监控系统，账号管理系统，系统管理层融合。如何和机房监控系统融合？

付鸿雁：这个问题也是我们现在看到很多高校和大型企业的现状。由于之前经费来源不同、需求不同，很多高校院系、课题组或企业的各部门，都分别建设了自己的集群。但现在这些集群大多都存在使用不均衡的现状。我们最近也在跟很多企业和高校一起探讨多元算力统一纳管的方案。

首先是监控系统，从监控层面来看还是非常容易整合的，只要已有集群能提供资源使用和任务使用情况的一些接口，就可以进行集中监控，去查看集群的使用率如何、资源使用情况怎么样。

第二个是账号管理系统，会相对复杂一点。有这样几种方案，如果原来每套集群都跟企业或者学校的统一身份认证对接过，那我们做集中的账号管理就相对容易。但如果都是自建用户，没有对接统一身份认证，我们去构建集中管理的时候，就比较复杂一点。要考虑到用户的映射，还要区分有一些同名的是不是同一个用户，或者同一个用户其实他不同名，这种就比较复杂，要根据实际情况去做定制方案。

第三个系统管理层，一般来说系统管理更多是强调对整套集群的管理，比如设置用户权限、匹配作业所需算力等。与机房监控系统的对接相对简单，如果以机房监控为主，我们可以把集群的接口给到机房，调取数据后由机房监控大屏做统一展示和监控；如果是以我们的超智融合算力管理平台CHESS为主，就可以把机房监控信息整合到CHESS平台上，在平台上做统一监控、报警或大屏展示。

这里还提到了多集群，我还想再多说一点，我们现在跟很多用户去探讨多元算力的统一纳管，我觉得纳管的信息不仅仅只是常提到的CPU、GPU算力，还要包括一些数据和应用的纳管，以及应用许可这些软资产的纳管，因为这些也跟计算息息相关。

前面我们说了很多算力，其实在数据管理方面也需要做一些统筹。比如生物信息和AI，都有很多我们需要从外面下载的公共数据，像人类全基因组的数据和公共的数据集等。另外还有我们通过超算或者智算算出来的一些结果数据，其实也需要统筹管理。

同时，还会遇到的问题是应用软件和应用许可分散采购，但跟算力一样也会有使用不均的情况，有的是用户买了很昂贵的软件许可放在那儿没人用，有的是软件许可不够用，无法支撑业务需求。

所以，我们在关注多元算力统一纳管的时候，我觉得不应该仅仅是算力本身，还要去看一看数据、应用软件、应用许可这些资产的统筹管理。

Q5：根据您的经验，目前哪些行业或应用场景使用超智融合算力中心比较合适？反之，哪些场景可能暂时还不适合采用这种架构？

付鸿雁：适合超智融合的场景，目前看一般是在高校和科研院所。前面提到AI for Science，在原来超算的研究方式中，很多学者也开始用AI的方式去解决问题。所以在很多科研机构里，都是超算和智算同时在用。另外是在医疗方面，医院跟算力相关的两个场景是基因分析和医学影像分析。比如用CPU去做基因组数据的分析，是超算类应用，而医学影像分析基本上要用到AI的能力，所以在医院里能看到的超智融合就是这两个大的场景。还有一些就是大型企业，比如钢铁企业，除了有材料的研究（偏超算），还有质量检测相关的（偏AI的场景），也可能会做一些超智融合的方案。

不适合的场景一般是那些对实时性要求非常高的，比如金融领域高频交易的实时性要求非常高。还有就是企业里传统的OA系统、财务系统、ERP、CRM、Email等web服务，这些标准化通用场景也不适合于超智融合的平台，更适合在云计算这样的通用算力平台上运行。

Q6：在融合架构中，数据在CPU、GPU和存储之间的流动至关重要。您如何看待RoCE、InfiniBand等高速网络技术在此类中心的作用？在构建网络时，如何避免其成为性能瓶颈？

付鸿雁：这个问题其实我们在方案设计过程中，也是经常会被反复提出来讨论和论证的话题，到底选IB还是RoCE？先排除要求必须国产化的政策因素。

那从技术上分析，超算和大模型训练场景，需要整合多机多核、多机多卡的能力，多机之间必然要通过网络传输数据，实现多机并行计算。这时网络的带宽和延迟是非常影响多机多卡训练性能的，所以也要求我们在网络选型上必须考虑高带宽、低延迟。

我们其实交付过一些项目，从性能指标上说，400G网络的带宽都是能测出来的，从延迟指标来看RoCE还是远高于IB。IB在单交换机内部，我们测到延迟在1微秒以下，跨交换机也就1微秒多一点。而RoCE的延迟，之前我们测试，在单交换机内部是3-5微秒量级，跨交换机就有7-10微秒量级。

如果你的应用场景是大规模，且对延迟指标非常敏感，任务拆分的越细，就越需要更多的节点和GPU来计算，相当于单卡任务所需算力会小。超算也是这样的，一个数据拆分的越细，每一个GPU、每一个核的计算量就越少，通讯就更频繁。在每一次通讯时，都会受到延迟的限制。刚才说到IB延迟1微秒，RoCE按照8微秒的延迟来算，二者就有了八倍的差距，可能在这几微秒之内就损失了很多算力，因为这个时间段是通信过程，CPU和GPU没有进行计算。

总体来看，IB的优势延迟小且稳定，RoCE的优势是成本低，以及还有一个最大的优势是协议统一，通过以太来访问，协议有非常好的通用性。也许有一些系统可以在以太上有很好的通讯，或者说只支持以太，那么这时必然只能选择RoCE网络。

所以，最终还是得根据实际场景来选择网络，如果真的是很多卡、很多核的多机并行运算，我觉得还是要选延迟更低的网络。

Q7：在超智融合的智算中心中，IB 和 roce 是混合部署吗？如何确认二者的配比？

付鸿雁：一般情况下二者是不会混合部署的。我们先考虑两个场景，一个是计算网，一个是存储网。如果是计算节点互联，网络选型一定是选其中一种，IB也好，RoCE也好，把所有的计算节点搭起来，存储节点也是同理。

当然存储网和计算网的选型可以考虑不同的网络，比如将IB用于计算网，用RoCE做存储网，这是可以的。但它不是配比，而是看存储的具体性能要求，来决定配多少G的RoCE存储网，每台机器是几张卡，多少G的。训练的计算网，一般都是8张卡，8个200G或者8个400G的IB卡，去构建IB网络。

Q8：异构算力集群结合公有云Kubernetes平台多吗？异构算力在工业制造仿真场景对比统一的x86架构是否有优势？

付鸿雁：单从K8S本身的功能来说，它是比较容易实现本地和公有云的统一管理和任务提交的。通过K8S的API可以提交任务，然后由系统来决定是在本地还是云上去运行。但是这种混合的或者是说跨地域的，在网络延迟、数据同步的时间、成本以及安全性上，用户还是有很多顾虑。

另一个问题是异构算力在工业制造仿真场景对比统一的x86架构是否有优势。这里所说的异构算力，我理解一个是GPU和x86 CPU的异构，或者是国产CPU的异构。如果是GPU和x86 CPU的异构，我了解到目前在纯工业仿真场景里，大多数应用还是以CPU为主，少量的应用能用到GPU，但加速效果不是特别好。整体来说，如果要做超算模拟，我们还是需要双精度，目前GPU的性价比不是特别好，用的人比较少。

如果是多种国产CPU异构的情况，目前看还是生态问题。比如Arm架构，主要是飞腾和华为的芯片，也有提供解码/转码工具，可以把商业软件在国产的Arm架构机器上运行，但是会有10-20%的性能损失。不过还是可以去采用的，毕竟能实现商业软件的运行，只是性能上会有一些损失。如果是有源代码级别的应用，那就不受国产芯片、x86的限制了，可以在国产CPU上对源代码进行编译、运行。目前大多数国产CPU都支持编译，也有运行环境，编译出来的应用基本都能跑。

Q9：在超智融合架构中，slurm与Kubernetes如何实现深度融合调度？是否会出现资源争抢或调度冲突？

付鸿雁：我们现在做的融合调度是肯定不会出现冲突的。slurm整体接管集群，K8S向slurm申请需要用的资源，然后slurm会隔离节点给到K8S，当slurm隔离出这个节点后，就不会再往该机器上提交任何任务。这个级别是到服务器本身的，如果K8S容器释放了资源，它会回归到slurm的调度里来，所以二者是绝对不会冲突的。

我们也在逐步增加一些策略，比如预先设置好一些slurm的固定资源池、K8S的固定资源池，也可以设定两者混合的资源池，即允许slurm和K8S在混合资源池里可以弹性设置。

Q10：多硬件厂家的超算和智算硬件集群，是否有统一管理的经验分享

付鸿雁：这个是有的，我们的超智融合算力管理平台CHESS支持多种CPU、多种国产化GPU的统一管理，且有过相关的交付经验。但对于多种CPU、多种国产化GPU的统一管理，我觉得难度不在管理和调度上。因为调度是比较容易识别资源类型的，并且资源的空闲率也都可以识别到，可以把任务发上去。

更多的难点是各种不同的芯片是否能支持应用运行，如果仅仅是相同架构但不同品牌的服务器就没有什么影响，我们跟主流的服务器都适配过。如果是不同的CPU和GPU，那还是要看芯片厂商对应用编译、转译、优化的技术支持程度，所以核心并不是在管理和监控上，也不在调度上。

Q11：一般集群的生命周期是多久？

付鸿雁：我觉得至少五年以上，5年左右会有集群扩容或利旧的需求，但我们也有客户的机器用到了十年。当然，五年之后可能会有个别零部件不能用了，也许就是几台机器再拆装一下，凑成几台机器用，也有这样的。

但是目前我们有用户是持续用十年的，不过可能算力也只剩原来的2/3甚至一半是可用的了，但还能提供超算的能力。

Q12：你们的合作模式是怎么样的？你们也代采购硬件设备吗？

付鸿雁：我们是只提供软件、方案和服务，包括前期的方案设计，部署过程中的性能优化和管理平台搭建，后期运维的巡检、排查、调试服务。硬件我们基本不代采，除非用户强烈要求。正是因为我们不参与硬件采购过程，所以才能以更中立的第三方视角帮助用户去做好集群方案设计，以及交付时的性能优化和把关。另外，我们的软件平台和服务，经常跟硬件设施是一个包，由一个总集方去投标，跟他们联合交付，是这样的一种模式，我们自己不做硬件业务。