Keras Community Update: Pluggable Backend Architecture and MLX/PaddlePaddle Support Coming Soon

Keras's recent community meeting sent a series of noteworthy technical signals. From backend architecture refactoring to modernizing the preprocessing toolchain, these changes affect not only the framework's engineering quality but also redefine Keras's positioning as a multi-backend deep learning interface. Here's a breakdown of the key changes discussed in the meeting and the significance behind them.

Pluggable Backends: From Built-in to On-Demand Installation

Keras 3 already supports three major backends — TensorFlow, JAX, and PyTorch — but the meeting laid out a more ambitious direction: a pluggable backend architecture. New backends will be distributed as independent add-on libraries rather than bundled into the Keras core.

The meeting also previewed two upcoming backends: MLX and PaddlePaddle. MLX is a machine learning framework optimized for Apple Silicon, and its addition means Keras could gain more native acceleration capabilities within the Mac ecosystem. PaddlePaddle, on the other hand, extends Keras's reach into China's deep learning ecosystem.

Decoupling backends into add-on libraries has clear engineering advantages: the core library stays lean, backend iterations are no longer tied to major release cycles, and third parties can more easily contribute new execution engines. This effectively evolves Keras from a "multi-backend framework" into a "backend-agnostic unified frontend."

MLX was open-sourced by Apple in late 2023 and is designed for devices running Apple Silicon (M-series chips). Its key feature is a unified memory model — CPU and GPU share the same physical memory with no explicit data copying required, which is especially valuable for bandwidth-constrained devices like MacBooks. MLX's API draws from NumPy and PyTorch conventions and natively supports lazy evaluation and automatic differentiation, giving it all the foundations needed to serve as a Keras backend. PaddlePaddle (飞桨) is an open-source deep learning framework led by Baidu, with a strong track record of custom operators and training optimizations in industrial deployment scenarios within China. Its integration with Keras allows Chinese developers to use Keras's high-level API on familiar infrastructure without rewriting model code.

Lowering the Bar for New Backend Integration

Enabling more backends to integrate smoothly requires reducing the number of operators (ops) each backend must implement. The approach discussed in the meeting is to provide backend-agnostic implementations for all secondary ops.

In other words, a new backend only needs to implement a minimal set of core operators; higher-level operations can reuse Keras-level, backend-agnostic generic implementations. This layered strategy significantly reduces the integration cost — backend developers don't need to reinvent the wheel to get most functionality running. For MLX, PaddlePaddle, and any future backends, this is a decisive factor in how quickly they can become viable.

The distinction between "primary ops" and "secondary ops" is central to the layered backend design. Primary ops — matrix multiplication, element-wise operations, reduction operations — are a limited set of performance-critical primitives that each backend must implement natively and efficiently. Secondary ops are higher-level operations composed from primary ops, such as activation function variants or certain normalization layer computations. These are less performance-critical but far more numerous. By providing reference implementations of secondary ops built from primary ops, Keras effectively compresses the integration cost from O(all ops) to O(core ops), dramatically lowering the barrier for teams looking to quickly validate a new execution engine.

A Unified Operator Testing Framework

Alongside the operator system refactoring, the testing process is also being streamlined. The meeting revealed that a single test harness can now cover functional validation for all operators, including critical behaviors like casting consistency.

In a framework that must support multiple backends, the importance of testing is amplified — the same code must produce consistent numerical results and behaviors across TensorFlow, JAX, PyTorch, and MLX. A unified test harness means cross-backend consistency can be verified systematically, rather than relying on scattered test cases. This kind of "unglamorous" infrastructure investment is precisely the foundational guarantee that makes a multi-backend strategy trustworthy over the long term.

KerasHub Model Additions and Preprocessing Migration

On the model side, progress is centered on KerasHub. The meeting mentioned that a large number of new models have been added to KerasHub, further enriching its out-of-the-box pretrained model library.

A notable preprocessing toolchain change was also discussed: KerasHub is migrating from tf-text preprocessing to PyGrain. tf-text is deeply tied to TensorFlow, which creates an awkward dependency in a multi-backend context — users running PyTorch or JAX backends shouldn't be forced to pull in an entire TensorFlow text processing stack. PyGrain, as a more backend-neutral data loading and preprocessing solution, aligns closely with the overall "pluggable backend" direction described above.

This migration once again reflects the Keras team's core philosophy: progressively eliminating hidden dependencies on any single backend, enabling the framework to be truly backend-agnostic.

PyGrain is an open-source data loading and preprocessing library from Google DeepMind, designed to be decoupled from any specific ML framework. It centers on native Python data structures and supports efficient random access, deterministic shuffling, and multi-process prefetching. By contrast, tf-text implements its operators as TensorFlow ops, with a hard runtime dependency on TensorFlow's computation graph and session mechanism — even if you just want tokenization or text encoding, you bear the full TensorFlow dependency. Migrating the preprocessing stack to PyGrain means data pipelines can run in any backend environment. Users can train models with JAX or PyTorch backends while using the same preprocessing logic, eliminating the chaotic situation where "the model backend is JAX, but the data processing is quietly running a TensorFlow session under the hood."

Reading the Overall Trend

Connecting all five points, the meeting's signal is remarkably clear. Keras is systematically undergoing an architectural "decentralization": pluggable backends, layered operator reuse, unified testing, and neutral preprocessing. Every change chips away at historical coupling to any specific backend — especially TensorFlow.

For users, this means greater freedom in backend choice and lighter dependencies. For the ecosystem, the addition of MLX and PaddlePaddle broadens Keras's applicability, from Apple devices to frameworks prominent in China. The value of Keras as a unified high-level API may be rediscovered and reassessed as this foundational engineering work matures.

Note: The above content is based on a summary of the community meeting. Specific implementation details and release timelines are subject to official Keras announcements.