Introduction

For the old tensorflow-gpu==1.4 stack, the safe standalone Keras pairing was historically in the 2.1.x line, most commonly keras==2.1.2 or keras==2.1.3. The exact answer matters because this was the pre-tf.keras era for most real projects, and version mismatches produced confusing backend and serialization errors. With legacy TensorFlow stacks, compatibility is not only about Keras. Python, CUDA, and cuDNN also have to line up.

The Short Compatibility Answer

If you are maintaining a legacy environment built around tensorflow-gpu==1.4, a practical pin is:

tensorflow-gpu==1.4.0
keras==2.1.2

keras==2.1.3 also worked in many setups from that period, but 2.1.2 is the conservative answer people most often pinned alongside TensorFlow 1.4.

The reason the answer is cautious rather than absolute is that old ML stacks were sensitive to multiple moving pieces, not just one package version.

Why Newer Keras Versions Cause Trouble

Standalone Keras talks to TensorFlow through the backend interface. When Keras moves ahead of the TensorFlow version underneath it, you can run into problems such as:

• missing backend functions
• incompatible layer serialization
• training-time errors in callbacks or optimizers
• import failures caused by backend API drift

That is why “latest Keras with old TensorFlow” was rarely a safe move in the TensorFlow 1.x era.

Build a Historically Consistent Environment

A typical legacy install sequence looked like this:

pip install tensorflow-gpu==1.4.0
pip install keras==2.1.2

Then verify the versions explicitly:

1import tensorflow as tf
2import keras
3
4print(tf.__version__)
5print(keras.__version__)

And confirm that Keras is using TensorFlow as the backend:

from keras import backend as K
print(K.backend())

You want the backend to report tensorflow.

Do Not Forget CUDA and cuDNN

For this era of TensorFlow, package compatibility also depended heavily on the CUDA stack. A Python environment can have the “right” package versions and still fail at import time if the GPU libraries do not match what TensorFlow 1.4 expects.

That means troubleshooting should check all of these together:

• 'tensorflow-gpu version'
• Keras version
• Python version
• CUDA version
• cuDNN version
• NVIDIA driver compatibility

If you only pin Keras and TensorFlow but ignore the GPU runtime, you can still end up with import errors or missing-device problems.

Legacy Example

A small sanity test for that environment might look like this:

1from keras.models import Sequential
2from keras.layers import Dense
3import numpy as np
4
5x = np.random.rand(100, 10)
6y = np.random.rand(100, 1)
7
8model = Sequential()
9model.add(Dense(16, activation='relu', input_shape=(10,)))
10model.add(Dense(1))
11model.compile(optimizer='sgd', loss='mse')
12model.fit(x, y, epochs=1, batch_size=8)

If the environment versions are compatible, this should import, compile, and run without backend-version surprises.

Prefer Reproducible Environment Files

With legacy stacks, do not rely on memory. Freeze the environment.

tensorflow-gpu==1.4.0
keras==2.1.2
numpy==1.13.3

The exact supporting package pins may vary by project, but the main point is that old deep-learning environments should be treated as reproducible historical artifacts, not as rolling installations.

Consider Migration If Possible

If you have the option, the better long-term answer is usually not “which Keras version fits TensorFlow 1.4 forever?” It is “can this environment be upgraded?” TensorFlow 1.4 is old enough that dependency maintenance, GPU-driver friction, and security issues all become harder over time.

Still, for legacy maintenance, the right move is to stabilize the environment you already have rather than mixing old TensorFlow with much newer Keras packages.

Common Pitfalls

A common mistake is installing the newest standalone Keras package on top of tensorflow-gpu==1.4 and expecting the backend API to remain compatible.

Another issue is forgetting that GPU support depends on CUDA and cuDNN versions too. Import failures are not always Keras-version problems.

Developers also sometimes mix keras and early tf.keras examples from different time periods. In the TensorFlow 1.4 era, that often creates more confusion than clarity.

Finally, do not upgrade one package in a legacy ML stack without pinning and retesting the entire environment.

Summary

• For tensorflow-gpu==1.4, the safest standalone Keras choice was typically keras==2.1.2, with 2.1.3 also working in many environments.
• Old TensorFlow and Keras versions must be treated as a matched stack, not as independent upgrades.
• GPU compatibility also depends on CUDA, cuDNN, Python, and driver versions.
• Verify the backend and run a small model after installation.
• If possible, prefer environment pinning or migration rather than ad hoc legacy package mixing.