LLM

Alibaba High Performance Network (HPN) HPN介绍了一种两层的双平面网络，可以在一个Pod中接入1.5w个GPU，通常需要3层Clos架构的网络才能容纳这么多GPU HPN 提出了一种新的双 ToR 设计，以取代传统数据中心网络中的单 ToR 1. 贡献与挑战 挑战 流量模式 传统网络无法应对LLM的低熵、周期性、突发的网络特点，传统的数据中心网络一般是高熵的（传统网络中会存在百万条流，但是每条流的利用率特别低，一半小于20%） ECMP在传统的数据中心的高熵、低利用率的网络中性能表现较好，但是在LLM训练中并不是最佳的 单点故障的敏感性高 LLM训练是一个同步过程，所有GPU合作完成一系列迭代，任何一个GPU发生故障都有可能导致整个训练过程出现问题 对LLM训练影响最大的是与机架顶部（ToR）相关的单点故障，这种故障可能会影响到各种GPU 生产统计数据显示，LLM训练中出现的故障造成的损失是一般云计算故障的 20 倍 贡献 非堆叠的双层ToR网络，可以在两个交换机之间直接同步，很好的改善了大规模部署的可信度 适配最新的51.2Tbps的交换机芯片，可以将1K个GPU部署在Tier 1网络中，使96.3%的训练任务获得高性能的网络 我们的实验表明，使用HPN的LLM训练吞吐量比传统数据中心网络高14.9倍 2. 背景知识 LLM的并行策略 DP：每次迭代使用All Reduce同步计算梯度数据 PP：每次使用Send/Recv传递中间结果 TP：每次迭代使用All Reduce/All Gather同步输出和对应的梯度 LLM的流量特征 带宽利用率周期性突发 流的数量少 传统的数据中心网络不适用于LLM流量模式 LLM对单点故障的敏感性 LLM每次的Checkpoint间隔大概在2-4小时，按照一个3k张GPU的集群计算，每次失败导致的回滚都将导致大约3w美元的损失 常见的监控工具和异常分析工具并不能避免网络产生故障，根据实验表明，在NIC到ToR之间每个月大概有0.057%的Link故障率，在ToR交换机每个月的故障率大约是0.051%，即一个LLM训练集群每个月可能会产生1-2次的Crash，5k-60k次的Link故障 LLM网络架构的建设目标 规模化：达到15K个GPU的规模，未来可以扩展到100K个GPU的规模 高性能：尽可能小的网络跳数，尽可能使用GPU-GPU直达的连接 单点故障容错率：在网络拓扑层尽可能改善单点故障的容错率 3. HPN架构 分为前端网络和后端网络，前端网络主要负责例如管理、接口、存储等网络流量，后端网络负责LLM的训练时的流量 每个Host包含8个GPU，使用NVLink互联，双向带宽达到400GBps-900GBps 每个Host包含9个2x200Gbps的网卡，其中一个连接到前端网络，其余的8个与GPU直连，接入后端网络 每个网卡的2个端口分别连接至不同的ToR网络，这种双ToR设计可以避免单点故障 4. 双ToR网络 传统数据中心的NIC的两个光缆接入一个交换机成为单ToR设计 双ToR设计将NIC的两个光缆接口分别接入不同的ToR交换机中 两个接口配置相同的IP和MAC地址，即使其中一个ToR故障，另外一个依旧可以正常工作 基于以上，同一个NIC的两个网卡共享相同的Queue Pair Context ...

1. 创建docker 1.1 docker命令 显示全部的镜像：docker images 创建一个容器：docker run ...<查看1.2节内容> 显示全部的容器：docker ps -a 启动一个容器：docker start <id> 停止一个容器：docker stop <id> 进入一个正在运行的程序：docker exec -it <id> /bin/bash 删除一个容器：docker rm <id> 1.2 创建容器 创建一个docker容器的时候需要同时挂载本地工作目录和相关的程序驱动，因此创建docker容器的命令参数较多，以下为一个创建docker容器命令的基本格式： docker run -it --ipc=host --name <name> -v <local_path>:<docker_path> \ --workdir=<docker_path> \ --pids-limit 409600 \ --privileged --network=host \ --shm-size=128G \ --device=/dev/davinci0 \ --device=/dev/davinci1 \ --device=/dev/davinci2 \ --device=/dev/davinci3 \ --device=/dev/davinci4 \ --device=/dev/davinci5 \ --device=/dev/davinci6 \ --device=/dev/davinci7 \ --device=/dev/davinci_manager \ --device=/dev/devmm_svm \ --device=/dev/hisi_hdc \ -v /usr/local/Ascend/driver:/usr/local/Ascend/driver \ -v /usr/local/Ascend/firmware:/usr/local/Ascend/firmware \ -v /usr/local/Ascend/add-ons/:/usr/local/Ascend/add-ons/ \ -v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi \ -v /usr/local/dcmi:/usr/local/dcmi \ -v /etc/ascend_install.info:/etc/ascend_install.info \ -v /etc/bashrc:/etc/bashrc \ -p 223:223 \ -p 224:6006 \ -p 225:8080 \ -p 226:8888 \ -u root \ <image_id> /bin/bash -it：已交互方式运行容器，并分配一个终端 ...

参考文献： Narayanan D, Shoeybi M, Casper J, et al. Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM: SC’ 21, November 14-19, 2021, St. Louis, MO, USA \[C\], 2021. ACM, 2021-01-01. 单一的MP或DP无法硬度继续增长的大模型算力需求，面对成千上万的GPU集群规模增长，结合TP、PP、DP等多种方式组成3D Parallelism的并行方式逐渐成为了主流的并行计算框架。 1. 基于Megatron-LM 1.1 研究背景 单一的DP、TP、PP方法无法满足日益增长的模型参数量，因此提出一种基于多种并行方法的PTD-P并行技术。 1.2 实现方法 图. 默认的Pipeline调度（上）和插值的Pipeline调度（下） 对每个设备上运行的网络层进行进一步拆分，每个子集称为一个Chunk，在图（下）中用深色和浅色两种颜色表示 假设一共4个Device，每个Device可以分为4层（例如：在Device 1上运行1~4层，Device 2上运行5-8），则可以将每个设备的计算过程分为两个Chunk（每个Chunk需要计算两层网络）例如：Device 1对应1，2，9，10四层，Device 2对应3，4，11，12四层。 以Device 3为例，为什么运行完Chunk 2的Batch2后需要Wait，而不是直接运行Batch 3？只是为了展示插值的概念？ 1.3 实验结论 提出一种插值Pipeline调度算法，实现在3072个GPU上训练1T参数的训练，总体算力达到502PFLOPS，单个GPU的算力达到了理论峰值的52%。 相比较ZeRO-3（不带MP），因为减少了通信量，在175B和530B规模的大模型上效果要好70% 插值Pipeline调度算法可以增加计算密集度，但是对通信的开销也会增加 PP在较大的模型上效率更高，效果更好，TP的并行方式会增加不同设备之间的通信量 重算技术只是一个为了平衡内存与算力之间可选的技术，会降低内存消耗，但同时也会增加1/3的算力消耗 高度的MP可能会导致较小的矩阵乘运算，降低GPU的利用率 1.4 实验数据 本文对PTD-P模型中，GPU数量、全局Batch Size、Microbatch Size、Bubble Time、Throughput等多个参量进行多角度多变量讨论 ...

参考文献： Huang Y, Cheng Y, Chen D, et al. GPipe: Efficient Training of Giant Neural Networks using Pipeline Parallelism: 33rd Conference on Neural Information Processing Systems (NeurIPS 2019), \[C\], Vancouver, Canada, 2018. Harlap A, Narayanan D, Phanishayee A, et al. PipeDream: Fast and Efficient Pipeline Parallel DNN Training \[J\]. ArXiv, 2018,abs/1806.03377. Kim T, Kim H, Yu G, et al. BPipe: Memory-Balanced Pipeline Parallelism for Training Large Language Models: Proceedings of the 40th International Conference on Machine Learning ...

参考文献： Team D, Majumder R, President V, et al. DeepSpeed: Extreme-scale model training for everyone \[J\]. Microsoft, 2020. Rajbhandari S, Rasley J, Ruwase O, et al. ZeRO: Memory optimizations Toward Training Trillion Parameter Models \[C\], 2020. IEEE, 2020-01-01. Ren J, Rajbhandari S, Aminabadi R Y, et al. ZeRO-Offload: Democratizing Billion-Scale Model Training \[J\]. arXiv.org, 2021. Rajbhandari S, Ruwase O, Rasley J, et al. ZeRO-Infinity: Breaking the GPU MemoryWall for Extreme Scale Deep Learning: SC’ 21, November 14–19, 2021, St. Louis, MO, USA ...