Introduction

Yes. In normal Keras usage, dropout is active during training and automatically turned off during evaluation and prediction. That default matters because dropout is a training-time regularization method, not something you usually want changing outputs in production inference.

How Keras Knows When to Use Dropout

Keras layers receive a training flag. During model.fit(), the framework passes training=True, so Dropout randomly masks part of the layer output. During model.evaluate() and model.predict(), Keras uses inference mode and dropout becomes a pass-through.

1import tensorflow as tf
2
3model = tf.keras.Sequential([
4    tf.keras.layers.Input(shape=(4,)),
5    tf.keras.layers.Dense(8, activation="relu"),
6    tf.keras.layers.Dropout(0.5),
7    tf.keras.layers.Dense(1, activation="sigmoid"),
8])
9
10model.compile(optimizer="adam", loss="binary_crossentropy")
11print(model.summary())

You do not need to remove the layer or flip a manual switch before prediction. The layer stays in the model, but its behavior changes based on training mode.

What Dropout Does During Training

Dropout randomly sets part of the intermediate activations to zero on each training step. That discourages the model from relying too heavily on any single path through the network and can reduce overfitting.

1import numpy as np
2import tensorflow as tf
3
4x = np.random.rand(200, 4).astype("float32")
5y = (x.sum(axis=1) > 2.0).astype("float32")
6
7model.fit(x, y, epochs=3, batch_size=16, verbose=0)

During these training steps, the hidden representation is slightly different on every batch because random units are dropped. That noise is intentional. It helps the model generalize instead of memorizing the training set.

One subtle point is that Keras scales activations during training so that inference-time behavior stays consistent. You do not usually need to perform manual rescaling.

What Happens During Prediction

When you call predict(), dropout is disabled and the full network is used. For the same input, the output should be stable apart from ordinary floating-point differences.

1sample = x[:1]
2
3pred1 = model.predict(sample, verbose=0)
4pred2 = model.predict(sample, verbose=0)
5
6print(pred1)
7print(pred2)

If the model and runtime are otherwise deterministic, these predictions should match closely because dropout is no longer injecting randomness.

This is also why training metrics and validation metrics are not computed under identical conditions. Training runs with dropout on. Validation runs with dropout off. A gap between the two is normal and does not automatically mean the model is misconfigured.

When You Might Keep Dropout Active

There are advanced workflows where you intentionally want dropout during inference, usually for uncertainty estimation. In that case, you call the model directly and force training=True.

1sample = x[:1]
2
3p1 = model(sample, training=True).numpy()
4p2 = model(sample, training=True).numpy()
5
6print(p1)
7print(p2)

Those outputs can differ between calls because dropout is active again. This technique is often called Monte Carlo dropout. It is useful for experiments, but it should be an explicit choice, not an accidental production setting.

Custom Models Must Forward the training Flag

Most confusion comes from subclassed models or custom layers. If you write your own call() method and do not pass the training argument into Dropout, you can get the wrong behavior.

1class MyModel(tf.keras.Model):
2    def __init__(self):
3        super().__init__()
4        self.hidden = tf.keras.layers.Dense(8, activation="relu")
5        self.drop = tf.keras.layers.Dropout(0.5)
6        self.out = tf.keras.layers.Dense(1, activation="sigmoid")
7
8    def call(self, inputs, training=False):
9        x = self.hidden(inputs)
10        x = self.drop(x, training=training)
11        return self.out(x)

That pattern is correct. The model exposes a training argument, then forwards it to the dropout layer. If you forget that step, dropout may stay active or inactive at the wrong times.

Batch normalization has a similar dependency on the training flag, so this is a general Keras design rule rather than a dropout-only detail.

Common Pitfalls

• Thinking you need to manually disable dropout before calling predict().
• Calling the model with training=True in production and then wondering why predictions vary.
• Forgetting to propagate the training flag in subclassed models or custom layers.
• Comparing training and validation metrics without remembering that dropout is active only during training.
• Assuming stochastic predictions are a bug when you intentionally enabled Monte Carlo dropout.

Summary

• Keras automatically enables dropout in training and disables it in inference.
• 'model.predict() uses inference mode, so dropout is off by default.'
• You can force dropout on with training=True for uncertainty experiments.
• Custom models must pass the training flag through correctly.
• Different behavior between training and validation is expected when dropout is present.