降龙十八掌:这套优化transformer内存占用的组合技值得收藏(2)

简介: 降龙十八掌:这套优化transformer内存占用的组合技值得收藏

梯度积累与微批

梯度累积是一种在训练过程中虚拟增加批大小的方法,当可用的 GPU 内存不足以容纳所需的批量大小时,这是非常有用的。并且这种方法只会在运行时产生影响,建模性能并不会受到影响。

梯度累积中,每批计算的量较小,并在多次迭代中累积梯度(通常求和或求平均),而不是在每个批次之后立刻更新模型权重。一旦累积的梯度达到目标「虚拟」批大小,模型权重就会用累积的梯度更新。

为了实现梯度积累,只需要对向前和向后传球进行两次小的修改:

05_gradient-acum.py 中的代码修改

本文作者的另一篇文章《使用梯度累积在单个 GPU 上微调 LLM》,更详细地介绍了梯度累积的细节。

文章地址:https://lightning.ai/blog/gradient-accumulation/


有效批大小为 16,并且累积步数为 4,意味着实际批大小为 4(因为 16/4=4)。

05_gradient-acum.py 的结果

这种技术的缺点是运行时间从 3.96 分钟增加到 12.91 分钟。

值得注意的是,批大小最小可以减少到 1,进一步减少 75% 的内存消耗。

使用更精简的优化器

时下流行的 Adam 优化器其实附带了额外的参数,例如,Adam 为每个模型参数提供了 2 个额外的优化器参数(平均值和方差)。

因此,通过将 Adam 与 SGD 等无状态优化器进行交换,可以将参数数量减少 2/3,这在使用 ViT 和 LLM 时非常重要。

普通 SGD 的缺点是收敛性较差。因此,Adam 与 SGD 交换后,需要引入余弦衰减学习速率调度器来进行补偿。

简而言之,通过将以下代码


optimizer = torch.optim.Adam(model.parameters(), lr=5e-5)


替换为






optimizer = torch.optim.SGD(model.parameters(), lr=0.01)
num_steps = NUM_EPOCHS * len(train_loader)scheduler = torch.optim.lr_scheduler.CosineAnnealingLR(    optimizer, T_max=num_steps)


通过这种变化,模型能够在保持大约 97% 分类准确率的同时减少峰值内存消耗:

06_sgd-with-scheduler.py 的结果

在目标设备上创建模型

在 PyTorch 中实例化模型时,通常是首先在 CPU 设备上创建它,然后将它转移到目标设备上,并将其转换为所需的精度:



model = vit_l_16(weights=ViT_L_16_Weights.IMAGENET1K_V1)model.cuda().float16()


但是 CPU 上生成完整精度的中间模型,是一种低效的方法。所以,可以使用 Fabric 中的 init_module 上下文在目标设备(例如 GPU)上直接创建所需精度的模型:







import lightning as L
fabric = Fabric(accelerator="cuda", devices=1, precision="16-true")
with fabric.init_module():    model = vit_l_16(weights=ViT_L_16_Weights.IMAGENET1K_V1)


在这种特定情况下(模型),前向通过期间的峰值内存大于其全精度表示中的大小。对模型加载本身对 fabric.init_module 方法进行基准测试,结果如下:

  • 没有 init_module 的 GPU 峰值内存:1.24 GB(07_01_init-module.py)
  • GPU 带 init_module 的峰值内存:0.65 GB(07_03_init-module.py)


可以看到,在这种情况下,init_module 将模型加载的峰值内存需求减少了 50%。

有关 init_module 的更多详细信息,可以参阅这篇关于大型模型的高效初始化的的文章。

文章地址:https://lightning.ai/pages/community/efficient-initialization-of-large-models/

分布式训练与张量共享

下一个修改是多 GPU 训练。多个 GPU 可供使用是有效的,因为这样做可以更快地训练模型。

然而,本文探讨的是内存节省。因此,需要一种更先进的分布式多 GPU 策略,称为完全共享数据并行(FSDP),该策略利用数据并行性和张量并行性在多个设备上共享大权重矩阵。

但是如果模型已经很小了,例如将此技术添加到上面第 7 节的代码中时,是几乎看不到任何效果的。因此,为了纯粹地关注分片的效果,可以与第 1 节中的全精度基线进行比较。

将以下代码


fabric = Fabric(accelerator="cuda", devices=1)


替换为











auto_wrap_policy = partial(    transformer_auto_wrap_policy,    transformer_layer_cls={EncoderBlock})    strategy = FSDPStrategy(    auto_wrap_policy=auto_wrap_policy,          activation_checkpointing=EncoderBlock)
fabric = Fabric(accelerator="cuda", devices=4, strategy=strategy)


08_fsdp 与 - 01-2.py 的结果

除了手动定义,请也可以使用以下方法,自动确定要分割哪些层:


fabric = Fabric(accelerator="cuda", devices=4, strategy="fsdp")


理解数据并行性和张量并行性

在数据并行中,mini-batch 需要继续被划分,并且每个 GPU 上都有一份模型副本。由于多个 GPU 并行工作,能够加快模型训练。


以下是工作原理:

  1. 在所有 GPU 中复制相同的模型。
  2. 然后,每个 GPU 被馈送输入数据的不同子集(不同的小批量)。
  3. 所有 GPU 独立地执行模型的前向和后向传递,计算各自的局部梯度。
  4. 然后,收集梯度并对所有 GPU 进行平均。
  5. 然后使用平均梯度来更新模型的参数。


这种方法的主要优点是速度块。由于每个 GPU 都在与其他 GPU 同时处理一个独特的小批量数据,因此可以在更短的时间内在更多数据上训练模型。这可以显著减少训练模型所需的时间,尤其是在使用大型数据集时。

然而,数据并行性有一些局限性。每个 GPU 必须具有模型及其参数的完整副本。这限制了可训练模型的大小,因为模型必须适合单个 GPU 的内存 —— 这对于现代 ViT 或 LLM 来说是不可行的。

与数据并行不同,张量并行将模型本身划分为 GPU。在数据并行中,每个 GPU 都需要适应整个模型,这在训练更大的模型时可能会成为一个限制。然而,张量并行性允许通过分解模型并将其分布在多个设备上来训练对于单个 GPU 来说可能太大的模型。


具体来说,其原理和矩阵乘法相似。按行或按列都可以对模型进行拆解。简单起见,以按列拆解为例,可以将一个大型矩阵乘法运算分解为单独的计算,每个计算都可以在不同的 GPU 上执行,如下图所示。然后将结果连接起来以获得原始结果,从而有效地分配了计算负载。


参数卸载

除了上一节中解释的 FSDP 策略之外,还可以将优化器参数卸载到 CPU,可以通过将以下代码





strategy = FSDPStrategy(    auto_wrap_policy=auto_wrap_policy,          activation_checkpointing=EncoderBlock,)


替换为






strategy = FSDPStrategy(    auto_wrap_policy=auto_wrap_policy,          activation_checkpointing=EncoderBlock,    cpu_offload=True)


内存消耗从 6.59 GB 减少到 6.03 GB:

09_fsdp-cpu-offload-with-01-2.py 的结果。

美中不足的小缺点是运行时间从 5.5 分钟增加到了 8.3 分钟。

将前面几招连着打出,就成为了最强的降龙十八掌最后一掌!

前几节对优化 ViT 进行了大量介绍,其实这些技术也同样适用于 LLM。

作者在 Lit LLaMA 和 Lit GPT 存储库中使用了许多这些技巧,这些存储库支持 LLaMA、Falcon、Pythia 和其他流行的模型。尽管如此,为了创建一个更通用的例子,作者从流行的 HF transformers 库中微调 LLM,用于对 IMDb 电影评论的情绪进行分类。

使用上述技术,仅使用 1.15 Gb 内存(bonus_DistilBERT-after.py)而不是 3.99 Gb(bonus_bigbird-before.py)就可以训练 DistilBERT 分类器。更令人印象深刻的是,通过将这些技术应用于 transformers 库中的 BigBird 模型,BigBird 仅消耗 4.03 GB(bonus_BigBird-after.py)。















strategy = FSDPStrategy(        cpu_offload=True   )
   fabric = Fabric(        accelerator="cuda",        devices=4,        strategy=strategy,         precision="bf16-true"   )
   with fabric.init_module():       model = AutoModelForSequenceClassification.from_pretrained(            "google/bigbird-roberta-base", num_labels=2)


结论

本文展示了 9 种减少 PyTorch 模型内存消耗的技术。当将这些技术应用于 ViT 时,单个 GPU 上减少了 20 倍的内存消耗。可以看到,跨 GPU 的张量分片甚至可以降低内存消耗。同样的优化还使 BigBird LLM 能够仅使用 4GB 峰值 GPU RAM 进行训练。

这些技术都不是特定于模型的,可以与任何 PyTorch 训练脚本一起使用。使用开源 Fabric 库,大多数优化都可以通过一行代码实现。

参考链接:https://lightning.ai/pages/community/tutorial/pytorch-memory-vit-llm/

相关实践学习
在云上部署ChatGLM2-6B大模型(GPU版)
ChatGLM2-6B是由智谱AI及清华KEG实验室于2023年6月发布的中英双语对话开源大模型。通过本实验,可以学习如何配置AIGC开发环境,如何部署ChatGLM2-6B大模型。
相关文章
|
7月前
|
机器学习/深度学习 算法 PyTorch
125_训练加速:FlashAttention集成 - 推导注意力优化的独特内存节省
2025年,大型语言模型的训练面临着前所未有的挑战。随着模型参数量和序列长度的不断增加,传统注意力机制的内存瓶颈问题日益突出。FlashAttention作为一种突破性的注意力算法,通过创新的内存访问模式和计算优化,显著提升了训练效率和内存利用。
771 3
|
7月前
|
存储 机器学习/深度学习 PyTorch
119_LLM训练的高效内存管理与优化技术:从ZeRO到Flash Attention
大型语言模型(LLM)的训练面临着前所未有的计算和内存挑战。随着模型规模达到数百亿甚至数千亿参数,高效的内存管理成为训练成功的关键因素之一。2025年,LLM训练的内存优化技术已经取得了显著进展,从ZeRO优化器到Flash Attention等创新技术,为训练超大规模模型提供了可能。
764 159
|
10月前
|
缓存 固态存储 Windows
如何让内存发挥到最大效能?全面优化指南,提升电脑运行体验
电脑内存使用不合理会导致卡顿,本文教你如何优化内存性能。检查内存容量与主板支持上限,考虑升级或调整配置;关闭后台程序、管理浏览器标签、结束异常进程以释放内存;设置虚拟内存、调整视觉效果、定期重启提升效率;必要时增加内存条、选择高频内存、更换固态硬盘。避免盲目清理内存和依赖大内存忽视其他硬件瓶颈。只需合理设置,无需额外花钱,就能显著提升电脑速度。
|
10月前
|
存储 人工智能 自然语言处理
AI代理内存消耗过大?9种优化策略对比分析
在AI代理系统中,多代理协作虽能提升整体准确性,但真正决定性能的关键因素之一是**内存管理**。随着对话深度和长度的增加,内存消耗呈指数级增长,主要源于历史上下文、工具调用记录、数据库查询结果等组件的持续积累。本文深入探讨了从基础到高级的九种内存优化技术,涵盖顺序存储、滑动窗口、摘要型内存、基于检索的系统、内存增强变换器、分层优化、图形化记忆网络、压缩整合策略以及类操作系统内存管理。通过统一框架下的代码实现与性能评估,分析了每种技术的适用场景与局限性,为构建高效、可扩展的AI代理系统提供了系统性的优化路径和技术参考。
682 4
AI代理内存消耗过大?9种优化策略对比分析
|
11月前
|
缓存 监控 Cloud Native
Java Solon v3.2.0 高并发与低内存实战指南之解决方案优化
本文深入解析了Java Solon v3.2.0框架的实战应用,聚焦高并发与低内存消耗场景。通过响应式编程、云原生支持、内存优化等特性,结合API网关、数据库操作及分布式缓存实例,展示其在秒杀系统中的性能优势。文章还提供了Docker部署、监控方案及实际效果数据,助力开发者构建高效稳定的应用系统。代码示例详尽,适合希望提升系统性能的Java开发者参考。
572 4
Java Solon v3.2.0 高并发与低内存实战指南之解决方案优化
|
10月前
|
存储 人工智能 API
AI代理性能提升实战:LangChain+LangGraph内存管理与上下文优化完整指南
在AI代理系统开发中,上下文工程成为提升系统性能的关键技术。本文探讨了从提示工程到上下文工程的转变,强调其通过为AI系统提供背景信息和工具支持,显著提升智能化程度和实用价值。文章系统分析了上下文工程的理论基础、核心策略(如写入、选择、压缩和隔离),并结合LangChain和LangGraph工具,展示了如何实现上下文工程技术以优化AI代理性能。通过Scratchpad机制、内存管理、RAG系统集成、多代理架构及沙盒环境等技术手段,开发者可以更高效地构建高性能、可扩展的AI系统。
1404 0
AI代理性能提升实战:LangChain+LangGraph内存管理与上下文优化完整指南
|
9月前
|
边缘计算 算法 Java
Java 绿色计算与性能优化:从内存管理到能耗降低的全方位优化策略与实践技巧
本文探讨了Java绿色计算与性能优化的技术方案和应用实例。文章从JVM调优(包括垃圾回收器选择、内存管理和并发优化)、代码优化(数据结构选择、对象创建和I/O操作优化)等方面提出优化策略,并结合电商平台、社交平台和智能工厂的实际案例,展示了通过Java新特性提升性能、降低能耗的显著效果。最终指出,综合运用这些优化方法不仅能提高系统性能,还能实现绿色计算目标,为企业节省成本并符合环保要求。
298 0
|
10月前
|
存储
阿里云轻量应用服务器收费标准价格表:200Mbps带宽、CPU内存及存储配置详解
阿里云香港轻量应用服务器,200Mbps带宽,免备案,支持多IP及国际线路,月租25元起,年付享8.5折优惠,适用于网站、应用等多种场景。
3110 0
|
10月前
|
存储 缓存 NoSQL
内存管理基础:数据结构的存储方式
数据结构在内存中的存储方式主要包括连续存储、链式存储、索引存储和散列存储。连续存储如数组,数据元素按顺序连续存放,访问速度快但扩展性差;链式存储如链表,通过指针连接分散的节点,便于插入删除但访问效率低;索引存储通过索引表提高查找效率,常用于数据库系统;散列存储如哈希表,通过哈希函数实现快速存取,但需处理冲突。不同场景下应根据访问模式、数据规模和操作频率选择合适的存储结构,甚至结合多种方式以达到最优性能。掌握这些存储机制是构建高效程序和理解高级数据结构的基础。
1014 1