LLaMA 3 背后的大规模 GPU 集群 RoCE 网络建设

程序学到昏

于 2024-08-22 20:27:22 发布

阅读量894

点赞数 21

文章标签： llama langchain 人工智能 prompt 大数据 Agent 开发语言

本文链接：https://blog.csdn.net/y525698136/article/details/141437329

版权

模型越来越大，需要的 GPU 越来越多；与此同时 GPU 性能也在不断增强，配套的网络带宽也不断增加到 400G（Blackwell GPU 甚至需要到 800 Gbps）。Ranking 模型还在迁移到 GPU 的早期阶段，但使用 GPU 的规模也在不断增加；而 LLM 通常需要使用更大规模 GPU。在构建这种规模的网络的同时保持高性能 GPU 间通信很有挑战。
Meta 在其 LLaMA 3 技术报告中简单提到用于训练 LLaMA 3 的大规模 GPU 集群，不过在报告中并没有详细介绍其集群的构成以及相应的网络解决方案。Meta 最近发布了相应的 Paper，我们这里进行简单介绍。
对应的论文为：Proceedings of the ACM SIGCOMM 2024 Conference: RDMA over Ethernet for Distributed Training at Meta Scale对应的 Meta Blog：RoCE networks for distributed AI training at scale - Engineering at Meta

02摘要

近年来，AI 模型的计算密度和规模都快速增长，推动了高效、可靠的专用网络基础设施的建设。本文中，Meta 作者介绍了其用于分布式 AI 训练的 RoCE 网络设计、实现和运维。
其设计原则涉及对工作负载的深刻理解，作者将这些间接转化为各种网络组件的设计：

网络拓扑：为了支持几代 AI 硬件平台的快速演进，将基于 GPU 的训练分离到自己的后向网络中。
路由：训练工作负载本身就会导致负载不均衡和流量突发，因此作者部署了多次迭代的路由方案，以实现接近最优的流量分布。
传输：解释了最初如何尝试使用 DCQCN 运行拥塞管理，不过后来放弃了 DCQCN，转而利用集合通信库来管理拥塞。
运维：作者分享了大规模 AI 网络运维的经验，包括开发的工具和故障排查示例。

03 引言

3.1 IB & RoCEv2

RDMA 是一种硬件辅助通信加速的行业标准，RDMA 实现了 “verbs” API，比如读和写（可以参考：RDMA Verbs API - NVIDIA Docs）。与基于 TCP/IP 的通信不同，基于 TCP/IP 的通信中，数据包需要先发送到内核，然后再复制到 CPU 内存中，而 RDMA 绕过了发送方和接收方的内核，直接从应用进程内存中传递数据。如下图所示：
在这里插入图片描述

如下图所示为几种常见的 RDMA 方案，现在比较常见的是 IB 和 RoCEv2：

IB 是 NVIDIA 提供的一种专用的高性能计算网络技术，具有专用的网络架构和硬件设备，IB 使用专用的 InfiniBand 协议栈，包括物理层、链路层、网络层和传输层，专门设计以优化高性能计算和低延迟通信。
RoCEv2 是一种在标准以太网基础上实现 RDMA 的协议，RoCEv2 使用常见的以太网交换机和网卡，因此更容易与现有的以太网基础设施集成。

在这里插入图片描述

RDMA verbs 消息封装在以太网/IPv6/UDP 数据包中，并通过常规以太网络进行传输，打包/解包封装在 RDMA NIC 硬件中处理。如下图所示为对应的 RoCEv2 Packet Format：
在这里插入图片描述

3.2 集合通信（Collective Communicatin）

集合通信库（如 NCCL）充当训练工作负载和 NIC 之间的软件抽象，通过 verbs API 层提供接口。它将集合通信原语（如 AllReduce）转换为逻辑拓扑实现（如 Ring 或 Tree），并进一步将这些分解为 GPU 之间基于 verbs 的 P2P 数据传输。这些传输需要 GPU-to-RDMA NIC 支持。集合通信库在源和目标 NIC 之间创建的队列对（Queue Pairs, QP）协调 verbs 调用。例如，NCCL 使用 RDMA 写入操作实现所有集合算法和 P2P 语义（具体可以参考 NCCL 的 ISSUE why uses rdma write for default ib traffic · Issue #609 · NVIDIA/nccl · GitHub）。
如下图 Table 1 列出了主要集合通信原语的特点以及每种集合通信的要求：

首先：集合通信原语由并行策略决定。比如，分布式数据平行（DDP**）使用 AllReduce；FSDP 使用 AllGather 和 ReduceScatter；Ranking 模型（例如 DLRM）使用 AlltoAllv（矢量化的 AlltoAll）来为模型并行分发 Embedding。
其次：集合通信原语可以生成多种网络流量模式。比如 AlltoAll 在所有 endpoint 之间形成 Full Mesh 流量模式，可能导致高度暂时性的网络拥塞。然而，它的高活跃流量简化了路由，可以使用哈希方案降低持续拥塞风险。
最后：集合通信原语选择的逻辑拓扑会影响 GPU 之间的网络拥塞和数据交换。与 Tree 方案相比，基于 Ring 实现的 AllReduce 具有独特的拥塞和哈希冲突含义。NCCL 会根据 GPU 数量和 Message 大小等因素优化相应选项。然而，这种方法也有局限性，比如，由于硬编码配置文件导致的潜在不确定性、某些消息大小或大型作业的性能不佳，以及一些实现中集合通信算法的不相关性。

在这里插入图片描述

3.3 训练工作负载

为了了解生成环境中实际的工作负载，作者利用 Chakra（[2305.14516] Chakra: Advancing Performance Benchmarking and Co-design using Standardized Execution Traces）收集了 2023 Q4 期间大约 30K 个随机选择的训练任务的集合通信数据。如下图 Figure 1:

（a）Job 大小趋势：这里主要是分析 GPU <= 128 的情况，也就是不包含大规模的 LLM Job。可以看出，Job 的 GPU 数通常是 8 的整数倍，这是因为单机 8 个 GPU，此外，作者也不推荐使用小于 8 卡运行（PS：小于 8 卡确实容易导致碎片化问题，但是有些小型任务也确实没必要使用 8 卡 H100，不过也许 Meta 有 A100 集群，可以让小型任务跑在 A100 上）。
（b）通信类型分布：基于 DDP 的任务中，AllReduce 和 AlltoAll(v) 占绝大部分；基于 FSDP 的任务中，会额外多了一些 AllGather 和 ReduceScatter。

在这里插入图片描述

如下图 Figure 2 所示为不同模型中各类通信原语实际通信 Message 大小（通信的元素数量）的分布，可以看出，不同模型的 Message 大小变化很大：
在这里插入图片描述

每个集合通信操作中 GPU 数量的趋势：无论是 Ranking Job，还是 LLM Job，每个集合通信操作中 GPU 的数量并没有与 Job 大小以相同的速度增长。这是因为在大规模训练中会使用多维并行策略，这有助于限制最大集合通信操作中 GPU 的数量，即使运行的 Job 中有成千上万个 GPU。因此，本文中的其他部分主要关注涉及 16-128 个 GPU 的集合通信操作。

3.4 Shallow Buffer Switch & Deep Buffer Switch

在网络交换机设计中，缓冲区（Buffer）是用来临时存储数据包的内存区域，通常用于应对网络流量高峰或者临时的拥塞情况。根据缓冲区大小的不同，交换机可以分为浅缓冲交换机（Shallow Buffer Switch）和深缓冲交换机（Deep Buffer Switch）。

Shallow Buffer Switch

小缓冲区：每个端口通常配置有相对较小的内存缓冲区（例如几百 KB 到几 MB）。
低延迟：由于缓冲区较小，浅缓冲交换机通常具有较低的转发延迟，适合延迟敏感的应用场景。
适用场景：浅缓冲交换机通常用于低延迟、高性能的环境中，当网络流量相对稳定且网络拓扑设计良好时，浅缓冲交换机的性能表现良好。

Deep Buffer Switch

大缓冲区：每个端口配置了较大的内存缓冲区（可以达到几十 MB 甚至更多），能够存储大量的数据包。
高缓冲能力：深缓冲交换机在面对突发流量或持续拥塞时，可以有效防止数据包丢失，因为其缓冲区能够在网络拥塞期间存储更多的数据包。
适用场景：深缓冲交换机适合那些存在大量突发流量或复杂流量模式的环境，如数据中心的边缘路由、以及需要应对突发流量的大规模分布式系统。

比如 NVIDIA 的 SN4000 系列以太网交换机都是 64MB 的 fully shared buffer（https://nvdam.widen.net/s/6269c25wv8/nv-spectrum-sn4000-product-brief）如下图所示；而最新的 SN5000 系列也只有 160MB 的 fully shared buffer。

在这里插入图片描述

而 ARISTA** 的 7800R3 系列交换机都采用 Deep packet buffer，最多可以达到 24GB/line（7800R3 Series Data Center Switch Router）
在这里插入图片描述

3.5 DSCP-based PFC

在传统的以太网中，流量拥塞时会导致数据包丢失，从而影响网络性能。为了解决这个问题，出现了优先级流控（PFC, Priority Flow Control），它通过暂停某些优先级的流量来防止拥塞，但PFC 是基于端口优先级（CoS, Class of Service）进行控制的。
DSCP 是一种在 IP 头中用于标识 IP 包优先级的字段。通过在 PFC 中引入 DSCP 字段，网络设备可以根据 IP 数据包中的 DSCP 值来识别不同的流量类别，并根据这些类别实施更加细粒度的流量控制策略。
相比传统的基于 CoS 的 PFC，DSCP-based PFC可以实现更精确的流量分类与管理，因为DSCP 字段的范围更广，可以定义更多的优先级和流量类别。因此，DSCP-based PFC 允许网络管理者在处理流量拥塞时，针对不同的流量类型采取不同的流控策略，避免对关键应用的影响，同时确保其他低优先级的流量不会完全丢失。

如何系统的去学习大模型LLM ？

大模型时代，火爆出圈的LLM大模型让程序员们开始重新评估自己的本领。 “AI会取代那些行业？”“谁的饭碗又将不保了？”等问题热议不断。

事实上，抢你饭碗的不是AI，而是会利用AI的人。

继科大讯飞、阿里、华为等巨头公司发布AI产品后，很多中小企业也陆续进场！超高年薪，挖掘AI大模型人才！ 如今大厂老板们，也更倾向于会AI的人，普通程序员，还有应对的机会吗？

与其焦虑……

不如成为「掌握AI工具的技术人」，毕竟AI时代，谁先尝试，谁就能占得先机！

但是LLM相关的内容很多，现在网上的老课程老教材关于LLM又太少。所以现在小白入门就只能靠自学，学习成本和门槛很高。

针对所有自学遇到困难的同学们，我帮大家系统梳理大模型学习脉络，将这份 LLM大模型资料 分享出来：包括LLM大模型书籍、640套大模型行业报告、LLM大模型学习视频、LLM大模型学习路线、开源大模型学习教程等, 😝有需要的小伙伴，可以 扫描下方二维码领取🆓↓↓↓

👉CSDN大礼包🎁：全网最全《LLM大模型入门+进阶学习资源包》免费分享（安全链接，放心点击）👈

一、LLM大模型经典书籍

AI大模型已经成为了当今科技领域的一大热点，那以下这些大模型书籍就是非常不错的学习资源。

在这里插入图片描述

二、640套LLM大模型报告合集

这套包含640份报告的合集，涵盖了大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示。(几乎涵盖所有行业)

在这里插入图片描述

三、LLM大模型系列视频教程

在这里插入图片描述

四、LLM大模型开源教程（LLaLA/Meta/chatglm/chatgpt）

在这里插入图片描述

LLM大模型学习路线 ↓

阶段1：AI大模型时代的基础理解

目标：了解AI大模型的基本概念、发展历程和核心原理。
内容：
- L1.1 人工智能简述与大模型起源
- L1.2 大模型与通用人工智能
- L1.3 GPT模型的发展历程
- L1.4 模型工程
- L1.4.1 知识大模型
- L1.4.2 生产大模型
- L1.4.3 模型工程方法论
- L1.4.4 模型工程实践
- L1.5 GPT应用案例

阶段2：AI大模型API应用开发工程

目标：掌握AI大模型API的使用和开发，以及相关的编程技能。
内容：
- L2.1 API接口
- L2.1.1 OpenAI API接口
- L2.1.2 Python接口接入
- L2.1.3 BOT工具类框架
- L2.1.4 代码示例
- L2.2 Prompt框架
- L2.3 流水线工程
- L2.4 总结与展望