训练过程--Batchsize（总之一般情况下batchsize能设多大就设多大）

ゝ一世哀愁。 2023-01-09 12:42 119阅读 0赞

只做记录，原文：https://blog.csdn.net/wydbyxr/article/details/84855489  
尽可能地设大batchsize

# 在合理范围内，增大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，泛化性不好。  
3）Batch\_Size 太小 收敛太慢，算法在 200 epoch 内不收敛。

# 不同的梯度下降算法下，不同Batch\_Size设置的影响 #

样本量少的时候会带来很大的方差，而这个大方差恰好会导致我们在梯度下降到很差的局部最优点（只是微微凸下去的最优点）和鞍点的时候不稳定，一不小心就因为一个大噪声的到来导致炸出了局部最优点，从而有机会去寻找更优的最优点。  
因此，与之相反的，当样本量很多时，方差很小，对梯度的估计要准确和稳定的多，因此反而在差劲的局部最优点和鞍点时反而容易自信的呆着不走了，从而导致神经网络收敛到很差的点上，跟出了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设置成几千甚至一两万才能发挥出最佳性能。

# batch\_size与2的倍数 #

一般而言，根据你的GPU显存，设置为最大，而且一般要求是8的倍数（比如32，128），这样，GPU内部的并行运算效率最高。  
那么怎么选择batch number呢？就像刚才说的，8的倍数，然后是稍微大一点（一般而言）。另外一个方法，就是选择一部分数据，跑几个batch看看你的loss是不是在变小,选择一个合适的就可以了。  
cpu有预取, gpu有合并访问, 不仅仅要求长度是2的次方, 内存地址也是有要求的。

另外，听说GPU对2的幂次的batch可以发挥更佳的性能，因此设置成16、32、64、128…时往往要比设置为整10、整100的倍数时表现更优。  
batch太大容易错事最有点，太小的话又会出现在局部最小点附近剃度下降特别慢，所以很多架构都有一个decay参数，在前期使用大的batch。

cpu是非常讨厌16，32，64…… 这样大小的数组的，gpu没有类似的问题（gpu 上最好都是 32 倍数，和 wrap 一致，可见cuda gpu的文档），但我还是要劝大家，超参的选取随意点。

# batch size与BN #

batch size大了则一个epoch update数量少的这个缺点，在bn面前似乎也没太多存在感了。  
不过bn的坏处就是不能用太小的batch size，要不然mean和variance就偏了。所以现在一般是显存能放多少就放多少。而且实际调起模型来，真的是数据分布和预处理更为重要，数据不行的话 玩再多花招也没用。  
如果用了batchnorm，batch size别太小（BN 大法虽然好，但是也存在一些局限和问题，诸如当 BatchSize 太小时效果不佳、对 RNN 等动态网络无法有效应用 BN 等）。

# 设置多大的batch\_size(未整理，凑合着看吧) #

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设的大一些，收敛得快，也就是需要训练的次数少，准确率上升得也很稳定，但是实际使用起来精度不高。  
batch\_size设的小一些，收敛得慢，而且可能准确率来回震荡，所以还要把基础学习速率降低一些；但是实际使用起来精度较高。一般我只尝试batch\_size=64或者batch\_size=1两种情况。  
Batch Size 的影响，目前可以实验证实的是：batch size 设置得较小训练出来的模型相对大 batch size 训练出的模型泛化能力更强，在测试集上的表现更好，而太大的 batch size 往往不太 Work，而且泛化能力较差。但是背后是什么原因造成的，目前还未有定论，持不同看法者各持己见。

Batch size设置以喂饱你的硬件为主要标准。只要显卡塞得下，首先挑大的。  
当感觉训练时噪音不够时，比如收敛碰到鞍点或者局部最小值时，调小batch size。（很少会碰到）  
当感觉训练时噪音太大时，调大batch size到喂饱硬件（因为2很少碰到，这也很少做），再不行就调小learning rate，也可以直接调小learning rate。  
综合起来用就是常见的带learning rate下降的sgd。开始时依赖batch带来的噪音快速下降，接下来使用较低的learning rate消除这些噪音寻求稳定收敛。一般而言只要batch不太大，样本里的噪音总是够用的。  
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开始收敛）。就像lecunnote里说的一样，随机梯度下降不能像full batch那样明显的保证收敛。

可能因为我调参的能力比较有限，确实batchsize太小会出现网络收敛不稳定，最后结果比较差的情况，这个在ImageNet和其他数据库上都遇到过，而batchsize太大确实也会影响随机性的引入。目前一般调ImageNet的时候，大家都喜欢把显存占满，不过小一些的库，个人感觉还是应该大大小小都尝试一下。