ATLAHS：面向AI、HPC及分布式存储的以应用为中心的网络模拟器工具链

摘要

        网络模拟器在评估大规模系统性能方面发挥着至关重要的作用。然而，现有的模拟器严重依赖合成的微基准测试，或仅狭隘地关注特定领域，限制了其提供全面性能洞察的能力。本工作中，我们介绍了ATLAHS，一个灵活、可扩展且开源的工具链，旨在追踪真实世界的应用程序并精确模拟其工作负载。ATLAHS利用GOAL格式来建模AI、HPC及分布式存储应用中的通信和计算模式。它支持多种网络模拟后端，并能处理多任务和多租户场景。通过广泛的验证，我们证明ATLAHS在模拟真实工作负载时具有高精度（误差持续低于5%），同时在模拟运行时间和追踪文件大小效率方面显著优于当前最先进的AI系统模拟器AstraSim。我们通过详细的案例研究进一步阐明了ATLAHS的实用性，重点展示了拥塞控制算法对分布式存储系统性能的影响，以及任务放置策略对应用运行时间的影响。

图1. A展示了大语言模型实际训练场景的时空图，显示了数据并行和流水线并行中重叠的通信。B描绘了网络层视图，展示了在两级胖树拓扑中，PP的受害者流如何因同时进行的DP环全局归约通信而遭遇拥塞。C使用两种合成的微基准测试和LLM训练工作负载，比较了Swift和MPRDMA拥塞控制算法的性能。百分比表示Swift相对于MPRDMA的性能提升（绿色）或下降（红色）。

1. 引言

        网络模拟器在评估大规模超级计算集群和数据中心的性能与可行性方面起着关键作用，例如Meta耗资8亿美元的数据中心、瑞士国家超级计算中心的Alps集群或百亿亿次级超级计算机El Capitan。通过创建可配置、可重复的环境来模拟大规模流量模式和工作负载，模拟器允许快速原型设计，并使研究人员和网络架构师能够在无需构建或修改物理基础设施的情况下快速识别潜在瓶颈和性能问题。这种能力对于在部署前设计和优化复杂系统至关重要。

图2. ATLAHS工具链概览。 应用和硬件组件用红色系表示。追踪生成和GOAL格式处理用绿色表示。模拟部分用蓝色表示。为保持一致性，本文所有图表将沿用此配色方案。

        这种虚拟探索在开发和评估新型网络拓扑、协议和标准（如HammingMesh、SMaRTT-REPS和Ultra Ethernet）的有效性时尤为关键。对于无法接触大规模系统的研究人员和实践者来说，模拟器提供了一种实用且经济高效的方法来评估新技术。然而，许多有影响力的网络研究主要依赖合成的微基准测试，如incast和permutation。尽管这些基准测试对于基本评估很有用，但它们通常无法准确代表真实世界的工作负载，可能会忽略关键的性能问题。图1展示了真实的AI训练工作负载如何揭示了Swift拥塞控制算法的缺陷，而仅靠合成基准测试无法捕捉到这些缺陷。虽然Swift和MPRDMA算法在合成基准测试下表现出相当的性能，但使用ATLAHS分析的AI追踪暴露了Swift因其单一的端到端延迟测量方法而在处理多跳拥塞方面的弱点。在检查总迭代时间时，Swift大约慢了4%，其中计算部分掩盖了部分通信开销。然而，即使是轻微的性能下降，在多次迭代中也会显著累积，导致大量的时间和成本效率低下。

        虽然一些论文采用了由真实微服务生成的流量，但这类方法尽管更接近现实，却往往无法捕捉真实流量模式中固有的时间动态性、突发性及相互依赖性。这些局限性可能会掩盖重要的洞见，例如流量之间的相关性或影响网络性能的时变行为。

        因此，我们强调，应用追踪对于发现合成微基准测试可能遗漏的性能问题是不可或缺的。以为网络模拟器生成工作负载的以应用为中心的方法，可以确保评估在实际大规模系统中是稳健可靠的。

        尽管有此需求，许多最先进的网络模拟器缺乏直观的接口来解析和回放真实的应用追踪，通常要求用户实现自定义流量生成器，这显著增加了复杂性和开发工作量。那些提供内置应用追踪支持的基于追踪的模拟器，往往狭隘地聚焦于特定领域，而非支持通用应用。例如，AstraSim和SimAI是专为AI应用量身定制的，而LogGOPSim、PHANTOM和SMPI则局限于HPC领域的MPI应用。因此，一个能提供统一接口以适应广泛应用的模拟工具链，将使研究人员和网络工程师能够进行更彻底、更多样化的性能评估。

        为此，我们介绍ATLAHS（面向AI、HPC及分布式存储的以应用为中心的网络模拟器工具链），这是一个旨在高效追踪和模拟来自多种应用的网络流量的工具链。ATLAHS的概览如图2所示。基于LogGOPSim工具链，ATLAHS利用了组操作汇编语言，该语言提供了计算和通信的统一表示。这使得ATLAHS不仅能为上述领域的应用生成合成的微基准测试和流量，还能为用户提供一个直观的接口来实现他们自己的追踪解析器，从而支持任何应用。

        此外，GOAL促进了多样化工作负载的集成与混合，允许用户轻松调整工作负载布局以模拟多任务和多租户场景。在执行模拟时，ATLAHS解析GOAL文件，调度操作，并根据用户需求灵活选择不同的网络模拟后端。用户可以选择消息级模拟以获得更快的执行速度，或选择数据包级模拟以获得更高的精度。我们针对最先进的AI模拟器AstraSim，在不同后端上验证了ATLAHS的准确性，并通过详细的案例研究展示了其实际用途。这些研究重点说明了ATLAHS如何评估关键因素，例如拥塞控制算法对分布式存储系统性能的影响，以及任务放置策略如何影响应用运行时间。为了促进开放研究并鼓励更广泛地采用ATLAHS，我们公开发布了一个涵盖众多应用、领域和配置的全面追踪集合。

本工作的主要贡献如下：

        (1) 我们开发了ATLAHS，一个开源工具链，强调使用应用追踪而非合成的微基准测试。这种方法捕捉了真实世界工作负载的复杂性和动态性，从而实现了更全面的性能评估。
        (2) 扩展了流行的LogGOPSim工具链的能力，ATLAHS具备多项新颖功能，包括集成AI、HPC、存储工作负载、灵活的模拟后端，以及对多任务和多租户场景的支持。
        (3) 为支持未来研究和可复现性，我们发布了一个涵盖不同领域和配置的全面应用追踪集合，并将其公开提供给社区。
        (4) 通过大量实验，我们验证了ATLAHS工具链在广泛AI和HPC工作负载上的准确性，证明其能持续实现高精度，同时显著优于AstraSim。
        (5) 我们呈现了详细的案例研究，阐明了ATLAHS的多功能性：从分析拥塞控制算法对分布式存储系统的影响，到评估计算集群内不同任务放置策略对应用性能的影响。

2. 背景与相关工作

2.1. 执行追踪格式

        在HPC领域存在多种执行追踪格式。例如，开放追踪格式是一种为高效存储和并行I/O提供特殊支持而设计的追踪格式。它被用于流行的HPC工具中，如Score-P、Scalasca、Vampir和TAU。虽然OTF在模拟器中提供了一定的回放能力，但其复杂性带来了重大挑战，因为它包含服务于不同目的的文件存档。这种复杂性很可能导致其在传统MPI应用之外的领域采用有限，尤其是在AI等领域。

        DUMPI是另一种广泛使用的追踪格式，用于捕获MPI通信事件。它被用于结构模拟工具包和其他模拟器工具链（如ROSS/CODES）中，以模拟和评估HPC系统性能。然而，与OTF类似，DUMPI主要针对基于MPI的HPC应用，使其较难适应非MPI领域。

        值得注意的是，大多数模拟器工具链依赖其自定义的追踪格式，包括PHANTOM、PSINS、BigSim、SMPI和SimGrid。然而，这些格式与其各自的模拟器紧密耦合，并且通常为HPC应用（尤其是基于MPI的应用）设计，进一步限制了它们在更广泛领域的通用性。

        在AI领域，Chakra引入了一种统一的追踪模式Chakra ET，以捕获机器学习应用中的计算和通信。它还支持基于生成式AI的合成以创建工作负载。然而，Chakra与ML特定语义紧密耦合，限制了其灵活性，并排除了对ML领域之外应用的支持，使其无法满足多领域的需求。

图3. A展示了节点0的GOAL调度示例的文本格式，而B展示了同一调度作为有向无环图的可视化。绿色的顶点被分配给计算流0执行，而青色的顶点l3被分配给计算流1执行。

        组操作汇编语言作为一种高级抽象被引入，提供了一种统一的方式来表征分布式和并行系统中的计算和通信工作负载。GOAL定义了三种类型的任务：发送、接收和计算。每个GOAL调度都表示为一个有向无环图，其中顶点代表任务，边定义它们的依赖关系。图3提供了一个简单GOAL调度的示例。用户可以将任务分配给不同的计算流；如果未指定，任务默认使用流0。这种机制能在模拟过程中准确表示并行执行，并促进根据用户指定将工作负载灵活分布到多个处理流上。由于历史原因，计算流使用标签cpu来指代。此外，为了提高存储和执行效率，GOAL调度以紧凑的二进制格式存储和执行。

        我们选择GOAL作为ATLAHS的中间追踪格式，主要有两个原因。首先，GOAL在先前的工作中得到了广泛验证，表明其简单的抽象足以精确建模和模拟网络通信。其次，其通用性使其类似于Java字节码，充当一种通用格式，任何应用的追踪都可以转换为此格式。这种灵活性使用户能够通过实现产生符合GOAL输出的自定义追踪器和解析器，来将ATLAHS扩展到新的工作负载。

2.2. 网络模拟器框架

        多年来，工业界和学术界开发了众多网络模拟器，大致分为数据包级模拟器（跟踪单个数据包的传输）和消息级模拟器（在消息级别抽象通信）。数据包级模拟器通常提供更高的保真度，但会产生显著的计算开销，而消息级模拟器则强调可扩展性和效率。ATLAHS作为一个统一的工具链，支持两种模拟方法，允许用户灵活选择最适合其需求的模拟器类型。本工作中，我们关注广泛采用的模拟器：htsim和NS-3作为数据包级模拟器，LogGOPSim作为消息级模拟器。

        现有模拟器的一个主要挑战是缺乏用户友好的、通用型的工作负载规范机制。每个模拟器（有时甚至是同一模拟器的不同版本）都依赖其自身的工作负载定义方法。例如，NS-3通常要求工作负载直接在C++中定义，这需要深入了解内部组件，并且难以建模复杂的分布式工作负载。虽然一些变体（如HPCC修改版的NS-3）为数据中心工作负载引入了自定义追踪格式，但它们仍然缺乏对表达依赖关系和计算开销的直观支持。这些解决方案通常是为狭窄的用例量身定制的，而不是作为通用工具链的一部分构建的。

        类似地，htsim在其最新版本中允许用户通过C++或连接矩阵文件来定义工作负载。虽然连接矩阵为工作负载规范提供了一种结构化的方法，但它们在表达能力上仍然有限，缺乏对计算建模的支持、高效的操作标记系统以及内置的追踪压缩功能。

        另一方面，LGS是一个消息级模拟器，它在更高层次上抽象通信交互，从而实现高效的大规模模拟。虽然LGS非常适合并旨在用于HPC工作负载，但它缺乏针对更广泛领域（如AI和存储系统）的标准化接口。然而，正如前面第2.1节所解释的，其输入语言GOAL为构建通用解决方案提供了所有必要的构建模块。

3. ATLAHS 工具链

3.1. 追踪收集与 GOAL 生成

        作为一个以应用为中心的工具链，ATLAHS 旨在高效地追踪应用程序并生成其对应的 GOAL 调度。默认情况下，它支持对来自三个关键领域（AI、HPC 和分布式存储）的应用进行追踪和 GOAL 生成，因为这些领域主导了现代 HPC 集群和数据中心的工作负载。在以下章节中，我们将详细解释如何为这些领域的应用收集追踪并将其转换为 GOAL 文件。

3.1.1. HPC

        鉴于 ATLAHS 扩展了最初为 HPC 应用设计的 LGS，我们首先讨论此领域，以便为 GOAL 生成过程提供背景。值得注意的是，在 HPC 和科学计算领域，MPI 仍然是最主流和最便捷的编程模型之一。因此，MPI 应用以及混合 MPI 与 OpenMP 的应用是这类重要工作负载支持的主要编程模型。

        MPI 程序使用一个名为 liballprof 的轻量级追踪库进行追踪，该库依赖 PMPI 接口来记录 MPI 操作、其参数以及每个操作的开始和结束时间戳。通过分析连续操作时间戳之间的差异，调度生成器 Schedgen 推断出在它们之间执行的计算量。此外，Schedgen 根据用户规范，将集体 MPI 操作替换为相应的点对点算法，从而在模拟中实现更大的灵活性。该过程的详细解释和示例可在中找到。

3.1.2. AI

图 4. 一个具有 2 个节点和 4 个 GPU 的 AI 应用示例，这些 GPU 以环状连接，每个 GPU 与其指定的接收器通信（如箭头所示）。NCCL 使用单个流多处理器来处理通信操作。使用 NCCL Simple 协议时，当 GPU 0 作为根节点广播 2 MB 数据时，数据被分成 4 个块并顺序传输。

图 5. 一个展示大规模分布式 AI 应用生成 GOAL 文件的 4 个阶段的示例。

        为了支持 AI 应用的 GOAL 生成，我们主要针对 NVIDIA 集合通信库，原因主要有两个。首先，NVIDIA 的硬件和软件栈占据了 AI 训练市场 90% 以上的份额，使得 NCCL 成为大多数 AI 工作负载中事实上的集合通信库标准。其次，与 AMD 的 RCCL 和 Intel 的 oneCCL 等替代方案相比，NCCL 提供了更成熟的工具和分析器生态系统，这显著加速了我们的开发。请注意，ATLAHS 并不局限于 NCCL，因为通过实现兼容的 GOAL 生成器，可以轻松支持来自其他 CCL 的执行追踪。

        鉴于 NCCL 的复杂性以及涉及的众多组件和配置参数，我们将 GOAL 生成过程构建为四个阶段，如图 5 中的示例所示。这种结构化的方法确保了模块化设计，使其更易于适应和扩展。

阶段 1

        NCCL 和 CUDA 编程涉及多个层次和粒度的操作，其中 CUDA 流是第一级并行执行。CUDA 流是在 GPU 上按顺序执行的一系列操作。通过利用多个流，开发者可以重叠操作，实现并发执行。因此，我们 GOAL 生成过程的第一步是识别执行的内核，确定其精确的执行时序，并建立它们之间的依赖关系和并行性。

        为实现此目标，我们使用 NVIDIA 的性能分析工具 Nsight Systems 来分析 AI 应用运行时期间的 GPU 流活动。它会生成详细的 nsys report 文件，捕获每个流和 GPU 的操作。然而，默认输出中缺少诸如 NCCL 内核使用的通信器等关键细节。为了解决这个问题，我们修改了 NCCL 以添加 NVTX 注释，从而能够收集这些信息供后续使用。我们选择 Nsight Systems 而非自定义追踪器或其他替代方案，是因为其精确性、高效性和低开销，这使其成为大规模 AI 工作负载的理想选择。

阶段 2

        在第二阶段，我们遍历每个 GPU 的 nsys report 文件并分析 CUDA 流。由于单个流内的 NCCL 操作必须顺序执行，我们构建一个连接每个 NCCL 操作的链表。然后使用时间戳，推断连续 NCCL 内核之间的计算，类似于 3.1.1 节中讨论的方法。

        为了准确表示由多个 CUDA 流引入的并发性，我们插入计算成本为零的虚拟节点，这些节点连接每个流的操作列表的起始和结束顶点。不同 CUDA 流中的操作被分配不同的标签，确保它们在后续的 GOAL 生成阶段被映射到不同的计算流（计算流的详细信息在第 2.1 节中描述）。这种显式标记使模拟器能够精确地模拟并发操作执行，保留基于 GPU 的工作负载的真实行为。

阶段 3

        阶段 3 是 GOAL 生成过程中最复杂的部分，因为它需要将 NCCL 集合操作分解为发送、接收和计算任务的依赖关系。与 MPI 集合操作不同，NCCL 调度根据 NCCL 配置参数（如通道数量、算法和通信协议，通过 NCCL_MAX_NCHANNELS、NCCL_ALGO 和 NCCL_PROTO 定义）而有显著差异。

        图 4 显示了一个示例，其中由于缓冲区大小限制，一个 NCCL 广播操作被分解为四个顺序发送。如果改用低延迟协议，调度将大不相同。我们系统地分析了各种参数设置下的 NCCL 集合操作，并将得到的调度集成到 ATLAHS 中。由于其复杂性，我们在此省略详细分解；完整的实现可在源代码中获取。

阶段 4

        在最后阶段，通过引入虚拟节点，将来自多个 GPU 的 DAG 合并，形成每个节点的单个 DAG，采用与阶段 2 相同的方法。此步骤可以按照原始系统设置执行，也可以重构 GPU DAG 以探索"假设"场景。例如，假设由 NCCL_ALGO 定义的逻辑拓扑保持一致，来自 8 GPU、2 节点设置的追踪可以被重构，以模拟具有 2 个 GPU 的 4 节点设置。

        一旦指定了 GPU 到节点的映射，我们通过将同一节点上 GPU 之间的发送和接收操作替换为计算顶点来进一步优化 DAG，因为节点内通信不经过节点间网络结构。这些替换的计算成本基于特定 GPU 的分析数据确定。例如，在图 5 中，GPU 0-1 之间以及 GPU 2-3 之间的通信操作被替换为计算顶点。

3.1.3. 存储

图 6. A 概述了应用程序如何与 Azure Direct Drive 交互。B 展示了一个时空图，说明了读取请求所涉及的操作序列。发送和接收显示为绿色虚线块，而计算显示为淡绿色块。该过程从节点联系变更协调服务以确定哪个块存储服务持有请求的数据开始。然后，节点向相应的 BSS 发送请求以检索数据。

        分布式存储系统在底层架构上与 AI 和 HPC 应用有显著不同。存储应用通常运行在云提供商托管的虚拟机上，其中磁盘 I/O 请求被发送到由分布式存储系统支持的虚拟磁盘，该系统专为冗余性和可扩展性而设计。当应用程序发起读取或写入请求时，虚拟化层将其转换为块级操作，存储系统跨多个节点处理这些操作。

        在这项工作中，我们特别关注存储系统内部的网络通信，捕获节点之间的底层数据传输。为了使网络模拟器能够有效评估此类架构的性能，它必须能够模拟各种存储系统组件之间的工作负载和交互。

        作为第一步，我们使用一个构建在 bpftrace 之上的自定义块级 I/O 追踪器来收集任意应用的追踪，bpftrace 是一个基于 Linux eBPF 框架的动态追踪工具。与 blktrace 等传统工具（会产生需要大量后处理的原始低级数据）不同，bpftrace 提供了一个可编写脚本的接口，用于以最低开销实时过滤 I/O 事件。生成的追踪以 SPC 追踪文件格式存储，其中每条记录对应一个 I/O 命令。UMass 追踪库也使用这种格式。

        I/O 请求根据目标存储架构转换为 GOAL 文件。ATLAHS 内置支持 Azure Direct Drive，这是一个由微软开发的块存储系统。图 6 提供了一个简化的概述，除了主机外，还突出了五个关键服务组件：变更协调服务、块存储服务、元数据服务、网关服务和软件负载均衡器。由于篇幅限制，我们请读者参阅微软的公开资源以获取详细描述。由于 Direct Drive 是专有系统，我们基于公开文档做出了假设，完整的实现细节可在我们的开源工具链中找到。

        ATLAHS 为 Direct Drive 提供了原生支持，其灵活且可扩展的框架允许网络架构师通过实现针对其自身系统的自定义 GOAL 生成器，来评估各种各样的分布式存储服务架构。

3.2. 多任务与多租户场景

        为了模拟多任务工作负载（即不同应用被分配到不同节点上并发运行），我们只需在 GOAL 生成期间将每个应用的 GOAL DAG 映射到其专属节点即可，这使得该场景易于建模。

        多租户在云环境中很常见，并且在 HPC 和 AI 系统中日益重要。由于 GOAL 将工作负载表示为有向无环图，它天然支持多租户工作负载的建模。通过合并来自不同应用的 DAG 并引入虚拟顶点（遵循第 3.1.2 节阶段 2 和阶段 4 中使用的方法），ATLAHS 可以模拟共享节点上的并发性，从而能够真实地评估资源争用和通信重叠。

        需要注意的是，虽然这种方法能有效模拟多租户环境下的网络争用，但它并不能完全捕捉虚拟化开销、内存子系统交互或缓存争用效应所带来的复杂性。尽管如此，该方法提供了一种轻量级且实用的方式来近似多租户并分析由此产生的流量模式及其对应用性能的影响。

3.3. 与网络模拟器的集成

图 7. ATLAHS API 及其代码概览。 左图中我们仅标示了 3 个核心操作。

        ATLAHS 的设计目标之一是提供一个灵活的工具链，能够轻松与各种现有网络模拟器集成。为实现此目标，我们通过一个统一的接口抽象掉模拟器特定的细节，该接口处理一组最核心的操作：send、recv、calc，以及一个名为 eventOver 的辅助函数（用于同步模拟时间与 ATLAHS 内部时间）。每个操作都可以针对特定的模拟器后端来实现。此外，一个模拟器特定的初始化函数 simulationSetup 用于配置拓扑、拥塞控制和负载均衡算法等方面。图 7 展示了这种集成机制及其对应的伪代码。

        举例来说，用于 htsim 的完整 ATLAHS 接口大约由 350 行代码组成，大部分用于实现前述的三个核心操作。根据具体的网络模拟器，这可能足以覆盖大多数情况，尽管某些模拟器在运行特定场景时可能需要添加一些边界情况处理。

        使 ATLAHS 能与任何网络模拟器协同工作的一个关键方面是，它需要负责驱动实际的网络模拟器。为此，我们实现了同步机制，以使模拟时间与 ATLAHS 内部时间匹配。我们的方法简单地使用 eventOver 函数向 ATLAHS 通知当前的实时模拟时间（除了报告已完成的实际事件之外）。只要一个网络模拟器能够提供此信息并支持前述操作，那么它就可以轻松地被 ATLAHS 支持。

        我们在 GitHub 上公开发布了 ATLAHS 文档、API 接口和当前的后端集成。

4. 追踪数据集
 

表 1. 发布的来自不同系统配置下各种应用的执行追踪及对应 GOAL 文件摘要。

        真实的应用追踪对于精确的网络模拟至关重要，并已在先前的研究中得到广泛应用。然而，许多追踪仍未公开，或者主要关注集群级的工作流和作业调度，缺乏模拟单个应用流量所需的粒度。为弥补这一差距并促进开放研究，我们在 https://spcl.inf.ethz.ch/Research/Scalable_Networking/ATLAHS/ 公开发布了一个精选的大规模应用追踪集合。该集合包括未处理的追踪文件（例如，nsys report、MPI 追踪）和相应的 GOAL 表示，允许用户进行实验并在需要时将其转换为其他格式。表 1 总结了可用的追踪，我们计划持续扩展此资源库。

5. 验证

        为验证 ATLAHS 的准确性，我们追踪了众多 AI 和 HPC 应用，并将其实测运行时间与不同网络后端的预测结果进行了比较。对于 AI 工作负载，我们还额外将 ATLAHS 与当前用于分布式 ML 系统的 SOTA 模拟器 AstraSim 2.0 进行了比较。虽然我们曾打算纳入与 SimAI 的比较，但在撰写本文时其源代码并未完全公开。此外，由于无法访问 Azure 的 Direct Drive，我们通过下一节介绍的案例研究来展示 ATLAHS 对分布式存储系统的支持。

        我们注意到，对于 htsim，我们以最新的公开版本为起点，但实施了多项改进，以大幅提升其性能，同时减少内存使用。根据我们的测试，复杂追踪的运行时间在改进后减少了 10 倍到 100 倍。由于其更好的性能以及被超以太网联盟采用，我们在验证过程中主要关注 ATLAHS 的 htsim 后端，而非 NS-3。在结果中，我们将使用 LogGOPSim 后端的 ATLAHS 称为 ATLAHS LGS，而将使用 htsim 后端的 ATLAHS 称为 ATLAHS htsim。

图 8. 各种 AI 训练工作负载的实测运行时间与 ATLAHS 和 AstraSim 预测运行时间的比较。 x 轴标签的第三行表示并行策略的配置，其中 TP 代表张量并行，PP 代表流水线并行，DP 代表数据并行，EP 代表专家并行。蓝色条形显示实际测量的运行时间，分解为未重叠的计算时间（深蓝色）和通信/同步时间（浅蓝色）。深蓝色条形上方的百分比表示每个工作负载中未重叠计算的比例，而红色的百分比表示预测误差相对于实测运行时间的百分比。

5.1. 实验设置

        AI 工作负载的追踪是在由瑞士国家超级计算中心运营的 Alps 超级计算集群上收集的。Alps 采用 Dragonfly 拓扑，包含 2,688 个计算节点，每个节点配备四个 NVIDIA Grace Hopper Superchip，通过高带宽的 150 GB/s 互连进行节点内通信，并使用 25 GB/s 单向的 Cray Slingshot 互连进行节点间通信。所有 AI 工作负载均在基于 NVIDIA PyTorch 容器（版本 24.10）构建的容器化环境中执行，运行在 Ubuntu 22.04 和 Python 3.10 上。我们使用了经过修改的 NCCL 2.20.5 版本，并扩展了额外的 NVTX 注释。

        HPC 工作负载的追踪来自 CSCS 管理的专用 188 节点测试平台集群。该 HPC 集群采用胖树拓扑，使用 18 个 Mellanox SX6036 交换机。每个节点配备一个 20 核 Intel Xeon E5-2660 v2 CPU、32 GB DDR3 内存和一个 ConnectX-3 56 Gbit/s 网卡，运行 CentOS 7.3。使用的软件栈包括 MPICH 4.1.2 和 UCX 1.16.0，整个栈及所有应用均使用 GCC 11.4.0 编译。HPC 应用以混合 MPI+OpenMP 配置执行，每个节点运行一个 MPI 进程，辅以 16 个 OpenMP 线程。

        ATLAHS 和 AstraSim 均在配备 AMD EPYC 9654 96 核 3.7 GHz CPU 和 375 GB 内存的专用机器上执行。

        ATLAHS htsim 采用 MPRDMA 作为其拥塞控制机制，每个端口的缓冲容量为 1 MiB，并将 K_Min 和 K_Max 分别设置为队列大小的 20% 和 80%。

5.2. AI

        对于 AI 工作负载，我们主要关注大语言模型的训练，因为这是现代 AI 中最普遍且通信密集的应用之一。此外，LLM 训练利用了多样化的并行策略，使其特别适合全面评估 ATLAHS 的准确性。我们使用 2025 年 2 月 4 日的夜间构建版将 ATLAHS 与 AstraSim 进行了比较。为确保公平评估，AstraSim 的 Chakra 追踪是直接从原始 PyTorch 和 Kineto 追踪生成的，从而保证两个模拟器中的执行模式完全相同。为减少测量波动，我们在收集后续 2 次迭代的追踪之前，先让每个训练工作负载运行 5 次预热迭代。每个实验进行 5 次，呈现的结果是这些试验的平均值。此外，我们计算了未重叠计算的百分比，以量化每个工作负载的通信强度。

        由于 NCCL 操作中的发送和接收是在 GPU 上执行的，我们无法直接使用 Netgauge 等工具获取 LogGOPS 参数，我们根据 Fusco 等人、De Sensi 等人和 Groves 等人的基准测试工作估算了参数值。LogGOPS 参数的最终值为：L=3700, o=200, g=5, O=0, G=0.04, S=0，单位均为纳秒。我们为 AstraSim 设置的参数尽可能模拟了真实的追踪设置；详情可在我们发布的源代码中找到。在整个实验中，我们配置 ATLAHS htsim 以匹配 ATLAHS LGS 使用的这些参数。

图 8 展示了使用 Llama 和混合专家架构的各种分布式训练配置的验证结果。

        尽管我们仔细遵循了所有提供的追踪生成指南，AstraSim 仅成功执行了两种配置，在其他所有场景中（跨不同网络后端）均遇到运行时错误。我们推测这些问题出现的原因是 AstraSim 当前对真实执行追踪的支持主要局限于数据并行工作负载。AstraSim 提供了两个额外的后端：拥塞感知后端和 NS-3 后端。然而，拥塞感知后端目前仅支持一维拓扑，当用于现实的多维拓扑时会产生显著的预测误差，使得公平比较不可行。此外，尝试使用 NS-3 后端始终导致段错误，无法收集有意义的结果。

        我们还注意到，在 AstraSim 成功执行的两种场景中，ATLAHS 在模拟准确性（LGS 和 htsim 均如此）和速度（对于 LGS）方面 consistently 优于 AstraSim。虽然图中未描绘，但与 AstraSim（无拥塞感知后端）相比，ATLAHS LGS 实现了显著更短的模拟时间。具体来说，在 4 节点场景中，ATLAHS LGS 在 5.50 秒内完成模拟，而 AstraSim 耗时 76.63 秒（加速 13.9 倍）。ATLAHS htsim 耗时 180.01 秒，但作为更昂贵的数据包级模拟器，这不具直接可比性。类似地，在 32 节点场景中，ATLAHS LGS 在 232.20 秒内完成模拟，而 AstraSim 耗时 636.87 秒（加速 2.7 倍）。ATLAHS htsim 完成模拟耗时 5100.43 秒。所有报告的结果代表五次独立试验的平均值。

图 9. GOAL 与 Chakra 的追踪大小比较。 每对条形图上方的绿色标签表示 GOAL 相对于 Chakra 的追踪大小比率。

        此外，我们比较了 ATLAHS 和 AstraSim 生成的追踪大小，结果如图 9 所示。我们观察到 ATLAHS 使用的 GOAL 文件 consistently 且显著小于 AstraSim 使用的 Chakra 文件。尽管 Chakra 文件包含额外信息，例如计算内核的数据，但这种额外的存储开销似乎并未带来预测准确性的提升。

        在本节中，我们在 SOTA 超级计算集群的一系列真实 LLM 训练场景下，验证了 ATLAHS 在不同后端上的准确性。此外，我们的结果表明，ATLAHS 在最流行的 AI 系统模拟器之一 AstraSim 的比较中，不仅在模拟准确性、速度，而且在追踪存储效率方面 consistently 表现更优。这些优势凸显了 ATLAHS 作为 AI 工作负载网络性能评估的有效工具链的能力。

图 10. 来自不同领域的 HPC 应用的实测运行时间与 ATLAHS 预测运行时间的比较。 x 轴标签的第二行表示每个实验中使用的进程和节点数量（进程数/节点数）。深蓝色条形内的百分比表示每个工作负载中未重叠计算的比例。上方的红色百分比表示 ATLAHS 相对于实测运行时间的预测误差。

5.3. HPC

        我们使用 Netgauge 测量了 LogGOPS 参数。得到的值为：L=3000, o=6000, g=0, G=0.18, O=0, S=256000。为验证 ATLAHS，我们选择了涵盖广泛科学领域的 HPC 应用，包括天气和气候模拟、流体动力学模拟和分子动力学，并跨越不同的节点配置。对于每个应用和配置，运行时间是 10 次独立试验的平均值，数据集包括弱扩展和强扩展场景。

        图 10 展示了验证结果。值得注意的是，虽然对于 ATLAHS LGS，随着进程和节点数量的增加，预测误差有轻微增大的趋势，但在所有案例和应用中，误差 consistently 保持在 5% 以下。另一方面，ATLAHS htsim 似乎未受到规模增长的负面影响，也始终保持其错误率低于 5%。这表明 ATLAHS 有效地捕捉了不同 HPC 工作负载的基础通信和计算动态，在广泛的应用领域和使用不同后端时均保持了高精度。

6. 案例研究

        本节实验旨在展示ATLAHS在AI、HPC及存储应用中的不同功能。此外，我们也将重点关注不同ATLAHS后端的优势与不足。

6.1. 拥塞控制对分布式存储请求的影响

图 11. 不同拓扑及运行不同拥塞控制算法下存储流量的消息完成时间比较。

        我们现在展示一个与第3.1.3节描述的存储流量和Direct Drive架构相关的ATLAHS用例。具体来说，我们模拟了由UMass数据集的金融分布生成的5千次存储操作。我们在ATLAHS htsim中比较了两种拥塞控制算法：MPRDMA（一种基于发送端的算法，类似于DCTCP但基于逐数据包操作）和NDP（一种基于接收端的算法）。为了比较，我们采用了两种相似的胖树拓扑：一种是全供给网络，另一种在Tor交换机和核心交换机之间存在8:1的超额订阅比。在全供给拓扑中，两种算法表现相似；然而，在超额订阅的情况下，NDP的性能显著下降，平均消息完成时间增加了14%，第99百分位数和最大MCT分别上升了35%和77%。这种性能下降是因为NDP以及通常的基于接收端的算法，难以处理远离接收端发生的网络内拥塞，这在超额订阅条件下尤为明显。NDP的作者承认了这些问题，并且近期的工作尝试结合基于发送端和基于接收端的算法以利用两种方法的优势。

        这个例子说明了ATLAHS对于网络工程师的众多潜在应用之一。然而，由于ATLAHS生成的追踪是通用的GOAL格式，我们设想的用例可能也会超越纯网络应用或我们在本文中设想的范围。

6.2. ATLAHS LGS 对比 ATLAHS htsim

        在第5节中，我们观察到在所有实验中，ATLAHS LGS和ATLAHS htsim的性能大体相当，彼此差距在1-2%以内。这只有在满足一系列使ATLAHS LGS表现出色的假设条件下才可能实现：我们考虑的拓扑是全供给且对称的，计算组件通常能很好地"掩盖"网络低效，集合通信的设计限制了incast场景，并且我们假设没有因数据损坏或故障导致的数据包丢失。

        如果这些假设不成立，ATLAHS LGS可能会在不同程度上难以提供准确的预测。例如，在图12中，我们通过首先在相同的全供给拓扑上模拟Llama 7B，然后在ToR和核心交换机之间具有4:1超额订阅的拓扑上进行模拟来展示这一点。由于ATLAHS LGS无法支持任意拓扑，我们对两种配置都设置 G=0.04，因为即使超额订阅拓扑中可用的上行链路较少，理论注入带宽也未改变。这自然会导致准确性下降，因为ATLAHS LGS感知不到从ToR到核心交换机可用带宽的减少。如图12左侧所示，我们观察到，在没有超额订阅的情况下，两者都表现良好，彼此差距在1%以内。然而，当运行4:1超额订阅拓扑时，差异跃升至120%以上。这是由于拥塞的上行链路上发生了显著的数据包丢失（在图12右侧可视化），这严重延迟了消息传递并拉长了总运行时间。

图 12. 使用不同网络拓扑时，ATLAHS LGS 和 ATLAHS htsim 运行时间的比较。 右图展示了一种只有数据包级模拟器才能提供的可能统计量（数据包丢失）。

        此外，使用数据包级模拟器使网络工程师能够收集细粒度的细节，例如总丢包数、全面的公平性统计数据和队列稳定性指标等。只有这种详细的分析，才能实现如第6.1节中针对存储所呈现的分析。然而，这并不削弱ATLAHS LGS的价值。如前所述，它在理想条件下能够提供高精度，并且即使在其理想参数范围外运行，它也能提供一个有用的近似值，并具有比数据包级模拟器快得多的显著优势（在大多数情况下，ATLAHS LGS比ALTAHS htsim快10-50倍）。

6.3. HPC集群中作业放置的影响

        如第3.2节所讨论的，ATLAHS还提供了使用多种分配策略将来自不同应用的不同追踪合并在一起的可能性。

        为展示此能力，图13展示了一个AI应用（Llama）和HPC应用（LULESH）共享一个集群的场景。我们使用前一个例子中相同的超额订阅拓扑，并使用ATLAHS的htsim后端评估两个工作负载。在"紧凑分配"策略中，节点按顺序分配给每个作业，保持通信主要在本地，并最小化核心网络的使用。相反，在"随机分配"策略中，节点分配不考虑局部性，增加了节点间距离和超额订阅核心的负载。结果，Llama在随机分配下的运行时间增加了36%。LULESH受到的影响较小，这是由于其未重叠的计算量有限，如图10所示。这个例子突显了不仅模拟单个应用，而且模拟完整执行流水线（包括作业放置、拓扑感知和后台干扰）的价值。

图 13. 同时运行两个应用（Llama 和 LULESH）时，不同作业分配策略的运行时间比较。

7. 讨论与扩展

        目前ATLAHS范围之外的一个方面是详细的硬件模拟，例如对GPU计算内核及涉及内存子系统的交互进行建模，这是AstraSim具备的功能。此排除是一个深思熟虑的设计选择，旨在优先考虑网络模拟的效率。正如我们的验证结果所示，将非通信任务简单地表示为通信事件之间的calc操作，足以实现网络工作负载的精确运行时间估计。ATLAHS允许用户通过应用从两个系统性能剖析得出的缩放因子，来调整从一个硬件平台收集的追踪，以模拟另一个平台。具体来说，用户可以测量相对性能差异，并相应地缩放所有calc值，以近似不同硬件上的计算。

        ATLAHS有几个方面可以从进一步的改进中受益。首先，当从NCCL追踪生成GOAL文件时，目前未捕获跨流的CUDA内核之间的数据依赖性。这种简化可能导致与计算和通信重叠相关的不准确性，尽管网络通信指标仍然是准确的。未来的工作将通过在GOAL生成期间显式地建模CUDA内核依赖关系来解决这个问题。

        由于GOAL格式的特性，ATLAHS目前不支持动态调度的通信操作。尽管我们的验证表明，此限制对模拟基于NCCL的工作负载的准确性影响不大，但它可能对大规模图神经网络训练、Charm++等编程框架或分布式存储系统中的容错协议构成挑战，因为这些场景的通信模式本质上是动态的。在未来的扩展中，我们旨在通过纳入动态调度能力来增强GOAL，从而使ATLAHS能够支持更广泛的应用和场景。

8. 结论

        在这项工作中，我们介绍了ATLAHS，一个以应用为中心的模拟工具链，旨在弥合AI、HPC和分布式存储系统中真实工作负载建模与网络性能评估之间的差距。通过支持基于GOAL格式的追踪模拟，ATLAHS能够精确建模多种真实应用的通信和计算模式。我们的工具链是高度模块化和灵活的，支持多种网络模拟后端，并为多任务和多租户场景提供内置支持。我们在多样化的LLM和HPC工作负载上验证了ATLAHS，证明了其持续的高模拟精度（误差低于5%），同时在运行时间效率和追踪大小方面均优于AstraSim等SOTA框架。

        除了验证，我们通过详细的案例研究展示了ATLAHS的实用性。这些研究重点说明了拥塞控制算法如何影响大规模分布式存储系统的性能，以及作业放置策略如何影响共享计算集群的性能。这些见解强调了ATLAHS不仅作为一个模拟框架，而且作为研究人员和系统架构师在真实工作负载下优化现实世界大规模系统的实用设计和性能评估工具的价值。

        通过发布ATLAHS以及大量的应用追踪集合，我们希望促进更广泛的社区参与并推进网络性能评估的研究。我们希望ATLAHS能使研究人员和实践者能够进行更准确、更真实的模拟，最终指导更高效的大规模系统的网络设计。

9. 致谢

        本项目获得了欧洲研究理事会根据欧盟地平线2020研究与创新计划（赠款协议PSAP，编号101002047）提供的资金。我们也感谢瑞士国家超级计算中心为本工作提供的计算资源。作者使用了ChatGPT-4o和4.5来协助整个手稿的轻度编辑和校对。所有内容和思想均为作者的原创工作。