单GPU实现LLM多LoRA微调

论文标题：ASPEN: High-Throughput LoRA Fine-Tuning of Large Language Models with a Single GPU

论文地址：​​https://arxiv.org/abs/2312.02515​​

论文翻译https://arxivtools.blob.core.windows.net/xueshuxiangzipaperhtml/2023_12_6/2312.02515.pdf

参考代码：https://github.com/TUDB-Labs/multi-lora-fine-tune

摘要

基于transformer的LLM在不同领域表现出出色的性能，特别是针对特定领域进行微调时。微调LLM所需的资源可以通过低秩自适应（LoRA）等高效参数微调方法来节省。虽然LoRA有效减少了计算负担和资源需求，但它目前仅支持单作业微调。

本文提出了ASPEN，一个高吞吐量的LLM微调框架，其利用共享的预训练模型和自适应调度，使用LoRA在单个GPU上有效地训练多个作业。实验表明，ASPEN在NVIDIA A100 80 GB GPU上训练多个LLaMA7B模型时，可节省53%的GPU显存，在不同GPU上训练各种预训练模型时，吞吐量比现有方法提高约17%。自适应调度算法将周转时间减少24%，端到端训练延迟减少12%，对作业进行优先排序并防止内存不足问题。

1. 引言

LoRA不仅广泛用于LLM中的微调任务，而且还实现了与全参微调相当的精度。基于LoRA微调的极轻量级性质进一步允许在单个GPU上训练多个LoRA模块。直观地说，在多个LoRA模块之间共享预训练的模型训练应该会带来相同的好处，例如减少GPU内存使用和提高计算效率。然而，直接的共享方法-例如，在训练多个LoRA作业时，仅切入/切出LoRA模块，同时将预训练的模型保留在GPU内存中-可能会引入额外的开销，这可能是次优的。此外，当前基于LoRA的微调系统，如AlpacaLoRA，主要集中在优化单作业微调，并没有彻底研究微调多个作业的有效策略。

图2

本文提出了ASPEN，一个高吞吐量的微调框架，旨在在单个GPU上训练多个LoRA微调作业。其基于BatchFusion-一种新型并行微调方法，该方法通过将多个输入批次融合到单个批次中，实现了多个LoRA微调作业的并发训练和预训练模型的共享。为多个作业有效地分配系统资源是一项复杂的任务。因此，ASPEN结合了一个细粒度的，高效的作业级调度器来处理多个LoRA作业，成功地解决了以下关键问题：

BatchFusion过程中，当训练数据长度变化时，对齐是必要的，并通过填充token来匹配迭代中最长数据的长度来实现。图2(a)为批次融合的示例，其中填充令牌占了很大比例，导致整体吞吐量效率较低。虽然这些填充令牌不会直接影响模型性能，但会导致计包含它们会导致算效率低下。ASPEN的一个关键目标是通过设计有效的填充策略来提高有效吞吐量，从而减轻可变数据长度引起的计算效率低下。

在资源有限的单个GPU上训练多个LoRA微调作业需要有效的资源管理。如图1（左）所示，根据损失或准确率趋势，应提前终止J2和J3，因为继续运行这些作业获得的收益最小，同时消耗宝贵的计算资源，而不会带来显著的收益。此外，最大化资源使用还需要限制训练错误。例如，并发运行太多作业可以最大限度地利用资源，但存在内存不足风险，为每个作业动态分配资源（如GPU内存）至关重要，但在调度期间预测确切的内存需求具有挑战性。ASPEN通过开发精细的模型来克服这些挑战，1）预测作业何时不太可能提前终止，2）估计运行作业的内存需求，避免内存不足错误。

了评估ASPEN，我们微调了几个LLM，包括LLaMA-7B/13B ，ChatGLM2 - 6B 和LLaMA2 7B/13B 。实验结果肯定了ASPEN在优化GPU利用率、GPU内存使用率和单个GPU训练吞吐量方面的效率。当与Huggingface的PEFT（AlpacaLoRA ，QLoRA 等采用的领先的参数高效微调库）相比时，吞吐量显著增加，提升高达17%。本文贡献如下：

1. 引入了Multi-LoRA Trainer，在LLM的微调过程中，通过BatchFusion方法实现了预训练模型权重的高效共享。
2. 提出了自适应作业调度算法，该算法从作业中收集各种度量，能够准确估计模型的性能和资源利用率，最大限度地提高系统效率。
3. 与最先进的LoRA训练系统相比，ASPEN有效地利用了计算资源，从而提高了训练吞吐量并减少了训练延迟。在NVIDIA 100 80 GB GPU上训练多个LLaMA-7B模型时，节省53%的GPU内存，并在不同GPU上使用各种预训练模型进行训练时，与现有方法相比，吞吐量提高约17%。

2. 背景和动机

图3

• 微调预训练模型需要大量资源
• 作为最先进的PEFT技术之一，LoRA 通过完全冻结预训练模型并通过可训练的低秩分解矩阵引入权重修改来实现有效的微调
• 机会：共享预训练模型。当使用相同的预训练模型训练多个LoRA微调作业时，在所有作业之间共享预训练模型似乎可以直观地节省保存GPU内存。实现这一点的一种简单方法是只交换每个作业的低秩矩阵A和B，同时将预训练的模型保留在GPU内存中。通过这种方式，多个作业被单独和顺序地训练，同时共享相同的预训练模型。尽管简单，但按顺序训练多个LoRA作业在资源利用率和训练性能方面可能不是最有效的方法。我们注意到，每个矩阵乘法和加法运算产生的内核启动成本在整个训练执行时间中起着重要作用。此外，我们观察到，如果可以并行训练多个LoRA作业，如图3(b)所示，通过在将其与共享的预训练模型权重相乘之前将各个作业的训练数据“合并”到一个大矩阵中，可以显着减少矩阵乘法的数量（即降低启动成本）。受这些启发，我们提出BatchFusion。
• 挑战：最大限度地利用资源。虽然训练多个LoRA作业可以更有效地使用计算资源并减少训练开销，但在内存资源有限的情况下，同时运行所有作业通常是不可能的。如何调度作业的运行顺序，以最大限度地利用计算资源，提高系统的性能，是一个挑战。与其他作业调度算法不同，在基于lora的场景下 使用多个作业进行调优，可以提前估计每个作业的内存使用情况。此外，早停预测模型使作业的运行时间可预测。这就需要一种更适合管理LoRA微调作业调度的调度。

3. 系统概述

图4

如图4所示，ASPEN由三个主要组件组成：

• 1个可以处理多个LoRA微调作业的自监督语言模型训练器，称为Multi-LoRA Trainer
• 1个分析器，收集正在运行作业的各种指标，并为这些指标生成估计结果
• 1个作业调度程序，可以根据分析器的估计结果和用户需求选择调度策略

ASPEN的微调工作流程：

• 如图4所示，用户向ASPEN发起请求，提供超参数配置、训练数据和调度目标，其中包括最小化等待时间、减少周转时间、最大化吞吐量等，如§5所述。随后，ASPEN基于此信息生成多个候选作业，并在系统初始化期间在Profiler中为每个作业配置预估的基本参数。
• 系统初始化后，Scheduler从候选人中选择一个作业子集，将其与用户定义的调度目标相匹配，并将其提交给MultiLoRA Trainer进行并发训练。Multi-LoRA Trainer 向Profiler提供训练作业的性能指标以进行估计。这些步骤的迭代构成了一个训练周期，重复直到所有候选作业都完成训练。
• 如果在训练过程中出现新的请求，ASPEN会根据请求中提供的信息异步生成候选作业。随后，Profiler为每个作业配置估计的基本参数。然后在下一次迭代开始之前更新候选作业集，确保训练过程无缝地包含最新的输入。

4. Multi-LoRA Trainer

4.1 Batch Fusion

本文提出了一种新的BatchFusion技术，用于在训练多个LoRA微调作业时更有效地共享预训练模型，如图3（b）所示。BatchFusion在每次训练迭代之前将来自多个微调作业的训练数据融合到一个批次中；因此，多个LoRA模块可以共享相同的预训练模型，并在每次迭代中并行参与训练（而不是顺序或单独训练）。这样有2个好处：1）它通过避免微调作业之间的频繁交换和减轻模型切换开销来并行化微调过程。2)它通过降低内核启动成本，进一步优化GPU资源的使用，从而提升整体计算效率。

具体来说，Multi-LoRA Trainer有助于在同一GPU上并行执行多个微调作业。在形式上，设Fusion表示BatchFusion过程，其中，Concat表示矩阵的拼接操作,该操作与矩阵拼接类似，但是我们添加了额外的填充标记来确保维度对齐，以及额外的信息来识别输入数据属于哪个LoRA模块。

给定输入作业的第i个作业 ，输出是ℎ. 批次融合矩阵为 = (1,...,)，它将与预训练的权重和所有LoRA模块权重相乘，然后将各个结果相加以产生最终输出.

4.2 成本分析

• GPU内存成本：并行运行时，BatchFusion减少了为每个作业复制预训练模型权重的需要。比如训练k个作业, 预训练模型大小 nGB，可以节省(k-1) nGB
• GPU计算成本：在GPU计算中，在每个操作之前，需要启动内核以执行矩阵乘法和加法，并且与此内核启动相关联的开销可能是很大的。将多个小内核融合到一个大内核中，可以通过节省内核启动成本来降低整体计算成本;它可以有效地降低大约30% - 50%的理论内核启动成本

4.3 数据对齐和填充

如图2（a），其中描述了四个微调作业，每个作业的批大小为2，总共有六个训练数据点。这些数据点的长度各不相同，最长的是六个单位。为了对齐数据长度，将填充标记附加到较短的数据点。因此，这导致计算资源的使用效率较低。

形式上，我们引入了填充比的概念，表示为，表示一个批次中填充token的比例。对于共享相同输入训练数据的微调作业，例如超参数搜索场景，每个作业的训练输入数据都是相同的，因此，不需要引入填充标记，该值为0；另一方面，在涉及解决不同领域问题的微调作业的场景中，每个作业将使用不同的训练集，这些数据集可能具有不同的长度分布，每次迭代中训练数据的长度会有所不同，导致更高的填充比，我们的目标是在提高有效吞吐量的同时，降低填充比。

我们引入了OptimalBatch算法来最小化训练数据集中的填充比。最优批处理算法在训练过程的每次迭代中执行以下关键步骤：首先，它根据训练数据的长度对每个作业进行排序。接下来，它从每个作业中选择最短或最长的训练数据。最后，它使用BatchFusion操作（如第4.1节所述）来组合这些选定的训练数据。然后，这些融合数据将被送入Multi-LoRA Trainer进行处理。

图5

然而，这种方法面临两个主要挑战：1）使用排序数据训练模型可能导致模型性能收敛问题。如图5所示，可以观察到两条不同的损失曲线。左边的异常曲线表现出波动行为，没有显示出明显的收敛趋势，与右边的稳定和收敛曲线形成对比。2)实现此方法需要将所有作业存储在GPU内存中，以确定最佳的GPU解决方案。在内存受限的环境中，尤其是在管理大量作业时，可能导致内存不足。

改进方案：

图6

图6显示了一个示例，其中只能容纳两个作业。虽然 FIFO 是一种常见的调度方法 ，但它在融合批次中会产生四个填充标记。相比之下，MinPad算法 （ 本文方法）将其简化为只有一个。观察：在处理大量候选作业时，为同一批次选择数据长度分布相似的作业可以降低填充率，从而提高有效吞吐量。

基于此，我们提出了MinPad 算法，以解决 BatchFusion 引起的填充问题：它首先确定可以同时训练的最大作业数M 。在每次迭代之前，它会查看每个作业的数据， 并选择 M个填充令牌最少的训练数据。MinPad执行顺序与训练数据长度的分布相关联，保证了最小填充率，最大化有效吞吐量，避免了排序导致的训练过程的不收敛，但不考虑作业的优先级、周转时间和等待时间。FIFO算法通常用于管理作业优先级 ，但这种方法不考虑训练数据长度的分布，可能会增加填充率并降低吞吐量。

5 作业调度器

5.1 优化训练吞吐量

见4.3

5.2 早停和吞吐量建模

在模型训练过程中，如果模型的性能变差或保持不变， 可以采用提前停止来提前终止训练 。这种方法避免 等待完成所有训练数据，从而减少了不必要的计算成本。如图1 所示，左下角显示了训练期间四个作业的性能。在计算 J2 的损失值时，会发生NaN错误。如果继续训练，该错误将再次出现，导致模型性能异常，浪费计算资源。J3 和 J4使用各种指标来决定何时提前停止。每次迭代后，都会使用测试集评估其准确性。J3的准确率在训练过程中稳步下降，表明进一步的训练不会提高性能，只会浪费资源。因此，可以提前停止。

5.3 微调内存使用情况建模

图7

如图2（b）所示，在模型训练过程中，数据分布不均匀，不同的输入数据长度会导致不同的 GPU 内存要求。图7的左列显示，我们将每个作业的批处理大小固定为 24， 然后调整输入数据长度，以确定在 48GB GPU 上可以运行而不会遇到内存不足的最大作业数。因此，假设我们知道作业在每个步骤中使用的资源量， 就可以动态调整可以并发运行的作业数。

5.4 自适应作业调度

• SJF-最短工作优先算法

6 评估

• 本文建立了常用的单任务LoRA微调系统，即Alpaca-LoRA ，作为基线方法。AlpacaSeq：在单个GPU上依次训练模型；Alpaca-Parallel：在单个GPU上同时训练多个模型。
• 在端到端性能实验中，本文使用相同的数据集来训练四个具有不同学习率的LoRA模型，监控每秒训练的token和填充token的数量，并计算有效吞吐量和无效吞吐量。

图8(灰色-无效吞吐量：a-不同模型；b-不同参数；c-不同硬件)

图9

图11

• 我们比较了四种不同的调度策略对系统的影响：
• MinPad算法-M3；FIFO算法-M1；优先级调度算法-M2；自适应调度算法- 4

• 感觉整体思路是不错的，如果模型占用显存小，利用率低的话可以同时多lora训练 或者用不同lora配置来搜索合适的超参；作者应该是实践其中的一部分，不同数据集不同lora实验没有，同一数据集不同lora的实现见 - https://github.com/TUDB-Labs/multi-lora-fine-tune

本文转自 AI生成未来 ，作者：龟壳

原文链接:​​https://mp.weixin.qq.com/s/zGRlay0-V88iIOKk5xkdBw​​