显存优化综述

简介: 显存优化综述

动态图和静态图


动态图是边计算边搭建计算图,中间结果一目了然。


静态图是先搭建计算图,最后喂入输入,直接出结果。


因为静态图在编译的时候进行了一些优化,比如改变了代码的计算过程,以利于GPU更好的并行计算,那么想debug看中间结果就很困难了,有时候看到的和期望的可能会有些出入。另外就是每次当我们搭建完一个动态计算图,然后在反向传播结束之后,整个计算图就在内存中被释放了。如果想再次使用的话,必须从头再搭一遍。


静态图显存优化


对于大网络结构的训练场景,在静态图上的显存优化主要可以分为三个方向:


静态显存分配。由于获得了整张计算图,所以可以去分析每一个 tensor 和每个算子的生命周期。对于生命周期没有重叠的算子,它们是可以共享显存的。


梯度检查点(用计算换显存)。设置一些梯度检查点,剩下的中间结果就先释放掉,如果将来在反向传播的过程中发现前向结果不在显存中,就找到最近的梯度检查点,恢复出被释放的 tensor。


内存交换(用带宽换显存)。把暂时不用的数据从 GPU 上交换到 CPU 上,到了需要的时候,再把它交换回来。


动态图显存优化


动态图无法提前获得全局的计算图信息。因为无法得到每个 tensor 的生命周期,所以静态显存分配不再可用


  1. 1.用计算换显存,也就是动态图版的 Sublinear 显存优化;

  2. 2.用带宽换显存,在 GPU 和 CPU 之间交换内容。
  3. 19.png
  4. 如上图所示,交换耗时比计算耗时高出很多,因此用带宽换显存不合理。
  5. 20.gif
  6. 如上图所示,在前向传播中(第一行从左到右),蓝色圆圈表示模型的中间计算结果开始占用显存。一直到前向传播完成,第一行完全变为蓝色圆圈,前面计算所占用的显存都不能释放。


等到反向传播开始(第二行从右到左),随着梯度的计算与完成应用,前向传播保留在显存中的张量才可以释放。


很明显,如果要降低显存占用,就要拿前向传播保存的中间计算结果开刀,这也正是 MegEngine 动态图显存优化的主要方向。

21.gif

如上为梯度检查点技术原理示意,前向传播中第三个点为检查点,它会一直保存在显存中。第四个点在完成计算后即可释放显存,在反向传播中如果需要第四个点的值,可以从第三个点重新计算出第四个点的值。


DTR


问题


大部分场景下,网络训练的中间特征占用了绝大部分得到显存,模型权重这是占据了极小的一部分。


这些中间特征在反向传播的算子中还需要用到,所以不好被释放。


解决办法


引入LRU cache的机制,选择代价最低的tensor进行释放,在需要用到的时候进行重计算。


重计算的开销越小越好


释放的tensor占用显存越大越好


该tensor的访问间隔越长越好


LRU cache:距离上次访问时间间隔最长的,进行释放


另外,DTR 论文中还提出,除了重计算带来的开销之外,其他的额外开销主要用于寻找应该被释放掉的最优 tensor。因为在显存中,tensor 停留的时长是不断在变化的,所以只能在需要释放的时候现场计算最优的 tensor。


对此,论文中提出了两个运行时的优化技巧:


不考虑小的 tensor,当 tensor 大小小于候选集中的 tensor 的平均大小的 1% 时,不加入候选集;


每次在需要释放 tensor 的时候,随机采样 sqrt(N) 个 tensor 进行遍历(N 为目前可释放的 tensor 候选集的大小)

23.png

重计算的局限性


  • 释放的显存不连续,形成的显存碎片,无法容纳新的tensor

例如,新的tensor需要100M的显存,为此释放了两个tensor,但是这两个tensor不是连续的,不能被使用,根据释放机制,就会一直释放下去,直到释放出一段连续可用的显存

24.png

在显存池里的排列并非最优,是按照计算顺序排列的

25.png

26.png

in-place op 失效


重计算实质上把in-place op变成了非in-place op


in-place op:模型权重会被修改利用,以此来节省显存和cache,原地修改会造成后续的值改变。


DTR:模型权重不可被修改,额外申请资源进行计算,生成新的tensor,分散在显存池中,很难形成连续大显存。

27.png

Coop


对显存的排列方式进行优化,一次性找出可以生成足够大的连续空闲显存、并且总代价最低的tensor集合。

28.png

29.png

recomputable in place


对于不再变化的tensor,进行共享存储。

30.png

op-guided allocation


根据op进行显存池中位置的分配,相同的放在一起。(原先是按照计算顺序来的)

31.png

Layout-aware Eviction


将显存池中空闲显存当做代价为0的tensor。


利用滑动窗口找出代价最小的连续tensor,进行释放。

32.png


实验效果


消耗的时间


下图是Coop和同样在OneFlow中实现的DTR、DTE策略在八种不同的网络、不同显存阈值下的对比,可以看到Coop均超过了其它两种方法:


横轴为显存,纵轴为时间倍数

33.png

显存碎片率


同时,Coop 将显存碎片率减少了一个量级(注意 BiLSTM 的 y 轴为对数坐标)

在大部分网络中,显存碎片率最低

34.png

搜索时间


Coop 的搜索过程时间复杂度为 O(N) 而不是 O(N^2)(N 为显存池中的 tensor 个数),在

绝大多数场景下也取得了最快的搜索速度(注意 BiLSTM 和 BERT Large 的 y 轴为对数坐

标)

35.png

目录
相关文章
|
2月前
|
机器学习/深度学习 测试技术 PyTorch
深度学习之测量GPU性能的方式
在深度学习中,测量GPU性能是一个多方面的任务,涉及运行时间、吞吐量、GPU利用率、内存使用情况、计算能力、端到端性能测试、显存带宽、框架自带性能工具和基准测试工具等多种方法。通过综合使用这些方法,可以全面评估和优化GPU的性能,提升深度学习任务的效率和效果。
226 2
|
3月前
|
机器学习/深度学习 并行计算 PyTorch
GPU 加速与 PyTorch:最大化硬件性能提升训练速度
【8月更文第29天】GPU(图形处理单元)因其并行计算能力而成为深度学习领域的重要组成部分。本文将介绍如何利用PyTorch来高效地利用GPU进行深度学习模型的训练,从而最大化训练速度。我们将讨论如何配置环境、选择合适的硬件、编写高效的代码以及利用高级特性来提高性能。
647 1
|
3月前
|
存储 机器学习/深度学习 PyTorch
深入理解GPU内存分配:机器学习工程师的实用指南与实验
给定一个模型架构、数据类型、输入形状和优化器,你能否计算出前向传播和反向传播所需的GPU内存量?
43 0
|
5月前
|
机器学习/深度学习 并行计算 算法框架/工具
为什么深度学习模型在GPU上运行更快?
为什么深度学习模型在GPU上运行更快?
76 2
|
6月前
|
机器学习/深度学习 算法 物联网
LISA微调技术解析:比LoRA更低的显存更快的速度
LISA是Layerwise Importance Sampling for Memory-Efficient Large Language Model Fine-Tuning的简写,由UIUC联合LMFlow团队于近期提出的一项LLM微调技术,可实现把全参训练的显存使用降低到之前的三分之一左右,而使用的技术方法却是非常简单。
|
6月前
|
机器学习/深度学习 并行计算 PyTorch
【多GPU炼丹-绝对有用】PyTorch多GPU并行训练:深度解析与实战代码指南
本文介绍了PyTorch中利用多GPU进行深度学习的三种策略:数据并行、模型并行和两者结合。通过`DataParallel`实现数据拆分、模型不拆分,将数据批次在不同GPU上处理;数据不拆分、模型拆分则将模型组件分配到不同GPU,适用于复杂模型;数据和模型都拆分,适合大型模型,使用`DistributedDataParallel`结合`torch.distributed`进行分布式训练。代码示例展示了如何在实践中应用这些策略。
1792 2
【多GPU炼丹-绝对有用】PyTorch多GPU并行训练:深度解析与实战代码指南
|
6月前
|
物联网 调度 异构计算
使用GaLore在本地GPU进行高效的LLM调优
GaLore是一种新的优化策略,它通过梯度低秩投影减少VRAM需求,使得大型语言模型(如70亿参数的模型)能在消费级GPU上进行微调,而不减少参数数量。与LoRA相比,GaLore内存效率更高,且性能相当或更优。它在反向传播期间逐层更新参数,降低了计算负荷。虽然GaLore训练时间较长,但它为个人爱好者提供了在有限资源下训练大模型的可能性。相关代码示例和性能对比显示了其优势。
190 0
|
机器学习/深度学习 并行计算 安全
2023 年最佳多 GPU 深度学习系统指南
2023 年最佳多 GPU 深度学习系统指南
170 1
|
机器学习/深度学习 存储 人工智能
神经网络推理加速入门—— GPU为什么这么牛
大家好啊,我是董董灿。 GPU为什么能在各种行业大放异彩,这篇文章讲述了GPU 的技术和引用。
神经网络推理加速入门—— GPU为什么这么牛
|
机器学习/深度学习 算法
机器学习 PAI 支持的机型显存大小
机器学习 PAI 支持的机型显存大小
336 0