# Batch size vs gradient accumulation

**URL:** <https://discuss.huggingface.co/t/batch-size-vs-gradient-accumulation/5260>\
**Category:** Beginners\
**Created:** [April 1, 2021, 3:09pm UTC](https://discuss.huggingface.co/t/batch-size-vs-gradient-accumulation/5260 "2021-04-01T15:09:26Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![ozcangundes](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/ozcangundes/32/2346_2.png) [@ozcangundes](https://discuss.huggingface.co/u/ozcangundes)\
**Post date:** [April 1, 2021, 3:09pm UTC](https://discuss.huggingface.co/t/batch-size-vs-gradient-accumulation/5260/1 "2021-04-01T15:09:26Z")

</div>

Hi,

I have a basic theoretical question. Which one is better for the model and GPU usage?

First option:

```auto
--per_device_train_batch_size 8 
--gradient_accumulation_steps 2

```

Second option:  
`--per_device_train_batch_size 16`

---

<div class="post-metadata">

**Author:** ![sgugger](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/sgugger/32/2291_2.png) [@sgugger](https://discuss.huggingface.co/u/sgugger)\
**Post date:** [April 1, 2021, 3:55pm UTC](https://discuss.huggingface.co/t/batch-size-vs-gradient-accumulation/5260/2 "2021-04-01T15:55:21Z")

</div>

If the second one does not OOM, you should have better performance with it. The first is a way to get around the memory error the second would give you.

Both commands are completely equivalent in terms of training done otherwise.

---

<div class="post-metadata">

**Author:** ![bui](https://avatars.discourse-cdn.com/v4/letter/b/91b2a8/32.png) [@bui](https://discuss.huggingface.co/u/bui)\
**Post date:** [December 21, 2021, 12:09pm UTC](https://discuss.huggingface.co/t/batch-size-vs-gradient-accumulation/5260/3 "2021-12-21T12:09:19Z")

</div>

Hi @sgugger

It is better if you can supply some references on this problem.

---

<div class="post-metadata">

**Author:** ![BramVanroy](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/bramvanroy/32/47360_2.png) [@BramVanroy](https://discuss.huggingface.co/u/BramVanroy)\
**Post date:** [December 21, 2021, 12:13pm UTC](https://discuss.huggingface.co/t/batch-size-vs-gradient-accumulation/5260/4 "2021-12-21T12:13:35Z")

</div>

A source is not necessary for this, I think. The goal of gradient accumulation is exactly to overcome memory constraints of the hardware.

---

<div class="post-metadata">

**Author:** ![bui](https://avatars.discourse-cdn.com/v4/letter/b/91b2a8/32.png) [@bui](https://discuss.huggingface.co/u/bui)\
**Post date:** [December 21, 2021, 12:30pm UTC](https://discuss.huggingface.co/t/batch-size-vs-gradient-accumulation/5260/5 "2021-12-21T12:30:31Z")

</div>

So where is the difference in performance between using GA and without GA as @sgugger mentioned in his answer?

I am not sure that it just involves hardware only.

---

<div class="post-metadata">

**Author:** ![sgugger](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/sgugger/32/2291_2.png) [@sgugger](https://discuss.huggingface.co/u/sgugger)\
**Post date:** [December 21, 2021, 3:14pm UTC](https://discuss.huggingface.co/t/batch-size-vs-gradient-accumulation/5260/6 "2021-12-21T15:14:54Z")

</div>

Using gradient accumulation loops over your forward and backward pass (the number of steps in the loop being the number of gradient accumulation steps). A for loop over the model is less efficient than feeding more data to the model, as you’re not taking advantage of the parallelization your hardware can offer.

The only reason to use gradient accumulation steps is when your whole batch size does not fit on one GPU, so you pay a price in terms of speed to overcome a memory issue.

---

<div class="post-metadata">

**Author:** ![lkurlandski](https://avatars.discourse-cdn.com/v4/letter/l/b782af/32.png) [@lkurlandski](https://discuss.huggingface.co/u/lkurlandski)\
**Post date:** [July 11, 2023, 10:07pm UTC](https://discuss.huggingface.co/t/batch-size-vs-gradient-accumulation/5260/7 "2023-07-11T22:07:13Z")

</div>

As far as I am aware, the common rule of thumb to select the batch size is “as big as your hardware can support”. For example, [the most recent leaks concerning GPT-4’s training](https://www.reddit.com/r/LocalLLaMA/comments/14wbmio/gpt4_details_leaked/) suggest that a staggering batch size of 60M is used. This makes me wonder how an engineer should balance the batch size and gradient accumulation steps hyperparameters. For example, at what point do the potential drawback of increasing gradient accumulation steps outweigh the benefits that are attained by using large batch sizes (I guess this particular question would specifically pertain to the clear performance benefits of large batch sizes vs the possible convergence benefits)?

---

<div class="post-metadata">

**Author:** ![Ntsako](https://avatars.discourse-cdn.com/v4/letter/n/7feea3/32.png) [@Ntsako](https://discuss.huggingface.co/u/Ntsako)\
**Post date:** [April 12, 2024, 11:42am UTC](https://discuss.huggingface.co/t/batch-size-vs-gradient-accumulation/5260/8 "2024-04-12T11:42:07Z")

</div>

such a beautiful answer bro, it just clicked

---

<div class="post-metadata">

**Author:** ![xshubhamx](https://avatars.discourse-cdn.com/v4/letter/x/90ced4/32.png) [@xshubhamx](https://discuss.huggingface.co/u/xshubhamx)\
**Post date:** [April 17, 2024, 6:10am UTC](https://discuss.huggingface.co/t/batch-size-vs-gradient-accumulation/5260/9 "2024-04-17T06:10:36Z")

</div>

Isnt it the opposite? Using batched input results in higher memory usage and not gradient accumulation. If gradient accumulation is giving an OOM (Out Of Memory Error), it is guranteed that the first one will also give the same error

---

<div class="post-metadata">

**Author:** ![CChung-at-VSA](https://sea2.discourse-cdn.com/hellohellohello/user_avatar/discuss.huggingface.co/cchung-at-vsa/32/53048_2.png) [@CChung-at-VSA](https://discuss.huggingface.co/u/CChung-at-VSA)\
**Post date:** [November 28, 2024, 11:56pm UTC](https://discuss.huggingface.co/t/batch-size-vs-gradient-accumulation/5260/10 "2024-11-28T23:56:33Z")

</div>

- Thanks to @ozcangundes for this question. It helps me to understand the interaction of batch\_size and gradient\_accumulation\_steps, and to calculate the number of chunks/rows processed in each step (basically the product of the two), and the number of steps (# of chunks/# of chunks processed in each step).
- Although theoretically, First option and Second option should be the essentially the same (round error notwithstanding), be aware of a bug in small batch size that got fixed just recently.
- Here is the link:  
[Fine-tuning with small batch sizes and gradient accumulation poorly perform if you use Transformers (TRL)!](https://www.reddit.com/r/LocalLLaMA/comments/1g0dy0k/finetuning_with_small_batch_sizes_and_gradient/).
- Basically, batch\_size=1 and gradient\_accumulation\_steps=32 is much worse than batch\_size= 32 and gradient\_accumulation\_steps=1 while they are mathematically equivalent! From this article, batch\_size of 8 seems to be just good enough.
- Here is one of the fix (and HF has also a fix subsequently): [LLM training bug fixes - Gradient accumulation was wrong](https://www.reddit.com/r/LocalLLaMA/comments/1g4ego7/llm_training_bug_fixes_gradient_accumulation_was/)  
[Bugs in LLM Training - Gradient Accumulation Fix](https://unsloth.ai/blog/gradient)  
[Transformers Release Notes v4.46.3 and v4.46.0](https://github.com/huggingface/transformers/releases)
- This bug seems to have pretty widespread consequence, and could affect many models.
