Every couple of weeks I have the same conversation with someone who runs a high-performance computing (HPC) cluster. They have to keep the cluster running, support general Kubernetes, and now serve generative AI, and the cluster was never built for inference. So they stand up a separate stack for each one. Fuzzball lets you describe a job once and run it on the infrastructure you already operate, so a new kind of workload doesn't have to mean a new stack.
This post follows the third part of my session at AI Infrastructure Field Day, where I walked through how Fuzzball orchestrates distributed HPC and AI work. Watch the full segment.
Describe the job once and run it where the capacity is
A Fuzzball workflow is one YAML file. It describes the compute each job needs, the container images it runs, the data it uses, and the order the jobs run in. A training job can request GPUs, and a serving job can depend on it.
You can deploy across AWS, Google Cloud, Oracle Cloud, CoreWeave, and Azure, alongside your on-premises clusters. When you operate more than one cluster, Fuzzball places each job by cost, performance, and data locality.
One Fuzzball workflow file runs on-premises, in a public cloud, or on a GPU cloud, with no rewrite for each environment.
Start on the Slurm or PBS deployment you run today
Gregory Kurtzer, the founder of CIQ, created Fuzzball [VERIFY: Brian to confirm "created Fuzzball"; the Tech Field Day recap says it, the repo and the ciq.com leadership page do not] for HPC organizations that needed to modernize and give students and researchers access to compute faster. Fuzzball runs on top of your existing Slurm or PBS deployment and uses that deployment as a resource manager, so nothing has to move on day one. It's also a successor to that generation of resource manager, so you can move everything onto Fuzzball if you want to.
Fuzzball does need Kubernetes. It deploys on a Kubernetes cluster, so if your team doesn't run Kubernetes yet, that comes first.
Run batch jobs and model serving from one control plane
Fuzzball started with batch HPC work. We've since extended it to AI workloads, including long-running services. A completed training workflow can be published as an inference service from the same definition. The service runs as a pool that adds replicas as demand grows and gives its GPUs back when nobody is using it.
Fuzzball schedules NVIDIA and AMD GPUs from the same control plane. When you want capacity from another cluster or another cloud, that control plane federates across them.
Give researchers a catalog and a Run button
The part of Fuzzball I'm proudest of is the workflow catalog. Someone on your team writes a workflow once and publishes it. A researcher finds it in the browser, fills in the parameters, and runs it.
The catalog also includes validated model configurations. You start one by name and serve it on your own GPUs, with the GPU count and serving settings already worked out.
A researcher running a workflow from the Fuzzball catalog doesn't need to know where the compute is or how to connect to it.
Let AI agents operate the cluster within limits you set
Fuzzball includes an MCP server, so an AI agent can inspect the environment and draft and run workflows. You set the limits. Reads are open, and writes and runs wait for your approval.
Take the layer you need
Fuzzball is one layer of the AI kit I described in the first part of the session. You can deploy it without any other CIQ product, on the clusters you have. I don't expect anyone to replace their whole stack at once.
