大家好，又见面了，我是你们的朋友全栈君。
尽可能地设大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的时候，大家都喜欢把显存占满，不过小一些的库，个人感觉还是应该大大小小都尝试一下。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/125764.html原文链接：https://javaforall.cn
