语言大模型的分布式训练与高效微调指南

发布时间：2024年01月18日

原文：语言大模型的分布式训练与高效微调指南 - 知乎

目录

收起

1 分布式训练

2 ZeRO驱动的数据并行

3 全分片数据并行

4 实现

5 高效微调

6 实践指南

7 关于DeepSpeed和FSDP的更多内容


OneFlow编译
翻译｜杨婷、宛子琳

最近语言大模型（LLM）异常火爆，一个非常特别的开源社区正在探索在消费级硬件上微调、提供服务和进行推理的最佳方式。为满足上述需求，出现了许多出色的开源代码库，以HuggingFace生态系统为中心，这些代码库还包括FastChat、Axolotl和LLama.cpp。

本文专注于分布式训练策略的具体细节，特别是DeepSpeed和FSDP，并总结了以多GPU和多节点训练为主的不同高效微调方法。显然，当前的趋势是，我们会使用越来越多的计算资源，因此将需要更多GPU来运行更大的模型。

在这种情况下，理解这些主题尤为重要，尤其是当你想要将几个3090家庭服务器升级到具有8个A100 80GB的GCP容器时，另外，这对于试图微调自己的语言模型的初创公司或企业来说也很重要。大型科技公司进行的实际大规模训练涉及大量资料，这些内容大部分来自主导了BLOOM-176B训练的Stas Bekman，GPU匮乏的用户（即GPU-poors）关注这些资料的意义并不大。

本文从多个优秀的资源中整合了各种观点，着重讨论了HuggingFace生态系统的相关内容，并考虑了一些来自在线资源以及作者本人在2023年暑期实习中所学到的实际情况。

综上，本文希望能够回答以下问题：

1. 在分布式训练和性能优化方面，我们应该关注什么？DeepSpeed和FSDP在背后是如何运作的？2. 不同的分布式训练策略需要的硬件设置和注意事项？

3. 各种有效的微调优化器以及可能存在的权衡？

4. 一些可以覆盖所有重要微调优化的实用指南，用以在多GPU和多节点设置中训练大模型。

5. 现在可以使用的开源代码库以及各自的优缺点？

（本文作者为加州大学圣地亚哥分校计算机科学系的硕士研究生Sumanth R Hegde。以下内容由OneFlow编译发布，转载请联系授权。原文：https://sumanthrh.com/post/distributed-and-efficient-finetuning/?）


1 分布式训练

分布式训练涵盖的范围非常广泛，因此本文无法覆盖所有内容。在训练/微调LLM时，我们通常会面对超10亿参数的庞大模型和大规模数据集（超1万亿词元的预训练数据集，超100万词元的监督微调数据集）。我们最终的目标是尽快完成训练，以最大化吞吐量，即希望能够每秒处理尽可能多的样本。LLM在训练过程中需要大量的GPU显存，不仅仅因为模型参数数量庞大（例如，Falcon 40B拥有40亿参数，在BF16格式下仅模型权重就需要约74GB显存），还因为优化器状态所需的显存——例如，使用普通的AdamW优化器，每个参数需要12个字节来存储模型权重的副本、动量和方差参数。因此，我们需要智能的分布式训练策略，以确保每个GPU worker只需处理部分训练状态和数据。

主要的并行策略有：

1. 数据并行（Data Parallelism, DP）：每个GPU worker获取整个小批量数据的一部分，并在该部分数据上计算梯度。然后在所有worker上对梯度进行平均，以更新模型权重。在其最基本的形式中，比如PyTorch中的DDP，每个GPU存储模型权重的副本、优化器状态以及所处理数据部分的梯度。

2. 模型并行/垂直模型并行（MP）：在模型并行中，模型被分割成多个部分，每个部分被放置在不同的GPU上，这被称为垂直模型并行。举例来说，如果有一个包含12层的单一模型，该模型的不同层会被分别放置在3个不同的GPU上。

---------------  ---------------  -----------------
1 | 2 | 3 | 4 |  5 | 6 | 7 | 8 |  9 | 10 | 11 | 12 |
---------------  ---------------  -----------------

在朴素模型并行（naive model parallelism）中，所有GPU在处理相同的数据批次时都需要等待前一个GPU完成计算，然后才能处理数据。这意味着在任何给定时刻，除了一个GPU外，其他GPU实际上都处于闲置状态（因此称为“朴素”）。为改善这种情况，可以使用流水线并行（PP），这种方式通过让不同微批次数据的计算重叠，给你带来并行的错觉。这类似于计算机架构中的经典流水线。参见以下关于GPipe的博文：

为了在多个加速器上实现高效训练，GPipe将模型划分到不同加速器，并自动将一个小批次的训练样本分成更小的微批次。通过在这些微批次上进行流水线式的执行，各个加速器可以进行并行计算。

3. 张量并行（TP)：在张量并行中，每个GPU通过在GPU worker之间对模型进行水平切片，仅处理张量的一部分。每个worker处理相同的数据批次，计算他们所拥有权重部分的激活值，并交换彼此需要的部分，每个worker计算他们所拥有权重部分的梯度。

我们可以将上述各种并行策略结合起来，以实现更好的吞吐量增益。接下来，我们将更详细地了解两种用于数据并行训练的改进方法：零冗余优化器（Zero Redundancy Optimizer）和密切相关的全切片数据并行策略（Fully Sharded Data-Parallel strategies）。

注释：我将使用术语“GPU worker”来指代在每个GPU上运行的各个进程。虽然这种表述并不十分准确，但在数据并行设置中，这样说更方便，更易于理解。

拓展阅读：

2 ZeRO驱动的数据并行

这是当前最高效、最热门的分布式训练策略之一。DeepSpeed的ZeRO是一种数据并行处理形式，它极大提高了内存效率，其主要思想是利用数据并行训练中的内存冗余和快速GPU间通信的最新改进来提高吞吐量，根据不同阶段，会增加一些通信量。实际上，ZeRO有两个组成部分：ZeRO-DP（数据并行）和ZeRO-R（残留内存）。DeepSpeed团队还提出了一些后续优化措施，这进一步提升了ZeRO的吸引力，例如ZeRO-Offload/Infinity（将计算卸载到CPU/NVMe磁盘）和ZeRO++（实现了灵活的多节点训练和量化权重）。

ZeRO-DP的可视化图表如下（来自DeepSpeed的博客文章）：

在64个GPU上训练7.5B参数模型时，模型表现如下：

  1. 基准：PyTorch DDP

2.?ZeRO 第一阶段/?���?：内存减少4倍（特定示例），与基准的通信量相同（没有额外的GPU间通信）。

3.?ZeRO 第二阶段/?���+�?：内存减少8倍（特定示例），与基准的通信量相同。

4.?ZeRO 第三阶段/?���+�?：内存减少64倍（特定示例），通信量为基准的1.5倍（这里的1.5倍针对的是不同硬件设置和模型大小）。

基准

PyTorch DDP实现了简单的数据并行性。每个GPU worker都有模型权重、优化器状态和梯度的副本。后向传播后，各个worker间的梯度会被平均化（即全局归约（all-reduce）），并且模型权重会被更新。

关于通信量的注释：为理解ZeRO的好处，我认为，重要的是要明确通讯量的确切含义。典型DP中存在一个全局归约步骤，其中每个worker都会发送出其所拥有的梯度数组，然后接收其他worker的梯度数组，以获得平均值。下文摘自ZeRO论文：

当前最先进的全局归约实现采用了两步操作：第一步reduce-scatter，它在不同进程上的数据的不同部分会被归约。第二步是all-gather，其中每个进程都在这一步中收集所有进程上的归约数据。这两步的结果就是全局归约。同时，reduce-scatter和all-gather都采用了流水线方式实现，这导致每个步骤需要Ψ个元素（对于具有Ψ个元素的数据）的总数据搬运量。因此，在标准的数据并行性中，每个训练步骤会产生2Ψ的数据搬运量。

在这种情况下，“数据”指的是我们的梯度，而进程指的是每个GPU上运行的单个worker。总而言之，我想表达的是：如果你有Ψ个参数，那么普通数据并行性将产生2Ψ通信成本。

ZeRO 第一阶段/Pos（优化器状态分区）

在这种情况下，只有优化器状态在GPU worker之间进行了分区/分片，而模型权重和梯度在所有worker之间进行了复制。反向传播后，需要进行一次常规全局归约，以便在所有worker间获取平均梯度值。然后，每个worker更新其分区中的优化器状态。Adam方程如下。

(w、g、v 和m 分别对应权重、梯度、速度和动量)。需要注意的是，这些都是逐元素操作，在计算梯度后，各个权重分片之间并没有依赖关系。

通信量：首先我们会执行一次全局归约操作，将更新后的梯度通信给所有GPU，然后，在更新各自分片的优化器状态之后，每个GPU仍需要从其他GPU获取更新后的权重。ZeRO论文并没有清楚表明这样做是否会增加通信量。在我看来，对ZeRO的第1阶段和第2阶段来说，这种实现实际上是一样的：

  • 梯度的全局归约由两部分组成：reduce-scatter和all-gather。
  • 在DeepSpeed ZeRO1和2中，首先进行reduce-scatter操作，在不同GPU上分别减少梯度的不同部分。接着，每个GPU计算其所管理的优化器分区对应的更新后权重，之后我们只需进行一次all-gather操作，将更新后的模型参数传播给所有其他GPU。这样就能在通信量不变的情况下，减少内存消耗。

ZeRO Stage 2 /?���+�

（优化器状态+梯度分区）

在这种情况下，优化器状态和梯度都被分区/分片到不同的worker上。这意味着，两个GPU worker在训练期间不仅要关注不同的微批次数据，还要维护模型参数子集的梯度。关键在于，每个worker都在更新其优化器状态的分区，因此对于一个worker而言，它所需的梯度（或者说，经过归约/平均的梯度）只是对应于该状态分区的梯度。至于实现方式，正如上面提到的，DeepSpeed有效地执行了reduce-scatter操作，其中每个worker对应的梯度在该worker处被平均（而不是对所有参数进行典型的all-reduce操作）。这意味着，在相同通信量下节省了更多内存，也就是说，与DDP相比，这里没有额外的数据搬运成本。

注意：在使用ZeRO Stage 1和2时，仍然需要整个模型适配单个GPU。此外，在使用RAM时，需要注意如下事项：随着进程/GPU数量的增加以及模型大小的扩展（超过40亿参数），模型初始化会占用大量RAM。ZeRO 3对此有所改进。

ZeRO Stage 3 /?���+�+�

（优化器状态+梯度+参数分区）

对我来说，这是ZeRO最有趣的阶段。除优化器状态和梯度外，第3阶段还跨worker划分了模型参数。来自DeepSpeed的可视化图表如下：

使用4个GPU实现不同训练状态的可视化

使用DeepSpeed ZeRO-3对训练状态分片

借用Stas Bekman指南中的一个例子，假设有以下3层模型和4个GPU：

?La | Lb | Lc
---|----|---
a0 | b0 | c0
a1 | b1 | c1
a2 | b2 | c2
a3 | b3 | c3

使用DeepSpeed ZeRO 3，GPU的配置方式如下：

GPU 0:
La | Lb | Lc
---|----|---
a0 | b0 | c0
?
GPU 1:
La | Lb | Lc
---|----|---
a1 | b1 | c1
?
GPU 2:
La | Lb | Lc
---|----|---
a2 | b2 | c2
?
GPU 3:
La | Lb | Lc
---|----|---
a3 | b3 | c3

在ZeRO-3中，模型的每一层都被水平切片，每个worker存储权重张量的一部分。在前向和后向传播过程中（每个GPU worker 仍然看到不同的微批次数据），不同的GPU worker交换它们所拥有的每一层的部分（按需进行参数通信），并计算激活/梯度。

其余部分类似ZeRO Stage 2。很容易看出，ZeRO-3的通信量是基准DDP的1.5倍：在每个训练步骤中，我们需要在前向传播中额外进行一次模型参数的all-gather操作。在这个操作中移动的数据量为Ψ（每个GPU），因此总通信量为Ψ（参数all-gather）+Ψ（梯度reduce-scatter）+Ψ（all-gather，用于更新的参数）= 3Ψ= 1.5倍DDP。考虑到内存消耗被GPU workerN 削减，这给人留下了深刻印象。ZeRO论文的另一个关键洞察如下：

只要有足够的设备来共享模型状态，ZeRO就可以使DP适应任意大小的模型。

也就是说，只要有足够多的GPU，在进行数据并行（DP）训练时，我们就不会再受到每个GPU显存的限制（说起来容易做起来难）。

ZeRO-R

我并不想深入探讨这一话题，但ZeRO-R在ZeRO-DP的基础上，通过关注激活的内存消耗和管理内存碎片化做了改进提升。ZeRO-R通过对激活进行分区，减少了激活的内存占用。此外，它还在管理临时缓冲区方面进行了一些改进，你可以将之视为在worker间进行梯度累积和归约期间分配用于存储中间结果的内存。

ZeRO-Offload

ZeRO-Offload是一种优化技术，可以将优化器和计算从GPU卸载到主机CPU上。在2021年1月发布时，ZeRO-Offload可在1个NVIDIA V100 GPU上实现40 TFLOPS（V100 32 GB vRAM，最大吞吐量为130 TFLOPS），适用于10亿参数模型。而采用PyTorch DDP时，最大值为30 TFLOPS，适用于14亿参数模型，在不耗尽内存的情况下，这是可以运行的最大模型。将计算卸载到CPU的主要问题是，以吞吐量衡量，CPU要比GPU慢上多个数量级。ZeRO-Offload采用的这种策略是，只将较少的密集计算（<< O(MB)，其中M 是模型大小，B 是批次大小）卸载到CPU，以使总计算复杂度保持不变（O(MB)）。在实践中，这意味着诸如范数计算（norm calculation）、权重更新等操作可以在CPU上完成，而前向和后向传播的矩阵乘法需要在GPU上完成。ZeRO-Offload适用于ZeRO的所有阶段（1、2和3）。

这里（https://docs.it4i.cz/dgx2/introduction/）给出了用于实验的DGX-2节点规格，该节点配备了16个V100 GPU。需要注意的是，如果处于ZeRO-2设置中，ZeRO-Offload仍然会受到每个GPU可用内存的限制，即在每个GPU上容纳整个模型可能成为瓶颈。

ZeRO-Infinity

ZeRO-Infinity是ZeRO-Offload的改进版本，于2021年4月推出。它允许将计算卸载到磁盘（NVMe内存），并对CPU卸载进行了改进。研究表明，ZeRO-Infinity在一个DGX-2节点上训练时，可以适应10-100万亿参数的模型（万亿级别！）。ZeRO-Infinity通过同时利用CPU和NVMe内存来实现这一点。以下是论文中的可视化图表：

以上是ZeRO Infinity在4个数据并行排布（GPU）上的截图，描述了反向传播期间的状态。分区/分片的参数从慢速内存（CPU+ NVMe）移动到GPU，然后被收集起来形成完整的层。在梯度计算之后，它们被聚合、重新分区，然后卸载到慢速内存。分区/分片的参数从慢速内存（CPU+ NVMe）移动到GPU，然后被收集起来形成完整的层。在梯度计算之后，它们被聚合、重新分区，然后卸载到慢速内存。

与ZeRO-Offload不同，ZeRO-Infinity是基于ZeRO-3专门构建的。作者在32个DGX-2节点、512个GPU上对模型速度进行了评估。结果表明，ZeRO-Infinity可训练高达20万亿参数的模型，每个GPU的吞吐量可达49 TFlops，而3D并行等替代并行策略可训练的模型规模要小40倍。ZeRO-Infinity要想成为有竞争力的选择，需要满足一些带宽要求，即NVMe-CPU和CPU-GPU通信。

关于ZeRO-Offload和ZeRO-Infinity之间的差异，以下是DeepSpeed团队的评论：

DeepSpeed首先包含了ZeRO-Offload的卸载功能，ZeRO-Offload是一个用于将优化器和梯度状态卸载到ZeRO-2内的CPU内存的系统。ZeRO-Infinity是ZeRO-3可以使用的下一代卸载功能。相比ZeRO-Offload，ZeRO-Infinity能够处理更多数据，能更有效地利用带宽，并且能更好地实现计算和通信重叠。

默认情况下，使用ZeRO-3进行卸载时，ZeRO-Infinity的优化机制会自动生效；使用Stage 1/2进行卸载时，ZeRO-Offload会生效。

拓展阅读：1. ZeRO-Offload/Infinity 教程:https://www.deepspeed.ai/tutorials/zero-offload/

2. ZeRO-Offload - 十亿级模型训练大众化 :https://arxiv.org/abs/2101.06840

3. ZeRO-Infinity - 打破GPU内存墙，实现超大规模深度学习:https://arxiv.org/abs/2104.07857

ZeRO++

ZeRO++是DeepSpeed团队对ZeRO-3的最新改进。主要改进如下：

1. 量化权重（qwZ）：通过将模型权重量化为int8，将all-gather参数通信量减少一半。

2. 层次划分 (hpZ)：层次划分是一种混合分区方案，适用于DeepSpeed ZeRO 3的多节点设置。在这种情况下，模型参数会在一个节点内分片，然后在不同节点之间复制。这意味着，与典型的ZeRO-3全面运行相比，我们无法节省相同数量的内存，但可以避免昂贵的节点间参数通信开销，从而提高整体吞吐量。我更倾向于FSDP中使用的 "混合分片（hybrid sharding）" ，而非 "层次划分"，下文讨论FSDP时，会再次深入讨论这个问题。

3. 量化梯度（qgZ）：通过在梯度reduce-scatter操作中使用int4量化数据替换fp16，可以节省更大通信量。（回顾：这是发生在ZeRO 2/3阶段，针对分片梯度进行的梯度聚集和平均）

总体而言，与ZeRO-3 相比，ZeRO++通过这三项改进将通信量减少了4倍。

拓展阅读：

1. ZeRO：训练万亿参数模型的内存优化:https://arxiv.org/abs/1910.02054

2. ZeRO教程:https://www.deepspeed.ai/tutorials/zero/

3. ZeRO++：针对巨型模型训练的超高效集体通信:https://arxiv.org/abs/2306.10209

4. ZeRO++教程:https://www.deepspeed.ai/tutorials/zeropp/

3 全分片数据并行

全分片数据并行（FSDP）是另一种旨在提高内存效率、减少通信计算开销以提高吞吐量的数据并行技术。FSDP的分片策略基于Xu等人和ZeRO的想法。FSDP有两种分片策略：全分片（Full Sharding）和混合分片（Hybrid Sharding）。

全分片

这基本上与ZeRO-3相同，其中参数、优化器状态和梯度被分片到各个worker或设备上。下图来自FSDP博客，展示了两个设备之间不同操作的低层次可视化。

正如你所看到的，每个worker/设备仅持有权重的子集，并且可以按需进行参数通信来计算中间激活和梯度。以下是来自PyTorch的FSDP教程：

“在前向传播中运行all_gather从所有rank中收集全部分片，以恢复该FSDP单元中的完整参数运行前向计算丢弃刚刚收集的参数分片

在后向传播中运行all_gather从所有rank中收集全部分片，以恢复该FSDP单元中的完整参数运行后向计算运行reduce_scatter以同步梯度丢弃参数”

此处，“rank”指的是一个GPU worker。

下图是另一篇论文中有帮助的可视化图，特别是对比了全分片和混合分片：

混合分片

混合分片包括分片和复制。这意味着，对于给定数量的worker/ GPUW，分片仅在大小为F 的子集之间发生，并在不同子集之间复制。

具体来说，假设我们想要跨2个节点进行多节点训练，每个节点在GCP中都是一个a2-ultragpu-8g节点。每个节点有8个A100 GPU，共有16个worker。那么可以使用混合分片在每个节点内部对模型参数进行分片，然后在节点之间复制。这意味着，在每个前向/反向传播中，每个节点内部有类似的all-gather和reduce-scatter操作，即从其他GPU获取模型参数（节点内部），并计算中间激活和梯度。然后，我们需要进一步在节点之间进行另一个all-gather操作，以获得在该训练步骤中处理的总小批量数据的平均梯度值。当我们被迫处理分片参数（即不能选择ZeRO 2/1时），并处于多节点设置中时，这种方法尤其有吸引力。这类似于ZeRO++中的“层次划分（hierarchical partitioning）”。

4 实现

如何使用DeepSpeed和FSDP？

DeepSpeed ZeRO/FSDP的主要优势之一在于，当实际上只处于数据并行设置时，我们可以在数据+张量并行的情况下节省内存，提升吞吐量。这意味着，我们无需进行任何临时的架构更改，也无需通过混乱的`.to()`设备转换或任何定制操作来改变前向传播过程。因此，ZeRO/FSDP可以在不同的架构中运行，实现良好的集成效果。ZeRO是在微软的DeepSpeed库中实现的，并已整合到Accelerate库中。而FSDP则是PyTorch本身的一部分，同样也整合到了Accelerate库。因此，我们可以使用Trainer API（其后端使用了Accelerate）中的任一策略，或者直接使用Accelerate。

流水线并行和张量并行？

目前，流水线并行（PP）和张量（TP）并行需要进行架构更改和/或调整模型的前向传播过程。如果想要在DeepSpeed中使用流水线并行，那么则需要更改模型的架构定义。

此外，由于Transformers库为每个模型实现了数十种特性，这使得对其进行集成变得非常复杂。当然，我们已经可以通过device_map="auto"实现朴素模型并行，但在使用多个GPU时，这是一种非常糟糕的策略，它只在模型无法适配单个GPU的情况下才有意义（否则最好还是只使用单个GPU）。如果确实需要流水线并行和张量并行，那么目前最好的选择是使用Megatron-LM，并专注于他们支持的模型（如BERT、GPT-2、T5、Llama）。

此外，还可以在Megatron-DeepSpeed中使用ZeRO支持的DP、DeepSpeed PP和Megatron TP，但这些方法仅适用于基于BERT、GPT-2和T5的模型训练。Stas Bekman曾试图在HuggingFace中实现流水线并行和张量并行，但未能成功。以下摘自Stas Bekman的博文：

Transformer现状：目前的情况是，没有一个模型支持完全的流水线并行（full-PP）。GPT2和T5模型具有朴素模型并行（naive MP）支持。目前的主要障碍是无法将模型转换为nn.Sequential，并将所有输入转化为张量。因为目前模型中包含许多特性，这些特性使转换变得非常复杂，因此我们需要删除特性才能实现转换。

我们已经尝试了开源，但这个问题太过棘手，尽管已向Stas Bekman求助，但仍未能解决。

DeepSpeed ZeRO和FSDP会继续存在吗？

我认为，由于其易用性，DeepSpeed的ZeRO和PyTorch的FSDP很可能会被保留下来，或者说只会被非常相似的策略取代。在语言大模型领域，变化是唯一的不变。

随着新模型、架构、注意力实现、位置嵌入改进等的出现，能够在几小时内用一个架构替换另一个架构，并在10M个样本上训练40亿+参数的模型变得非常重要。即使新的DP + PP + TP策略最终能够实现比ZeRO驱动的DP更高的吞吐量，可能也不会有太多的采纳量。出于相似原因，我认为，DeepSpeed ZeRO和FSDP会获得更多关注度，它们的吞吐量将进一步优化，甚至可能出现针对纯数据并行类别的定制计算集群配置。因此，如果我们坚持仅采用DP，结果不会太差。

（当然，这与OpenAI、Anthropic等所进行的超大型语言模型训练无关）

5 高效微调

这又是一个热门话题！接下来我将简要列举一些最受欢迎的优化方法：

混合精度

对于大模型训练而言，这是一个不言而喻的选择。简而言之，权重、激活和梯度以半精度格式存储，同时你有一个FP32/单精度格式的“主副本”权重。两种常用的半精度格式是BF16（由Google Brain开发的“Brain Float 16”）和FP16。FP16需要额外的损失扩展以防止梯度下溢，而BF16似乎不存在这些问题。

拓展阅读：

  1. 混合精度训练：https://arxiv.org/abs/1710.03740
  2. 性能和可扩展性：如何适配更大的模型并进行更快的训练：https://huggingface.co/docs/transformers/v4.18.0/en/performance

参数高效微调（PEFT）

PEFT旨在通过冻结大部分模型权重，将其中的子集/少量额外参数设置为可训练，从而在微调过程中降低内存需求。LoRA是最流行的PEFT，其中对模型参数进行了低秩版本的权重更新微调。

另一种有效的PEFT是IA(3)，它在基于Transformer体系结构中的键、值和前馈层中注入可训练向量。对于LoRA和IA(3)，添加的权重/向量可以与基础权重合并，这意味着，在推理时无需进行额外的计算（加法/乘法）。不足之处在于，其性能可能不及完全微调时的性能。然而，这一情况已迅速改变，实际上，只要你向所有线性层添加可训练权重，基于LoRA的方法可以达到完全微调的性能。

就IA(3)而言，在我对GPT-2（770M）这样的小型模型进行的实验中，发现IA(3)可以在可训练参数的数量不到1/10的情况下与LoRA的性能相匹配。然而，这仍需要更多社区实验，尤其是在LLama-2-7B或Falcon-40B的规模上。

拓展阅读：

IA3概念指南：

Flash Attention

Flash Attention是一种快速（速度得到提升！）、内存高效（节省内存！）、精确（无需近似！）、IO感知（通过考虑GPU内存的不同级别进行读/写操作！）的注意力算法。 使用 Flash Attention 2（自2023年7月份推出），你可以在A100 80GB上获得220 TFLOPS以上的性能（其最高性能为315 TFLOPS）。 换句话说，当Flash Attention 1在2022年中问世时，它拥有当时可达到的最佳吞吐量，最高可达124 TFLOPS。 此外，根据我们之前研究的部分DeepSpeed ZeRO论文，预计在2021年，Tesla V100的可实现峰值吞吐量约为70 TFLOPS！

目前，Flash Attention支持Ampere、Ada或Hopper NVIDIA GPU（如A100、RTX 3090、H100等），且仅支持半精度数据类型bf16/fp16。要在Transformers中使用Flash Attention，只需对LLama和Falcon进行一处更改（将use_flash_attention=True?传递给AutoModel）。对于其他模型，则需手动将forward中使用的注意力函数改为Flash-attention的高吞吐量版本，不过这一点正在快速取得进展。Flash Attention很快将集成到PyTorch的?scaled_dot_product_attention?中，这样就不必再依赖猴补丁（monkey patches）。（这本应在v2.1版本中实现，但有望在不久的将来实现）

Flash Attention v1.0集成在Optimum中也已经有一段时间了，但不能使用填充词元（padding tokens），这使得它的作用非常受限。

拓展阅读：

梯度/激活检查点

通常情况下，每次在前向传播中，所有中间激活都会被保留在内存中，因为它们在计算反向传播时是必需的。梯度/激活检查点（checkpointing）是一种通过仅保留部分中间激活，并根据需要重新计算其余部分来减少内存消耗的技术。其中牵涉到的权衡是额外的重新计算时间。据HuggingFace提供的经验法则，梯度检查点会使训练减慢约20%。当模型层数为N 时，激活的内存需求从O(N)下降到?�(�)?。当然，因为总内存中存储的不仅仅是激活，所以内存消耗可能没有那么大。

拓展阅读：

量化

量化是黑客的最爱，主要有两种量化方法，下面我将简要介绍：

  • 后训练量化（PTQ）：旨在实现高效推断。LLM.int8()，GPTQ就属于这一类。

  • 量化感知训练：从术语的原始意义出发，这意味着从一开始就使用量化的权重和激活来训练模型，以备后续推理使用。这正是我们想要的 ——一种使用量化参数进行训练的策略。QLoRA属于这一类（在某种程度上，因为它将量化整合到训练过程中）。QLoRA主要将基础预训练模型权重量化为8/4bits，然后以浮点半精度/全精度训练额外的LoRA参数。这是一种十分强大的策略，能在单个拥有48GB vRAM的GPU上微调超过600亿参数的模型。当然，需要注意的是，其吞吐量会大大降低。原因很简单：每当计算给定层的激活时，都会发生额外的去量化步骤（具体数字取决于硬件设置。例如，你可能能够在8个A100上运行DeepSpeed ZeRO 3的Falcon-40B训练时不进行量化，在这里单独使用量化毫无意义，即使你可以获得更好的批次大小。不过，在只有2个A100的情况下就不一样了）。

补充信息：完整的QLoRA论文值得一读。他们的方法除了能在消费级GPU上训练65B参数的模型（这是当时最大的开源语言模型）之外，该论文还表示，基于LoRA的训练可以与完全微调相媲美（他们增加了更多可训练的层，但通过对基础权重进行量化使其比原始LoRA配置更高效），并且数据集的质量在监督微调中至关重要（450K FLAN样本比9K高质量人工标注样本更糟糕）。

拓展阅读：

梯度累积

梯度累积是一种提高有效批次大小的方法，尽管吞吐量会有所下降（有时甚至会下降至零）。

比如，假设你的批次大小为2，梯度累积步长为4。使用梯度累积，你会在每个训练步骤中进行常规的前向和后向传播，但是，你会在每4个训练步骤中调用一次优化器步骤（在PyTorch中为optimizer.step()）。这意味着，在4个步骤中会进行梯度累积，然后使用这8个样本的平均梯度更新模型权重。这样一来，你的批次大小增加了，这使得权重更新变得更加平稳，但内存消耗保持不变。实际上，使用多GPU/多节点训练的梯度累积可以增加批次大小，同时加快训练速度。因为在正常训练中，梯度在本地（由GPU处理的批次）被局部平均，并且每个训练步骤都需执行一次全局归约。而使用梯度累积，你可以在更大的间隔（即gradient_accumulation_steps）上执行这一全局归约操作。减少此类全局归约可降低worker间的通信负担（可能还包括节点间的通信），进而提高训练速度。

拓展阅读：

是否应该一直尝试增加批次大小？

阅读完我们讨论的所有内容之后，这是一个吸引人的问题。答案是：否！要记得，我们的目标是尽可能快地使用现有硬件，训练出可能的最优神经网络。因此，即使你只使用了可用GPU内存的75%（例如在A100中为60GB/80GB），也可能已经达到了系统中的最大吞吐量。这意味着，进一步增加批次大小将导致相应时延的增加，结果是吞吐量不会提高，甚至可能降低。此外，即使你有一套强大的硬件配置来训练40B+参数的模型，仅通过上述内存优化来增加批次大小还不够，因为这可能会影响收敛性能。因此，很难针对大模型展开一项良好的研究。

在Transformer时代之前有一篇论文（https://openreview.net/forum?id=H1oyRlYgg）显示，大型批次大小可能会影响泛化性能。DeepSpeed提到，你可以找到更好的超参数/优化器选择，使更大型批次大小发挥作用，正如1-cycle 学习速率调度指南（https://www.deepspeed.ai/tutorials/one-cycle/）所证明的那样。DeepSpeed的一位作者还提出，为使大规模训练运行达到目标收敛速率，全局批次大小通常是固定的。总之，更大型的批次大小并不一定更好！

到底多大的批次大小算大？

便于参考，BLOOM-176B预训练采用了366B个词元，全局批次大小为2048。尤其是在微调阶段，目前还不清楚批次大小大到何种程度才会影响模型的收敛。

6 实践指南

总结

综上所述，以下是尝试在1000万以上规模的数据集上对10-100B+模型参数进行实验和微调的实用指南（我有DeepSpeed的经验，尚未使用FSDP，所以我将重点放在这上面）：

  • 默认情况下使用BF16/ FP16。BF16基本不需要其他配置参数，通常不会出现任何溢出问题（相反，FP16可能会因不同的损失扩展因子导致不同的结果，并且由于动态范围较小，可能出现更多的溢出问题），因此非常方便。
  • 使用LoRA，并将可训练参数添加到所有线性层。如果你想紧密遵循QLoRA，可在这里（https://github.com/artid?oro/qlora/blob/7f4e95a68dc076bea9b3a413d2b512eca6d004e5/qlora.py#L248）使用他们的实用函数。
  • 如果你GPU支持Flash Attention，那么可以使用它。目前，Flash Attention 2可在HuggingFace的Llama 2和Falcon上使用，其他模型可能需要进行调整。
  • 使用梯度/激活检查点。这将略微降低吞吐量。如果你使用了Flash Attention，可能就不需要梯度检查点。参考Flash Attention论文（另见Tri Dao的建议，https://github.com/EleutherAI/gpt-neox/pull/725#issuecomment-1374134498）。

  • 在你的数据加载器中使用高效的采样器，如多重包采样器（multi-pack sampler）。
  • 如果你有多个GPU，首先尝试使用BF16+LoRA+梯度检查点+DeepSpeed ZeRO 3。
  • GPU内存有限时，可使用量化。QLoRA风格的训练目前仅适用于DeepSpeed ZeRO 1/2。因此，即使它在模型参数方面非常高效，但在ZeRO 1/2中仍有参数冗余，并且吞吐量也会减少。
  • 随着GPU的增加（如8个V100或A100），DS ZeRO-3成为了最佳选择。DS ZeRO-2也不错，但你可能会受到CPU内存限制的影响（在模型初始化期间），因为模型参数会在所有工作节点上被复制。例如，如果要在具有8个GPU的节点上使用Falcon-40B模型，那么CPU内存需要超过1.5TB，而云容器实例（AWS、GCP等）很少有这么大的内存，所以会受到限制。当然，在家用服务器上可能不适用，因为家用服务器没有用于GPU间通信的NVLink。DS ZeRO-3具有更多的GP间通信，因此NVLink很重要。
  • 在小规模多节点设置中，启用了层次分区（或FSDP的混合分片）的DeepSpeed ZeRO-3似乎是最佳选择。如果你有Infiniband互联，大多可以使用普通的DeepSpeed ZeRO-3，并用于更大模型。
  • 如果在上述所有优化之后仍然批次大小不足，应该使用梯度累积。对于大模型和多GPU/多节点设置，梯度累积可加快训练时间。
  • 如果你的GPU内存非常有限，可以激活CPU/磁盘卸载（通过硬盘，这必须是ZeRO-Infinity 的NVMe）。随着Flash Attention 2的出现，我们需要对纯GPU训练和GPU + NVMe/CPU卸载之间的吞吐量差距进行另一项研究。我怀疑现在这个差距比以前大得多，因此只有在真正受限的情况下才进行卸载（这就是为什么这是要尝试的最后一个优化）。ZeRO-Infinity 优于ZeRO-Offload，对于这一点你必须使用ZeRO Stage 3。
  • 计算有效的批次大小，并相应调整超参数。一个通用的指导原则是，随着有效批次大小的增加，要增加学习率。正如OpenAI的微调文档中提到的，即使对于100B+的模型，这似乎仍然成立。
  • 最后，在开始训练时，使用?htop?监控RAM使用情况（有时会出现RAM OOM问题），同时使用?nvidia-smi?确保GPU没有被数据预处理拖慢（你应该争取接近100%的GPU利用率，即使GPU内存使用较少）。

关于超参数的更多内容：以下为学习率缩放的相关评论。事实证明，在预训练过程中，随着模型的增大（比如100B+），即使使用了更大的批次大小，通常来说，我们还是应该降低而非增加学习率，这一点可以在OpenAI的GPT-3论文和BLOOM论文中得到证实。要建立对这种模式的直觉十分困难，因此我们只能采取非常实证的方法，如果实验结果与之相悖，就迅速更新所有先验知识。

补充指南

在Transformers的文档中提供了许多关于性能和可扩展性的有用技巧。如果你关心在家搭建和管理服务器时可能遇到的问题，或者NVLink的具体作用，又或者想深入了解内存管理，这些内容都非常有价值。Stas Bekman系列（https://github.com/stas00/ml-engineering）收录了许多与调试和性能相关的实用提示，可能会有所帮助。

7 关于DeepSpeed和FSDP的更多内容

使用DeepSpeed ZeRO-3进行多节点训练

对于普通ZeRO-3，你需要确保跨节点的参数通信不会成为一个巨大的瓶颈，否则，即便使用两个节点，吞吐量的提升可能也非常有限。通过Stas Bekman的调查，我们对需要具备怎样的跨节点网络有了清晰的认识：

对于大小为M?的模型，有N?个节点，每个节点有G?个GPU，每个节点在每个训练步骤中发送约48*M/Nbits的数据。即便是对于两个8xA100节点，配备一个40B参数模型，每个节点在每个训练步骤中通信的数据量就达到了120GB！对于大规模训练（64GPU+），确实需要具备1000Gbps的InfiniBand互连。对于较小规模的多节点训练，可选择100-400Gbps的带宽。在亚马逊EC2 P4d实例（配备了8个A100，用于机器学习训练的节点）上，通常使用弹性网络适配器（Elastic Fabric Adapter，EFA）作为跨节点的网络接口，根据规格，你可以获得高达400Gbps的网络带宽，这相当不错！实际上，你获得的确切带宽约为340Mbps，因此应该规划使用规格中列出的最大带宽的80-85%。用于AWS P5实例的EFA v2配备了H100，速度快了整整8倍。

要测算你所获得的跨节点网络带宽，可使用Stas Bekman的实用函(https://github.com/stas00/ml-engineering/blob/9a51114f8377350bfbf1764f23feac441e865401/multi-node/all_reduce_bench.py）。这个函数专门用于对所有归约操作进行基准测试，因此能够准确测试训练过程中所能看到的情况。

建议：在没有Infiniband的情况下，最好使用ZeRO++和层次分区（hpZ）。要实现这一点，你需要将zero_hpz_partition_size?配置参数设置为每个节点的GPU数量/rank。例如，如果你使用两个节点进行训练，每个节点有8个A100 GPU，那么zero_hpz_partition_size?将设置为8。

Accelerate/Transformer 支持：目前尚不清楚加速DeepSpeed集成是否支持层次分区（hpZ）。表面上看，应该支持，因为加速应该整合DeepSpeed ZeRO的所有功能，而hpZ只是DeepSpeed配置文件中的一个参数更改。我已经提了一个issue（2023年10月1日），如有需要，我会更新这篇帖子。

对于FSDP，你将使用混合分片策略（HYBRID_SHARD）。对于多节点训练（至少是小规模的，没有Infiniband的情况下），这似乎是一个不错的选择，但有用户通过艰难的方式发现了这一点。Accelerate已经支持带有混合分片的FSDP。

DeepSpeed 内存需求

当你拥有新的基础架构设置，并希望尝试DeepSpeed时，绝对应该使用DeepSpeed的内存估算器。

DeepSpeed ZeRO 1/2

deepspeed.runtime.zero.stage_1_and_2.estimate_zero2_model_states_mem_needs_all_live(model,
  num_gpus_per_node=1, num_nodes=1, additional_buffer_factor=1.5)

使用默认缓冲因子（这是一个简单地扩展所有CPU和GPU内存估算的估算因子），对于一个拥有3B参数的模型，在拥有1个节点和8个GPU的环境中，你将得到以下结果，来自于DeepSpeed文档：

python -c 'from transformers import AutoModel; \
from deepspeed.runtime.zero.stage_1_and_2 import estimate_zero2_model_states_mem_needs_all_live; \
model = AutoModel.from_pretrained("t5-3b"); \
estimate_zero2_model_states_mem_needs_all_live(model, num_gpus_per_node=8, num_nodes=1)'
?
Estimated memory needed for params, optim states and gradients for a:
HW: Setup with 1 node, 8 GPUs per node.
SW: Model with 2851M total params.
  per CPU  |  per GPU |   Options
  127.48GB |   5.31GB | offload_optimizer=cpu
  127.48GB |  15.93GB | offload_optimizer=none

以Falcon-40b为例，使用ZeRO 1/2所需的CPU RAM大于1.5TB。你无需实际运行训练/微调代码来测试这一点，只需使用上述模型和硬件设置运行上述命令，就会得到一个估算。对于FSDP，我没有找到类似的内存估算器，因此可直接使用DeepSpeed ZeRO-3对FSDP的全分片估算。

注意：再补充一点关于CPU RAM不足的情况。这可能很难调试，因为你的进程将在日志中没有任何信息的情况下失败。添加PyTorch分布式调试标志（NCCL_DEBUG=INFO, TORCH_DISTRIBUTED_DEBUG=INFO?）也无济于事，因为这是一个RAM问题。我只是在初始训练阶段通过监视htop（如前文所述）发现了这一困难。

DeepSpeed ZeRO 3

python deepspeed.runtime.zero.stage3.estimate_zero3_model_states_mem_needs_all_live(model, \
  num_gpus_per_node=1, num_nodes=1, additional_buffer_factor=1.5)

在一个节点上，每个节点有8个GPU的硬件设置下，对于一个包含3B参数的模型，使用以下命令可以估算参数、优化状态和梯度所需的内存：

python -c 'from transformers import AutoModel; \
from deepspeed.runtime.zero.stage3 import estimate_zero3_model_states_mem_needs_all_live; \
model = AutoModel.from_pretrained("t5-3b"); \
estimate_zero3_model_states_mem_needs_all_live(model, num_gpus_per_node=8, num_nodes=1)'
?
Estimated memory needed for params, optim states and gradients for a:
HW: Setup with 1 node, 8 GPUs per node.
SW: Model with 2851M total params, 32M largest layer params.
  per CPU  |  per GPU |   Options
   71.71GB |   0.12GB | offload_param=cpu , offload_optimizer=cpu , zero_init=1
  127.48GB |   0.12GB | offload_param=cpu , offload_optimizer=cpu , zero_init=0
   63.74GB |   0.79GB | offload_param=none, offload_optimizer=cpu , zero_init=1
  127.48GB |   0.79GB | offload_param=none, offload_optimizer=cpu , zero_init=0
    1.47GB |   6.10GB | offload_param=none, offload_optimizer=none, zero_init=1
  127.48GB |   6.10GB | offload_param=none, offload_optimizer=none, zero_init=0

这也让你对不同的卸载策略和初始化有了一个概念！使用zero_init=1?时，模型权重将以一种内存可扩展的方式初始化，一旦分配后，权重将立即在你的worker之间分区。当zero_init=0?时，CPU RAM需求可能会飙升（对于10B+模型和多个GPU来说可能会达到TB 级别），因此你绝对应该使用zero_init=1。在多GPU设置中使用CPU卸载也会增加大量RAM的需求，并且可能导致RAM OOM。使用估算器，之后如果确实需要，如CPU RAM不足的话，可以切换到NVMe卸载。

使用Accelerate

Accelerate 旨在提供一个统一的界面，用于启动各种分布式训练运行，同时为你提供在纯 PyTorch中编写代码的灵活性。目前看来，如果你打算在FSDP和DeepSpeed之间切换同一段代码，可能会有一些注意事项。例如，对于FSDP，你必须在实例化优化器之前调用accelerator.prepare(model)。我不确定相同的方法是否适用于 DeepSpeed（对于 DeepSpeed，你可以对一切进行.prepare()调用）。还有一些其他注意事项，这里就不展开了，但可以查看以下Accelerate的文档。

拓展阅读：1.使用Accelerate进行FSDP：https://huggingface.co/docs/accelerate/usage_guides/fsdp

2.使用PyTorch FSDP对Llama 2 70B进行微调：https://huggingface.co/blog/ram-efficient-pytorch-fsdp

8开源代码库

短短几个月内，开源代码库已取得了长足进步。在这里，我主要想回答“如果我想立即开始使用开源代码库进行微调，可以使用什么？应该牢记什么？”等问题。如往常一样，细节决定成败。接下来我将总结FastChat和Axolotl的平台功能，这是两个最实用、最受欢迎的平台。

FastChat

FastChat是一个用于微调、服务和评估LLM-based chatbots from LMSys的平台。其功能包括：

Serving

你可以使用FastChat为Llama、Falcon、WizardLM等模型提供服务。（支持的模型列表）添加新模型进行推理/服务似乎非常简单，并支持因果模型（如 Llama）和序列到序列模型（如 T5）。他们还支持使用CPU卸载和不同的量化方案等服务。在幕后，FastChat使用了出色的vLLM库进行高效推理，这也是另一个LMSys开源项目。

微调

  • 支持微调的模型有Llama、T5和Baichuan。如有错误，烦请指正。主要的微调脚本仅适用于Llama模型，并有针对Llama特定的魔法数字。此外，还有针对T5和Baichuan模型的额外微调脚本。Falcon模型的训练支持仍有待解决。
  • 专门针对（单轮/多轮）对话数据监督微调，以训练聊天机器人。在类似FLAN的数据集上，用（instruction, response）对进行指令微调是有可能的（单轮对话），但不可能混合因果语言建模数据集等其他数据集格式，或者在多个数据集上进行训练。
  • 支持LoRA和基于QLoRA的训练。提供的DeepSpeed配置是参考配置，适用于低资源环境（例如，1个V100 32GB用于微调Llama-13B），因此会默认启动CPU卸载。请确保根据你的硬件设置进行修改。更多参考信息请参阅训练文档。
  • FastChat使用Trainer API，并且与几乎所有可用的开源训练包一样，在训练和评估中仅支持单一的同质数据集（在这种情况下，还必须是对话数据）。这意味着，你可以看到组合数据集的训练损失和评估损失，但在监控运行时不会看到其他信息。

评估

FastChat的评估包以MT-bench为基础，是一个基于多轮对话的评估数据集。在评分方面，他们使用LLM作为评委，可以利用GPT-3.5或GPT-4等更强大的语言模型对模型输出评分。

Axolotl

Axolotl是一个用于微调语言模型的大规模开源项目，具有以下显著特点：

  • 支持Llama、MPT、Falcon等各种因果语言模型。目前尚不支持序列到序列模型。
  • 具有多种格式，支持在多个数据集上训练。在我看来，对Axolotl来说，这是一个极其重要的功能。数据集格式的完整列表太过庞大，但你可以在类似FLAN的指令微调数据集、类似ShareGPT的基于对话的数据集以及简单的基于文本补全的数据集上进行训练（用于因果语言建模的纯文本/代码）。Axolotl还支持预标记数据集。
  • 支持LoRA、QLoRA，以及多包采样器，该采样器将相似长度的序列打包在一起，以避免在填充词元上浪费计算。
  • Axolotl还使用Trainer API，并具有许多用于自定义评估和记录的功能。你可以在MMLU上进行评估，或者在本地基准数据集上记录训练期间的损失/准确性。
  • 此外，Axolotl还支持FSDP和DeepSpeed，主要是因为它们只需让Trainer处理这一部分。Flash-Attention也适用于Llama、BTLM和新的Mistral等其他模型。
  • 因为在Trainer上定制起来比较困难，所以Axolotl不支持对不同任务（如MMLU和MATH）进行评估，不能分开可视化损失曲线。
  • 对此，我有一个小小的疑问，除?prediction_step?和?training_step?等方法之外，Axolotl最终几乎定制了Trainer的每个部分。如果他们已经可以使用 torch.distributed.gather ，我想知道为什么不直接从一开始就用纯PyTorch + Accelerate编写所有代码，这样本就可以避免冗余。Trainer还提供了十几种优化器以供选择，但监督微调只需要其中的一小部分。

实用的微调指南

HuggingFace近期发布的几篇值得阅读的微调指南：

9超大型模型训练

首先，在搭载8枚A100显卡的单一节点上，我们可以训练多大的模型。通过上述优化措施，目前我们可以在搭载8枚A100-80GB显卡的DGX节点上微调Falcon 180B。根据HuggingFace的指南（https://www.philschmid.de/deepspeed-lora-flash-attention），你可以在153分钟内，使用15000个样本，在dolly数据集上对一个包含180亿参数的模型进行3轮微调，其中有效批次大小为64，序列长度为2048个词元。由于文本块是作为预处理步骤进行的，因此不知道准确的吞吐量数值，当然我们也需要估算每个训练步骤所需的时间（因为总训练时间包括了评估和检查点所需的时间），但每秒吞吐量可能大于5个样本，对于180B参数的模型来说，这是相当不错的表现。

如果想了解更多关于管理大规模训练运行的信息，可以向Stas Bekman寻求帮助。前文已经提到过，但我还是再次重申：开源社区要感谢Stas Bekman的地方很多，其中包括他对大规模训练的出色论述。大规模训练的调试、监控、深入研究大规模多节点网络设置等内容都可以在他的合集中找到。不过其中一些关于分布式训练的资料和建议可能有点过时。

其他人都在看

文章来源:https://blog.csdn.net/javastart/article/details/135667854
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
最新文章