From local prototyping to GPUs in the GCP cloud: Creating a satellite image classification system using Keras and Kinetic

Training state-of-the-art deep learning models, such as Vision Transformers (ViTs), demands computational resources that often exceed local hardware capabilities. Traditionally, scaling these workloads to the cloud introduces significant technical friction, requiring developers to manage infrastructure, containerization, and cluster provisioning. This article explores how to radically simplify this process using **Kinetic Keras**, a tool that seamlessly runs Keras and JAX workloads on cloud TPUs and GPUs using a single Python decorator, eliminating the need for manual infrastructure management.

To demonstrate this, we will walk through a practical, high-impact use case: building a Vision Transformer to classify satellite imagery into 10 distinct land cover categories. Using the EuroSAT dataset, which comprises high-resolution RGB images collected by the Sentinel-2 satellite, we aim to help an agricultural management agency conduct rapid assessments of vulnerable regions following extreme weather events such as droughts or flooding. By grouping these images into categories — such as healthy cropland, dense forest, or bare soil — we can quickly identify critical indicators of damaged or at-risk agroecological zones, such as stagnant water or exposed earth.

Throughout this guide, you will see how Kinetic Keras bridges the gap between agile local prototyping and heavy cloud training, allowing us to focus entirely on the model’s architecture and data analysis without worrying about the underlying hardware.

Kinetic Keras on GCP

The Infrastructure and Hardware Problem

Transitioning a machine learning model from a local prototyping environment to cloud-grade accelerators — such as NVIDIA L4s, A100 GPUs, or TPU clusters — typically introduces significant technical friction. Traditionally, developers scaling their workloads must step out of their data science workflows and take on complex DevOps tasks. This includes provisioning node pools, building container images, managing Kubernetes manifests, handling data synchronization, and configuring network access.

**Kinetic** is an open-source tool developed by the Keras Team designed to run Keras and JAX machine learning workloads seamlessly on cloud TPUs and GPUs, specifically designed to eliminate this infrastructure management overhead.

It completely automates the process of running Python functions on Google Cloud Platform (GCP) accelerators, providing a seamless experience for executing remote workloads without requiring you to restructure your code.

By simply wrapping your training function with a Python decorator like [@kinetic.run() or @kinetic.submit()](https://kinetic.readthedocs.io/en/latest/guides/keras_training.html), Kinetic takes care of the heavy lifting behind the scenes. When the decorated function is called, the system automatically performs several critical operations:

• Artifact Preparation: It resolves your local context, serializes the function and its closures usingcloudpickle, and packages your local working directory into a ZIP archive.
• Container Management: It generates a hash of your project dependencies (like your requirements.txt o pyproject.toml if you use uv) and dynamically initiates a Cloud Build job to create a container image if it doesn't already exist in the Artifact Registry.
• Job Execution: Kinetic submits the job to the target Kubernetes cluster (GKE), where the remote pod pulls the image, mounts necessary data volumes, and executes the function on the requested hardware.
• Result Retrieval: Upon completion, the result is deserialized and returned directly to your local Python process.

Essentially, Kinetic allows you to maintain the simplicity of a local script while taking advantage of massive cloud computing power, completely abstracting the underlying infrastructure.

Key Benefits

• Simple Remote Execution: You can execute your training loop on a remote accelerator without fundamentally restructuring your local code. Scaling your model to powerful hardware is as easy as modifying a parameter in the decorator, such as setting accelerator="l4" or accelerator="tpu-v6e-8".
• Detached Background Jobs: For training sessions that take hours or days, Kinetic provides the @kinetic.submit() decorator. Instead of blocking your local terminal, this submits the job and returns aJobHandle, allowing you to safely disconnect, poll the job status, tail logs, or retrieve the results later from a completely different machine.
• Native Data and Checkpoint Management: Kinetic simplifies data handling through the kinetic.Data(...) API, which automatically ships local files or mounts Google Cloud Storage (GCS) buckets directly into your remote job. Furthermore, any artifacts, logs, or model weights saved to the KINETIC_OUTPUT_DIR environment variable are automatically persisted as durable outputs.

Use Case: Agroecological Assessment via Satellite Image Classification

To demonstrate the power of Kinetic Keras, we will apply it to a real-world scenario. Consider an agricultural management agency that needs to conduct a rapid assessment of land cover status in a vulnerable region following an extreme weather event, such as a severe drought or flooding.

Often, these agencies lack up-to-date baseline data for the affected areas but have immediate access to thousands of high-resolution satellite images. The objective is to deploy a machine learning model capable of classifying these images into specific land cover categories.

By successfully categorizing the terrain, the agency can quickly identify critical indicators of damaged or at-risk agroecological zones — for instance, spotting areas that have turned into bare soil, or identifying stagnant water where healthy crops used to be.

To train our model for this task, we utilize the **EuroSAT dataset**, a widely recognized benchmark for land use and land cover classification.

The dataset features high-resolution RGB images collected directly from the Sentinel-2 satellite. Each image is structured at a resolution of 64x64 pixels and possesses a Ground Sampling Distance of 10 meters, providing an excellent balance between detail and computational efficiency for deep learning models.

In total, the dataset comprises 27,000 images, providing a robust and well-balanced foundation for training our model. The class distribution is highly consistent:

• 3,000 images each for Sea/Lake, Residential, Annual Crop, Forest, and Herbaceous Vegetation.
• 2,500 images each for Highway, River, Industrial, and Permanent Crop.
• 2,000 images for Pasture

The images are strictly categorized into 10 distinct land cover classes:

• Annual Crop
• Permanent Crop
• Pasture
• Forest
• Herbaceous Vegetation
• Highway
• Industrial
• Residential
• River
• Sea/Lake

EuroSAT dataset

Having these specific categories is highly advantageous for our use case. It allows the model to differentiate complex texture patterns, such as distinguishing dense vegetation (Forests) from agricultural mosaics (Crops and Pastures). This precise distinction is crucial for the agency’s monitoring systems, enabling them to track active crop zones independently from forest reserves and set up automated alerts for droughts, floods, or deforestation.

Vision Transformers (ViT): Architecture and Components

To classify our satellite imagery, we implemented a Vision Transformer (ViT). Unlike traditional Convolutional Neural Networks (CNNs) that process images through local receptive fields, the ViT architecture excels at modeling global dependencies across the entire image right from the first layer through a mechanism known as self-attention.

Our ViT implementation relies on three fundamental components:

• Patch Embedding: The first step is dividing the input image into fixed-size, non-overlapping patches. For our EuroSAT images (64x64 pixels), we configured a patch size of 8x8 pixels, resulting in exactly 64 patches per image. These patches are then flattened into vectors and projected into a higher-dimensional embedding space. Technically, this is achieved efficiently using a Conv2D layer with both the kernel_size and strides set to the patch size. This process treats each spatial region as a unique "visual token," similar to how words are processed in Natural Language Processing (NLP).
• The [CLS] Token: Following the architectural design of BERT, a specially initialized, learnable vector known as the [CLS] (classification) token is prepended to the sequence of image patch embeddings. Since the self-attention mechanism allows all tokens to interact with one another, the [CLS] token “attends” to all image patches throughout the Transformer layers. This creates a clean bottleneck where the model distills the spatial information of the entire image into a single class-level descriptor needed for the final prediction.
• Transformer Encoder Blocks: The core processing happens in the encoder blocks. Each block appliesLayerNormalization, followed by MultiHeadAttention to weigh the importance of different patches relative to each other. The output then passes through another normalization layer and a Feed-Forward network (implemented sequentially via Dense layers) using the GELU activation function. Finally, Dropout layers are applied for regularization to prevent overfitting.

If you want to know and delve into ViT this article can give you more information

Vision Transformer. Image based on this article

Infrastructure Preparation and Provisioning with Kinetic Keras

The true magic of Kinetic Keras lies in how it abstracts the heavy lifting of cloud infrastructure creation into simple, declarative commands. If you are the first user configuring the project, you do not need to navigate complex cloud consoles, write Terraform scripts, or manually configure Kubernetes. Instead, you simply execute a single, one-time command in your terminal to initialize the entire environment:

kinetic up --project=<YOUR_GCP_PROJECT_ID> --accelerator=l4 --yes

When this command is executed, Kinetic automatically handles several crucial setup tasks behind the scenes:

• API Activation: It automatically enables all the required Google Cloud Platform APIs, including Cloud Storage, Cloud Build, Artifact Registry, and Google Kubernetes Engine (GKE).
• Container Storage: It creates an Artifact Registry repository dedicated to storing the Docker container images that Kinetic will build dynamically for your runs.
• Hardware Provisioning: Most importantly, it provisions a GKE cluster specifically configured with the requested accelerator node pool. For this use case, we requested an NVIDIA L4 GPU (accelerator="l4"), but Kinetic allows you to easily swap this out for other hardware—such as A100 GPUs (a100) or specific TPU slices (like tpu-v6e-8)—simply by changing the accelerator string.
• Access Configuration: It automatically configures local Docker authentication and kubectl access, ensuring your local Python environment can seamlessly communicate with the remote cluster.

Creating environment

Environment Created

Once the infrastructure is up, your local environment is fully connected to the cloud hardware. Additionally, Kinetic simplifies the cleanup process: once your model training and evaluation are complete, tearing down the entire infrastructure to stop incurring cloud costs is as simple as running the kinetic down command.

Deleting all kinetic resources

Other Kinetic commands

kinetic jobs list: see the jobs created

Job List

kinetic jobs logs <ID> -f: see logs by job

Remote logs for job

kinetic pool list: list of pools and infrastructure state

Infrastructure state

kinetic jobs cancel <ID>: Cancel job

Job Canceled

Development Process and Cloud Training

The development cycle with Kinetic Keras does not force you to adopt a new programming paradigm; in fact, it feels almost identical to coding a standard Keras model locally.

For our EuroSAT classification task, we define and compile our Vision Transformer exactly as we normally would do: setting the optimizer (AdamW), the loss function (SparseCategoricalCrossentropy), and configuring callbacks such as ReduceLROnPlateau and EarlyStopping to optimize the learning rate over a maximum of 100 epochs.

The paradigm shift happens precisely when it is time to execute the training loop. Instead of running model.fit() locally and tying up your machine's resources, you simply wrap your training routine with the @kinetic.run() or @kinetic.submit() decorator.

When this decorated function is invoked, Kinetic packages your local state and ships your code to the remote accelerator. It is important to understand the lifecycle and expected timing of this process:

• Cold Start (First Run): During your very first execution or after changing your dependencies, the system will take approximately 2 to 5 minutes to start. This slight delay occurs because Cloud Build is dynamically generating a container image, freezing your specific project dependencies into an image tagged by a unique hash.
• Warm Start (Subsequent Runs): Once the container image is cached, subsequent runs or iterations take under a minute to schedule and start. This means you can rapidly change your ViT architecture, change hyperparameters, or adjust your dataset augmentation, and re-run the training process at the full speed of the cloud hardware (ike the L4 GPU we provisioned without paying the build cost again.

Because the decorated function executes in a completely fresh process inside a remote container, no local state crosses the boundary implicitly. Any variables, models, or datasets loaded locally in your script will not exist on the remote node unless explicitly provided. Everything the function needs must be passed as an argument, captured via closures, or safely shipped using the kinetic.Data(...) API, ensuring a clean and reproducible execution environment.

Here’s the code, but you can check out my repository for more details.

[embed]

Training Results and Model Evaluation

After executing our Vision Transformer on the cloud hardware via Kinetic, the model demonstrated exceptional learning capabilities over the EuroSAT dataset. Thanks to our configured callbacks, the training process was highly efficient. The ReduceLROnPlateau callback successfully adjusted the learning rate down to 1.25e-04 to stabilize convergence, and EarlyStopping halted the training to prevent overfitting, automatically restoring the optimal model weights from epoch 86.

Ultimately, the model achieved a highly robust validation accuracy of 92.83% (val_accuracy: 0.9283) with a validation loss of 0.2239 (loss: 0.2184 on the training set).

Classification Report

Evaluating the detailed classification report on the 5,400 test images, the ViT achieved an overall macro and weighted average F1-score of 0.91 and 0.92, respectively. The model was remarkably precise at identifying distinct natural landscapes. For instance, the SeaLake class achieved a near-perfect F1-score of 0.98 with a precision of 1.00, while the Forest class followed closely with an impressive F1-score of 0.97. The Residential and HerbaceousVegetation categories also performed excellently, both scoring an F1-score of 0.93.

Confusion matrix

However, a deeper look at the confusion matrix reveals the subtle visual challenges the model faced with certain structurally similar classes. The Highway category recorded the lowest F1-score (0.82) and recall (0.80). The matrix shows that Highway images were most frequently misclassified as Industrial areas (44 instances) or Residential zones (22 instances). This is logically consistent, given the shared concrete, asphalt textures, and dense infrastructure among these anthropogenic classes. Furthermore, 25 Highway images were confused with the River class, highlighting the geometric similarity of long, linear features when viewed from a satellite perspective.

We also observed expected overlaps within the agricultural domains. For example, PermanentCrop was occasionally confused with HerbaceousVegetation (21 instances) and AnnualCrop (17 instances), which reflects the nuanced visual differences within active farming boundaries.

Despite these minor textural overlaps, the overall results strongly validate the Vision Transformer's ability to capture global dependencies and extract highly accurate spatial features for rapid agroecological monitoring.

Pros and Cons of this Architecture

While Kinetic Keras drastically simplifies the transition from local development to cloud training, adopting it introduces specific trade-offs that developers must consider.

Pros:

• Zero-DevOps Elastic Acceleration: Kinetic eliminates the need to configure Kubernetes manually, manifests, or Dockerfiles. Scaling from local execution to enterprise-grade hardware is as simple as modifying a string in the decorator. Furthermore, managing cloud costs is straightforward, as the kinetic down command entirely dismantles the infrastructure once you are done.
• Seamless Background Execution: For long-running training loops, such as our 100-epoch ViT training, the @kinetic.submit() decorator is invaluable. It submits a detached job and returns a JobHandle. This allows you to safely disconnect your local terminal, poll the job status later, or even retrieve the final metrics from a completely different machine.
• Native Data and Checkpoint Management: Moving gigabytes of satellite imagery is typically a pain point. Kinetic solves this elegantly through the kinetic.Data(...) API, which mounts local files or Google Cloud Storage (GCS) buckets directly into the remote pod. Additionally, any weights or logs saved to the KINETIC_OUTPUT_DIR are automatically persisted as durable outputs.

Cons:

• Cold Start and Rebuild Penalties: In its default Bundled mode, Kinetic triggers Cloud Build to generate a container image. While cached runs are fast (under a minute), any modification to your project’s dependencies forces a new image build, resulting in a 2 to 5-minute wait time before the pod starts.
• Strict State Boundaries: Because the decorated function executes in a completely isolated remote container, local state does not cross the boundary implicitly. Any large datasets or custom variables loaded locally will not exist on the remote node unless explicitly shipped. Additionally, the remote function’s return value is serialized back to your local process, meaning you should only return small objects (like a dictionary of metrics or a file path) rather than the entire trained model object.
• GCP Ecosystem Lock-in: Kinetic’s powerful automation is currently tightly coupled with Google Cloud Platform services. It relies heavily on GKE, Artifact Registry, Cloud Build, and GCS under the hood.

Conclusions

• Scaling deep learning models from local prototypes to cloud-grade accelerators has traditionally been a daunting task, fraught with DevOps complexities and infrastructure overhead. Through this use case of classifying the EuroSAT satellite dataset with a Vision Transformer, we have demonstrated how Kinetic Keras fundamentally changes this paradigm.
• By abstracting away the underlying infrastructure, Kinetic enabled us to deploy a computationally intensive ViT model seamlessly to an NVIDIA L4 GPU. With just a simple @kinetic.run() decorator and the kinetic up command, we bypassed the need to write Dockerfiles, configure Kubernetes clusters, or manually manage data synchronization.
• For our agricultural management scenario, this rapid development cycle means faster deployment of critical classification models. Distinguishing between dense forests, agricultural mosaics, and bare soil after an extreme weather event can now be done with state-of-the-art accuracy and cloud-scale speed, all while keeping the data scientist’s focus strictly on the machine learning architecture rather than the deployment pipeline.
• Ultimately, Kinetic Keras represents a significant leap forward in machine learning productivity. It empowers researchers and engineers to harness the full power of enterprise hardware without ever leaving the comfort of their local Python environment, proving that the future of cloud training is frictionless.

References

P. Helber, B. Bischke, A. Dengel, and D. Borth, “Eurosat: A novel dataset and deep learning benchmark for land use and land cover classification,” IEEE Journal of Selected Topics in Applied Earth Observations and Remote Sensing, 2019.

A. Dosovitskiy et al., “An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale,” in International Conference on Learning Representations (ICLR), 2020.

Keras Team, “keras-team/kinetic: Run ML workloads seamlessly on cloud TPUs and GPUs with a single Python decorator,” GitHub, 2026. [Online]. Available: https://github.com/keras-team/kinetic.

Keras Team, “Architecture Overview — kinetic documentation,” 2026. [Online]. Available: https://kinetic.readthedocs.io.

Keras Team, “Execution Modes — kinetic documentation,” 2026. [Online]. Available: https://kinetic.readthedocs.io.

Keras Team, “Training Keras Models — kinetic documentation,” 2026. [Online]. Available: https://kinetic.readthedocs.io.

Keras Team, “Accelerator Support — kinetic documentation,” 2026. [Online]. Available: https://kinetic.readthedocs.io.

G. Dahiya et al., “EuroSat Dataset,” Kaggle. [Online]. Available: https://www.kaggle.com/datasets/apollo2506/eurosat-dataset.

Machine Intelligence and Deep Learning Lab, “ViT (Vision Transformer),” Medium. [Online]. Available: https://medium.com/machine-intelligence-and-deep-learning-lab/vit-vision-transformer-cc56c8071a20.

J. G. Gómez Torres, “multivariate-analysis-clustering-eurosat,” GitHub, 2026. [Online]. Available: https://github.com/jggomez/multivariate-analysis-clustering-eurosat

Thank you for reaching the end of this article. Remember to visit our website, devhack.co, and leave your comments on what topics you want us to delve into. See you next time! Chao chao!

Visit my social networks:

• https://github.com/jggomez/visual-transformer-kinetic-keras
• https://devhack.co/
• https://twitter.com/jggomezt
• https://www.linkedin.com/in/jggomezt/
• https://www.youtube.com/devhack