阿里QA导读:人工智能的质量评估,是一个前沿的细分领域,可以理解为对AI进行专项测试。人工智能绿色度评估工具包GreenFlow-Measure在多项人工智能任务测定的绿色度结果准确度均优于业界同类型工具,让我们带领大家一起学习前沿的自动化评估方法。
1 导言
近年来,由于计算机硬件设备的快速发展,海量数据集和超大规模预训练模型的兴起,使得相关领域产品获得了极大的收益,但在其背后却带来了极大的计算资源和能源消耗。越来越多的研究者呼吁降低人工智能研究的计算成本和环境成本,回归到追求高效和环境友好的人工智能体系中。因此,我们提出了三项衡量人工智能绿色度的指标,倡导研究者们将绿色度指标与结果指标视为同等重要的地位。其次,我们将介绍人工智能绿色度评估工具包——GreenFlow-Measure,GreenFlow-Measure在多项人工智能任务测定的绿色度结果准确度均优于业界同类型工具,并且效率更高、接入更加便捷。
2 背景和挑战
图1 模型参数量和数据样本量正在急剧上升
2012年起深度学习模型被广泛的应用于各种各样的领域,并取得了极大的成功。然后从图1中可以看出,随着深度学习的发展,人们似乎走向了一个数据和算力主导的胡同,越来越多的state-of-the-art(SOTA)结果依靠庞大的数据集的预训练和无限堆叠的参数而获得。从AlexNet(约60M参数)到如今的巨无霸GPT-3(约1750B参数)参数量扩大约30,000倍,与此同时带来的是巨额的计算成本和环境成本,可预见的未来可能会出现更多使用海量数据预训练的庞大模型,而它的出现仅仅是为了在前一位巨物的指标结果上提升零点一个百分点。为了遏制无休止的算力大战,许多的研究者倡导专注于发现成本与结果之间的平衡,Green AI(绿色AI)因此而诞生。绿色AI呼吁使用更低的计算成本和环境更加友好的方式进行人工智能研究。制定一系列被广泛认可的绿色AI衡量标准,让研究者们更加关注于人工智能的效率,而非最终结果。而当前业界主要聚焦的绿色AI评估指标可以分为以下三项:
算力消耗(浮点运算量消耗量,FLOPs):指的是在执行特定模型时运行模型所需的计算次数。模型越复杂,所消耗的算力越多。模型执行次数越多,消耗算力也就越多。算力的消耗与计算的硬件与软件无关,只与模型的复杂度和计算次数有关。
能耗(Energy):指特定模型在实验、训练和推理过程中所消耗的电能。其主要包含机器运行时的电能消耗和维持机器高效运行环境所消耗的能源(补偿能耗,PUE:通常指冷却或加热数据中心而产生的能量,不同数据中心其取值不同)。
二氧化碳排放量(CO2 Emission):CO2排放量与能耗存在线性关系,影响CO2排放量的主要因素包括计算机所处的地区、国家、时间以及生产能源的方法。其计算方法是采用所在地区的碳排放因子乘以能耗得到,碳排因子可通过国家或地区相关数据统计机构得到。
而当前为了准确的衡量以上三项绿色AI衡量指标,我们需要面临的挑战和问题可以归纳为以下几个方面:
常用算力评估工具(TF Profiler)存在许多错误和不足:
形状推断错误 TF Profiler在计算形状未知的运算符时,通常是将多维矩阵的未知维度设置为batchsize。例如:在时间序列预测任务中,TF Profiler将位置为None的维度设置为batchsize,也就是将[None,num head,embedding size]填充为[batch size,num head,embedding size],但是实际计算时应该填充batch size*seq len,因此会造成十分大的偏差。
条件分支算力统计错误 条件运算符tf.conf中有两种不同的分支子图,这将导致两个影响计算的问题:一个是两个子图的输出形状可能不同。另一个是不同分支子图所消耗的浮点计算量不同。静态分析既不能推断执行模型运行时计算的分支,也不能准确计算输出数据的形状,这将带来较大的统计误差。
特定算子复杂度错误TF Profiler在计算一些算子时忽略了算子本身的理论复杂度,而简单的将其认为是1次浮点计算,比如:sigmoid算子,在TF Profiler里将其统计为1次浮点计算,而根据其数学表达式可以很容易的推出其总共进行了4次浮点计算。
算子覆盖度不足 TF Profiler总共支持不到50个算子,而实际在进行浮点计算量统计时TensorFlow约有200个算子会产生浮点计算。
业界能耗采集工具存在许多的缺陷:
能耗采集结果为整台计算机的消耗数据,针对特定模型存在数据偏差 当前业界常用的能耗采集方案均是使用硬件厂商提供的接口进行数据采集,但是该接口得到的数据为整台计算机的能耗数据,而非特定程序产生的能耗。因此对于单台计算机存在多个模型混合运算或存在较多其他进程的情况下存在较大的数据偏差。
仅支持单台计算机的数据采集 当前业界主流的能耗采集工具carbontracker和codecarbon仅支持单机场景下的能耗数据采集,但是在真实业务场景下的机器学习任务,通常是在多机集群下完成的训练与部署,所以当前业界现存的能耗采集工具没有办法适配所有的运行模式。
用户编码风格不统一,难以完全适配 当前业界主流的采集工具均会让用户进行特定的编码修改,比如让用户告知其训练loop的执行情况,但是用户在真实进行程序编码时可能会存在各种各样的编码风格,所以需要尽量少的侵入用户代码,适配更多的用户编码风格,让用户更少的感知到能耗采集工具的存在,才能真实降低用户的接入成本,提高用户的幸福感。
3 方案
为了解决上述提到的问题,我们提出了动态算力计算方法和进程级能耗拆分方案,用以计算和采集更加精准的算力与能耗信息,并且我们将这两种能力集成到GreenFlow-Measure绿色AI评估工具中,提供接入便捷与高适配度的绿色数据采集体验。接下来将针对各项解决方案进行逐一讲解。
3.1 动态算力
对于当前算力评估工具存在的问题,我们提出了动态算力采集方案,旨在正确的推导每一个算子或节点的向量形状,在存在条件分支时梳理出正确的计算链路同时准确的评估每条链路的浮点计算次数。同时,针对TF Profiler算子覆盖度不足和少量算子统计出错等问题进行二次开发并完善。
3.1.1 技术方案
为了能够准确的得到每个算子输入和输出的实际形状和所消耗的算力,需要将计算图中的算子按照控制流分类分为三种:
无控制流算子,可以直接执行。
条件控制流算子,只能执行真值条件。
循环控制流算子,无法直接执行。
在算子分类前,还需要执行计算图分析,去除不需要的冗余节点。对于预测图,根据输出递归找出所有的输入节点即为非冗余节点;对于训练图,根据train_op来递归找出所有的输入节点即为非冗余节点。
1) 无控制流算子
为了识别无控制流算子,只根据节点属性是不够的,还需要根据计算图做结构分析,否则会导致一些无控制流算子被遗漏,进而导致sess执行报错。为了准确找出可以直接执行的无控制流算子,需要反向找出无法直接执行的控制流相关算子,具体来说,将Enter->Exit之间的算子和Switch->Merge之间的算子筛选出来。实现上,我们找到Enter算子当做开始节点,找到Exit算子当做结束节点,广度遍历来找到中间节点,然后调整父子关系,将Exit节点的父节点修改为Enter节点,然后再对Switch->Merge节点执行相同的操作。先执行Enter->Exit节点,是因为涉及到的tf.while里面有Merge->Switch节点子图,需要避免在额外的干扰。图2是tf.cond和tf.while的算子展开后的结构,可以看到if和while在tf里面的实现方案。
图2 tf.cond和tf.while算子结构实现展示
2) 条件控制流算子
条件控制流的真假分支在不同的控制流上下文上,难以直接进行分析。我们设计了一个只依赖当前控制流上下文的方案,即构造一个Merge算子,合并当前控制流的pivot算子input中output节点的真假分支(有些拗口,可参看下列伪代码理解),该Merge算子不在上下文内部,是可执行的,根据通过Merge算子的输出和当前分支是否为真值支路来判断当前分支是否可执行。
3) 循环控制流算子
TensorFlow在执行过程中存在frame的概念,而循环内部的算子都是在一个特定的frame内,因此无法直接执行并取出值。为了解决这个问题,我们设计了一种巧妙的方法,在控制流上下文内部新建Exit算子,并在外部拷贝Exit算子的值,其伪代码如下。
3.2 进程级能耗采集
当前业界常用的CPU能耗采集方法是通过硬件厂商提供的相关接口进行数据收集,而使用该方案得到的能耗数据并不能赋予计算机中每一个不同的进程,因此该方案得出的能耗数据并不能准确的反映出每一个独立进程的能耗数据,因此本文提出了一种进程级的能耗计算方案。
3.2.1 技术方案
图3 多种不同型号的CPU,能耗与负载之间均存在线性关系
3.3 GreenFlow-Measure 绿色AI评估工具
GreenFlow-Measure绿色AI评估工具集成了动态算力计算和进程级能耗拆分,可以有效的收集AI模型在训练时,所消耗的计算机算力和电能,并可以计算对应的二氧化碳排放量,其开发的设计理念主要基于以下原则:
易于使用 采集AI模型绿色度只需要新增两行代码和简单的配置即可,不会修改或侵入用户原有的代码或逻辑。此外,一旦GreenFlow-Measure开始工作,就无需用户进一步的操作。
多种工作模式 GreenFlow-Measure支持两种工作模式:本地模式和服务器模式。当个人研究者训练深度学习模型时,推荐使用本地模式,这有助于他高效地收集模型绿色度指标。服务器模式适用于多人合作或研究机构场景。在这种情况下,不同用户的深度学习模型的绿色度指标被归纳记录,进行可视化分析。
分布式计算 传统单机的机器学习模型已不适用于当前所处的大数据时代。近年来,采用多工作器分布式方法进行深度学习模型训练或部署的使用案例越来越多,分布式训练或部署方案正成为研究者们青睐的方法,GreenFlow-Measure不仅支持单机场景下的数据采集,也支持分布式场景。在分布式场景下,每一个计算结点均会计算当前结点的绿色度指标,通过gRPC通道上传到中心服务进行数据聚合分析与对外服务。
可扩展 GreenFlow-Measure不仅支持Intel和AMD的CPU,还支持NVIDIA的GPU进行能耗数据采集。同时,该工具具有开放的应用程序编程接口(API),鼓励用户自定义不同硬件的能耗采集方法,同时后续我们也将继续扩展工具的覆盖面,支持更多的硬件和软件数据采集。
开发环境友好 GreenFlow-Measure是一个用Python编写的工具,主要用于跟踪训练深度学习模型时的能耗和碳排放。并且可以通过PyPi下载和安装。此外,它是异步与主线程跟踪绿色度数据,对训练性能几乎没有影响。它针对Tensorflow深度学习框架进行优化的,适配了各种不同类型的编码风格,使得用户无感的接入并在最终得到准确的绿色AI评估报告。
3.3.1 技术架构
GreenFlow-Measure采集工具整机架构如图4所示,总共分为三层:
第一层为 采集终端(Agent) ,该层主要为对接用户计算机硬件接口获取元数据,并进行初步加工处理(包括数据拆分和二氧化碳转化),同时将加工后的数据存储与用户本地文件系统,以便用户后续查看和上报核心系统。
第二层为 核心系统(Server) ,该层会收集Agent层所采集的数据并按照用户的实验维度进行聚合,并提供数据存储和数据监控服务,同时在Server端会对用户所有的计算节点中的Agent进行管理,保障用户整个实验绿色度数据完整性。
第三层为 用户接口,该层主要为用户提供了可视化的交互界面和数据服务接口,用户可以根据自己需求启动服务端可视化绿色度数据,并且可以通过开放接口对绿色度数据的二次开发。
图4 GreenFlow-Measure绿色AI评估工具包架构图
4 实验设计与结果
首先在本节将使用LSTM模块验证动态算力采集方法与当前常用的算力采集工具TF Profiler之间的主要区别。其次,本节将验证能耗与负载之间的线性关系,以证明CPU能耗会随着CPU负载而呈现线性增高的趋势,并可以通过该方法得到单个AI模型更加准确的能耗数据。最后,本节将用绿色AI评估工具GreenFlow-Measure对多项人工智能领域常用的数据集和模型进行评估,验证评估工具的性能和有效性。
4.1 动态算力评估
模型浮点计算数是一项能够有效反映模型绿色度的指标。在前文,我们提出了动态算力评估方法,为了验证动态算力评估的准确性,在本节将通过LSTM模块的数学模型,来计算其实际的浮点计算次数,并与各类算力工具做对比,得出各类浮点计算次数评估工具的准确性。
图5 LSTM结构图,其内部结构主要包含3个门控函数(输入门,遗忘门,输出门)
根据推导式(11)~式(16),可以得到LSTM各部分理论算力消耗值如表1所示。
表1 LSTM模块在batch size为1,dim为8时式(11)~式(16)浮点计算次数
另一方面,为了验证动态算力采集工具的精准度,分别使用了TF Profiler工具和本文提出的动态算力方案(RuntimeProfiler)对LSTM模块进行了浮点计算数采集,其结果如表2所示。
表2 各算力评估工具对LSTM模块的计算结果(单位次)
其中 ✖️100% 可以从表2的实验结果看出,TF Profiler对算力评估的估值远低于实际计算量。其主要原因是TF Profiler计算激活函数tanh和sigmoid时,将其消耗简单的记为1而不是其实际的消耗值。并且当step大于1时LSTM模块会出现循环结构,并且每个循环均共享一套参数,但是TF Profiler仅会统计一次循环所产生的浮点计算数,因此会出现极大的偏差。而RuntimeProfiler算力统计模块准确的对模型浮点计算数进行了评估。表2中展示出的RuntimeProfiler比理论值略大,主要是因为手动计算LSTM模块时没有考虑参数初始化等少量算子所产生的浮点计算数。
4.2 能耗与负载的线性关系
为了验证进程能耗拆分方法的准确性和可靠性,本文在不同负载下对一个相同任务进行能耗采集。首先,本文分别采集了单台计算机在负载0%,20%,40%的情况下,使用minst训练LeNet和AlexNet 10个epoch单位时间(10s)内的能耗,其能耗测评结果如表3所示,在不同负载情况下同一任务单位时间能耗差异相差在30J以内(由于外部负载因素,所以实验进程可以得到的资源受到压缩,所以单位时间能耗会有少量差异)。
表3 不同负载下,相同复杂度的计算任务单位时间内的能源消耗相差不大
另一方面,为了验证进程级能耗采集工具的准确性,本文进一步对能耗采集组件进行评估,在表3相同的实验环境下,同时启动两个一样的实验脚本,其能耗评估结果如表4所示。
表4 单机情况下,多次运行相同的实验任务能耗采集结果
综合表3和表4的实验结果,针对同一个实验任务,其产生的能耗在不同的计算机负载情况下均能得到一个较为稳定的值,充分说明本文进程级能耗采集方法的有效性。
4.3 GreenFlow-Measure绿色AI评估工具
在本文介绍了基本动态算力和进程级能耗采集的绿色AI评估工具GreenFlow-Measure,为了评估绿色度采集工具的性能,在本节将选择了多项图像识别和自然语言处理任务进行验证。其中包括了CPU任务、CPU+GPU任务和CPU+多GPU任务,本文计算了这些模型训练任务从开始到结束的能耗、二氧化碳排放和算力消耗,所有的采集数据均通过GreenFlow-Measure工具进行采集并上报至中央服务器进行数据分析。
4.3.1 实验细节
在图像识别任务中,本文使用minst数据集训练了标准的LeNet-5[8]和AlexNet[7],ImageNet数据集训练了ResNet 50,其中batch size为64,总共训练了1个epoch。在自然语言处理任务中,本文使用了Wikipedia语料库预训练BERT-Large其参数配置与文献[9]一致,总训练20k步。当前实验所使用的测试机器拥有2颗Intel(R) Xeon(R) Platinum 8163 CPU和8张Tesla V100-SXM2-16GB GPU,机器地址在中国浙江杭州。
表5 不同模型和任务的能耗、碳排和能耗
可以从表5中的测试数据看出,随着算力消耗的提高,能耗和二氧化碳会同时大量的增长,所以设法降低模型浮点计算次数是当前绿色AI发展中一项十分有意义的研究方向。也希望有更多的研究者加入到降低模型复杂度的工作中来,挑战以更小的算力消耗,获取更强大的模型。
5 总结和展望
深度学习正处于高速发展期间,未来会有越来越多的预训练大模型涌现,而因此带来的却是越来越庞大的能源消耗与更多的环境破坏,我们希望更多的研究者们在追求极致效果的同时,将视线转换到获取更好的结果的同时,降低人工智能研究和开发的成本,因此我们提出了三项评估人工智能模型绿色度的衡量指标,并且开发了绿色AI评估工具包GreenFlow-Measure,我们在多项人工智能领域的研究任务上验证了GreenFlow-Measure能够提供准确的算力消耗、能源消耗和二氧化碳排放数据。希望更多的人们应用GreenFlow-Measure等类似的绿色AI评估工具包准确的评估研究成本,并通过评估报告定向修正研究中的不足。同时,我们也呼吁研究者们将绿色度指标提升到与结果指标一致的地位,因为无休止的算力堆叠会正在逐步的侵蚀环境。
当前GreenFlow-Measure虽然已经建立了成熟的绿色AI评估框架,但是由于深度学习框架和计算机软硬件更新迭代速度快,且品类繁多,所以在未来任然需要投入时间去适配和调整。未来工作主要可以归为以下三类:
支持更多深度学习框架 业界深度学习框架多做多样,当前动态算力计算方案仅针对TensorFlow进行适配,若跳出TensorFlow框架的生态环境,动态算力计算是否仍是当前最优的算力评估方法?是否可以开发一个更加通用的算力计算工具,可以简单的适配到不同的深度学习框架中,是一个当前较为重点的探索方向。
支持更多的操作系统 虽然当前大多数深度学习服务部署在Linux中,但是更多的研究者依旧是使用的Window操作系统平台进行模型训练与实验,所以支持更多的操作系统刻不容缓,并且当前国际上和国内出现了均出现了各种各样基于Linux的定制版操作系统,当前是否能够完全适配和通用,还需要更多的验证。
支持更多的硬件设备 计算机硬件设备更新迭代十分迅速,多种指令集和架构的芯片面世,需要我们持续投入人力支持更多CPU和GPU的适配与验证工作。并且,当前国产的各类型芯片井喷式增长,我们还需要面向一些新兴市场进行适配,将程序可用性进一步提高。
参考文献
1.Roy Schwartz, Jesse Dodge, Noah A. Smith, and Oren Etzioni. Green AI. Commun. ACM, 63(12): 54–63, 2020a.
2.Wilcox, M., Schuermans, S., Voskoglou, C., and Sobolevski, A. Developer economics: State of the developer nation q1 2017. Technical report, 2017.
3.Loïc Lannelongue, Jason Grealey, and Michael Inouye. 2021. Green algorithms: Quantifying the carbon footprint of computation. Advanced Science (2021), 2100707.
4.Lacoste, A., Luccioni, A., Schmidt, V. and Dandres, T., 2019. Quantifying the carbon emissions of machine learning. arXiv preprint arXiv:1910.09700.
5.Anthony, L.F.W.; Kanding, B.; Selvan, R. Carbontracker: Tracking and Predicting the Carbon Footprint of Training Deep Learning Models. arXiv 2020, arXiv:2007.03051.
6.Jingjing Xu, Wangchunshu Zhou, et al. A survey on green deep learning. arXiv:2111.05193, 2021.
7.Krizhevsky A , Sutskever I , Hinton G . ImageNet Classification with Deep Convolutional Neural Networks[J]. Advances in neural information processing systems, 2012, 25(2).
8.Lecun Y , Bottou L . Gradient-based learning applied to document recognition[J]. Proceedings of the IEEE, 1998, 86(11):2278-2324.
9.Vaswani A , Shazeer N , Parmar N , et al. Attention Is All You Need[J]. arXiv, 2017.
关注「阿里巴巴技术质量」阅读更多
本文分享自微信公众号 - 阿里巴巴技术质量(AlibabaTechQA)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。