深圳专业做网站建网站价格,湖南seo推广方法,大型购物网站有哪些,俄罗斯门户网站有哪些前言首先#xff0c;如果你现在已经很熟悉tf.dataestimator了#xff0c;可以把文章x掉了╮(#xffe3;▽#xffe3;””)╭但是#xff01;如果现在还是在进行session.run(..)的话#xff01;尤其是苦恼于GPU显存都塞满了利用率却上不去的童鞋#xff0c;这篇文章或许… 前言首先如果你现在已经很熟悉tf.dataestimator了可以把文章x掉了╮(▽””)╭但是如果现在还是在进行session.run(..)的话尤其是苦恼于GPU显存都塞满了利用率却上不去的童鞋这篇文章或许可以给你打开新世界的大门噢(∇)如果发现经过一系列改良后训练效率大大提高了记得回来给小夕发小红包(∇)不过这并不是一篇怒贴一堆代码言三简言意两赅语就结束的CSDN文风的文章。。。所以伸手党们也可以X掉了╮(▽””)╭缘起很早很早之前在小夕刚接触tensorflow和使用GPU加速计算的时候就产生过一个疑惑。为什么显卡的显存都快满了GPU利用率还显示这么低呢好浪费呀但是又无可奈何。当时GPU利用率100%的情况基本是仅存于一块显卡塞4、5个不费显存的小任务的情况。在比较极端的情况下甚至GPU的利用率会降到10%以下就像这样而大部分情况下写出来的代码train起来后是这样的可以看到虽然显卡的显存都塞满了但是显卡功率最左边那一栏114W和69W和利用率最右边那一栏35%和38%却远远没有达到极限。大部分人的想法是算了算了这不重要我去做实验了再见然而如果你在做大型实验train一次跑几天呢这个细节会极大的影响你的实验效率和DDL到来前的实验次数想一下完全一样的model和设置你的代码要train一周然而隔壁老王只需要train三天╮(▽””)╭路人甲我有256张显卡小夕好了这篇文章你可以X掉了那么我们有没有可能一直这样呢是不是这功率和利用率看起来不可思议不要怀疑这是PS的图这只是小夕的日常截图tricks用的好GPU利用率掉不下来99%然鹅代码写的足够蠢也可以上不去5%那么问题来了到底是什么导致的这个差异呢不要急我们来放大一下那些gpu利用率只有30%几的代码在训练时的gpu利用率的变化情况好像句子有点长watch -n 0.1 nvidia-smips:可能掉帧太严重了看着不连贯╮(▽)╭建议在自己的机器上试一下会直观的多看是不是一下子就发现问题啦可以看到其实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(...) # cpu1-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.dataTF的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_size1然后我们要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是128prefetch size1那么准备一个batch要串行的跑128*2256次的预处理但是如果我们开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_callsN) # parellely tf.data.XXDataset(..)y y.map(..., num_parallel_callsN)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_size1) # prefetchiterator dataset.make_xx_iterator()return iterator.get_next()当然如果用上tf.record后就不用分别从x和y俩文件中读数据啦感兴趣的童鞋可自行去了解一下。补充福利当然刚从传统的代码迁移到tf.dataestimator的时候可能会不太适应最主要的还是debug的方式不能像之前一样直接session.run(debug_tensor)了那怎么办呢一般来说我们打印tensor有两种情况一种是计算图出错时需要打印一次或几次来定位问题一种是像global_steploss等需要周期性check。对于这两种情况之前是习惯session.run的时候把要打印的tensor也run出来而现在这两种情况可以区分对待啦。对于第一种小夕感觉最高效的还是直接在计算图里插tf.Print(..)使用非常方便debug能力很强大如果打印还需要配合global step加一条tf.cond就搞定啦。对于第二种其实global step和loss的话estimator默认就会打印出来如果是其他需要周期性打印的tensor那么就用tf.train.LoggingTensorHook包装一下然后丢进estimator.train里吧习惯之后竟然还感觉挺方便的m(_ _)m最后愿天下没有空闲的显卡
