尽可能地设大batchsize "Large Batch
Large Batch在 keypoints上也是有用的,大概能提到0.4到0.3的点的AP。"
在利用 ImageNet 训练 AlexNet 模型时,其中每 GPU 的最优批量大小为 512。如果我们希望使用大量 GPU 并保证每 GPU
皆拥有理想的执行效率,则应当将批量大小设定为 16 x 512 = 8192。 "Train的batch是多少?
我们训练的时候根据输入图像的尺寸不同,batch_size在20到64之间。"
SGD 算法的 batch size 并不能无限制地增大。SGD 采用较大的 batch size 时,如果还是使用同样的 epochs
数量进行运算,则准确度往往低于 batch size 较小的场景 ; 而且目前还不存在特定算法方案能够帮助我们高效利用较大的 batch size。
对于大批量训练场景,我们需要确保使用较大的 batch size 训练能够在相同 epochs 前提下获得与较小的 batch size
相近的测试准确度。这里我们之所以保持 epochs 数量不变,是因为从统计学角度来讲,一个 epoch 代表着算法与整体数据集接触一次 ;
而从计算角度来讲,固定 epochs 数量意味着保证浮点运算次数不变。
Batch_Size 既然 Full Batch Learning 并不适用大数据集,那么走向另一个极端怎么样?所谓另一个极端,就是每次只训练一个样本,即
Batch_Size = 1。这就是在线学习(Online
Learning)。线性神经元在均方误差代价函数的错误面是一个抛物面,横截面是椭圆。对于多层神经元、非线性网络,在局部依然近似是抛物面。使用在线学习,每次修正方向以各自样本的梯度方向修正,横冲直撞各自为政,难以达到收敛。
在合理范围内,增大batch size "好处
1)内存利用率提高了,大矩阵乘法的并行化效率提高。
2)跑完一次 epoch(全数据集)所需的迭代次数减少,对于相同数据量的处理速度进一步加快。
3)在一定范围内,一般来说 Batch_Size 越大,其确定的下降方向越准,引起训练震荡越小。"
“随着 Batch_Size 增大,处理相同数据量的速度越快。
随着 Batch_Size 增大,达到相同精度所需要的 epoch 数量越来越多。” 由于最终收敛精度会陷入不同的局部极值,因此 Batch_Size
增大到某些时候,达到最终收敛精度上的最优。
"盲目增大 Batch_Size 有何坏处?
1)Batch_Size 增大到一定程度,其确定的下降方向已经基本不再变化。
2)太大的batch size 容易陷入sharp minima,泛化性不好"
Batch_Size 太小 收敛太慢,算法在 200 epoches 内不收敛。 基于梯度下降的情况下
"样本量少的时候会带来很大的方差,而这个大方差恰好会导致我们在梯度下降到很差的局部最优点(只是微微凸下去的最优点)和鞍点的时候不稳定,一不小心就因为一个大噪声的到来导致炸出了局部最优点,或者炸下了马(此处请保持纯洁的心态!),从而有机会去寻找更优的最优点。
因此,与之相反的,当样本量很多时,方差很小(咦?最开始的时候好像在说标准差来着,反正方差与标准差就差个根号,没影响的哈~),对梯度的估计要准确和稳定的多,因此反而在差劲的局部最优点和鞍点时反而容易自信的呆着不走了,从而导致神经网络收敛到很差的点上,跟出了bug一样的差劲。
小总结一下,batch的size设置的不能太大也不能太小,因此实际工程中最常用的就是mini-batch,一般size设置为几十或者几百。"
“使用更大的方差来试探最优点的质量。
所以在小batch size时,逐渐减少learning rate的神经网络玩的就是退火算法。
不同的batch size不仅仅会影响你的收敛速度,还经常影响你最终收敛时的准确率。
工程上实验验证 batch size 越大,比如1000 对 100的效果要差。即发现batch 太多大, 训练一点效果没。”
"这之前我们的讨论是基于梯度下降的,而且默认是一阶的(即没有利用二阶导数信息,仅仅使用一阶导数去优化)。因此对于SGD(随机梯度下降)及其改良的一阶优化算法如Adagrad、Adam等是没问题的,但是对于强大的二阶优化算法如共轭梯度法、L-BFGS来说,如果估计不好一阶导数,那么对二阶导数的估计会有更大的误差,这对于这些算法来说是致命的。
因此,对于二阶优化算法,减小batch换来的收敛速度提升远不如引入大量噪声导致的性能下降,因此在使用二阶优化算法时,往往要采用大batch哦。此时往往batch设置成几千甚至一两万才能发挥出最佳性能。
另外,听说GPU对2的幂次的batch可以发挥更佳的性能,因此设置成16、32、64、128…时往往要比设置为整10、整100的倍数时表现更优"
batch太大容易错事最有点,太小的话又会出现在局部最小点附近剃度下降特别慢,所以很多架构都有一个decay参数,在前期使用大的batch
如何选择batch size "一般而言,根据你的GPU显存,设置为最大,而且一般要求是8的倍数(比如32,128),这样,GPU内部的并行运算效率最高。
那么怎么选择batch
number呢?就像刚才说的,8的倍数,然后是稍微大一点(一般而言)。另外一个方法,就是选择一部分数据,跑几个batch看看你的loss是不是在变小,选择一个合适的就可以了。"
cpu有预取, gpu有合并访问, 不仅仅要求长度是2的次方, 内存地址也是有要求的
"batch_size设的大一些,收敛得快,也就是需要训练的次数少,准确率上升得也很稳定,但是实际使用起来精度不高。
batch_size设的小一些,收敛得慢,而且可能准确率来回震荡,所以还要把基础学习速率降低一些;但是实际使用起来精度较高。一般我只尝试batch_size=64或者batch_size=1两种情况。"
"我来简单说一下怎么操作吧,
* Batch size设置以喂饱你的硬件为主要标准。只要显卡塞得下,首先挑大的。
* 当感觉训练时噪音不够时,比如收敛碰到鞍点或者局部最小值时,调小batch size。(很少会碰到)
* 当感觉训练时噪音太大时,调大batch size到喂饱硬件(因为2很少碰到,这也很少做),再不行就调小learning
rate,也可以直接调小learning rate。
综合起来用就是常见的带learning rate下降的sgd。开始时依赖batch带来的噪音快速下降,接下来使用较低的learning
rate消除这些噪音寻求稳定收敛。一般而言只要batch不太大,样本里的噪音总是够用的。
cpu是非常讨厌16,32,64…… 这样大小的数组的,gpu没有类似的问题(gpu 上最好都是 32 倍数,和 wrap 一致,可见cuda
gpu的文档),但我还是要劝大家,超参的选取随意点。
"
"full batch是特殊的mini batch。
batch size越大每次迭代的梯度越接近样本的真实梯度。
小的batch size能有效避免样本中的冗余信息。
大的batch能更充分利用GPU。
batch的大小并没有固定模式,不需要非要2^n的size。
综合以上几点进行权衡,选择你的batch。"
就个人经验而论 batchsize越大越好1.震荡明显减少 2.收敛速度加快
3.同样学习率下大batch可以收敛到更好的水平。目前没发现什么大batch过早陷入局部最优的现象,在我这都是batch越大,精度越高,当然我还在继续实验观察
实验
这个做过几个实验,但是没有详细的做,主要是针对googlenet,alexnet以及vgg几个模型(实验结果就是batch为32的时候,alex开始收敛,但是googlenet不收敛;提高batch
size,googlenet开始收敛)。就像lecun[note](http://cilvr.nyu.edu/lib/exe/fetch.php?media=deeplearning:dl-optimization.pdf)里说的一样,随机梯度下降不能像full
batch那样明显的保证收敛。
可能因为我调参的能力比较有限,确实batchsize太小会出现网络收敛不稳定,最后结果比较差的情况,这个在ImageNet和其他数据库上都遇到过,而batchsize太大确实也会影响随机性的引入。目前一般调ImageNet的时候,大家都喜欢把显存占满,不过小一些的库,个人感觉还是应该大大小小都尝试一下。
batch size与BN "batch size大了一个epoch update数量少了的这个缺点在bn面前似乎也没太多存在感了。
不过bn的坏处就是不能用太小的batch
size,要不然mean和variance就偏了。所以现在一般是显存能放多少就放多少。而且实际调起模型来,真的是数据分布和预处理更为重要,数据不行的话
玩再多花招也没用。" 另外如果用了batchnorm,batch size别太小
"BN 大法虽然好,但是也存在一些局限和问题,诸如当 BatchSize 太小时效果不佳、对 RNN 等动态网络无法有效应用 BN 等。
Batch Size 的影响,目前可以实验证实的是:batch size 设置得较小训练出来的模型相对大 batch size
训练出的模型泛化能力更强,在测试集上的表现更好,而太大的 batch size 往往不太
Work,而且泛化能力较差。但是背后是什么原因造成的,目前还未有定论,持不同看法者各持己见。"
热门工具 换一换