Introduction

In Keras, use_multiprocessing controls how background workers fetch data for model.fit when the input pipeline uses generator-style loading. It does not make the model itself train on multiple CPUs or GPUs. Its purpose is narrower: it can parallelize data loading and preprocessing so the training loop spends less time waiting for batches.

What the Flag Actually Affects

The use_multiprocessing argument matters when Keras is pulling data from a Python generator or a Sequence-style object with background workers. In that situation, Keras can create worker processes instead of worker threads.

The related arguments are usually:

• 'workers: how many background workers to use'
• 'use_multiprocessing: whether those workers are separate processes instead of threads'
• 'max_queue_size: how many prepared batches can wait in the queue'

A simplified example with a Sequence looks like this:

1import math
2import numpy as np
3import tensorflow as tf
4
5class ToySequence(tf.keras.utils.Sequence):
6    def __len__(self):
7        return math.ceil(100 / 10)
8
9    def __getitem__(self, idx):
10        x = np.random.rand(10, 4).astype("float32")
11        y = np.random.randint(0, 2, size=(10, 1)).astype("float32")
12        return x, y
13
14model = tf.keras.Sequential([
15    tf.keras.layers.Dense(8, activation="relu", input_shape=(4,)),
16    tf.keras.layers.Dense(1, activation="sigmoid")
17])
18
19model.compile(optimizer="adam", loss="binary_crossentropy")
20model.fit(
21    ToySequence(),
22    epochs=2,
23    workers=4,
24    use_multiprocessing=True,
25    max_queue_size=10,
26)

In this setup, Keras can prepare batches in parallel while the main process focuses on training steps.

Why Separate Processes Can Help

Python threads are limited by the GIL for CPU-bound Python code. If your generator spends significant time decoding files, augmenting images, or doing Python-heavy preprocessing, process-based workers can use multiple CPU cores more effectively than threads.

That means use_multiprocessing=True is mainly useful when data preparation is the bottleneck, not when the model computation is the bottleneck.

If batch generation is already fast, turning on multiprocessing may add overhead without improving throughput.

It Does Not Parallelize the Model Itself

A common misunderstanding is that use_multiprocessing=True makes training itself run in parallel. It does not. The forward pass, backward pass, and optimizer steps still run according to the model's actual execution environment, such as one CPU process or a GPU.

The flag only changes how input batches are produced and queued.

So if training is slow because the model is large or the GPU is saturated, this flag may do nothing useful.

Sequence Is Safer Than a Plain Generator

When using worker processes, tf.keras.utils.Sequence is usually safer than an arbitrary Python generator because it provides deterministic indexing and clearer multiprocessing behavior.

A plain generator can be harder to serialize or harder to coordinate across workers. A Sequence object gives Keras a more controlled contract for parallel access.

That is why many examples pair workers and use_multiprocessing with Sequence instead of with a handwritten infinite generator.

Platform and Debugging Considerations

Multiprocessing behavior differs by operating system. On Windows and sometimes in notebook environments, process spawning can be more fragile than on Unix-like systems. Code that works in a Linux script may need additional care in interactive environments.

Multiprocessing also increases memory overhead because each worker process needs its own state. If the generator holds large arrays or large preprocessing objects, using too many workers can make memory usage worse instead of better.

When to Use It

Use use_multiprocessing=True when all of these are true:

• the input pipeline is generator- or Sequence-based
• batch creation is noticeably slower than model execution
• preprocessing is CPU-heavy enough to benefit from multiple processes
• the generator is safe to run in parallel

If your input comes from tf.data, this flag is usually not the right optimization knob. tf.data has its own parallelism controls and is often the preferred modern input pipeline.

Common Pitfalls

The most common mistake is expecting use_multiprocessing to speed up model computation. It only affects data loading workers.

Another mistake is enabling multiprocessing for a generator that is not safe to share across multiple workers. That can lead to duplicate batches, hangs, or hard-to-debug state issues.

Developers also increase workers aggressively without watching memory use, even though each extra process adds overhead.

Summary

• 'use_multiprocessing changes how Keras background workers load data for model.fit.'
• It helps with input preparation, not with the model's forward or backward pass.
• It is most useful when generator or Sequence preprocessing is CPU-bound.
• 'Sequence is generally a safer input type than a plain generator when multiprocessing is enabled.'
• If you use tf.data, optimize that pipeline directly instead of relying on this argument.