Introduction

If Keras complains about get_config while loading a model that you believe uses only built-in layers, the failure is usually caused by something around the model rather than the obvious layer list. Common causes include Lambda layers, custom metrics or losses saved with the model, version mismatches, subclassed models, or trying to deserialize training state that you do not actually need for inference.

Why get_config Matters

Keras reconstructs many objects by serializing their configuration and then recreating them later. Built-in layers already know how to do this. Custom or partially custom objects often do not, unless they implement the expected serialization hooks.

That is why a model can look "standard" at first glance and still fail at load time. The non-serializable part may be:

• a Lambda layer wrapping a Python function
• a custom loss passed to compile
• a custom metric
• a subclassed Model or Layer
• optimizer state saved from a different environment

A Model Can Be Non-Portable Without Obvious Custom Layers

This model uses only standard dense layers and is easy to save and load:

1from tensorflow import keras
2
3model = keras.Sequential([
4    keras.layers.Input(shape=(10,)),
5    keras.layers.Dense(32, activation="relu"),
6    keras.layers.Dense(1)
7])
8
9model.compile(optimizer="adam", loss="mse")
10model.save("good_model.keras")
11loaded = keras.models.load_model("good_model.keras")

Now compare that to a model with a Lambda layer:

1from tensorflow import keras
2
3model = keras.Sequential([
4    keras.layers.Input(shape=(10,)),
5    keras.layers.Lambda(lambda x: x / 255.0),
6    keras.layers.Dense(32, activation="relu"),
7    keras.layers.Dense(1)
8])

That Lambda function may be the real reason deserialization fails, even though the rest of the layer stack looks standard.

First Debugging Step: Load Without Compiling

If you only need the model for inference, try:

from tensorflow import keras

model = keras.models.load_model("model.keras", compile=False)

This skips deserializing training configuration such as losses and metrics. If the model now loads correctly, the problem was likely in the compile-time objects rather than the forward-pass architecture.

That is a very common fix when the saved model architecture is usable but the training metadata is not portable.

Replace Lambda with a Real Layer

If you used Lambda, replace it with a serializable layer or a built-in preprocessing layer when possible.

Example:

1from tensorflow import keras
2
3inputs = keras.Input(shape=(10,))
4x = keras.layers.Rescaling(1.0 / 255.0)(inputs)
5x = keras.layers.Dense(32, activation="relu")(x)
6outputs = keras.layers.Dense(1)(x)
7
8model = keras.Model(inputs, outputs)
9model.save("portable_model.keras")

Built-in layers such as Rescaling are much easier to serialize reliably than arbitrary Python lambdas.

If You Truly Have a Custom Object

When a custom layer or model is real, implement get_config and optionally from_config.

1from tensorflow import keras
2
3class ScaleLayer(keras.layers.Layer):
4    def __init__(self, factor=1.0, **kwargs):
5        super().__init__(**kwargs)
6        self.factor = factor
7
8    def call(self, inputs):
9        return inputs * self.factor
10
11    def get_config(self):
12        config = super().get_config()
13        config.update({"factor": self.factor})
14        return config

Then load with custom_objects if needed:

1loaded = keras.models.load_model(
2    "model.keras",
3    custom_objects={"ScaleLayer": ScaleLayer}
4)

Even if your current model is supposed to be standard, this example shows what Keras expects from anything outside its built-in registry.

Version Mismatch Is a Real Cause

A model saved in one Keras or TensorFlow environment can fail in another if serialization rules changed or a class path no longer matches. If a previously working file suddenly fails to load:

1. check the save-time package versions
2. check the load-time package versions
3. try loading in the original environment

If the model loads there, the file is probably fine and the environment mismatch is the issue.

When Saving Weights Is Safer

If your architecture is defined in code and you do not need full object serialization, saving weights can be more robust:

1model.save_weights("weights.h5")
2
3# Later
4recreated_model = build_model()
5recreated_model.load_weights("weights.h5")

This avoids some serialization complexity, but it requires the model code to be rebuilt exactly before loading.

Common Pitfalls

• Assuming "no custom layers" means "nothing custom at all." Losses, metrics, lambdas, and wrappers can still break serialization.
• Trying to load a model for inference with full compile state when compile=False would avoid the failing training metadata.
• Using Lambda for behavior that could be expressed with a built-in serializable layer.
• Ignoring TensorFlow or Keras version differences between the environment that saved the model and the one loading it.
• Reaching for get_config fixes immediately when the real problem is that saving weights only would have matched the deployment need better.

Summary

• A get_config loading error often comes from non-obvious custom objects, not just explicit custom layers.
• 'compile=False is the first thing to try when you only need inference.'
• Replace Lambda layers with serializable built-in layers whenever possible.
• If you do own a custom layer or model, implement get_config properly and register it during loading.
• When portability is more important than full serialization, saving weights plus rebuilding the architecture can be the safer path.