Introduction

GlorotUniform is a built-in Keras initializer, so under normal circumstances it should load without any special handling. If you see Unknown initializer: GlorotUniform, the real problem is usually a serialization mismatch: different Keras stacks, an old HDF5 model file, or a custom object path that no longer resolves in the environment doing the load.

Why This Error Happens

Keras saves not just weights, but also configuration describing layers, activations, losses, and initializers. When load_model reconstructs the network, it has to deserialize each configured object by name.

For a simple built-in initializer, this should work:

1import keras
2
3model = keras.Sequential([
4    keras.layers.Dense(
5        16,
6        activation="relu",
7        kernel_initializer=keras.initializers.GlorotUniform(),
8        input_shape=(8,),
9    ),
10    keras.layers.Dense(1, activation="sigmoid"),
11])
12
13model.save("model.keras")
14restored = keras.models.load_model("model.keras")

If the loader still says GlorotUniform is unknown, one of these is usually true:

• the model was saved with a different Keras or TensorFlow stack than the one loading it
• the file uses older serialization conventions, often through legacy .h5
• a custom layer or wrapper serialized the initializer in a non-standard way
• the runtime mixes keras and tf.keras inconsistently

The important observation is that built-in Keras initializers are not supposed to need custom_objects in a healthy setup.

First Fix: Load With the Same Stack You Saved With

If the model was saved with standalone Keras, load it with standalone Keras. If it was saved with tf.keras, load it with the TensorFlow-backed Keras API that matches that environment.

The bug often appears when code like this is mixed across projects:

1# Saved with:
2from tensorflow import keras
3
4# Loaded later with:
5import keras

That does not always fail, but it is a common source of deserialization surprises, especially for older files. Use one stack consistently end to end.

Also prefer the modern .keras format when you control the save step:

model.save("classifier.keras")
model = keras.models.load_model("classifier.keras")

This is generally more robust than relying on legacy .h5 model serialization for complex projects.

Second Fix: Pass custom_objects as a Compatibility Workaround

If you must load an older file right now and you know the missing object is really the built-in initializer, pass it explicitly:

1import keras
2
3model = keras.models.load_model(
4    "legacy_model.h5",
5    custom_objects={
6        "GlorotUniform": keras.initializers.GlorotUniform,
7    },
8)

This is a practical compatibility fix, not the ideal long-term solution. If the file loads successfully, resave it in the current format from the current environment so you do not keep paying the compatibility cost forever.

Third Fix: Register True Custom Objects Properly

Sometimes the error message mentions GlorotUniform, but the real culprit is a custom class that contains or wraps the initializer. In that case you should register the custom object for serialization instead of only patching the initializer name.

1import keras
2
3@keras.saving.register_keras_serializable(package="MyLayers")
4class MyDense(keras.layers.Dense):
5    pass

For custom layers, models, losses, or initializers, registration is the cleanest approach because Keras can deserialize them by name later without requiring a manual dictionary every time.

If the custom object has constructor arguments that are not trivially serializable, implement get_config and, when needed, from_config so the object can be reconstructed correctly.

Debug the Saved Config When the Cause Is Unclear

If you do not know what the file is trying to deserialize, inspect the model config. Many times the issue becomes obvious when you look at how the initializer was recorded.

config = model.get_config()
print(config["layers"][0]["config"]["kernel_initializer"])

In a healthy current Keras serialization flow, the initializer metadata should clearly identify GlorotUniform as a built-in object. If the config contains a custom module path, an unexpected registered name, or a legacy structure from an older stack, that points directly to the compatibility boundary you need to fix.

Common Pitfalls

The most common mistake is assuming this error means GlorotUniform itself is missing from Keras. It usually is not. The real issue is deserialization context.

Another common problem is mixing standalone keras and tf.keras across training and inference environments. That mismatch can stay hidden for months until a saved artifact crosses the boundary. Developers also often keep patching custom_objects forever instead of loading once in a compatible environment and resaving in the current format.

Finally, do not forget that a custom layer can be the real missing object even when the error message points at an initializer name inside its config.

Summary

• 'GlorotUniform is a built-in Keras initializer, so this error usually signals a serialization mismatch rather than a missing feature.'
• Keep the save and load stacks consistent, especially between keras and tf.keras.
• Prefer the modern .keras model format for new saves.
• Use custom_objects as a compatibility bridge for legacy files, then resave.
• Register genuine custom objects with Keras serialization utilities so future loads are predictable.