Skip to main content
开放网络的先行者与推动者—星融元
加入我们技术支持(Support)  TEL:(+86)4000989811

标签: 技术实现

一文揭秘AI智算中心网络流量 – 数据存储篇


关注星融元


本篇为“揭秘AI智算中心网络流量“系列的第三篇,前篇请参阅:


01、生成式AI对数据存储有哪些需求?

对于较小规模的AI模型,本地连接的磁盘存储可能就足够;进入大模型时代,则通常需要基于对象存储或并行文件系统的共享存储。一个完整的生成式AI的工作流的各阶段对存储有不同需求,具体可拆解如下:

  • 数据挖掘:需要从多个来源收集非结构化的数据,一般与混合云集成,用数据湖作为存储平台;
  • 数据准备:进行数据汇总、标准化和版本控制,关注存储的效率和灵活的数据管理能力,多采用统一存储平台;
  • 模型训练和微调:在智算中心内部,结合GPU服务器本地内存和远端的并行/分布式存储系统。因为GPU的投入巨大,需要高性能存储来高效地提供数据,并在整个过程中保持高利用率;
  • 推理阶段:该阶段旨在利用已训练好的模型实时生成输出,需要将输入模型和推理生成的文字/图片/视频流存储下来作为备份。

02、智算中心的存储网络

我们大致可将AI智算中心内部的数据存储系统进行简单的层次分类,主要包括GPU内存、存储网和存储设备。

| 图片引自 NVIDIA技术博客

| 图片引自 NVIDIA技术博客

一般来说,在存储层次结构中位置越高,其存储性能(尤其是延迟)就越快。因为本文的定位在分析网络流量,我们将聚焦于存储网络(data fabric)层次,即智算中心内部GPU服务器内存与远端存储服务器之间传输的数据

在一个计算和存储分离的部署场景中,一般推荐部署2张Spine-Leaf架构的物理网:前端网和后端网。其中,存储前端网和业务网共用一张物理网。

存储后端网则单独使用一张物理网,以保证分布式存储集群能够快速无阻塞地完成多副本同步、故障后数据重建等任务。存储节点对网络接入侧的可靠性要求相对较高,因此推荐使用双归(MC-LAG)或者多归(EVPN-Multihoming)接入。

存储网络流量主要发生在模型训练的场景,它是一种单播流量,逻辑上仅需要以存储服务器为中心的星型连接。

  • 一是从存储服务器中分批加载训练数据集到GPU内存。
  • 二是训练的中间结果(定期保存的参数和优化器状态,即Check Point)要在存储服务器共享,并通过网络读写。

⑴ 数据集加载流量分析

在一个epoch中,整个训练集被遍历一次,如果进行评估,验证集也将被遍历一次。以下假设在每个epoch中进行评估,整个数据集的存储大小为D。

  • 数据并行时,整个数据集从网络存储读取,通过scatter操作分别加载到不同的GPU上,总网络流量为D。
  • 张量并行时,整个数据集从网络存储读取,通过broadcast操作发送给所有GPU,总的网络流量为 D x G。
  • 流水线并行时,整个数据集从网络存储读取,喂给流水线上第一个GPU,总网络流量为D。
  • 3D并行时,整个数据集从网络存储读取,在数据并行维度上分配,在张量并行维度上广播,总网络流量为D x G(tp) 。

以C4数据集为例,数据集的大小约38.5 TB,假设张量并行GPU数量为8,3D并行时每个epoch中加载数据集产生的网络流量为308TB

⑵ Checkpoint存储流量分析

Checkpoint中存储了模型参数、优化器状态和其它训练状态(包括模型配置、训练的超参数、日志信息等)。优化器包含了梯度、动量和二阶矩估计等,每一种数据大小都等于模型参数。其它训练状态的大小可以忽略不计。假设模型参数为P,数据格式为BFLOAT16,优化器为Adam/AdamW,则checkpoint总大小为:

2 x P + 2 x P x 3 = 8 x P

这个checkpoint要保存在存储服务器中,虽然在张量并行、流水线并行和3D并行时,这些数据从多个GPU上通过gather操作汇聚到存储服务器,但无论如何,数据总量是一个checkpoint大小。假设每个epoch存储一次。这样,每个epoch产生的流量为:

8 x P

以Llama3-70B模型为例,假设每个epoch均存储,则产生的网络存储流量为560GB

03、存储网设备选型:RoCE还是InfiniBand

相比训练场景,在智算中心存储网传输的流量与并行计算完全不在一个量级——虽然对链路带宽要求不那么高,但仍需满足高速分布式存储业务中所需的高吞吐、低时延、无损传输特性,并灵活满足存储集群规模调整所需的高可扩展性。

NVIDIA DGX SuperPOD™ 的方案在存储网采用的是200G的InfiniBand交换机。而事实上,随着近年来AI以太网技术的进步,RoCE与IB在转发时延上的细微差异,对分布式存储业务性能几乎没有影响。结合科学的网络参数调优,我们已在多个客户现场稳定测得了运行RoCEv2协议的交换机端到端性能全面优于IB交换机的结果。RoCE交换机作为IB平替已是不争的事实。

星融元 CX664P-N 是一款专为智算/超算中心设计的超低时延RoCE交换机,凭借以下特性在存储场景中脱颖而出。

型号为CX564P-664D-N数据中心交换机产品图

CX664D-N— 业务接口:64 x 200GE QSFP56, 2 x 10GE SFP+

  • CX-N系列一贯的超低延迟特性,端到端性能可媲美IB*(*测试数据详见方案手册)
  • 12.8Tbps 的线速 L2/L3 交换性能,提供高密度 200G/100G 以太网接口,满足主流存储网络需求并兼顾未来升级空间;另有两个 10G 端口用于管理网接入
  • 支持基于 RDMA 的 NVMe-oF (全端口标配RoCEv2)和EVPN-Multihoming → 什么是EVPN多归属,和MC-LAG的区别?
  • 搭载持续进化的企业级SONiC——AsterNOS网络操作系统,其开放的软件架构通过REST API开放全部网络功能给AI智算中心管理系统,实现无损以太网的自动化极简部署 → Easy RoCE:一键启用无损以太网

除存储网之外,基于通用、解耦、高性能的以太网硬件和开放软件框架,星融元可为大模型算力中心提供10G-800G的全场景互联能力。

一文揭秘AI智算中心网络流量 – AI推理篇


关注星融元


本篇为“揭秘AI智算中心网络流量“系列的第二篇,前篇请参阅:一文揭秘AI智算中心网络流量 – 大模型训练篇 。有关数据存储流量的分析将于下篇呈现,敬请关注。

AI推理是指从经过训练的大模型中获取用户查询或提示的响应的过程。

为了生成对用户查询的完整响应,AI推理服务器从一次推理迭代中获取输出token,将其连接到用户输入序列,并将其作为新的输入序列反馈到模型中以预测下一个token。这个过程被称为“自回归”计算,此过程重复进行,直到达到预定义的停止标准。

自回归

AI推理系统如何生成一次完整的响应?

⑴ 预填充/提示(Prefill):模型从用户那里获得输入序列。基于此输入,模型预测第一个输出token。

⑵ 解码(Decode):将生成的输出token连接到输入序列。更新后的输入序列被反馈到经过训练的模型中,然后生成下一个token。

⑶ 循环:解码继续进行,每个新token都是基于所有先前token的累积序列生成的。这种将输出token自回归地馈送到输入的过程确保模型在每个步骤的输出都受到所有先前token的影响,从而使其能够保持上下文和连贯性。

⑷ 终止:当模型达到停止标准时,它会终止该过程。停止标准可以是以下之一。

  • 最大序列长度:一旦达到总token(输入和输出)数量的定义限制
  • 序列结束 (EOS) :模型生成一个特殊token,表示文本生成的结束。
  • 上下文完成:当模型确定生成的文本已根据提供的上下文得出自然且合乎逻辑的结论

AI并行推理网络流量分析

由于在预填充阶段已知整个token输入序列,因此推理加速器可以并行计算所有输入token的信息,并执行模型来预测下一个输出token。

在大模型推理时,虽然模型经过了压缩(比如4bit量化),但模型尺寸仍可能超过单个GPU的内存,这时候就需要张量并行,即使单个GPU可以容纳整个模型,张量并行可以加速推理过程。如果并发用户数较大,单个GPU来不及及时响应,就需要数据并行

让我们再次回顾AI推理的两个关键阶段:

  1. 预填充(Prefill)阶段根据用户输入的prompt,生成输入token序列,并进行批处理,计算KV(Key, Value)缓存,并生成第一个输出token。这个阶段可以认为是大模型在理解用户输入,KV缓存存储了输入序列的上下文信息(为下面的Decode阶段缓存),其特点是需要大量的计算。
  2. 解码(Decode)阶段是一个循环过程,根据之前生成的token序列和KV缓存,计算下一个token,直到生成完整的输出。这个阶段可以认为是大模型在一个字一个字的说话。由于KV缓存的密集型计算已在 Prefill 阶段完成,因此此阶段仅处理上一阶段新生成的 token。因此,计算密集程度较低;但这一步需要从 KV缓存中读取前面所有token的Key,Value,所以需要高速的内存访问。

由于以上两个阶段对GPU的需求不同,我们可以采用Prefill-Decode解耦的方式,由2个不同类型的GPU分别承担Prefill和Decode阶段的计算任务,顺序执行。这时候就需要在两个阶段间传输KV缓存。

在生产部署时,通常结合上述几种方式。相比AI训练,AI推理只有前向传播过程,计算量相对较低,但需要快速的生成下一个token。流量产生有两个来源:

  1. 每次推理在Prefill GPU和Decode GPU之间传递KV缓存;
  2. Prefill GPU集群和Decode GPU集群分别实施张量并行,产生的中间激活的传递。不会有巨量的梯度同步流量。

假设并发用户数为U,数据并行维度为G(dp),张量并行维度为G(tp),用户输入序列的平均长度为S(in)个token,模型产生输出的平均长度为S(out)个token。

在张量并行时,前向传播产生了GPU间的网络流量,各个GPU计算出的中间激活值需要合并,由all-reduce操作进行求和。

假设模型有L层,在一次推理过程中,S(in)个输入token在模型的每一layer进行2次批量合并,共2L次,而对于每个输出Token,在模型的每个layer的中均进行2次合并,共 2xS(out) x L 次。此外,在Prefill阶段和Decode阶段之间有一次KV缓存的传递。AI并行推理网络流量如下图所示:

假设模型的隐藏状态大小为H,GPU数量为G,计算激活使用的数据格式为FLOAT16(2个字节表示一个数),每次all-reduce操作的通信量为

2 x H x (Gtp-1)x Gtp

在Prefill阶段,所有输入Token,在模型的每个layer的中均进行2次批量合并,共2xS(in)xL次。在Decode阶段,对于每个Token,在模型的每个layer的中均进行2次合并,共2xS(out)xL次。因此,U个用户的并发推理,中间激活值的总网络流量为

4 x U x(Sin+Sout)x L x H x (Gtp-1)x Gtp

另外,在一次推理中,KV缓存的大小为

4 x Sin x L x H

因此,U个用户的并发推理,KV缓存传递的网络流量为

4 x U x Sin x L x H

以Llama3-120B模型为例,模型层数140, 隐藏状态大小8192,张量并行度为4,用户prompt的平均长度S(in)为256个token,产生的输出的平均长度S(out)为4096个token。则要支持100个并发用户请求所需要的推理流量为:

4 x 100 x (256 + 4096)x 140 x 8192 x (4-1)x 4 + 4 x 100 x 256 x 140 x 8192 = 21.896TB

其中,KV缓存传递的流量虽然不大,每个用户约1.17GB,但需要在10ms左右的时间内一次传递完成。如果用1个800G端口传递,最快需要11.7ms。

AI推理对网络的需求

超高频率

AI推理流量虽然远小于训练时的网络流量,但值得注意的是,推理需要在很短的时间内完成,每个token在每一层产生2次流量,并要求在极短时间内传输完毕。假设至少要达到100token/s的推理速度,并行加速比为90%,那么每个token的推理速度要小于1ms,KV缓存需要在10ms左右完成。整个网络吞吐量应大于

4 x 100 x 140 x 8192 x (4-1)x 4/0.001 + 4 x 100 x 140 x 8192/0.01 = 5551GB/s 44.4Tbps

严格时间同步

无论是训练还是推理流量,都具有非常严格的周期性规律。基于木桶原理,如果GPU的时钟不同步,将造成同样的计算量花费不同的时间,计算快的GPU不得不等待计算慢的GPU。

开放与兼容性

AI推理进程涉及应用已训练好的AI模型进行决策或识别。对比AI训练,AI推理芯片门槛相对更低,我们的确也看到推理领域萌生出了开放生态的雏形,不少新兴初创企业加入竞争,涌现出基于不同算力架构的技术方案。

另一方面,在实际生产部署中的AI推理业务往往会与前端的业务/应用网络形成紧密配合,经由现有数据中心和云网络基础设施对外提供服务。

这便要求基础设施具备相当的开放性——网络不但要连接底层的异构算力(GPU、CPU、NPU)系统,还需要实现与上层管理系统的对接集成,例如与基于K8s的算力调度平台、已有的云管平台等等。

随着大模型的应用不断深化,AI算力部署将从训练场景逐步转向推理,推理需求也逐渐从云端迁移至边缘/终端,并呈现出垂直行业定制化的趋势。在云-边-端之间,我们需要构建一个更为均衡、通用化的网络基础设施体系。

在已被用户场景充分验证的数据中心开放云网能力之上(BGP、VXLAN、Calico容器路由、RoCE、NVMe-oF等),星融元推出的 星智AI 网络解决方案基于通用、解耦、高性能的以太网硬件和开放的SONiC软件框架,为AI智算中心提供10G-800G速率的以太网交换机,灵活支持单一速率或混合速率交换机组网,在保持极致性能的同时可编程、可升级,帮助客户构建高性能的AI智算中心网络,提供用于AI训练、推理、分布式存储、带内外管理等场景的互联能力。

  • 最大支持64个800G以太网接口,共51.2T交换容量
  • 超低时延,在800G端口上实现业界最强的560ns cut-through时延
  • 全端口标配支持RoCEv2
    200+MB大容量高速片上包缓存,显著减小集体通信时RoCE流量的存储转发时延
  • Intel至强CPU + 大容量可扩展内存,运行持续进化的企业级SONiC——AsterNOS网络操作系统,并通过DMA直接访问包缓存,对网络流量进行实时加工
  • INNOFLEX可编程转发引擎:可以根据业务需求和网络状态实时调整转发流程,最大程度避免网络拥塞和故障而造成的丢包
  • FLASHLIGHT精细化流量分析引擎:实时测量每个包的延迟和往返时间等,经过CPU的智能分析,实现自适应路由和拥塞控制
  • 10纳秒级别的PTP/SyncE时间同步,保证所有GPU同步计算
  • 开放的软件架构(生产就绪的SONiC,AsterNOS)通过REST API开放全部网络功能给AI智算中心管理系统,与计算设备相互协同,实现AI算力集群的自动化部署

AI Open Ecology

一文揭秘AI智算中心网络流量 – 大模型训练篇


关注星融元


前言:自2017年起,AI模型的规模每半年翻一番,从初代Transformer的6500万增长到GPT-4的1.76万亿,预计下一代大语言模型将达到10万亿规模。另一方面,用于模型训练的数据量持续增长,如C4数据集,原始数据量累计超过9.5PB,每月新增200-300TB,目前经过清洗加工后的数据集大小约38.5 TB,训练样本数364.6M。进一步,随着多模态大模型的兴起,训练数据从单一的文本过渡到图像和视频乃至3D点云,数据规模将是文本数据的1万倍以上。

AI模型的规模巨大并持续快速增长,不仅将带来数据中心流量的指数型增长,独特的流量特征也将为数据中心网络带来崭新的需求。

深入分析AI大模型在训练、推理和数据存储流量将帮助数据中心建设者有的放矢,用更低的成本,更快的速度、更健壮的网络为用户提供更好的服务。

本篇我们将聚焦于介绍AI大模型训练场景下的网络流量,AI推理和数据存储场景会在接下来的文章中呈现,敬请关注。

AI model

AI训练程序首先将模型参数加载到GPU内存中,之后将经历多个epoch(即使用所有训练集对模型进行一次完整训练),每个epoch的处理过程可以简单描述为4步:

  1. 加载训练数据,在每个epoch中,根据batch size将整个数据集分为若干个mini-batch,分批次加载训练数据,直到遍历整个训练数据集。
  2. 训练,包括前向传播、计算损失、反向传播和参数/梯度更新,每个mini-batch都进行上述步骤。
  3. 评估,使用评估数据集对模型的指标进行评估。这一步是可选的,可以在整个训练完成后单独进行,也可以间隔若干个epoch进行一次。
  4. 保存checkpoint,包括模型状态、优化器状态和训练指标等。为了减少存储需求,通常经过多个epoch后保存一次。

在大模型出现之前,整个过程在可在一台AI服务器内部完成,训练程序从服务器本地磁盘读取AI模型和训练集,加载到内存中,完成训练、评估,然后将结果存储回本地磁盘。虽然为了加速训练,也会采用多块GPU同时训练,但所有的I/O均发生在一台AI服务器内部,并不需要网络I/O。

AI大模型训练的网络流量有哪些?

进入大模型时代,AI训练的流量路径和其网络需求发生了巨大变革。

首先是模型的参数规模超出了单个GPU的内存,采用GPU集群协同计算,则需要相互之间通信以交换信息,这类信息包括参数/梯度、中间激活值等。

庞大的数据集被所有GPU共享,需要集中存放到远端的存储服务器中通过网络调用,分批加载到GPU服务器上。此外,定期保存的参数和优化器状态也需要通过存储服务器共享,在每个训练epoch中,都要通过网络读写数据。

由此,AI大模型训练的网络流量可分为以下两类:

  • 第一类是GPU之间同步梯度和中间激活的网络流量,它发生在所有GPU之间,是一种广播式流量,逻辑上需要所有GPU全连接。
  • 第二类是GPU和存储服务器之间的流量,它仅仅发生在GPU和存储服务器之间,是一种单播流量,逻辑上仅需要以存储服务器为中心的星型连接。

并行训练技术

其中,GPU之间的网络流量与传统数据中心内部流量迥然不同,这与AI大模型的训练方法息息相关——并行训练技术。

并行训练:AI智算中心的主要流量来源

当前广泛应用于AI训练并行计算模式主要有以下三类:

数据并行将不同的样本数据分配给不同的GPU,以加快训练速度;用在主机之间
张量并行将模型的参数矩阵划分为子矩阵,并分配到不同的GPU上,以解决内存限制并加速计算。一般用在主机内部。
流水线并行将模型分为多个阶段,每个阶段分配给不同的GPU,以改善内存利用率和资源效率。一般用在主机之间

并行训练

常见的集合通信流量模式(如下图)

Collective communication

1.数据并行(Data Parallelism)

在数据并行时,主要的网络流量来源于梯度同步,它发生在每次mini-batch处理之后,由一个all-reduce操作计算平均值。理想情况下,所有GPU全连接,每个GPU给其它G-1个GPU单独发送数据,共需发送G x(G-1)份数据。

FSDP(完全分片数据并行)是一种改进的数据并行技术,旨在优化内存使用和通信效率。它通过将模型参数和梯度在多个GPU之间分片(shard)存储,实现更高效的内存利用和通信。

在FSDP时,网络流量来自前向传播的参数收集以及反向传播中的梯度同步。

前向传播的参数收集由all-gather操作完成,all-gather的通信复杂度与all-reduce相同。

后向传播的梯度同步由all-reduce操作完成,由于每个GPU的参数只有原来的1/G,一个epoch中总的网络流量只有普通数据并行的1/G。

2.张量并行(Tensor Parallelism)

在张量并行时,模型参数分布到G个GPU上,每个GPU只存储1/G参数。网络流量主要来自前向传播过程的中间激活值的传递以及反向传播过程中的梯度同步。

前向传播中,各个GPU计算出的中间激活值需要合并,由一次all-reduce操作进行求和。对于每个Token,在模型的每个layer的中均进行2次合并,共2xTxL次通信。

反向传播中,梯度需要在GPU之间同步,这种在每一层的处理中发生2次,由all-reduce操作将各个GPU上梯度求和。这种同步发生在每个mini-batch的每个layer的处理过程中。共2×N×L次通信。

3.流水线并行(Pipeline Parallelism)

在流水线并行时,网络流量主要来自前向和反向传播过程的中间激活值的传递。与张量并行不同,这些流量的传递发生在模型的前后两个阶段之间,使用Point-to-point通信而非all-reduce操作,并且频率也大大减小了。

综上,在三种并行方式中,张量并行的网络流量最大、频率最高,流水线并行的流量最低,数据并行的通信频率最低。如下表所示,P为模型参数,T为token数,L为模型层数,H为隐藏状态大小,G为GPU数量,N为mini-batch的数量,采用BFLOAT16数据格式,每个参数占2个字节。在每个epoch过程中:

 流量模式后向传播总网络流量反向传播同步次数前向过程总网络流量前向过程传递次数
数据并行all-reduce2 × N × P × G × (G-1)100
FSDPall-gather + all-reduce2 × N × P × (G-1)L2 × N × P × (G-1)L
张量并行all-reduce4 × N × P × L × (G-1)2 × L4 × L × T × H × (G-1) × G2 × L × T
流水线并行Point-to-point2 × T × H × (G-1)G-12 × T × H × (G-1)G-1

以具有80层(L)的Llama3 70B(P)模型和C4数据集为示例计算:采用BFLOAT16数据格式,每个参数占2个字节,隐藏层维度设为8192(H),使用8个GPU(G)进行数据并行。C4数据集token(T)总数约156B,样本数364.6 millions;batch size为2048,则每个epoch包含约178,000个mini-batch(N)

计算可得每个epoch过程中:

 反向传播总网络流量(PB)反向传播同步次数前向过程总网络流量(PB)前向过程总网络流量
数据并行1396 PB100
FSDP1758017580
张量并行2662216021840160*156*10^9
流水线并行17.9717.97

3D并行技术下的网络流量

数据并行、张量并行和流水线并行三个技术通常会组合起来使用,可进一步提高训练大模型时的效率和可扩展性。这时候,GPU也就按照这三个维度组成了GPU集群。

3D并行技术

假设共有G(tp)×G(pp)×G(dp) 个GPU组成的3D并行阵列,全部P个参数将分割为G(tp)×G(pp)份,每一份大小为P/G(tp)/G(pp)。在模型并行、流水线并行和数据并行三个维度上都存在网络流量。接下来我们将深入到每个epoch的训练过程,分别计算不同阶段的网络流量组成和规模。

3D并行技术

1.反向传播中的网络流量

在每个mini-batch中,反向传播时的梯度同步分为:

  1. 张量维度上的梯度同步,在模型的每一层和数据维度的每一组中进行,总共 LxG(dp) 次,每次包含2个all-reduce操作。
  2. 数据维度上的梯度同步,在流水线维度的每个阶段和张量维度的每一组中进行,总共 G(tp)xG(pp) 次,每次包含1个all-reduce操作。

如下图所示:

反向传播中的网络流量

这样,在一个epoch中,梯度同步的总网络流量为:

4xNxP/Gtp/GppxGtpx(Gtp-1)xLxGdp+2xNxP/Gtp/GppxGdpx(Gdp-1)xGtpxGpp=2xNxPxGdpx[2xLx(Gtp-1)/Gpp+(Gdp-1)]

3.流水线并行维度的中间激活梯度传播,流量为:

2xTxHx(Gpp-1)

因此,在一个epoch中,整个反向传播的总流量为:

2xNxPxGdpx[2xLx(Gtp-1)/Gpp+(Gdp-1)]+2xTxHx(Gpp-1)

2.前向传播中的网络流量

前向传播时,中间激活的传递依次在张量并行、流水线并行维度上交替进行,其中张量并行的激活传递每次包含2个all-reduce操作。

如下图,以一个Token的前向传播所示:

Token的前向传播

因此,在一个epoch中,前向传播总网络流量为:

4xTxHxLxPxGtpx(Gtp-1)+2xTxHx(Gpp-1)

即:

2xTxHx(2xLxGtpx(Gtp-1)+(Gpp-1)

由此,我们以Llama3-70B模型为例,采用8路张量并行 x 8路流水线并行 x 16路数据并行的模式,在共1024个GPU上进行训练,一个epoch产生的总流量约为85EB。如此庞大的流量规模,如果用1个交换容量为51.2T的交换机,24小时满负荷运行,需要约20天才能传输完毕。

考虑到一次预训练通常包含100个左右epoch,如果需要在100天完成训练,至少需要20台51.2T交换机来传输训练过程产生的数据。

AI训练对智算中心网络的要求

通过以上分析和计算,我们可以得出一个典型的AI智算中心对计算网的核心需求。

  • 超高带宽:一个epoch就会产生85EB的数据量,相当于整个互联网2.5天的流量。
  • 超低时延:一个训练样本的处理,就会产生100GB以上的数据,并需要在小于1毫秒的时间传输完毕。相当于1000个800G接口的传输速度。
  • 集合通信:GPU服务器之间的All-reduce, All-gather操作带来广播式流量,在上万个GPU之间,也就是上亿个GPU-GPU对之间同步。
  • 零容忍丢包:基于木桶原理,在集体通信过程中,仅仅是一对GPU之间流量的丢包和重传,也会造成整个集体通信的延迟,进而造成大量GPU进入空闲等待时间。
  • 严格时间同步:同样基于木桶原理,如果GPU的时钟不同步,将造成同样的计算量花费不同的时间,计算快的GPU不得不等待计算慢的GPU。

星融元CX-N系列交换机正是为智算中心AI训练场景而生的超低时延以太网交换机——在保持极致性能的同时,实现可编程、可升级的能力,与计算设备形成协同,共同打造10万级别的计算节点互联,将数据中心重构为可与超级计算机媲美的AI超级工厂。

  • 最大支持64个800G以太网接口,共51.2T交换容量。
    超低时延,在800G端口上实现业界最强的560ns cut-through时延。
  • 全端口标配支持RoCEv2,支持Rail-only,全连接Clos以及200G/400G混合组网,灵活适应不同的算力中心建设方案
  • 200+ MB大容量高速片上包缓存,显著减小集体通信时RoCE流量的存储转发时延。
  • Intel至强CPU + 大容量可扩展内存,运行持续进化的企业级SONiC——AsterNOS网络操作系统,并通过DMA直接访问包缓存,对网络流量进行实时加工。
  • INNOFLEX可编程转发引擎,可以根据业务需求和网络状态实时调整转发流程,最大程度避免网络拥塞和故障而造成的丢包。
  • FLASHLIGHT精细化流量分析引擎,实时测量每个包的延迟和往返时间等,经过CPU的智能分析,实现自适应路由和拥塞控制。
  • 10纳秒级别的PTP/SyncE时间同步,保证所有GPU同步计算。
  • 开放API,通过REST API开放全部功能给AI数据中心管理系统,与计算设备相互协同,实现GPU集群的自动化部署。

Easy RoCE:在SONiC交换机上一键启用无损以太网


关注星融元


RDMA(远程直接内存访问)技术是一种绕过 CPU 或操作系统,在计算机之间直接传输内存数据的技术。它释放了内存带宽和 CPU,使节点之间的通信具有更低的延迟和更高的吞吐量。目前,RDMA 技术已广泛应用于高性能计算、人工智能工作负载、存储和许多其他场景。

1、RoCEv2对网络的需求和挑战

RoCEv1 基于以太网链路层实现,通过交换机上的流量控制技术确保物理层的可靠传输。RoCEv2 在 UDP 层之上实现,弥补了 InfiniBand 的一些局限性,支持更广泛的 RDMA 应用。

与 TCP 协议相比,UDP 速度更快,消耗的资源更少,但没有TCP的滑动窗口和确认响应等机制来确保可靠传输。在 RoCEv2 网络中,如果出现数据包丢失,网卡将丢弃所有收到的数据包,而发送方需要重新传输所有后续数据包,导致网络传输性能大幅下降。因此,我们通常使用 PFC(优先级流量控制)和 ECN(显式拥塞通知)等功能来保证可靠性。

在以太网交换机上配置上述功能需要熟悉 QoS 机制、配置逻辑和相关命令行。对于长期为客户配置 RoCEv2 网络的工程师来说,这可能并不困难。但对于大部分从事高性能计算和存储领域的技术人员,他们通常专注于服务器侧的相关技术,这种相对复杂的,但又必须调通的网络配置给他们带来了很多麻烦,甚至以往运维过IB网络的工程师也需要花时间学习相关知识。

2、在SONiC交换机上用常规步骤配置无损以太网

现在让我们快速回顾一下如何在SONiC交换机上按常规方法配置 RoCEv2 无损以太网。这里使用的是星融元CX-N系列超低时延交换机,搭载SONiC企业级发行版AsterNOS3.1 R0405P01版本,但没有使用其上的 EasyRoCE 功能。

在部署 RoCEv2 网络时,务必首先确认网络硬件条件:低延迟网络交换机需要能支持 PFC 和 ECN 等功能,服务器侧的网卡也需要支持 RoCEv2 。常规步骤下:

  1. 启用和取消需要分别配置 PFC 和 ECN。
  2. 故障排除或状态检查通常需要进入不同的命令行视图并多次执行 “show “命令,以确定当前队列映射、缓冲区、启用的队列、阈值、队列吞吐量、暂停和 CNP 触发器。

第一步,确保服务器网卡工作在 RoCEv2 模式下,为业务流量配置 PCP 或 DSCP,并启用 ECN。


#设置网卡RDMA CM的工作模式
[root@server ~]# cma_roce_mode -d mlx5_0 -p 1 -m

#设置网卡的优先级类型为DSCP
[root@server ~]# mlnx_qos -i enp1s0f0 –trust=dscp
DCBX mode: OS controlled
Priority trust state: dscp

#在队列3上开启PFC
[root@server ~]# mlnx_qos -i enp1s0f0 -f 0,0,0,1,0,0,0,0

#在队列3上开启DCQCN
[root@server ~]# echo 1 > /sys/class/net/enp1s0f0/ecn/roce_np/enable/3
[root@server ~]# echo 1 > /sys/class/net/enp1s0f0/ecn/roce_rp/enable/3

#设置CNP DSCP
[root@server ~]# echo 48 >


然后,在交换机端口配置以启用 PFC 和 ECN 功能并指定队列。您需要在以太网交换机的指定队列(需与服务器上的队列匹配)上启用 PFC 和 ECN,并调整缓冲区和阈值。


# 设置PFC门限值
sonic(config)# buffer-profile pg_lossless_100000_100m_profile
sonic(config-buffer-profile-pg_lossless_100000_100m_profile)# mode lossless dynamic -2 size 1518 xon 0 xoff 46496 xon-offset 13440
sonic(config-buffer-profile-pg_lossless_100000_100m_profile)# exit

# 在3、4队列开启PFC功能(AsterNOS的PFC功能默认使能3、4队列,无需配置)
sonic(config)# priority-flow-control enable 3
sonic(config)# priority-flow-control enable 4
sonic(config)# exit

# 设置ECN门限值
sonic(config)# wred roce-ecn
sonic(config-wred-roce-ecn)# mode ecn gmin 15360 gmax 750000 gprobability 10
sonic(config-wred-roce-ecn)# exit

# 配置Diffserv map
sonic(config)# diffserv-map type ip-dscp roce-dmap
sonic(config-diffservmap-roce-dmap)# ip-dscp 48 cos 6

# 配置Class map
sonic(config)# class-map roce-cmap
sonic(config-cmap-roce-cmap)# match cos 3 4
sonic(config-cmap-roce-cmap)# exit

# 配置Policy map
sonic(config)# policy-map roce-pmap
sonic(config-pmap-roce-pmap )# class roce-cmap
sonic(config-pmap-c)# wred roce-ecn
sonic(config-pmap-c)# priority-group-buffer pg_lossless_100000_100m_profile
sonic(config-pmap-c)# exit
sonic(config-pmap-roce-pmap )# set cos dscp diffserv roce-dmap
sonic(config-pmap-roce-pmap )# exit

# 进入以太网接口视图,绑定策略,将RoCE网络配置在接口上使能
sonic(config)# interface ethernet 0/0
sonic(config-if-0/120)# service-policy roce-pmap


3、使用AsterNOS上的Easy RoCE快捷配置无损以太网

星融元在 AsterNOS 上推出了 “EasyRoCE” 功能,该功能将无损以太网相关的配置命令行进行了封装和模板化,大大简化了RoCEv2网络配置和部署流程。请注意,以下命令行仅简单展示交换机上与该功能相关的部分关键配置,完整的验证演示流程请参考文末视频

一键启用无损以太网

一键RoCE

故障排除或状态检查

AsterNOS 的 Easy RoCE 功能支持 show roce 命令行,用于一站式查看全局或接口视图的RoCE 配置和计数,以及清除所有配置和计数。

# 检查RoCE配置
sonic# show qos roce

故障排除

# 查看特定接口的计数
sonic# show counters qos roce interface 0/0 queue 3
# 清除全部计数
sonic# clear counters qos roce

状态检查

自动化配置和网络可见性

上述命令可帮助您快速配置无损以太网,如果您需要微调参数,Easy RoCE也支持自定义更改设备提供的默认模板,该模板也可通过上层管理平台向设备下发。

基于 AsterNOS 的开放式架构,我们还开发了一个容器化部署的 roce_exporter,用于提取设备 RoCE 相关信息,并与 Prometheus 无缝对接以提高网络可见性。

自动化配置

相关文章

实战演练:一文教你将交换机纳入K8s,对容器进行纳管


关注星融元


随着云计算的发展和云原生应用的兴起,容器技术成为一种流行的应用部署和管理方式。容器化应用程序具有轻量、可移植和可扩展的特点,能够快速部署和运行在不同的环境中。Kubernetes作为一个容器编排平台,为云原生应用的部署、管理和自动化提供了强大的支持,因此得到了广泛的关注和采用。

AsterNOS由于其系统的开放性,能够提供计算资源给用户以部署容器化服务。在客户拥有K8s管理集群的条件下,可以通过K8s纳管AsterNOS设备,将第三方应用部署在AsterNOS上,从而简化应用程序的管理和运维过程。通过使用K8s进行容器编排和自动化管理,便能实现应用的自动伸缩、自动恢复和自动升级,减少了人工干预和操作的工作量。可以提高运维效率,降低运维成本,并提供更好的应用程序可用性和稳定性。

流程图

配置K8s之前,先给读者们讲个故事:

在K8s诞生时,CNCF(云原生计算基金会——主导了K8s项目)便致力于推行一个标准的容器对接方案CRI,符合该容器标准的容器技术能够被K8s纳管,但是docker当时已经作为市场主流方案被接受,因此不符合该标准。出于市场原因K8s最开始在内部运行了名为docker-shim的垫片程序作为与docker的临时对接方案,在1.24版本后,K8s便放弃了与docker的兼容工作,将该垫片剥离出去。这方面工作就由Mirantis公司(docker母公司)接手,开发出名为cri-dockerd的垫片程序进行兼容工作。自此,如果想使用K8s管理docker,便需要使用一个名为cri-dockerd的容器运行时作为中间垫片。


因此,方案整体采用docker + cri-dockerd + K8s 的架构进行部署验证。

方案主体

可以通过两种方式将CX-N作为K8s集群中的工作节点:

  • CX-N作为普通node节点纳入集群,在此方案中K8s中的kube-proxy以及kubelet作为必要组件会运行在工作节点中。该方案所占资源更多但是更加通用,能够实现K8s所有的功能。
  • 将CX-N作为边缘设备纳入集群,该方案使用kubeedge组件,在主节点启用cloudcore,边缘节点启动edgecore加入主节点。此方案所占用性能更低,但是如果将该节点当作普通node来使用可能会出现兼容性以及功能方面的缺失问题。

组网拓扑

1、IP规划

名称IP
K8s-master10.230.1.26/24
CX532P-N10.230.1.10/24
CX308P-N10.230.1.21/24
Pod-cidr10.244.0.0/16
Service-cidr10.96.0.0/12

2、kubeedge方式部署

kubeedge方式部署

(1)软件环境

机器名称版本
K8s-masterLinuxUbuntu 20.04.6 LTS
dockerdocker ce:26.0.0
containerd:1.6.28
cri-dockerv0.3.11
keadmv1.16.1
kubeedgev1.16.1
kubeadm、kubelet、kubecliv.1.27.6
flannelv0.24.4
CX532P-Ndockerdocker ce:26.0.0
containerd:1.6.28
cri-dockerv0.3.11
keadmv1.16.1
kubeedgev1.16.1
cni-pluginv1.4.1

(2)最终效果

在主节点上显示节点信息:

节点信息
节点信息

显示容器信息:

master节点容器信息
master节点容器信息

在CX-N设备上显示容器信息:

node节点容器信息
node节点容器信息

3、node方式部署

(1)软件环境

机器名称版本
K8s-masterLinuxUbuntu 20.04.6 LTS
dockerdocker ce:26.0.0
containerd:1.6.28
cri-dockerv0.3.11
kubeadm、kubelet、kubecliv.1.27.6
flannelv0.24.4
CX532P-Ndocker
docker ce:26.0.0
containerd:1.6.28
cri-dockerv0.3.11
kubeadm、kubelet、kubecliv.1.27.6
flannelv0.24.4

(2)最终效果

master节点容器信息
master节点容器信息

node节点容器信息
node节点容器信息

4、结论

两种方案对比:

 kubeedge节点普通K8s node节点
功能边缘计算能力,能在边缘设备上运行容器化应用和进行边缘计算完整的容器编排和管理能力,适用于云端和数据中心环境
生态支持生态对比普通Kubernetes有所不足成熟的生态系统和广泛的社区支持
设备边缘设备和边缘计算基础设施的支持普通计算节点
网络要求离线工作支持,能在无网络连接的情况下继续工作需要高速稳定的网络连接和可靠的云端基础设施
性能占用边缘设备的资源限制可能影响应用程序的性能和可扩展性性能占用略高,不适合特定于边缘计算场景的要求
部署管理部署和管理边缘节点更复杂部署管理较为简单
资源控制node资源控制能力不足完善的pod,namespace以及node资源控制管理能力

总的来说,kubeedge是专属于为边缘计算场景设计:

  1. 边缘计算环境:能够在边缘设备上运行容器化应用和进行边缘计算。因此,KubeEdge 特别适用于需要在边缘设备上进行实时数据处理、低延迟计算或离线工作的场景。
  2. 边缘数据处理:要求边缘设备具有本地数据处理能力,可以减少数据传输到云端的延迟和带宽消耗。这使得 KubeEdge 适用于需要实时数据处理、减少云端数据传输、保护数据隐私等场景,如物联网应用、视频监控、智能交通等。
  3. 离线工作支持:即使在边缘设备失去网络连接的情况下,仍然能够继续工作,适用于偏远地区或断网环境下的场景。

而普通的K8s节点更适用于如下场景:

  1. 云端和数据中心环境:节点具备完整的容器编排和管理能力,适用于在云端和数据中心部署和管理大规模的容器化应用。
  2. 易于扩展和管理的场景:普通 Kubernetes 节点在扩展性和管理性方面具有优势,可以轻松地扩展和管理大规模的集群,适用于需要高度可扩展性和灵活性的场景。
  3. 依赖云端资源的场景:普通 Kubernetes 节点通常依赖于云端的弹性和资源来处理工作负载,适用于需要利用云端资源来处理应用程序的场景。
  4. 广泛的生态系统和社区支持:普通 Kubernetes 在生态系统和社区支持方面非常强大,有着广泛的工具、插件和文档资源,适用于需要成熟的生态系统和广泛的社区支持的场景。

通过以上两种方式,星融元AsterNOS设备上能够运行K8s容器,想要自行配置体验?方案获取:解决方案-基于Kubernetes的AsterNOS资源管理方案

相关文章

大型语言模型(LLMs)是怎样“学习”的?一封给网络工程师的大模型指南


关注星融元


数字时代,人工智能(AI)及其相关技术正日益成为许多领域的热门话题。其中,生成式人工智能(Gen AI)和大型语言模型(LLMs)引起了广泛的兴趣和讨论。然而,尽管这些术语在科技界和专业领域中频繁出现,网络工程师对其的理解却不多。

什么是生成式人工智能和大型语言模型?本文将为大家介绍大型语言模型和生成式人工智能的基本概念、应用领域及大语言模型的运行原理,阅读本文后您将更全面地了解这些领域的前沿技术,我们一同踏上这段探索新领域的科普之旅吧!

什么是生成式人工智能和大型语言模型?

“生成式人工智能(Generative AI,一般简称为Gen AI)”是一种人工智能技术,专注于创造或生成新的内容,例如图像、文本或音乐。这些内容不是直接复制或派生自现有的示例,而是由计算机自己创造的。生成式AI的一个重要应用是生成文本,比如自动写作、诗歌创作或对话生成。

“大型语言模型(Large Language Models,LLMs)”是一类生成式AI,它们通过深度学习算法在大量自然语言数据上进行训练。这些模型学习人类语言的模式和结构,并能够对各种书面输入或提示生成类似人类的回应。最近的LLMs表现出了接近人类的水平,例如GPT-3.5,它能够产生几乎完美的文本回应。

这些近乎完美的类人化回应,包括来自chatGPT和其他最近的LLMs,得益于模型架构的进步。这些模型采用高效的具有数十亿个参数的深度神经网络(DNNs)经过大规模数据集的训练得出,其中大部分参数被用于训练和推理的矩阵权重。而训练这些模型的浮点运算次数(FLOP)几乎与参数数量和训练集大小成线性关系。这一系列运算是在专门用于矩阵运算的处理器上执行的,例如图形处理单元(GPUs)、张量处理单元(TPUs)和其他专用的AI芯片等。GPU、TPU、AI加速器以及它们之间的通信互联技术的进步让庞大模型训练成为现实。

LLMs有哪些应用?

大型语言模型(LLMs)具有许多用例,几乎每个行业都可以从中受益。不同的组织可以根据自身的特定需求和领域对模型进行微调。微调是指在特定数据集上对预先存在的语言模型进行训练,使其更专业化并适应特定任务。通过微调,组织可以在利用这些训练模型预先存在能力的同时,将其调整得能够满足自己得独特需求,这让模型能够获取领域特定的知识,从而提高其生成组织用例所需输出的能力。通过微调的模型,组织可以在多个用例中使用LLMs。

例如,根据公司文档进行微调的LLMs可用于客户支持。LLMs可以通过创建代码或支持他们创建部分代码来帮助软件工程师。当与组织的专有代码库进行微调时,LLMs有可能生成类似于并符合现有代码库的软件。

LLMs的众多用例包括用于评估客户反馈的情绪分析、将技术文档翻译成其他语言、总结会议和客户电话以及生成工程和营销内容。

pictures

随着这些LLMs的规模持续呈指数级增长,对计算和互连资源的需求也显着增加。只有当模型的训练和微调以及推理有足够成本效益时,LLMs才会被广泛采用。

LLMs如何使用深度学习算法进行训练?

为了使用自然语言文本训练LLM,通常需要收集大量数据,包括网络抓取(爬取网页)、维基百科、GitHub、Stack Exchange、ArXiv等。大多数模型通常使用开放数据集进行训练。这些数据集中的大量文本首先会进行标记化,通常使用字节对编码等方法。标记化将来自互联网的原始文本转换为整数序列(标记,tokens)。一个标记(唯一整数)可以表示一个字符或一个单词,甚至可以是单词的一部分。例如,单词“unhappy”可能会被分成两个标记——一个表示子词“un”,另一个表示子词“happy”。

编码

比如这段文本先被标记化,再被编码化

根据数据集的不同,可能会有成千上万个唯一标记,数据集本身可能映射到数千亿个标记。序列长度是模型在训练过程中预测下一个标记时要考虑的连续标记的数量。GPT-3和LLaMA(Meta的LLM)的序列长度约为2000。一些模型使用的序列长度甚至达到10万。表1比较了GPT-3和LLaMA模型的训练参数。

为了训练模型,标记被分成大小为batch_size(B)x序列长度的数组,然后将这些批次馈送给大型神经网络模型。训练通常需要几周,甚至几个月,并且需要大量的GPU集群。

模型参数 GPT-3 LargeLLaMA
词汇量大小 50,25732,000
序列长度 2,0482,048
最大训练模型参数 1750亿650亿
训练数据集中的标记数3000亿1到1.3万亿
GPU数量10,000 x V100 GPUs2,048 x A100 GPUs
训练时间一个月21天

一旦基础模型训练完成,通常会进行监督微调(Fine-Tuning,SFT)。这是一个可以让LLMs扮演助手角色,回答人们提示问题的重要步骤。在有监督微调中,人们会创建一个精心策划的数据集(数量较少但质量很高的数据集),其中包含提示和响应的形式,然后使用这个数据集重新训练基础模型。经过训练的SFT模型会成为一个能对用户提示作出类似人类回应的助手。

以上是对LLMs的简单解释,接下来将直接讲述LLMs的模型计算过程。(敲黑板,上强度了!)

模型计算

一个具有1750亿参数的模型通常需要超过1TB的内存来存储参数和计算过程中的中间状态。它还需要存储检查点的训练状态(以防在训练迭代过程中遇到硬件错误)。一万亿个标记通常需要4TB的存储空间。像Nvidia的H100这样的高端GPU具有80GB的集成HBM内存(如果想用H100装下一个一万亿标记的模型,需要4TB➗80GB=51.2张卡)。一个GPU的内存是无法容纳模型参数和训练集的。

根据维基百科的说法,大型语言模型(LLM)通常每个参数和标记需要进行六次浮点运算(FLOP)。这相当于对GPT-3模型进行训练需要进行3.15 x 10^23次浮点运算,其中GPT-3模型的训练耗时为三周。因此,在这三周的时间内,它需要5.8 x 10^16次每秒的浮点运算能力(FLOPs)。

pictures

一卡难求的H100长这样?

然而,尽管Nvidia的最高性能H100 GPU在FP32模式下可以达到约67 TeraFLOPS(每秒万亿次),但在许多训练工作负载中,由于内存和网络瓶颈,GPU的利用率通常只能维持在30%左右。因此,为了满足训练需求,我们需要三倍数量的GPU,大约是6,000个H100 GPU。原始的LLM模型(表1)是使用较旧版本的GPU进行训练的,因此需要10,000个GPU。

由于有成千上万个GPU,模型和训练数据集需要在这些GPU之间进行分区,以实现并行运行。并行性可以在多个维度上发生。

数据并行性

数据并行性(Data Parallelism)涉及将训练数据分割到多个GPU上,并在每个GPU上训练模型的副本。典型流程包含数据分布、数据复制、梯度计算、梯度聚合、模式更新和重复等。

  1. 数据分布:训练数据被划分为小批量,并在多个GPU之间分布。每个GPU获得一个独特的小批量训练集。
  2. 模型复制:模型的副本被放置在每个GPU上(也称为工作节点)。
  3. 梯度计算:每个GPU执行一次模型训练迭代,使用其小批量数据进行前向传播以进行预测,并进行反向传播以计算梯度(这些梯度指示模型参数在下一次迭代之前应如何调整)。
  4. 梯度聚合:来自所有GPU的梯度被汇总在一起。通常通过计算梯度的平均值来完成此步骤。
  5. 模型更新:汇总的梯度被广播到所有GPU。各个GPU更新其本地模型参数并进行同步。
  6. 重复:此过程重复多次,直到模型完全训练完成。

数据并行性可以在使用大型数据集时显著加快训练速度。然而,它可能会导致大量的GPU间通信,因为每个GPU都必须与训练中涉及的其他GPU通信。这种全对全的通信(All-to-All)可能会在每次训练迭代中在网络中产生大量的流量。

ALL-to-ALLALL-to-ALL

训练大型语言模型(LLMs)时,我们使用了一些方案,例如环形全局归约(Ring All-Reduce),将梯度以环形模式从一个GPU发送到另一个GPU。在这个过程中,每个GPU将其从前一个GPU接收到的梯度与本地计算的梯度进行聚合,然后将其发送到下一个GPU。然而,这个过程非常缓慢,因为梯度聚合分布在多个GPU之间,最终结果需要在环形拓扑中传播回所有GPU。如果网络拥塞,GPU之间的流量会因等待聚合梯度而停滞。

ALL-REDUCE

ALL-REDUCE

此外,具有数十亿参数的LLMs无法适应单个GPU。因此,仅靠数据并行性无法满足LLM模型的需求。

模型并行性

模型并行性(Model Parallelism)旨在解决模型无法适应单个GPU的情况,通过将模型参数(和计算)分布到多个GPU上。典型的流程包含模型分区、前向传播、反向传播、参数更新、重复等。

  1. 模型分区:将模型划分为若干个分区,每个分区分配给不同的GPU。由于深度神经网络通常包含一系列垂直层,因此按层次划分大型模型是合乎逻辑的,其中一个或一组层可能分配给不同的GPU。
  2. 前向传播:在前向传播过程中,每个GPU使用“整个”训练集计算其模型部分的输出。一个GPU的输出作为下一个GPU的输入传递。下一个GPU在接收到前一个GPU的更新之前无法开始处理。
  3. 反向传播:在反向传播过程中,一个GPU的梯度传递给序列中的前一个GPU。在接收到输入后,每个GPU计算其模型部分的梯度。与前向传播类似,这在GPU之间创建了顺序依赖关系。
  4. 参数更新:每个GPU在其反向传播结束时更新其模型部分的参数。需要注意的是,这些参数不需要广播到其他GPU。
  5. 重复:此过程重复多次,直到模型在所有数据上训练完成。

流水线并行性

流水线并行性(Pipeline Parallelism)将数据并行性和模型并行性相结合,其中训练数据集的每个小批量进一步分成几个微批量。在上面的模型并行性示例中,一个GPU使用第一个微批量计算输出,并将该数据传递给序列中的下一个GPU。与在反向传播中等待从该GPU获取输入不同,它开始处理训练数据集的第二个微批量,依此类推。这增加了GPU之间的通信,因为每个微批量都需要在序列中相邻的GPU之间进行前向传播和反向传播的通信。

张量并行性

张量并行性(Tensor Parallelism)是一种用于加速深度学习模型训练的技术。与模型并行和流水线并行技术不同,张量并行性在操作级别(或“张量”级别)上划分模型,而不是在层级别上划分。这种方法允许更精细的并行处理,对某些模型来说更高效。

具体来说,张量并行性的步骤如下:

  1. 模型分区:将模型划分为多个操作(或“张量”),每个操作分配给不同的GPU。这样,每个GPU只负责计算部分操作的输出。
  2. 前向传播:在前向传播过程中,每个GPU使用整个训练集计算其操作部分的输出。一个GPU的输出作为下一个GPU的输入传递。这样,模型的计算被分散到多个GPU上。
  3. 反向传播:在反向传播过程中,梯度从一个GPU传递到序列中的前一个GPU。每个GPU计算其操作部分的梯度。与前向传播类似,这也创建了GPU之间的顺序依赖关系。
  4. 参数更新:每个GPU在其反向传播结束时更新其操作部分的参数。这些参数不需要广播到其他GPU。

数据并行性、模型并行性、流水并行性、张量并行性……没搞懂不同并行技术的处理逻辑?下面这个案例或许可以给你一些启发,相信作为网工的你一定能很快理解~

假设我们有2台机器(node0和node1),每台机器上有8块GPU,GPU的编号为0~15。

我们使用这16块GPU,做MP/DP/TP/PP混合并行,如下图:

MP/DP/TP/PP混合并行

MP:模型并行组(Model Parallism):

假设一个完整的模型需要布在8块GPU上,则如图所示,我们共布了2个model replica(2个MP)。MP组为:[[g0, g1, g4, g5, g8, g9, g12, g13], [g2, g3, g6, g7, g10, g11, g14, g15]]

TP:张量并行组(Tensor Parallism)

对于一个模型的每一层,我们将其参数纵向切开,分别置于不同的GPU上,则图中一共有8个TP组。TP组为:[[g0, g1], [g4, g5],[g8, g9], [g12, g13], [g2, g3], [g6, g7], [g10, g11], [g14, g15]]

PP:流水线并行组(Pipeline Parallism):

对于一个模型,我们将其每一层都放置于不同的GPU上,则图中一共有4个PP组。PP组为:[[g0, g4, g8, g12], [g1, g5, g9, g13], [g2, g6, g10, g14], [g3, g7, g11, g15]]

DP:数据并行组(Data Parallism):

经过上述切割,对维护有相同模型部分的GPU,我们就可以做数据并行,则图中共有8个DP组。DP组为[[g0, g2], [g1, g3], [g4, g6], [g5, g7], [g8, g10], [g9, g11], [g12, g14], [g13, g15]]

读完本文,相信你对训练大语言模型(LLMs)的三个步骤已经很熟悉:

  1. 通过网络抓取等方式进行数据集集成;
  2. 将源文本分割为标记;
  3. 通过模型参数并行处理的方式进行模型训练

相信你也对大数据模型的多种并行类型有了初步认识:无论使用何种并行性类型,LLM 凭借其参数和数据集的庞大规模,都会通过连接这些 GPU 的结构产生大量的 GPU 间流量。结构中的任何拥塞都可能导致训练时间过长且 GPU 利用率极低。之后将继续推出AI系列科普文,为大家介绍GPU/TPU 集群设计,以了解互连以及它们如何进行 LLM 训练。

实际应用中,训练完大语言模型(LLMs)之后,需要对模型进行微调以满足不同组织(企业)的个性化需求,该如何优化LLMs模型?后续的推文将为您解答这些疑惑。

星融元作为一家网络公司,为什么会那么关注AI、LLMs这些看似与自身业务关系不大的领域,甚至开辟专栏为网络工程师科普相关知识?主要出于技术和市场竞争方面的考虑。

1.技术方面,网络在大语言模型(LLMs)的训练过程中至关重要:

LLMs训练之初便需要通过网络抓取大量的数据集成数据集,数据集中的大量参数和数据需要通过网络传输到GPU上进行并行处理,网络连接的质量直接影响了数据传输的速度和效率。LLMs的训练会涉及到多个GPU的协同工作,连接这些GPU的网络结构会产生大量的GPU间流量,如果网络拥塞,数据传输会受到影响,导致训练时间过长且GPU利用效率降低。

因此,网络的稳定性、速度和带宽都对LLMs的训练效果至关重要。网络拥塞可能导致训练效率下降,因此需要优化网络架构,确保数据传输的高效性。

2.市场竞争方面,AI离不开LLMs训练,市场潜力无穷:

人工智能作为人们高度关注的热点话题,在许多领域拥有巨大的市场潜力。LLMs训练完毕后,大模型与用户的交互过程中(如chatGPT爆火,全球很多用户都在使用的情况),网络质量会直接影响用户对Gen AI应用的体验。拥有先进技术和工具是企业保持竞争优势的关键,星融元顺势而为,持续关注智算市场的发展,并推出HPC、AI等场景的网络解决方案,为用户提供良好的网络环境,实现用户与自身的双赢!

参考:Large Language Models – The Hardware Connection (juniper.net)
数据并行(DP)、张量模型并行(TP)、流水线并行(PP)_tp pp dp-CSDN博客

相关阅读:星融元针对LLM大模型承载网发布星智AI网络解决方案

相关文章

从零开始:搭建PXE远程批量安装服务器


关注星融元


在大规模服务器部署时,面对成百上千台服务器,通过手动插入光盘或者USE驱动器来安装操作系统无比繁琐,让大量工程师在现场挨个安装系统也不切实际,PXE的出现使得网络远程批量自动安装和配置操作系统成为现实。

什么是PXE?

PXE(Pre-boot Execution Environment,预启动执行环境)是由Intel设计的协议,它允许计算机通过网络启动。这个协议工作在Client/Server模式下,允许客户机通过网络从远程服务器下载引导镜像,并加载安装文件或整个操作系统。

相比其他工具,PXE更好地解决了以下问题:

  • 自动化:PXE允许自动安装和配置操作系统,减少了手动操作的工作量。
  • 远程实现:通过网络远程安装操作系统,无需物理介质,方便管理远程服务器。
  • 规模化:特别适用于大规模服务器部署,可以同时装配多台服务器。。

PXE工作原理和配置

工作原理

  1. PXE启动:当终端进入网卡启动时,会发送一个特殊的PXE启动请求到本地网络上的DHCP服务器。
  2. DHCP服务:DHCP服务器收到PXE启动请求后,会向计算机发送DHCP响应,DHCP响应包含了计算的网络配置信息,以及PXE引导服务器的IP地址——TFTP Server(Trivial File Transfer Protocol)。
  3. TFTP传输:计算机收到DHCP响应后,会使用TFTP从Server下载引导文件——pxelinux.0或者bootx64.efi。
  4. 加载引导文件:计算机加载并执行从TFTP下载的引导文件。引导文件通常是一个小型的Linux内核,能够连接到PXE服务器并获取操作系统镜像。
  5. 获取配置信息:引导文件连接到PXE服务器后,会通过TFTP发送请求以获取更多的配置信息。
  6. 获取操作系统镜像:PXE服务器根据计算机的请求,将系统镜像发送给计算机。
  7. 操作系统加载:一旦操作系统映像文件下载完成,计算机会加载并执行该映像文件。此时,计算机将完全从网络上运行操作系统,而无需本地硬盘上的安装。

PXE启动流程

注意:虽然PXE很好用,但启动时也需要满足以下条件

  1. 网卡支持PXE,目前新出的网卡基本都支持,同时需要完成BIOS的启动项配置。
  2. 传统启动模式(Legacy)下,PXE客户端会请求pxelinux.0;UEFI启动会请求bootx64.efi。
  3. 也可以采用nfsboot方式,该流程采用的是ISO镜像下载再安装的方式。

由于星融元交换机的开放性,PXE Server所需的组件能全部部署在CX-M上,即一台CX-M设备即可满足PXE的需求。

安装配置

安装配置

安装配置

星融元已通过PXE成功实现了大规模服务器的商业部署、自动化操作系统安装,从安装配置TFTP到准备启动文件、安装配置TFTP、配置HTTP Server、配置启动文件、配置DHCP到最后的验证,都可以在PXE配置文档中学会。

在现代IT环境中,通过PXE自动化流程部署系统可以减少人为错误,有助于提高效率、简化管理并确保一致性,亲手配置试试吧~

技术手册-PXE配置指导手册

相关文章

对星融元产品感兴趣?

立即联系!

返回顶部

© 星融元数据技术(苏州)有限公司 苏ICP备17070048号-2