I am about to train a big LSTM network with 2-3M articles and I am struggling with Memory Errors (I use AWS EC2 g2x2large).

I find out that one solution is to reduce the batch_size. However, I am not sure if this parameter is only related with memory efficiency issues or it will have some effects on my results. As a matter of fact I have also noticed that batch_size used in examples usually is a power of two, which I don't understand neither.

I don't mind if my net takes longer to train but I want to know if reducing batch_size will decrease the quality of my predictions.


  • $\begingroup$ This question is not specific to keras. I think the general consesus is that smaller sample sizes converge slower but are less prone to getting stuck in the local minima $\endgroup$ – Alex Oct 23 '17 at 10:06
  • $\begingroup$ I have seen cases where too large a batch size can prevent convergence even with same number of training epochs. $\endgroup$ – Curtis White Oct 14 '18 at 13:04

After one and a half years, I come back to my answer because my previous answer was wrong.

Batch size impacts learning significantly. What happens when you put a batch through your network is that you average the gradients. The concept is that if your batch size is big enough, this will provide a stable enough estimate of what the gradient of the full dataset would be. By taking samples from your dataset, you estimate the gradient while reducing computational cost significantly. The lower you go, the less accurate your esttimate will be, however in some cases these noisy gradients can actually help escape local minima. When it is too low, your network weights can just jump around if your data is noisy and it might be unable to learn or it converges very slowly, thus negatively impacting total computation time.

Another advantage of batching is for GPU computation, GPUs are very good at parallelizing the calculations that happen in neural networks if part of the computation is the same (for example, repeated matrix multiplication over the same weight matrix of your network). This means that a batch size of 16 will take less than twice the amount of a batch size of 8.

In the case that you do need bigger batch sizes but it will not fit on your GPU, you can feed a small batch, save the gradient estimates and feed one or more batches, and then do a weight update. This way you get a more stable gradient because you increased your virtual batch size.

WRONG, OLD ANSWER: [[[No, the batch_size on average only influences the speed of your learning, not the quality of learning. The batch_sizes also don't need to be powers of 2, although I understand that certain packages only allow powers of 2. You should try to get your batch_size the highest you can that still fits the memory of your GPU to get the maximum speed possible.]]]]

  • $\begingroup$ I can't afford 32 but I can afford 16. However, I noticed that it is too slow. Do you think I should try some values between 16-32 or stick with 16? $\endgroup$ – hipoglucido Jul 2 '16 at 8:21
  • $\begingroup$ I would try and time some values. Every epoch should be around the same time so that won't take too long. Try 17 first to see if it's faster or slower because I'm interested in this, given that this power of 2 depends on GPU and/or backend of Keras. But I think just filling it to the brim is likely best $\endgroup$ – Jan van der Vegt Jul 2 '16 at 8:23
  • 8
    $\begingroup$ Are you sure that batch size doesn't influence the quality of learning? I remember reading some blogs/papers(?) where they said that smaller batches produce noisier gradients than larger batches, but noise can be useful to get out of local minimas. Not sure if/how this applies to LSTMs though. $\endgroup$ – stmax Jul 4 '16 at 9:54
  • $\begingroup$ Not entirely convinced, haven't had enough experience myself but that is what I read. I can see the gradients being less stable so I might be off. $\endgroup$ – Jan van der Vegt Jul 4 '16 at 11:50
  • 1
    $\begingroup$ One and a half years later and a lot more knowledgable now and I agree. I'm going to change my answer $\endgroup$ – Jan van der Vegt Oct 13 '17 at 9:14

I feel the accepted answer is possibly wrong. There are variants in Gradient Descent Algorithms.

  1. Vanilla Gradient Descent: Here the Gradient is being calculated on all the data points at a single shot and the average is taken. Hence we have a smoother version of the gradient takes longer time to learn.

  2. Stochastic Gradient Descent : Here one-data point at a time hence the gradient is aggressive (noisy gradients) hence there is going to be lot of oscillations ( we use Momentum parameters - e.g Nesterov to control this). So there is a chance that your oscillations can make the algorithm not reach a local minimum.(diverge).

  3. Mini-Batch Gradient Descent: Which takes the perks of both the previous ones averages gradients of a small batch. Hence not too aggressive like SGD and allows Online Learning which Vanilla GD never allowed.

The smaller the Mini-Batch the better would be the performance of your model (not always) and of course it has got to do with your epochs too faster learning. If you are training on large dataset you want faster convergence with good performance hence we pick Batch-GD's.

SGD had fixed learning parameter hence we start other Adaptive Optimizers like Adam, AdaDelta, RMS Prop etc which changes the learning parameter based on the history of Gradients.

  • $\begingroup$ 3) is called minibatch usually $\endgroup$ – Alex Sep 20 '17 at 9:14
  • $\begingroup$ @Alex: added the change. $\endgroup$ – Jil Jung Juk Sep 20 '17 at 9:59
  • $\begingroup$ I agree there is no rule regarding the batch-size parameter. But this statement - "The smaller the Mini-Batch the better would be the performance of your model" - is contrary to the general rule. You generally want to maximize the batch-size $\endgroup$ – MonsieurBeilto Nov 21 '18 at 22:35

Oddly enough, I found that larger batch sizes with keras require more epochs to converge.

For example, the output of this script based on keras' integration test is

epochs 15   , batch size 16   , layer type Dense: final loss 0.56, seconds 1.46
epochs 15   , batch size 160  , layer type Dense: final loss 1.27, seconds 0.30
epochs 150  , batch size 160  , layer type Dense: final loss 0.55, seconds 1.74


Using too large a batch size can have a negative effect on the accuracy of your network during training since it reduces the stochasticity of the gradient descent.

Edit: most of the times, increasing batch_size is desired to speed up computation, but there are other simpler ways to do this, like using data types of a smaller footprint via the dtype argument, whether in keras or tensorflow, e.g. float32 instead of float64


Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.