Zesty wants to turn spare GPU memory into usable AI capacity

Two jobs that fit inside a GPU’s memory still need a way to share its processing capacity. Zesty’s Automated Fractional GPUs, announced on 15 October, targets that allocation problem. The company says its software chooses which workloads share a GPU, their memory allocations and their sharing modes as demand changes.[1]

The opening came two days earlier, when NVIDIA released the full Run:ai orchestration platform as open source, including independently usable components. One is a GPU Fractioning Operator that brings CUDA-native memory limits into Kubernetes, the system used to manage groups of containerised applications. NVIDIA says this replaces Run:ai’s proprietary fractioning implementation with the native capability in CUDA 13.4.[2]

A memory boundary is a specific promise

The operator’s repository shows where enforcement happens. It injects a workload’s GPU memory limit before the container process starts; the NVIDIA driver enforces the cap. A container that exceeds its allocation is terminated for running out of memory. The software also exports per-workload memory and utilisation metrics. The limit is applied at the node where the GPU is used; the scheduling choice is made elsewhere.[3]

The placement decision already exists in the open-source stack. KAI Scheduler supports GPU sharing, workload priorities and policies that either pack jobs together or spread them across resources. Platform administrators already have a system for deciding where work runs.[4]

Zesty says its decisions use observed memory consumption, utilisation and workload behaviour, alongside the latency requirements and resource limits set by the operator. It supports time-slicing and NVIDIA’s Multi-Process Service. The distinction matters: dividing the memory establishes what each job may occupy; choosing a sharing arrangement addresses how the jobs use the processor together.[1]

The valuable outcome is released capacity

Zesty’s product page describes adjusting memory, compute share and sharing mode within performance and availability policies. Consider the financial consequence if a deployment can safely consolidate work onto fewer GPUs: spare capacity becomes available for another job, or a future purchase may be deferred. The result depends on what the operator can do with the freed resource. A server already purchased does not return its purchase price when utilisation improves.[5]

There is a real implementation boundary before any of that. The fractioning repository requires an NVIDIA r615-or-newer driver for CUDA 13.4, plus compatible GPU Operator, container-toolkit and device-plugin versions. Its instructions warn that the required driver is not the GPU Operator’s default. An existing Kubernetes installation is not by itself evidence that its GPU software stack can enforce the new limits.[3]

NVIDIA’s community distribution requires no paid Run:ai subscription, but NVIDIA enterprise support is not included. Teams can adopt the complete platform or individual components, while commercial supported offerings remain available. That leaves buyers with a concrete choice about which parts they want to operate themselves and which decisions or support they want a supplier to take on.[2]

Zesty says its agent installs without restarting workloads on a supported stack. An older cluster may first need a driver upgrade. Installing the agent and preparing the GPU are separate jobs.[1][3]

Report an error or suggest a correction