Introduction

ValueError: Unknown layer: Functional usually appears when Keras tries to deserialize a saved model and cannot resolve the internal model class name it finds in the file. In practice, this often means the model was saved and loaded with mismatched Keras or TensorFlow stacks, or the wrong loading API is being used for the saved format. The fix is usually about version and serialization compatibility, not about defining a custom layer literally named Functional.

Why Functional Appears in the Error

Models built with the Keras Functional API are serialized with metadata describing that model type. If the loader environment does not recognize that serialized class, Keras raises an unknown-layer-style error even though the issue is really about model deserialization.

A common bad mix is:

1. saving with one Keras or TensorFlow version
2. loading with a different major serialization stack
3. mixing standalone keras and tf.keras in the same project

That is why this error often shows up after environment changes.

Save and Load with the Same Stack

The safest starting point is to use the same framework family for both saving and loading.

1import tensorflow as tf
2
3inputs = tf.keras.Input(shape=(4,))
4x = tf.keras.layers.Dense(8, activation="relu")(inputs)
5outputs = tf.keras.layers.Dense(1)(x)
6model = tf.keras.Model(inputs, outputs)
7
8model.save("demo_model.keras")
9loaded = tf.keras.models.load_model("demo_model.keras")
10print(type(loaded).__name__)

If you save with tf.keras, load with tf.keras in a compatible TensorFlow version.

Avoid Mixing keras and tf.keras

One of the easiest ways to trigger serialization issues is mixing imports:

# bad pattern
from keras.models import load_model
import tensorflow as tf

Use one stack consistently:

import tensorflow as tf

loaded = tf.keras.models.load_model("demo_model.keras")

Even when code seems to work for model building, serialization boundaries are often where the mismatch shows up.

Prefer Modern Save Formats

Older HDF5-based model files are more fragile across version shifts than newer Keras or SavedModel formats. If you control both ends, prefer current formats and resave legacy models in a compatible environment when possible.

model.save("model.keras")

If you inherit an older .h5 file, load it in the closest matching environment available first, then re-export it with the newer stack.

custom_objects Helps Only for Actual Custom Components

Developers sometimes try to fix this error by passing custom_objects. That is correct only when the model genuinely contains custom layers, losses, or metrics.

1loaded = tf.keras.models.load_model(
2    "custom_model.keras",
3    custom_objects={"MyLayer": MyLayer}
4)

If the failing name is Functional, the root cause is more likely version or stack mismatch than a missing custom component.

Diagnose Before Rebuilding the Model

Useful checks include:

1. print the TensorFlow version in the save environment
2. print the TensorFlow version in the load environment
3. inspect whether the code imports keras and tf.keras together
4. confirm the model format being loaded

That usually reveals the problem faster than rewriting model code.

If the model came from another team, ask for the exact save code as well as the file. Knowing whether it was exported as HDF5, SavedModel, or the newer Keras format often shortens the debugging cycle immediately.

Common Pitfalls

• Mixing standalone keras imports with tf.keras save or load calls.
• Loading an old serialized model in a significantly different runtime stack.
• Assuming Functional is a user-defined custom layer that must be registered manually.
• Reaching for custom_objects before checking version compatibility.
• Saving in one format and loading with assumptions from another format.

Summary

• 'Unknown layer: Functional is usually a model-loading compatibility problem.'
• Keep saving and loading within the same Keras or TensorFlow stack.
• Avoid mixing keras and tf.keras in the same serialization workflow.
• Prefer modern save formats when you control model export.
• Use custom_objects for real custom components, not as the default fix for stack mismatches.