Multi GPU Training in Tensorflow Data Parallelism when Using feed_dict
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
In legacy TensorFlow 1.x code, multi-GPU data parallelism usually means building one model tower per GPU, splitting each training batch in Python, computing gradients on each device, and then averaging those gradients before applying a single update. This works with feed_dict, but it is verbose and is best thought of as maintenance knowledge rather than the preferred design for new TensorFlow code.
The Core Idea of Synchronized Data Parallelism
The high-level pattern is simple:
- each GPU gets the same model structure,
- each GPU receives a different slice of the batch,
- each tower computes its own loss and gradients,
- the host averages gradients and applies one shared optimizer step.
The last part is what makes the training synchronized. If each GPU updates its own weights independently, you no longer have the usual synchronized data-parallel setup.
Build One Tower Per GPU
A classic TensorFlow 1.x pattern uses separate placeholders per GPU shard and variable reuse after the first tower.
The reuse rule matters a lot. Only the first tower should create variables. Later towers must reuse those same variables.
Average the Gradients
After each GPU computes gradients, average them and apply a single update.
This is the synchronization step. Without it, the towers are not cooperating on one shared update.
Split the Batch in Python and Feed Each Tower
With feed_dict, the host code has to split the training batch manually.
This works, but it also shows why the pattern is considered legacy. Python becomes responsible for device sharding and input feeding, which can become a bottleneck.
Why Newer TensorFlow Uses tf.distribute
Modern TensorFlow usually solves this problem with tf.distribute.MirroredStrategy or related APIs. Those tools handle replication, synchronization, and device placement for you and integrate better with tf.data and Keras.
So the feed_dict tower pattern is still useful to understand when inheriting old code, but it is rarely the best design for new training pipelines.
Common Pitfalls
A common mistake is forgetting variable reuse and accidentally creating a separate model on each GPU instead of shared towers.
Another issue is averaging losses but not gradients, which is not the same optimization rule.
Teams also often underestimate the Python-side bottleneck. Even if the GPUs are configured correctly, feed_dict can become the limiting factor when input delivery is slow.
Summary
- Legacy TensorFlow multi-GPU training with
feed_dictuses one tower per GPU and averaged gradients. - Each tower must share the same variables rather than creating a separate model copy.
- Python splits the batch and feeds each tower separately.
- Gradient averaging is what makes the update synchronized across GPUs.
- For new TensorFlow code,
tf.distributeis usually the better solution.

