Fuzzball vs. NVIDIA Run:ai
Keep your orchestration layer independent
Run:ai is a GPU optimization layer that extends Kubernetes, centered on getting more utilization out of hardware you already own, and NVIDIA owns it. CIQ sells no accelerators. Fuzzball owns the whole workflow, from build through train, validate, and serve, executes it close to the hardware through its own runtime, and schedules NVIDIA and AMD from one control plane.
Get the Fuzzball solution brief
The short answer
NVIDIA Run:ai is a GPU scheduling and optimization layer that extends Kubernetes, best known for fractional GPU sharing. NVIDIA acquired it in 2024 and open-sourced its scheduling core as the KAI Scheduler. Fuzzball is built by CIQ, a company that sells no accelerators. It runs the full AI lifecycle, executes on-node without the Kubernetes pod model in the path, and schedules NVIDIA and AMD hardware from one control plane.
From the team that created Apptainer and Singularity at Lawrence Berkeley National Laboratory, and the founding sponsor of Rocky Linux.
Compare what each one is built for
NVIDIA Run:ai
- Fractional GPU sharing at the CUDA level, a genuinely sophisticated capability
- Quota, fairshare, and gang scheduling across a shared Kubernetes GPU cluster
- Interactive Jupyter, batch training, and autoscaling inference in a familiar Kubernetes ecosystem
- An optimization layer on a stack you still assemble and operate, sold by NVIDIA
Fuzzball
- Build, train, validate, serve, and iterate in one portable workflow definition
- Its own per-node runtime executing directly on the hardware, with gang scheduling built in
- NVIDIA and AMD ROCm scheduled from one control plane, on any major cloud and on-prem
- Layers on existing Slurm and PBS, and on the Kubernetes you already run
Give Run:ai credit where it is due
GPU efficiency is a real problem worth solving, and Run:ai solves it well. Fractional GPU sharing, which time-slices a physical GPU at the CUDA level so several workloads share it, meaningfully raises throughput on hardware you already own. The AI-aware scheduler handles multi-tenant quotas, priorities, fairshare over time, and gang-scheduled distributed training. If the goal is squeezing more utilization out of an NVIDIA GPU cluster running on Kubernetes, that is a legitimate reason to choose it, and CIQ says so plainly.
The distinction worth weighing is what each product is at its core: an optimization layer that extends Kubernetes, or a platform that owns execution from the hardware up.
Prove the neutrality, do not claim it
CIQ sells no accelerators. There is no GPU line, no hardware revenue, and no incentive anywhere in the business for Fuzzball to schedule one vendor’s silicon better than another’s. That is a fact about how CIQ makes money, and it does not change with a roadmap decision. Every claim below follows from it.
Two accelerator ecosystems, one control plane
Five clouds and your own racks, one workflow definition
The scheduler you already run keeps running
A track record of giving control away
Neutral does not mean generic
Weigh the differences that matter
Two of the big schedulers now sit inside a hardware vendor
Execution close to the hardware
A platform in place of a scheduler
The full lifecycle in one definition
Sovereign AI on infrastructure you govern
See what Fuzzball 4.2 adds
Schedule NVIDIA and AMD from one control plane
Give AI agents a safe way to run the workload
Let a workflow submit its own work
Schedule around unhealthy hardware
Account for what each workload consumed
Compare Fuzzball and Run:ai at a glance
NVIDIA Run:ai | Fuzzball | |
|---|---|---|
| Design center | ||
| Category | GPU optimization layer built on Kubernetes | Purpose-built, vendor-neutral HPC and AI platform |
| Core value | Maximize GPU utilization through fractioning and quotas | Run the whole AI workflow close to the hardware |
| Architecture | Scheduler extending Kubernetes, unit of work is a pod | On-node runtime executing directly on the compute node |
| Workload unit | Kubernetes workloads and jobs on a shared GPU cluster | A workflow: batch job, inference service, or both |
| Scheduling and hardware | ||
| GPU sharing | Fractional GPU and CUDA time-slicing, a genuine strength | Hardware-aware scheduling with bare-metal execution |
| Interconnect awareness | GPU-focused, through the Kubernetes device model | InfiniBand auto-detected, GPUs allocated with topology awareness |
| Node health | GPU utilization visibility and policy enforcement | Reliability scoring feeds placement, jobs restart on healthy nodes |
| Accelerator support | NVIDIA, as part of the NVIDIA AI Enterprise stack | NVIDIA and AMD ROCm from one control plane |
| Lifecycle and data | ||
| Lifecycle coverage | Jupyter, training, and autoscaling inference on Kubernetes | Train, validate, and serve in one workflow, with RAG and agents |
| Data management | Handled by the surrounding stack and the application | Ingress, caching, and egress declared as workflow volumes |
| Model ingress | Handled by the ML tooling you assemble | Pull from Hugging Face or Ollama as a declared input |
| Accounting | GPU utilization visibility and cost control | Compute, storage, and network egress per workflow |
| Independence and operation | ||
| Ownership | An NVIDIA product, with the KAI Scheduler core open sourced | Built by CIQ, which sells no accelerators |
| Hardware incentive | The vendor of the platform also sells the silicon | No GPU line and no hardware revenue anywhere in the business |
| Agent interface | Kubernetes and ML ecosystem tooling | MCP server for workflows, with per-action permissions |
| You still operate | Your Kubernetes cluster and the surrounding stack | One platform, and it layers on Slurm and PBS if present |
| Relationship | ||
| To each other | Requires a Kubernetes GPU cluster to install onto | Orchestrate deploys on Kubernetes, Substrate runs on-node |
Run Fuzzball alongside Kubernetes
The comparison is not always mutually exclusive.
On your Kubernetes
Orchestrate is a Kubernetes-native microservice stack, so it deploys on the conformant cluster you already operate.
On your nodes
Substrate executes jobs directly on the compute node, which keeps bare-metal performance for both training and serving.
On your schedulers
Fuzzball coexists with existing Slurm and PBS deployments and with parallel filesystems, and adds orchestration without a migration.
Match this to your situation
- The orchestration layer comes from the same vendor that sells the accelerators
- AMD or custom silicon is on the roadmap, and the platform would make switching costly
- A Kubernetes cluster has to exist and be operated before the AI platform can start
- Utilization looks healthy, and training runs still fail on bad nodes and restart from scratch
- Training runs on one stack and inference on another, with a manual handoff between them
- A sovereignty or data-residency requirement needs an answer a vendor-owned layer does not give
Zero
Accelerators CIQ sells
No GPU line and no hardware revenue, so nothing in the business favors one vendor’s silicon.
Full
Lifecycle in one portable workflow
Autoscaling inference, RAG, and agents defined alongside training rather than bolted on.
Sovereign
Models and data stay on infrastructure you control
Serve on-prem, or train on cloud GPUs and keep sensitive inference in house.
Per workflow
Compute, storage, and egress accounted for
Utilization says the GPUs were busy. Accounting says what the run cost.
Define the terms
- What is NVIDIA Run:ai?
- NVIDIA Run:ai is a GPU orchestration and optimization platform that extends Kubernetes with an AI-aware scheduler. It is best known for fractional GPU sharing, which time-slices a physical GPU at the CUDA level so several workloads can share it, alongside quota, fairshare, and gang scheduling. NVIDIA acquired Run:ai in 2024, and it is part of the NVIDIA AI Enterprise stack.
- What is the KAI Scheduler?
- The KAI Scheduler is the open-source scheduling core of NVIDIA Run:ai. NVIDIA released it under the Apache 2.0 license in April 2025, and it is now a CNCF Sandbox project. It is a Kubernetes-native scheduler for GPU and CPU AI workloads, and it continues to ship as part of the commercial Run:ai platform.
- What is fractional GPU sharing?
- Fractional GPU sharing is a technique that divides a single physical GPU among several workloads, so a job that cannot use a whole accelerator does not hold one idle. It raises utilization on existing hardware, and it is distinct from scheduling a tightly coupled job that needs whole GPUs allocated together with interconnect topology in mind.
- What is Fuzzball?
- Fuzzball is CIQ’s orchestration platform for HPC, AI training, and AI inference. It treats every workload as a containerized workflow, executes it through an on-node agent with direct access to GPUs and high-speed interconnects, and schedules NVIDIA and AMD ROCm hardware from one control plane across on-premises clusters, cloud, and edge.
Run Fuzzball on your own workflow
Bring one workflow and the environments you have to run it in. A CIQ engineer will walk your team through a run on your own hardware, then the same run in a cloud, unchanged.
Frequently asked questions
Yes. Run:ai is a strong GPU optimization layer, and GPU efficiency is a real problem worth solving. Fractional GPU sharing and AI-aware quota scheduling meaningfully raise throughput on hardware you already own. The distinction worth weighing is what each product is at its core: an optimization layer that extends Kubernetes, or a platform that owns execution from the hardware up.
Partly. NVIDIA released Run:ai’s scheduling core as the KAI Scheduler under the Apache 2.0 license in April 2025, and it is now a CNCF Sandbox project. The commercial Run:ai platform, including its management interface, policy controls, and fractional GPU capabilities, remains an NVIDIA product within the NVIDIA AI Enterprise stack.
Fractional sharing at the CUDA level is Run:ai’s signature capability. Fuzzball’s focus is different: hardware-aware scheduling with direct GPU and interconnect access, gang scheduling for tightly coupled training, and bare-metal execution for both training and inference. Teams choosing between them should weigh which problem is actually costing them more.
Yes. AMD ROCm support shipped in Fuzzball 4.2, so Fuzzball discovers and schedules workloads across both NVIDIA and AMD infrastructure from one control plane. That keeps the platform independent of any single accelerator supplier.
Fuzzball Orchestrate is a Kubernetes-native microservice stack and deploys on any conformant Kubernetes cluster. Substrate, the compute agent, runs directly on the compute node rather than as a Kubernetes-scheduled pod, which is what keeps the job execution path close to the hardware.
It is structural. CIQ sells no accelerators, so there is no GPU line and no hardware revenue anywhere in the business that would favor one vendor’s silicon. Fuzzball schedules NVIDIA and AMD ROCm from one control plane, deploys to AWS, Google Cloud, Oracle Cloud, Azure, CoreWeave, and on-premises hardware with the same workflow definition, and layers on existing Slurm, PBS, and Kubernetes rather than replacing them.
Leverage. NVIDIA acquired Run:ai in 2024 and SchedMD, Slurm’s maintainer, in December 2025, so two of the most widely used ways to schedule accelerated work now sit inside the company that sells the accelerators. Both remain open source and both pledges are credible. A neutral orchestration layer still means the platform never becomes the reason a hardware decision is hard to reverse.
Both. Service Endpoints define persistent, scalable inference and interactive endpoints alongside batch training steps in one portable workflow, and they preserve the same close-to-hardware performance while scaling with demand as part of the orchestrated job.
Fuzzball deploys to AWS, Google Cloud, Oracle Cloud, Azure, and CoreWeave, to on-premises clusters built with Warewulf, VMware, or bare metal, and onto existing Kubernetes distributions. The same workflow definition runs unchanged in all of them, and Fuzzball Federate unifies them and routes work on cost, performance, and data locality.
Still have questions?