前言

首先,如果你现在已经很熟悉tf.data+estimator了,可以把文章x掉了╮( ̄▽ ̄””)╭

但是!如果现在还是在进行session.run(…)的话!尤其是苦恼于GPU显存都塞满了利用率却上不去的童鞋,这篇文章或许可以给你打开新世界的大门噢( ̄∇ ̄)

如果发现经过一系列改良后训练效率大大提高了,记得回来给小夕发小红包( ̄∇ ̄)

不过,这并不是一篇怒贴一堆代码,言(三)简(言)意(两)赅(语)就结束的CSDN文风的文章。。。所以伸手党们也可以X掉了╮( ̄▽ ̄””)╭

缘起

很早很早之前,在小夕刚接触tensorflow和使用GPU加速计算的时候,就产生过一个疑惑。为什么显卡的显存都快满了,GPU利用率还显示这么低呢?好浪费呀,但是又无可奈何。当时GPU利用率100%的情况基本是仅存于一块显卡塞4、5个不费显存的小任务的情况。

大部分情况下写出来的代码train起来后是这样的:

可以看到,虽然显卡的显存都塞满了,但是显卡功率(最左边那一栏,114W和69W)和利用率(最右边那一栏,35%和38%)却远远没有达到极限。大部分人的想法是,算了算了这不重要,我去做实验了再见【wei笑】

然而!如果你在做大型实验,train一次跑几天呢?这个细节会极大的影响你的实验效率和DDL到来前的实验次数!想一下,完全一样的model和设置,你的代码要train一周,然而隔壁老王只需要train三天╮( ̄▽ ̄””)╭

路人甲:我有256张显卡
小夕:好了这篇文章你可以X掉了
那么,我们有没有可能一直这样呢:

是不是这功率和利用率看起来不可思议!不要怀疑这是PS的图!这只是小夕的日常截图!tricks用的好GPU利用率掉不下来99%,然鹅代码写的足够蠢,也可以上不去5%!

那么问题来了,到底是什么导致的这个差异呢?
不要急,我们来放大一下那些gpu利用率只有30%几的代码在训练时的gpu利用率的变化情况(好像句子有点长

watch -n 0.1 nvidia-smi

ps:(可能掉帧太严重了看着不连贯╮( ̄▽ ̄"")╭,建议在自己的机器上试一下,会直观的多~)
看!是不是一下子就发现问题啦?可以看到,其实gpu利用率并不是一直在比较低的水平,而是很有规律的周期性的从0涨到接近100再跌到0,再重新涨到100再跌回0。如果同时开着打印日志的窗口,你就会发现这个周期恰好跟每个训练step的时长一致!也就是说,在每个step,其实有一些时间并没有花在GPU里,那当然就是花在cpu里啦。

那在cpu里干什么的呢?当然就是load下一个batch、预处理这个batch以及在gpu上跑出结果后打印日志、后处理、写summary甚至保存模型等,这一系列的花销都要靠cpu去完成。回顾一下我们常写的代码:

create_graph()
create_model_saver()
create_summary_writer()
create_session()
do_init()
for i in range(num_train_steps):load_batch(...)                # cpupreprocess(...)                # cpufeed_dict = {...}              # cpufetch_list = [...]             # cpubuf = session.run(fetch_list, feed_dict)    # gpupostprocess(buf)               # cpuprint(...)                     # cpuif i % x == 0:summary_writer.write(...)  # cpuif i % xx == 0:model_saver.save(...)      # cpu

看,尤其是preprocess(…)任务比较重的话就容易导致代码在cpu里也要跑好一段时间,gpu利用率自然就会上不去而且呈现周期性变化啦。

那么有没有什么办法降低cpu时间,提高gpu时间呢?
一个很自(愚)然(蠢)的想法就是把一切训练代码都用tf的api重写不就好啦,甚至最外层的那个for i in range(num_train_steps)其实都可以用tf.while_loop重写呀。嗯,小夕还真的这么尝试过,然后发现

TF api这特喵的都是些什么鬼!各种跟numpy和python内置函数重名却行为不一致是什么鬼!卧槽这个api少了个参数我该怎么办?python里就一行代码就能搞定的事情我为什么写了几十行??

所以除了函数式编程的大牛,小夕极力的不建议重蹈覆辙!尤其是我们这些遇到汇编会哭,看到Lisp会崩溃的90后小仙女!

所以没办法把整个train loop都描述进计算图了?

别怕别怕,好在后来其实tensorflow已经封装了一个特别好(多)用(坑)的上层API来把整个train loop都能轻松的封装在计算图中,从而实现超级高的GPU利用率和训练效率!

Estimator

不用管它为啥叫Estimator,只需要知道,它把我们刚才想做的事情基本都给封装好了就行。把刚才的那个经典的写法搬过来

1. create_model()
2. create_model_saver()
3. create_summary_writer()
4. create_session()
5. do_init()
6. for i in range(num_train_steps):
7.      load_batch(...)                # cpu
8.      preprocess(...)                # cpu
9.      feed_dict = {...}              # cpu
10.     fetch_list = [...]             # cpu
11.     buf = session.run(fetch_list, feed_dict)    # gpu
12.     postprocess(buf)               # cpu
13.     print(...)                     # cpu
14.     if i % x == 0:
15.         summary_writer.write(...)  # cpu
16.     if i % xx == 0:
17.         model_saver.save(...)      # cpu

1-5行在estimator中都封装好啦,你只需要把相关配置塞进estimator的RunConfig就可以啦~

7-9行也封装好啦,你只需要把数据集载入和预处理的相关代码的函数塞给estimator.train的input_fn~

第10行也封装好啦,你只需要把要fetch的loss、train_op丢进estimator的EstimatorSpec~

第11行也封装好啦,你只需要把描述模型计算图的函数塞给estimator的model_fn~

第12-13行不用操心细节了,global_step和loss自动完成了,剩下的丢给tf.Print和LoggingTensorHook吧~

第14-17行不用你写了,自动完成了

╮(╯▽╰)╭

经过这么一顿折腾,我们发现GPU利用率大大提高啦~直逼80%甚至90%。那么还有没有可以压榨的空间呢?

其实这时仔细一分析就会发现虽然estimator把大部分的代码写进计算图里了,但是从数据的载入和预处理依然是在cpu里串行进行呀,而且比如一个batch有128个样本,那么estimaor内部在run每个step的时候还是要等着这128个样本串行的处理完才行。这显然就是最后的瓶颈啦!有没有办法消除掉呢?·当然有,那就是

tf.data

TF的dataset API可以说让人又爱又恨了,它确实看似提供了一种把整个预处理都搬进计算图进行并行化处理的途径,但是!如果你真的完全用tensorflow API来做复杂的预处理的话,真的会让人疯掉的QAQ因此,这里在用tf.data之前,小夕极力的建议先把数据集尽可能的transform成预处理后的样子,包括做分词、做截断、做word2id等,不过padding和input_mask可以留在TF里面做,毕竟都只需要一行。

那做完这些预处理后,数据该怎么存储会更方便后续的读取和处理呢?最最最建议的方式还是使用tf.records来存储,磁盘、内存的存储和IO效率都会相比传统方式更快一些,x和y也不用分开了。当然这样的唯一的坏处就是不能直接打开看数据集╮( ̄▽ ̄””)╭毕竟数据集被做成了二进制文件。

但是实在比较懒不想用tf.record的话,那么小夕极力建议把x和y分开存储,并且尽量让tf.data在读取数据的时候做完上面的那些必要的预处理,以避开难用的字符串基础操作API并且减轻训练时的cpu和内存压力。

tf.data还有一个很大的好处就是可以很天然的支持以streaming的方式读取数据,这样在面对大数据集时就不会发生数据load完后发现显卡被占的尴尬事件了╮( ̄▽ ̄””)╭

好像讲了这么久,还是没讲怎么用tf.data加速QAQ,来来来进入正题啦。

想想哈,没用tf.data的时候,我们写出来的代码实际跑起来就是这个样子的:

这也是文章开头小夕解释的为什么gpu利用率上不去并且周期性变化的重要原因。那么我们可以不可以消除idle,像下面这样让prepare和train的过程并行进行呢?

当然可以!那就是

prefetch

从prefetch的意思就可以理解,那就是预先获取下一个step要load的batch。使用tf.data里面的叫做prefetch的神奇api就可以轻松完成啦,这个api里的参数buffer_size就是讲的是额外的fetch多少份,比如buffer_size=1,然后我们要prefetch的是batch的话,那么模型每次prepare完一个batch后,就会自动再额外的prepare一个batch,这样下一个train step到来的时候就可以直接从内存中取走这个事先prepare好的batch啦。(详情见后面)

等下,看上图的话,有木有发现,如果prepare一个batch耗时很短的话确实两全齐美,但是如果耗时比较久,尤其一下子prefetch好几个batch的话,一旦prepare的用时超过了train一个step的用时,那么每个train step的性能就会受限于prepare的效率啦。放大一下这个问题的话如下图所示

看,prepare用时太久反而会导致train完一个step后gpu空闲了(虽然其实下个step的batch可能已经prepare好了)

那么能不能确保prepare阶段的用时小于train阶段的用时呢?

parallel mapping

一个很简单的想法当然就是让样本并行处理啦~如果batch size是128,prefetch size=1,那么准备一个batch要串行的跑128*2=256次的预处理,但是如果我们开4个线程去跑,是不是就看起来快多啦。幸运的是我们也不用自己手撸多线程了,tf.data.Dataset在map(预处理)函数里有一个参数num_parallel_calls,给这个参数赋值就可以并行parse啦。如图,

这样的话只要prefetch的buffer_size和map的num_parrellel_calls取得合适,基本就可以实现不间断的train啦,也就是几乎达到100%的GPU利用率!

好啦,思想明白了,代码就容易理解啦。不使用tf.record,直接从预处理好的纯文本格式的数据集load数据时的典型过程如下

def build_input(..):x = tf.data.XXDataset(..)x = x.map(..., num_parallel_calls=N)        # parellely = tf.data.XXDataset(..)y = y.map(..., num_parallel_calls=N)dataset = tf.data.Dataset.zip((x, y))dataset = dataset.repeat(num_epochs)    if is_train:dataset = dataset.shuffle(..)dataset = dataset.batch(batch_size)dataset = dataset.prefetch(buffer_size=1)   # prefetchiterator = dataset.make_xx_iterator()return iterator.get_next()

当然,如果用上tf.record后,就不用分别从x和y俩文件中读数据啦,感兴趣的童鞋可自行去了解一下。

机器学习如何提高GPU利用率相关推荐

  1. 香侬科技Service Streamer:加速深度学习Web服务、极大提高GPU利用率。| 百万人学AI评选

    2020 无疑是特殊的一年,而 AI 在开年的这场"战疫"中表现出了惊人的力量.站在"新十年"的起点上,CSDN[百万人学AI]评选活动正式启动.本届评选活动在 ...

  2. python视频处理加速的库_VPF:适用于 Python 的开源视频处理框架,加速视频任务、提高 GPU 利用率...

    原标题:VPF:适用于 Python 的开源视频处理框架,加速视频任务.提高 GPU 利用率 雷锋网 AI 开发者按:近日,NVIDIA 开源了适用于 Python 的视频处理框架「VideoProc ...

  3. 多个cuda 被单进程沾满_报名 | 提高GPU利用率,听英伟达专家分享这个CUDA工具

    随着 NVIDIA GPU 计算性能的不断提升,如何提升 GPU 利用率是开发者普遍关心的问题之一.从 Kepler 架构开始,NVIDIA GPU 支持多个 CUDA kernels 函数的并发执行 ...

  4. pytorch 提高gpu利用率

    pytorch跑Unet代码,gpu利用率在0%-20%闪现,主要问题是GPU一直在等cpu处理的数据传输过去.利用top查看cup的利用率也是从0省道100%且显然cup的线程并不多,能处理出的数据 ...

  5. VPF:适用于 Python 的开源视频处理框架,加速视频任务、提高 GPU 利用率

    0 背景 近日,NVIDIA 开源了适用于 Python 的视频处理框架「VideoProcessingFramework(VPF)」.该框架为开发人员提供了一个简单但功能强大的 Python 工具, ...

  6. Win10显卡跑不满?是时候给系统洗洗澡了,换系统提高GPU利用率

    有些模型用Win7或Win8跑的好好的,换成Win10以后就跑不动了?这是个什么问题呢,经过查询发现的确是Windows10系统的锅,请看:Win10 CUDA效率问题.也就是说Win10系统会默认预 ...

  7. 提高 Kubernetes 中的 GPU 利用率

    提高 Kubernetes 中的 GPU 利用率 对于可扩展的数据中心性能,NVIDIA GPU 已成为必备品. 由数千个计算内核支持的 NVIDIA GPU 并行处理能力对于加速不同行业的各种应用程 ...

  8. 聊聊GPU利用率那些事

    引言 众所周知,GPU本身的计算能力是越来越强大,特别是新一代的NVIDIA AMPERE架构发布之后,又一次刷新了大家对AI算力的认知.目前,确实有不少大规模分布式训练对更大算力的渴求是极其强烈的, ...

  9. 提高 GPU 训练利用率的Tricks

    前言 首先,如果你现在还是在进行session.run(..)的话!尤其是苦恼于GPU显存都塞满了利用率却上不去的童鞋,这篇文章或许可以给你打开新世界的大门噢 如果发现经过一系列改良后训练效率大大提高 ...

最新文章

  1. 刚刚!2020“中国高被引学者” 榜单发布:清华、北大、浙大位居内地前三!...
  2. 记忆的天空:智能进化三部曲
  3. BZOJ1257 [CQOI2007]余数之和
  4. squid介绍及其简单配置
  5. C语言gauss elimination高斯消元法算法(附完整源码)
  6. 通过非docker的方式进行RocketMQ的安装
  7. ANSI/UTF-8/UCS2(UTF-16),以及回车换行
  8. 转帖科学观点:没有特异性的免疫屏障
  9. c 语言车牌识别系统课题设计,基于图像的车牌识别系统的设计和实现
  10. java cloud面试题_spring cloud 面试题
  11. 计算机无法共享打印机共享的打印机驱动,打印机不能共享_打印机不能共享怎么办?-太平洋IT百科...
  12. 程序员笔试之吉比特雷霆游戏2021届技术类单选题收集整理(十一)
  13. 29、域名ICP备案查询API接口,免费好用
  14. 常见的计算机专业词汇
  15. 苹果公司的iPhone产品以及其历史
  16. linux环境,tomcat 关闭命令sh shutdown.sh 命令执行后进程没有关闭
  17. c语言case2什么意思,switchCase2
  18. 天池O2O优惠券使用预测
  19. JAVA判断字符串以什么什么开始_字符串不能以什么开头 Java 判断字符串是否以什么开头...
  20. 递归与动态规划---换钱的方法数

热门文章

  1. IT企业职业道德的反思
  2. 普元AppServer 使用多数据源
  3. 笑出腹肌,程序员从不撒谎,但注释却会
  4. 一.PHP基础知识相关面试题
  5. Javascript迭代、迭代、穷举、递归常用算法
  6. C语言中,的三种作用
  7. Idea搭建VUE+elementUi前端项目
  8. Flowable初始化失败 Table ‘xxxx‘ already exist
  9. List如何在遍历时删除元素
  10. python四位水仙花数代码_Python一句代码实现找出所有水仙花数的方法