KerasHub: pretrained models for Keras 3, one definition across JAX, TensorFlow and PyTorch

What KerasHub solves, and who it is aimed at

Getting a pretrained checkpoint into a working model usually means three separate chores: finding weights, reimplementing the architecture that matches them, and writing the preprocessing that turns raw text, images or audio into the tensors the model expects. KerasHub bundles all three. The README describes it as a pretrained modeling library that provides Keras 3 implementations of popular model architectures paired with pretrained checkpoints on Kaggle Models, usable for text, image and audio data for generation and classification.

The intended reader is someone who already knows Keras. The README makes that explicit: KerasHub components are Layer and Model implementations, so if you are familiar with Keras, you already understand most of KerasHub. That is a real design commitment rather than marketing. A classifier built from a preset behaves like any other Keras model, which means fit, predict and save work the way they always did.

The second audience is people who care about backend portability. A single model definition runs on JAX, TensorFlow and PyTorch, and the README states that models can be fine-tuned on GPUs and TPUs out of the box, with PEFT techniques for training on individual accelerators and model and data parallel training for larger runs.

How presets, backbones and task classes fit together

The API is organized around three ideas. A preset is a named checkpoint plus the configuration needed to rebuild the architecture that produced it, such as resnet_50_imagenet or bert_base_en_uncased. A backbone is the architecture without a task head. A task class, such as ImageClassifier or TextClassifier, wraps a backbone with the head and preprocessing needed for a specific job.

from_preset is the entry point that ties them together. Passing a preset name to a task class constructs the model and loads the weights in one call. That is why the README's examples are so short: the download, the architecture and the preprocessing are hidden behind the preset string.

The backend is chosen globally rather than per model. Keras reads the KERAS_BACKEND environment variable when it is first imported, and the README warns in a callout that it must be set before importing any Keras libraries. Setting it after the import has no effect. This is a single global switch for the whole process, not a per-model argument, and it is the main structural constraint of the library.

The repository layout reflects the same split: keras_hub/ holds the public package, keras_nlp/ remains as a compatibility path from the project's previous name, and integration_tests/, benchmarks/ and tools/ sit alongside the source. The pyproject.toml remaps keras_hub to keras_hub/api and keras_hub.src to keras_hub/src, so the published package is assembled from a source tree rather than being the source tree.

Installing KerasHub and running a first classification

The README gives a single install command for the latest release, and a separate nightly package for unreleased changes. Both are plain pip installs. Note that the package name on PyPI uses a hyphen, while the module you import uses an underscore.

pip install --upgrade keras-hub

After installing, you can optionally install the nightly build instead, which the README says tracks the latest changes for both KerasHub and Keras:

pip install --upgrade keras-hub-nightly

Before importing anything, pick a backend. The README shows the environment variable form for a shell session and the os.environ form for notebooks. The value can be jax, tensorflow or torch.

export KERAS_BACKEND=jax

Now load a preset and predict on one image. The README's quickstart uses a ResNet-50 checkpoint and a public domain image of a California quail, then decodes the output into ImageNet labels. The prediction call returns a batch, so the image is wrapped in a list before being converted to an array.

import keras
import keras_hub
import numpy as np

classifier = keras_hub.models.ImageClassifier.from_preset(
    "resnet_50_imagenet",
    activation="softmax",
)
url = "https://upload.wikimedia.org/wikipedia/commons/a/aa/California_quail.jpg"
path = keras.utils.get_file(origin=url)
image = keras.utils.load_img(path)
preds = classifier.predict(np.array([image]))
print(keras_hub.utils.decode_imagenet_predictions(preds))

The same pattern works for text. The README fine-tunes a BERT preset on IMDb reviews loaded through tensorflow_datasets, then predicts on two short strings. The classifier is created with num_classes=2 and a softmax activation, and fit is called with a validation split. Nothing in that example is KerasHub-specific beyond the from_preset call; the training loop is ordinary Keras.

The TensorFlow dependency you get whether you want it or not

The README is unusually direct about this: installing KerasHub will always pull in TensorFlow for use of the tf.data API for preprocessing. The requirements file confirms it, listing tensorflow-cpu on non-Darwin platforms, tensorflow on Darwin, and tensorflow-text on everything except Windows.

That is a meaningful cost if you selected the JAX or PyTorch backend precisely to avoid TensorFlow. The README softens it by noting that pre-processing with tf.data does not stop training from happening on any backend, which is true, but the dependency is still installed and still on your disk. On Windows, tensorflow-text is skipped by an environment marker, which suggests preprocessing paths that depend on it behave differently there. The README does not spell out which presets that affects.

There is a second, smaller constraint in the same file: kagglehub is pinned to anything except version 1.0.1, and kagglesdk is pinned to exactly 0.1.28. If your environment already constrains either package, expect a resolver conflict. Python 3.11 or newer is required.

Pre-1.0 versioning and what it means for a production model

The compatibility section states the project follows Semantic Versioning and plans to provide backwards compatibility guarantees for both code and saved models. Then it states the exception plainly: while development stays in the 0.y.z range, compatibility may be broken at any time and APIs should not be considered stable. The pyproject classifiers agree, marking the development status as Alpha.

The release history backs that up rather than contradicting it. Version 0.31.1 arrived on 2026-08-22, two weeks after 0.31.0 on 2026-08-08, and a 0.31.0.dev0 build landed the day before that. The last push to the repository was on 2026-09-10. Releases at that cadence are normal for a young library, but they also mean a pinned version is the only safe way to depend on KerasHub right now.

The practical consequence is about saved models, not just imports. If you fine-tune a classifier, save it, and later upgrade KerasHub, the compatibility promise does not yet cover you. The README does not describe a migration path or a deprecation window for preset names or task class signatures. Anyone putting a KerasHub model behind an API should pin the version and re-run their own evaluation after any upgrade.

Where KerasHub is the wrong tool

KerasHub is a modeling library, not a serving stack. It loads a checkpoint, runs it as a Keras model and lets you fine-tune it. If your problem is high-throughput inference behind an HTTP endpoint, nothing in the README describes batching strategy, request queuing or a server. The pyproject.toml does register a vLLM general plugin entry point at keras_hub.src.vllm.plugin:register_keras_hub, and the comment above it says vLLM calls this at startup and that it returns immediately unless the TPU backend is installed. That is a real integration, but it is a narrow one, and the README does not document how to use it.

The second mismatch is architecture coverage. KerasHub ships specific architectures with specific checkpoints. If your model is not among them, you are writing the Keras 3 implementation yourself, and the library gives you less help than a framework that lets you import arbitrary Hugging Face repositories. The README points contributors at CONTRIBUTING_MODELS.md, which tells you adding a model is a supported path, but it is still work you do.

Third, the pretrained weights are not all the project's to license. The disclaimer lists BART, BLOOM, DeBERTa, DistilBERT, GPT-2, Llama, Mistral, OPT, RoBERTa, Whisper and XLM-RoBERTa as provided by third parties under separate licences, and says the models are provided on an as-is basis without warranties. Check the checkpoint you intend to ship, not just the Apache-2.0 licence on the KerasHub code itself.

KerasHub compared with reaching for Hugging Face directly

The obvious alternative is the Hugging Face ecosystem, where you pull a model repository by name and get weights plus a configuration that transformers knows how to load. The difference is not coverage, it is where the abstraction sits. Hugging Face centers on its own model classes and its own file format. KerasHub centers on Keras: a preset produces a keras.Model, so it composes with Keras callbacks, Keras saving and Keras training loops, and the same definition runs under JAX, TensorFlow or PyTorch.

That matters if your training code is already Keras. Swapping in a Hugging Face model means either adopting that library's training idioms or writing a wrapper. With KerasHub, the fine-tuning example in the README is three lines of setup followed by a normal fit call.

The trade-off runs the other way on breadth and on stability. Hugging Face hosts a far larger catalogue, and its model APIs have been stable for far longer than a 0.y.z library. KerasHub's own README says APIs should not be considered stable at this stage. If you need a long-lived interface, that statement should carry more weight than the convenience of from_preset.

Who should adopt KerasHub, and what to verify first

Adopt it if you are building in Keras 3 and want a pretrained starting point without writing download and preprocessing code. The preset API is genuinely small, the backend switch is one environment variable, and the task classes cover classification and generation across text, image and audio. Teams doing fine-tuning on a single accelerator, where the README's PEFT support applies, get the most out of it.

Do not adopt it if you need a frozen API today, if your architecture is not in the preset list and you are not prepared to implement it, or if a TensorFlow dependency in your image is unacceptable. The README states that installing KerasHub always pulls in TensorFlow for tf.data preprocessing, and that is not optional.

Verify three things before committing. First, confirm your Python is 3.11 or newer and that kagglesdk==0.1.28 and the kagglehub exclusion do not conflict with your existing pins. Second, decide your KERAS_BACKEND and set it before any Keras import, including in test fixtures and worker processes, because setting it later silently does nothing. Third, read the licence of the specific third-party checkpoint you plan to deploy; the Apache-2.0 licence on the repository does not cover BART, Llama, Mistral, Whisper or the other models named in the disclaimer.

Editorial conclusion

KerasHub fits teams already building in Keras 3 who want a preset, a backbone and a task head without writing download and preprocessing code. It does not fit projects that need a frozen, stable API or that want to avoid a TensorFlow dependency for preprocessing. Before adopting it, check that your Python is 3.11 or newer, decide which KERAS_BACKEND you will set before importing Keras, and read the licence terms of the specific third-party checkpoint you plan to use, since the README lists BART, BLOOM, DeBERTa, DistilBERT, GPT-2, Llama, Mistral, OPT, RoBERTa, Whisper and XLM-RoBERTa as subject to separate licences.

Frequently asked questions

Official sources

1. keras-team/keras-hub on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases