大模型在超大规模集群性能提升实践

摘要：随着大模型技术从技术变革转向产业变革，大模型应用也会进一步繁荣，传统基础设施技术已经不足以满足大模型应用的快速发展。整个基础设施技术和产业链正在快速转型，向大模型基础设施技术演变。2025 QCon 全球软件开发大会（北京站）策划了「面向 AI 的研发基础设施

分享嘉宾 | ZOMI 酱

审校 | Kitty

策划 | QCon 全球软件开发大会

随着大模型技术从技术变革转向产业变革，大模型应用也会进一步繁荣，传统基础设施技术已经不足以满足大模型应用的快速发展。整个基础设施技术和产业链正在快速转型，向大模型基础设施技术演变。2025 QCon 全球软件开发大会（北京站）策划了「面向 AI 的研发基础设施」专题，通过本专题的深入探讨，希望让听众了解并掌握大模型基础设施技术的发展趋势和前沿动态，从企业工程实践和学术研究领域借鉴成功经验，为自身企业制定更大规模、更高性能以及更加稳定的大模型基础设施技术。详见会议官网：https://qcon.infoq.cn/2025/beijing/

万卡集群在执行大规模网络模型训练任务时负载重，面临功耗、网络拓扑、可靠性和故障恢复、并行计算、成本分析等多方面的挑战。越来越多开发者希望更好地驾驭万卡集群，提升大规模网络模型在万卡集群训练的集群整体性能。

在 InfoQ 举办的 QCon 全球软件开发大会上，华为昇腾生态技术首席 ZOMI 酱为我们带来了精彩演讲“大模型在超大规模集群上的性能提升实践”，深入探索如何在万卡昇腾 NPU 集群上，基于业界典型 AI 框架和 MindSpeed 分布式并行加速库，结合网络拓扑优化算法和华为开源 HCCL 集合通信库协同优化，并深入剖析了万卡集群训练过程中涉及的技术原理和难点，探讨万卡集群训练的性能和稳定性策略，最后结合案例讲解面向万卡集群的性能提升实践。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）：

我整体分享的内容分为四个部分。首先，我们来看一下大规模集群的发展；接着，我们探讨集群组网的整体优化，特别是华为是如何做的，从百卡集群到千卡集群，再到如今的万卡集群，整体组网方案的演进；然后我会分享多模态性能优化的案例；最后通过一个小红书的简单案例做一些总结。

大规模集群发展

尽管万卡集群在当下似乎已不再稀奇，但对于高校、个人开发者以及一些小型独立软件供应商（ISV）而言，万卡集群的构建仍然极具挑战性。Meta 的 LLaMA 43.1 基于 1.6 万张 H100 GPU 卡片开发；而近期发布的 MovieGen 则是基于 6000 张 H100 卡片进行训练。由此可见，千卡乃至万卡集群已成为众多模型和厂商的标配。xAI 更是宣布将自建一个 10 万卡的集群。这表明，万卡集群已成为新的技术门槛。

在万卡集群中，有几个核心指标备受关注。首先是 MFU（Model Flops Utilization，模型利用率），其次是 HFU（Hardware Flops Utilization，硬件算力利用率），两者存在一定差异。此外，集群的可用率，包括中断次数等，也是当前关注的焦点。

用户角度看 AI 集群

从用户视角来看，AI 集群面临三大主要问题。首先，AI 集群的成本居高不下。用户期望使用更强大的芯片和更高速的网络，但这无疑会进一步推高成本。其次，集群的稳定性问题亟待解决。稳定性受到多种因素的影响，例如计算错误率、ECC（Error-Correcting Code，纠错码）错误率、网络中断以及板卡元器件失效等。这些因素都可能影响整个 AI 集群的稳定性。目前，一个大模型通常运行在一个集群上，若其中一张卡出现中断，整个模型可能都需要中断。再次，集群的启动和运行速度过慢。即使使用 PyTorch 拉起一个万卡集群，完成心跳同步可能需要 20 到 30 分钟，而下发任务时还需等待通信。因此，从用户角度总结，AI 集群目前面临的问题主要集中在成本高、稳定性差以及运行速度慢三个方面。

从生态角度看，英伟达在 PyTorch 领域构建了天然的生态壁垒。无论是对于华为还是国内其他芯片厂商而言，打破这种垄断都并非易事。因此，越来越多的厂商开始逐渐接入 PyTorch 生态。从需求角度看，当前大模型的训练场景，无论是大语言模型还是多模态大模型，都在推动整个 AI 集群的发展。未来，推理场景可能会逐渐成为推动集群发展的新动力。

AI 集群当前的通用问题

从我们真正从事底层 Infra（基础设施）工作的人的角度来看，当前面临的问题主要集中在以下几个方面。首先，摩尔定律已开始逐渐失效。目前，计算芯片和网络的增速远远落后于 AI 的计算量和参数量的增长，差距甚至达到数倍之多。其次，假设芯片制程无法继续提升，那么堆叠数量就成为一种解决方案。我们通过贴合封装技术，将单个芯片扩展为节点，将节点升级为超节点，最终将超节点组成一个超大规模的网络集群。这种堆叠的方式已经发展到相当复杂的程度。

此外，芯片层级的新技术不断涌现，但发展速度却远低于预期。例如，片上 SRAM（静态随机存取存储器）、片内 HBM（高带宽存储器）的 IO 带宽，以及芯片的光照面积限制等问题，都在制约着芯片技术的发展。这些技术的发展速度远没有我们想象中那么快，尤其是在我国，掌握这些核心技术的难度仍然较大。除了芯片内部的技术挑战，片外、带外以及跨节点的互联技术，如微光互联和光交换，也相对落后。尽管国内有一些创新创业公司在尝试突破，但这一领域属于重资本产业，尤其是硅光互联和光交换技术。一旦通信数据量达到一定规模，光交换就会受到物理极限的约束。同时，scale-up（纵向扩展）与 scale-out（横向扩展）、存内计算与寄存计算之间的争论也在不断涌现。例如，面对内存不足的问题，是否可以通过净存计算来解决？是否可以将或 HBM 与计算更加紧密地结合？这些都成为当前需要面对的新问题。

能耗问题也尤为突出。一些二级市场或一级市场的投资人曾问我，是否有必要投资能源公司的股票，或者关注新建智算中心的能耗占比。事实上，智算中心的能耗占比非常高。目前，我们的机房大多建在贵州、内蒙古等地，利用自然冷源进行散热，但风冷已无法满足需求，因此不得不转向液冷技术，以降低温度并减少能耗。然而，上述许多问题并非短时间内能够解决，但这并不意味着我们应放弃努力。实际上，我们仍有许多工作可以开展。

在这一领域，国内外涌现出许多新的集群和云平台公司。例如，国内的阿里云、腾讯云、火山云、百度百舸，国际上的谷歌 TPU、亚马逊 AWS，以及 Meta 等。华为也有自己的华为云，而昇腾则在很大程度上支撑了这些云服务和集群服务的运行。

基于这些现状，我们看到 AI 集群的性能提升主要集中在芯片能力、集群能力、算力效率和可用率等方面。在算法层面，常见的优化手段包括计算优化、通信优化、并行优化和内存优化。在推理加速方面，我们也做了大量工作，包括通信加速、解码优化、量化压缩以及最优并行调度优化等。然而，这些内容大多是脱离业务的。如果仅从硬件 Infra 支撑的角度来看，这些内容与业务的关联性并不强，显得有些过于宏观。今天，我主要想分享的是更深入、更具体、与昇腾或华为业务强相关的内容。

集群组网优化

参数面多轨组网

从百卡集群到千卡集群，再到万卡集群，我们进行了架构的逐步优化。下图右边的图例中 100G 网络对应的是 100Gbps 的通信带宽；GE（Gigabit Ethernet）是普通的以太网通信，带宽相对较低；10GE 是带外通信。在日常操作中，我们通常通过公网、云专用网或 IP 承载网，经由最外层的路由器接入整个集群。而集群内部真正运行模型的部分是下图中间的 AI 集群，存储和计算集群是分开的。

因此我们产生了多个不同的业务面：参数面、业务面 / 数据面。参数面是指网络模型参数传递的网络。在一个万卡集群中，用英伟达的卡， GPT-3 模型的 MFU（Model Flops Utilization，模型利用率）最高能达到 50%，大部分时间都在进行网络通信，通信对我们来说已经变得非常关键。当时，参数面主要采用多轨主网架构，参数面接入的是 100G 的 RoCE（RDMA over Converged Ethernet）网络，这是一种典型的配置。数据面和业务面负责将存储的图片、文本以及对话数据等，通过存储后端传递给计算面，即我们的 AI 集群。在参数面的早期阶段，即 2020 年之前，当时还没有大规模推动千卡或万卡集群时，我们的组网方案相对简单。

参数面由多轨调整为单轨

集群组网，尤其是英伟达的万卡组网，是在近两年才逐渐兴起的概念。在过去，很少有人提及万卡集群或千卡集群。由于早期集群中没有独立的数据面，数据面与业务面合为一体，通常通过 NFS（Network File System，网络文件系统）协议进行访问。这种架构存在潜在风险，数据可能因访问协议的开放性而外泄。这成为许多客户极为关心的问题：购买集群后，数据应如何得到有效保护？如果数据面与业务面没有分离，且上层连接路由器，一旦接入路由器，网络很容易受到攻击，进而导致数据被访问或泄露。

尽管目前在大模型训练中，数据安全问题尚未成为主要关注点，但对于许多 B 端企业，尤其是业务级公司来说，数据泄露风险是他们极为重视的问题。在早期的百卡集群中，样本面与业务面的网络是共享的，组成了一个多轨的 100G RoCE 网络。这种架构会影响整个 IO 的读取速率，因此我们对方案进行了升级。

在千卡集群阶段，我们不能再沿用早期的架构。经过深入研究并与众多客户交流后，我们将数据面从整体架构中分离出来。在 AI 集群中，我们从多轨方案转变为单轨方案。多轨方案存在一个较为致命的问题：维护成本极高。虽然它可以连接多个二级交换机，使集群规模更大，但维护成本的增加会导致可用性下降。尤其是在千卡集群中，我们希望集群能够随时启动，避免像万卡集群那样频繁出现错误、掉卡或网络中断等问题，包括光模块故障等。

因此，我们将参数面从多轨调整为单轨，并将网络带宽从 100G RoCE 升级到 200G RoCE，从而提升了参数面的整体性能。提升参数面性能的目的是为了提高节点之间的通信效率，最终实现参数面与数据面（即业务面）的分离，并将 NFS 协议改为 DPC（Direct Parallel Communication，直接并行通信）协议进行访问。

目前，一些厂商可能会将数据直接存储在 AI 集群的每个节点中，但这种方式对数据的维护和管理带来了极大挑战，尤其是对于 CKPT（Checkpoint，检查点）数据。在实际业务上线时，可能会存在多个分散的 AI 集群，因此配备一个集中的存储端口是非常必要的，尤其是面向未来的推理集群。如今，我们的整体架构包括一个训练集群、一个独立的存储区域以及一个管理区域，分别用于管理带内和带外网络。通过这种方式，我们将之前提到的问题进行了有效隔离，尽可能确保整个网络和网段的安全性，同时实现了数据与业务的分离。

提高计算侧数据面接入网卡速率

我们正在进行架构演进，以应对对万卡集群甚至更大规模的方案。随着大模型的兴起，尤其是强化学习的广泛应用，数据源源不断地从存储集群流向 AI 集群，甚至推理集群。在推理业务中，数据持续产生，因此我们需要减少 AI 集群与存储区之间的数据传输延迟，尽可能拉近它们之间的距离。为此，我们制定了新的方案，适用于万卡集群以及未来的 Post-Training（后训练）和推理业务场景。在这一方案中，我们将计算面的网络从 2×25G 升级为 2×100G 的 RoCE 网络。整体网络架构中，绿色的连接线已发生变化，全部采用 DPC（Direct Parallel Communication）协议进行访问。最重要的是，我们再次分离了样本面与业务面，目前仍采用单轨方案，服务器到 Leaf（叶节点）之间采用二分之一的线缆连接。这种设计的核心目标是提升网络性能，尽可能减少等待时间。

针对万卡集群的维护难题，我们优化了方案。万卡集群的维护极为复杂，一旦有一张卡掉线，可能会影响整个万卡集群的大模型训练。因此，我们通过减少维护工作量，提高集群的整体可用性。此外，训练区采用了全液冷方案，参数面和业务面被进一步分离，整体线路更加清晰，便于维护。同时，存储区和管理区也进行了新的业务隔离，以更好地支持万卡集群的运维需求。

从百卡方案到千卡方案，再到万卡集群方案，我们在做的事情可能用户难以感知，但对于从事底层系统工作的人来说，这些内容极为核心且备受关注。性能的优劣并非仅仅取决于并行策略的先进性，更在于网络如何组网，以及并行策略如何根据组网方案进行优化。在使用英伟达集群时，用户会发现其提供了成熟的 TPPP（Tensor Parallelism、Pipeline Parallelism 等）切分方案，大家通常会按照这一方案进行并行计算。然而，当面对新的集群，尤其是国产集群或不同网络架构的集群时，切分方式和并行方式会有所不同。因此，若想真正做好这一领域，实现性能的最优，就必须深入到底层进行探索。

多模态性能优化

SORA 多模态

在多模态场景中，以我们近期支持的 SORA 大模型为例，该模型自 2 月中旬推出以来，国内已有众多公司在开展图文生成和视频生成的相关工作。在视频生成任务中，大规模集群的应用必不可少。然而，大规模集群不仅成本高昂，还面临诸多问题。首先，面向新的业务场景时，不再是像 LLM 那样可以直接使用。例如，SORA 并未公开代码，用户需要自行编写或运行代码。如果代码无法运行，那么大量计算资源（如万卡集群）将被闲置浪费。即使集群处于通电状态但未运行任何业务，也是一种巨大的浪费。如果代码运行出错，同样意味着计算资源的浪费。因此，我们希望在按下回车键的那一刻，所有配置都是正确的，能够在两个月内成功训练出一个文生视频的大模型。

我们在 SORA 多模态业务中究竟做了哪些工作呢？首先，我们会分析网络模型或业务场景对每一层的挑战。客户最关心的往往是软件层面的挑战，因为软件与客户的算法和业务紧密相关。其次，我们也会关注芯片层面的挑战，而生态和算法层面虽然也很重要，但并非我们最关注的点。从性能角度来看，我们目前如何基于千卡规模训练一个文生图模型，因为文生视频模型本质上仍源于文生图模型。我们会分析文生图模型的业务痛点和问题。例如，batch size（批量大小）会不会特别大，是否容易出现 host bonding（下发瓶颈）问题。由于图片是一张张处理的，即使设置了 batch size，将多张图片打包下发时，很容易形成瓶颈。此外，在文生图和文生视频的训练中，我们不是像大语言模型那样一次性处理所有图片和文字，而是多次处理所有数据或图片，这相当于多次训练 RoPE（Rotary Position Embedding）。接着，我们会处理不同分辨率的负载问题。在训练视频或图片大模型时，数据分辨率的差异较大，有些图片大，有些图片小。如果将图片尺寸固定为某一规格，生成结果的灵活性将大打折扣。此外，我们还会研究分布式推理、稀疏场景以及下采样策略等，深入剖析每一个算法细节，以提升性能。

在内存方面，国产芯片的内存规格与英伟达的有所不同。英伟达的 A100 芯片内存为 80GB，H100 为 96GB，甚至还有高配版 164GB，但国产芯片由于 HBM（High Bandwidth Memory，高带宽存储器）供应问题（HBM 主要依赖国外供应，国内产量较低），其内存规格与英伟达不同。由于供应链问题导致内存大小的差异，我们可能需要采用不同的内存优化方案、切分方式，以及在每张卡上运行的小模型或参数的大小也会有所不同。因此，我们需要深入研究内存优化策略。此外，精度问题也极为复杂。它可能涉及硬件问题、用户代码问题，甚至可能是训练技巧不足。目前，真正掌握大模型训练技巧的人才极为稀缺，每个人在运行万卡大模型时，一旦按下回车键，模型运行失败，往往会怀疑是硬件不行，而不会首先考虑是算法问题。因此，精度问题也是我们研究的重点之一。

性能瓶颈分析

对于 3D Attention 来说，当图片或视频的分辨率提升 n 倍时，序列长度和动态内存的使用量会变为原来的 n² 倍，而 Attention 计算的开销则会增加到 n⁴ 倍。这是因为图片和视频的维度包括长、宽、高以及时间序列，整体计算开销非常大。此外，视频的变化也会导致整体计算开销显著增加。

在 3D Attention 的应用场景中，例如生成纹身视频时，序列长度可以达到百 k 级别。大部分计算集中在 Fresh Attention 这一算子上，因此我们可以进行整体分析。在下图的左侧，我们将每一帧及其对应的 Fashion Attention 的 Ship 提取出来，并分析整个 MPU 的耗时，以及每次计算所使用的内存或显存。而在右侧的细节图中，我们进一步深入分析在每一微秒、每一毫秒内需要执行的具体计算内容。

整体来看，3D Attention 对性能和内存的挑战极大。目前，单步迭代时间已达到 170 秒，这意味着仅完成一次迭代就需要如此长的时间。因此，除了前面提到的优化措施外，我们还需要引入序列并行或改进模型结构，以进一步提升性能。

训练 DeepSpeed 精度问题

精度问题。最初，我们与北京大学的兔展智能合作，参与了 Open SORA Plan 这一开源项目。当时，该项目使用的是 DeepSpeed 框架，即微软的分布式训练框架。然而，我们在使用过程中发现该框架存在一些问题，尤其是在算子层面。因此，我们决定不再使用 DeepSpeed 框架。在万卡集群的训练场景下，我们无法确切判断每一个中间件是否存在潜在问题。DeepSpeed 是微软开发的，但业界尚未有在万卡集群上运行的成功案例。如果出现问题，很难判断是微软框架的问题还是硬件本身的问题。因此，我们最终放弃了 DeepSpeed，转而使用 PyTorch 的分布式数据并行 DDP 进行训练。结果发现，使用 PyTorch DDP 时精度表现正常，而使用 DeepSpeed 时则会出现精度问题。

在 DeepSpeed 框架下，我们还发现了一个有趣的现象：当使用 4GB 的混合精度训练时，loss（损失值）表现正常；但当扩展到 8GB 训练时，loss 会异常。我们当时对这一问题进行了深入研究。在 DeepSpeed 的框架下，我们尝试通过梯度累积的方式模拟大 batch size 的训练，此时 loss 仍然表现正常。然而，在实际运行大模型时，情况并非如此简单。

为了避免潜在问题，我们会在小规模参数下进行“演习”，例如将一个 100B 参数的模型缩减为 10B 参数，在小规模集群中进行简单验证。通过这种方式，我们能够排除许多与算法或超参数相关的影响。在 DeepSpeed 框架中，我们发现精度问题主要源于 all_gather 算子。因此，我们对 DeepSpeed 框架进行了一些修改和优化，并将这些代码贡献给了 DeepSpeed 社区。此外，我们还更新了底层算子库，解决了 DeepSpeed Zero-1 和 Zero-2 的一些精度问题。

对内存的优化

我们看一下内存性能和精度优化的相关案例。实际上，在进入 DIT（Diffusion-based Inference and Training，基于扩散模型的推理与训练）领域后，尽管 Meta 最近发布的文章指出，使用 DIT 进行推理或生成时，其整体耗时可能会受到影响，因此目前许多互联网厂商和合作伙伴又开始转向使用自回归方法进行文生视频任务。然而，在使用 DIT 的过程中，整个流程会涉及视频数据处理、分辨率变换、VAE 编码、文本编码以及编解码问题。如果考虑到不同分辨率，目前多种分辨率会导致不同的 batch 预处理开销，而每个 batch 的开销不同又会导致 host 负载不均衡，进而影响整体训练性能，表现为训练性能的抖动。

那么，这种抖动究竟是由硬件还是软件引起的呢？经过分析，我们最终发现这是由算法原因导致的。因此，我们总结出文生视频的三个典型特点：

数据预处理是一个重负载；

数据通常需要训练多个 Epoch；

训练步数（200k-1000k）更重要，Batch Size 不那么重要。

针对上述三个问题，我们采用了数据预处理方案。在 EPOCH 0（第 0 轮训练）时，我们保存 VAE 编码和文本编码的结果，尽可能多地将这些中间结果存储下来。从第二轮训练（EPOCH 1）开始，不再重新计算整体编码，从而减少 host 的计算开销，并充分发挥存储系统的性能优势。这一优化方案也与我们之前提到的参数面与业务面分离、提升计算集群与存储集群网络性能等内容密切相关。由于集群组网方案的变更，我们引入了新的加速手段。

解决内存不足问题

在当前的 NPU 架构中，为了应对内存不足的问题并提升性能，引入了序列并行技术，尤其是在处理类似 SORA 这种复杂模型时显得尤为重要。与传统的 LLM 相比，SORA 的序列并行更为复杂，主要面临以下三大挑战：

训练模式复杂：Sora 的训练同时涉及图片和视频数据，其中图片不参与序列并行（SP），而视频数据则参与 SP 并行。这种差异导致在并行策略设计上需要针对不同类型的数据进行区分处理。

时空 Attention 机制复杂：Sora 模型包含时空 Attention 机制，其空间 Transformer 层中，Batch 维度对应时间，序列维度对应空间；而时间 Transformer 层中，Batch 维度对应空间，序列维度对应时间。序列并行仅针对时间 Transformer 层进行处理，且在并行过程中，Tensor 的布局会在 BSH（Batch, Sequence, Hidden）和 SBH（Sequence, Batch, Hidden）之间交替变换，以适应 All2All 通信的需求。

输入数据多且复杂：Sora 基于 Text2Video，属于多模态模型，输入数据包括 Timestep（用于扩散模型）、文本编码（用于 Cross Attention）、视频 Mask 和文本 Mask 等。由于序列并行需要对所有输入数据进行 All2All 处理，以确保计算的正确性，这进一步增加了并行策略的复杂性。

解决 Attention 计算复杂度高问题

在算法层面，我们不仅进行了诸多工程性的细粒度优化，还提出了一种稀疏注意力（Sparse Attention）机制，以解决传统注意力机制计算复杂度较高的问题。这一机制与传统方法有所不同，是我们与华为诺亚研究院（2012 实验室）合作探索的新算法方向。具体实现分为三个阶段：

第一阶段：聚类

在注意力模块中，$\text{Softmax}\left(\frac{QK^T}{\text{Scale}}\right)$ 权重矩阵的每个 Token $Q _ i$ 与向量 _K_ 的相似度呈现出一定的规律性。基于这种规律性，可以将相似度分布相近的 Token $Q _ i$ 进行聚类，聚类结果如图 3 所示。

第二阶段：重排计算

对第一阶段得到的聚类结果，每行按照相似度大小由高到低进行排序。由于每份聚类结果 $CQ ^ i$ 中的每个 Token 与向量 _K_ 的相似度分布相近，可以设置一个固定阈值 _ϵ_，对相似度小于 _ϵ_ 的 Token $K _ i$ 进行过滤。因此，每份 $CQ ^ i$ 都将对应得到一个更小的矩阵 $CK ^ i$。随后，对重排后的矩阵 $CQ ^ i$ 和 $CK ^ i$ 进行计算，得到权重矩阵的子结果（如图 4 红色框内部分所示）。整体计算性能的提升与矩阵 $CK ^ i$ 的序列缩短长度成正比。

第三阶段：补齐还原

将第二阶段得到的子结果按照向量 _K_ 的长度进行补齐（补齐值为 0），然后重排还原。最后，将所有子结果拼接，得到完整的权重矩阵计算结果。

通过这一系列操作，我们主要目的是去除大量冗余的、无关紧要的计算。计算量的减少自然也会导致数据量的降低，进而减少存储需求。存储需求的降低进一步提升了训练性能，因为芯片内部的数据搬运过程是按照微秒级别进行的：数据从存储单元搬运到计算核心，计算完成后又在微秒级别内搬运回存储单元。这一过程非常耗时，因此通过减少计算和存储需求，整体性能得到了显著提升。

小红书案例

在支撑多模态场景的工作中，我们进行了一些基础但关键的 Infra（基础设施）层面的优化。华为在这方面的工作与其他公司有所不同，我们专注于分析业务需求，抽象出可以提升性能的关键点，特别是在计算、内存以及路由通信网络等方面。在在这个小红书案例中使用了华为云服务。由于华为云的组网方案已经确定并构建完成，因此我们不再需要考虑组网方案的演进，而是在一个已经达到次优状态的云环境中工作。

在处理大模型时，我们面临的主要任务是提升性能。许多基础问题已经得到解决，因此我们转而分析可以进一步优化的方案。我们对算子通信、算法等方面进行了深入分析，并收集了性能分析数据。通过对比 GPU 和 NPU 的性能分析，我们确定了性能瓶颈和通信耗时的阻塞点，以及计算耗时的具体位置。

经过分析，我们识别出了所有可以提升性能的关键点。对于耗时过长的算子，我们进行了等价替换。例如，我们发现 reduce getter 算子实际上是由 all reduce 和 all getter 两个算子组合而成的，可以将其视为一个通信算子。此外，All2All 通信也可以通过点对点通信的组合来实现，这是一种等价替换。

我们还充分利用了 AI Core 的能力。华为的芯片以及国内其他芯片厂商的产品与英伟达的 GPU 有所不同，后者拥有大量的 CUDA Core 和 Tensor Core。而我们的芯片拥有专门的 AI Core，这是华为芯片的最大特点之一。我们尽可能地将算力集中在 AI Core 上。此外，我们还采用了空间换时间的策略，以及多融合算子或自定义融合算子进行优化。最后，我们还进行了通信优化，进一步提升了系统的整体性能。

总结与思考

在大模型训练领域，尤其是千卡万卡规模的模型训练中，基础设施（Infra）性能提升的关键并非仅限于分布式并行策略的研究与应用。去年，我主要负责大模型训练的系统工程（SE），当时的工作重心集中在分布式并行上。因此，我主导开发了一个名为“AscendSpeed”、现在称为“MindSpeed”的框架，专门用于性能优化。

除了分布式并行策略，我们还需要在单个芯片上运行一些大型融合算子，例如 Fetch Attention。这种算子在小规模集群中能够显著提升性能，甚至可能达到两倍的提升效果。此外，我们还需要研究集合通信算法各种 NCCL 库，以及环回算法。内存优化算法也是我们研究的重点。

大多数人可能会认为，在万卡集群中提升性能只需关注上述这些方面。但实际上，万卡集群的构成远比这复杂。例如，光模块的功率、温度、连通性以及信噪比等各种各样的因素都会影响集群的性能。在真正的基础设施层面，尤其是在底层基础设施层面，我们的工作往往并不那么“高大上”，很多时候更像是在从事体力劳动。