tensorflow
memory error
ResourceExhaustedError
AddV2 operation
deep learning issues

tensorflow.python.framework.errors_impl.ResourceExhaustedError failed to allocate memory OpAddV2

ML System Design practice on Codemia

Design recommenders, ranking systems and training pipelines the way ML interviews actually ask for them, with worked solutions.

Practice ML system design

Introduction

ResourceExhaustedError: failed to allocate memory [Op:AddV2] usually means TensorFlow asked the CPU or GPU for more memory than was available at that moment. The AddV2 part is often just the operation that happened to trigger the allocation failure, not the real root cause. In practice, the problem is usually model size, batch size, tensor shape growth, or GPU memory configuration.

Why AddV2 shows up in the error

AddV2 is TensorFlow's element-wise addition op. Many layers and training steps use addition internally, so it often appears in stack traces even when the overall memory pressure comes from something larger, such as a big activation tensor or a large batch.

That means you should not assume the fix is "change the add operation." Instead, inspect the tensors flowing into the failing step:

  • Batch size
  • Input resolution
  • Model width or depth
  • Intermediate tensor shapes
  • Other processes already using GPU memory

If one tensor unexpectedly becomes huge, even a simple addition can push the program over the limit.

First fix: reduce batch size

The fastest practical fix is usually to lower the batch size because batch size scales the memory needed for activations and gradients.

python
1import tensorflow as tf
2
3(x_train, y_train), _ = tf.keras.datasets.mnist.load_data()
4x_train = x_train.astype("float32") / 255.0
5x_train = x_train[..., None]
6
7model = tf.keras.Sequential([
8    tf.keras.layers.Conv2D(32, 3, activation="relu", input_shape=(28, 28, 1)),
9    tf.keras.layers.Flatten(),
10    tf.keras.layers.Dense(128, activation="relu"),
11    tf.keras.layers.Dense(10)
12])
13
14model.compile(
15    optimizer="adam",
16    loss=tf.keras.losses.SparseCategoricalCrossentropy(from_logits=True),
17    metrics=["accuracy"],
18)
19
20model.fit(x_train, y_train, batch_size=32, epochs=1)

If batch_size=256 fails and batch_size=32 works, you have confirmed the issue is memory pressure rather than a broken TensorFlow install.

GPU memory growth can help

TensorFlow often reserves most visible GPU memory up front. The official GPU guide documents a memory-growth option that lets TensorFlow expand usage as needed instead.

python
1import tensorflow as tf
2
3gpus = tf.config.list_physical_devices("GPU")
4if gpus:
5    for gpu in gpus:
6        tf.config.experimental.set_memory_growth(gpu, True)

Run that before creating tensors or models. It will not make an oversized model fit magically, but it can reduce contention and make development less brittle on shared machines.

Other ways to lower memory use

After batch size, the next levers are model size and tensor precision. Smaller images, fewer channels, fewer layers, or mixed precision training can all reduce the amount of data TensorFlow keeps in memory.

For example, if a classification model uses large dense layers after flattening a high-resolution feature map, those layers can dominate memory. Replacing a flatten-heavy design with pooling is often more efficient.

Another overlooked cause is accidentally storing tensors you no longer need. Keeping entire prediction lists, gradient histories, or repeated model outputs in Python containers can steadily grow memory across training steps.

Check the shape that actually failed

When the error appears suddenly, print tensor shapes around the failing area. A silent broadcasting mistake can turn a modest tensor into a very large temporary one.

python
1import tensorflow as tf
2
3a = tf.ones((64, 1024, 1024))
4b = tf.ones((64, 1024, 1024))
5
6print(a.shape, b.shape)
7c = a + b
8print(c.shape)

That simple example is fine on a capable machine, but the same pattern with larger shapes can quickly exhaust GPU memory. Shape inspection is often more revealing than the final op name in the traceback.

Common Pitfalls

The first pitfall is focusing too literally on AddV2. It is usually the location of failure, not the original design mistake.

Another problem is setting memory growth too late. TensorFlow requires GPU memory configuration before the runtime initializes the device. If you create tensors first and configure later, the setting call can fail.

Developers also forget other GPU users. A browser tab, notebook, or separate training job can already be holding most of the device memory before your script starts.

Finally, be careful with hidden shape explosions from broadcasting, oversized embeddings, or flattening large feature maps. Those issues can create enormous intermediate tensors even when the top-level model looks reasonable.

Summary

  • 'ResourceExhaustedError means TensorFlow ran out of memory, often on the GPU.'
  • 'AddV2 is usually just the op that exposed the memory problem.'
  • Lower batch size first because it is the simplest and most effective fix.
  • Enable GPU memory growth early if you are working on shared hardware.
  • Inspect tensor shapes and model design for accidental memory blowups.

Related reading
Free course
Beginner
7 lessons
2 hours
Tackling System Design Interview Problems

A short course that equips you with the skills to approach system design interviews methodically.

Start the free course
Track what you have practised

A free account saves your progress, solutions and study plan across every problem on Codemia.

ML System Design practice on Codemia

Design recommenders, ranking systems and training pipelines the way ML interviews actually ask for them, with worked solutions.

Practice ML system design

All Rights Reserved.