Compare Fuzzball vs. OpenStack
Run the workload, not the machine
OpenStack is Infrastructure-as-a-Service. It delivers a virtual machine or a bare-metal server booted from an OS image and leaves everything above that to you. Fuzzball takes a containerized application and schedules, executes, and manages it directly, with no hypervisor between the workload and the silicon.
Get the Fuzzball solution brief
The short answer
OpenStack is an Infrastructure-as-a-Service platform that hands back a machine: a Nova virtual machine or an Ironic bare-metal node booted from an OS image. Fuzzball is a workload orchestration platform that takes a containerized HPC or AI workflow and runs it. The two sit at different layers, and Fuzzball commonly runs on top of OpenStack rather than instead of it.
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
OpenStack
- Self-service pools of VMs, storage, and networking for enterprise IT
- Web apps, databases, and internal systems that need no hardware-aware placement
- Live migration, snapshots, and overcommit, the flexibility a private cloud exists to provide
- Ironic drops the hypervisor and still hands back a bare OS image
Fuzzball
- HPC, AI training, and inference scheduled with GPU and interconnect awareness
- Containerized workflows with data ingress and egress declared inline
- Substrate on the compute node, with no hypervisor in the job execution path
- No OS to provision, patch, or configure, because the platform is the runtime
Understand the real difference
Infrastructure-as-a-Service delivers compute, storage, and networking, and hands responsibility for everything above that to the consumer: OS configuration, runtime dependencies, schedulers, drivers, and the application. OpenStack is a textbook example. Whether the request goes through Nova or Ironic, the deliverable is an operating system instance. You receive a machine, not a working environment.
Fuzzball operates one layer up. A user submits a workflow describing containerized steps, their resource needs, and their data dependencies, and Fuzzball schedules, sequences, and executes that application directly. Nothing gets provisioned, patched, or configured first.
Containers versus virtual machines is a real architectural difference between the two, and it is a symptom rather than the cause. The cause is what each platform was designed to deliver.
See what’s new in Fuzzball
Serve a model on the capacity you provisioned, by name
Hold nothing when idle
Govern who can reach which provisioner
Keep agents and retrieval inside the tenant boundary
Cover AMD hardware health too
Weigh the differences that matter
Closest to the hardware wins
Tuning costs you the flexibility
Ironic solves half the problem
Data as part of the workload
Batch and inference in one workflow
Compare Fuzzball and OpenStack at a glance
OpenStack | Fuzzball | |
|---|---|---|
| Design center | ||
| Category | Infrastructure-as-a-Service | Workload orchestration for HPC, AI, and inference |
| What you get | A VM or bare-metal node booted from an OS image | A scheduled, running application, with no OS to manage |
| Workload unit | Operating system instance | A workflow: batch job, inference service, or both |
| Applications | Web apps, databases, internal enterprise systems | Simulation, AI training and inference, scientific pipelines |
| How the work runs | ||
| Customer builds | The whole stack: schedulers, MPI, drivers, tooling | Nothing, turnkey from a workstation to national-lab scale |
| Execution path | Nova or Ironic, and either way still infrastructure | Substrate executes on-node, no hypervisor in the data path |
| Hardware awareness | GPU and interconnect access through passthrough and tuning | InfiniBand auto-detected, GPUs allocated with topology awareness |
| Node health | Rebuild the instance, with no view of the job on it | Reliability scoring feeds placement, jobs restart on healthy nodes |
| Data, services, and cost | ||
| Data for the app | Cinder and Swift are raw storage, and the wiring is yours | Ingress, caching, and egress declared as workflow volumes |
| Model ingress | Scripted staging by the researcher | Pull from Hugging Face or Ollama as a declared input |
| On-demand inference | No native model, the serving stack is yours to build | Service Endpoints in the same workflow as training |
| Accounting | Infrastructure metering by instance, volume, and network | Compute, storage, and network egress per workflow |
| Multi-tenancy | Projects, quotas, and roles at the infrastructure layer | Storage isolation and compute-policy grants at the workload layer |
| Interface and heritage | ||
| Interface | More than thirty services with their own APIs and consoles | One web UI, CLI, and SDK at full parity |
| Agent interface | APIs for provisioning machines | MCP server for workflows, with per-action permissions |
| Container lineage | Not container-native, HPC performance is a tuning exercise | Same team and design lessons as Apptainer, in a purpose-built runtime |
| Relationship | ||
| To each other | Can host Fuzzball Substrate and Orchestrate as its compute layer | Runs on OpenStack, and federates it with on-prem, cloud, and edge |
Run Fuzzball on top of OpenStack
The two occupy different layers, so they are not mutually exclusive.
Compute
Substrate runs on nodes OpenStack provisions, whether Nova virtual machines or Ironic bare metal. Pairing Fuzzball with Ironic keeps the job execution path close to the silicon.
Orchestration
Orchestrate deploys on OpenStack infrastructure and turns provisioned capacity into a turnkey HPC and AI platform rather than raw machines to build up.
Federation
Federate brokers workflows across OpenStack clusters, on-prem systems, and cloud or edge at once, and routes each job on cost, performance, and data locality.
Match this to your situation
- A private cloud hands researchers a VM and leaves the entire HPC stack to them
- Hypervisor jitter shows up as synchronization stalls in a 500-rank MPI job
- Cinder and Swift are in place, and every workflow still scripts its own staging
- An inference service is something the team designs, scales, and operates itself
- Finance wants to charge a business unit for a training run, and instance hours are the only number available
- The GPU nodes were bought for AI, and the researchers still open a ticket to get one
Zero
Hypervisors in the job execution path
Process-level isolation, with no guest OS and no emulation between workload and silicon.
One
Workflow for batch jobs and inference
Service Endpoints sit alongside training rather than in a stack you build.
Both
Platforms, at different layers
Fuzzball turns OpenStack-provisioned capacity into a usable HPC and AI platform.
Per workflow
Compute, storage, and egress accounted for
Chargeback at the workload layer, not just the instance layer.
Define the terms
- What is OpenStack?
- OpenStack is an open-source Infrastructure-as-a-Service platform for building private and public clouds. It is a collection of more than thirty interconnected services covering compute, storage, networking, identity, DNS, and secrets management, and it originated in a joint effort by NASA and Rackspace. Its core deliverable is a virtual machine or a bare-metal server.
- What is Infrastructure-as-a-Service?
- Infrastructure-as-a-Service is a cloud model in which the provider delivers virtualized or bare-metal compute, storage, and networking, and the consumer is responsible for everything above that layer: operating system configuration, runtime dependencies, schedulers, drivers, and the application itself. IaaS delivers capacity. It does not run workloads.
- What is OpenStack Ironic?
- OpenStack Ironic is the OpenStack service that provisions physical bare-metal servers instead of virtual machines. It removes the hypervisor and its virtualization overhead. The deliverable is still an operating system image, so schedulers, MPI, GPU drivers, container tooling, and data movement remain the customer’s to install.
- What is Fuzzball?
- Fuzzball is CIQ’s orchestration platform for HPC, AI training, and AI inference. It treats every workload as a containerized workflow and executes it through an on-node agent with no hypervisor in the data path. Fuzzball runs on infrastructure that OpenStack provisions, including Ironic bare metal.
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
Usually not, because the two sit at different layers. OpenStack delivers a virtual machine or a bare-metal server booted from an OS image, and Fuzzball takes a containerized application and schedules, executes, and manages it. In many environments Fuzzball runs on top of OpenStack rather than instead of it, and turns provisioned capacity into a turnkey HPC and AI platform.
You can run HPC on OpenStack, and it takes work. The deliverable is an OS image, so schedulers, MPI, GPU drivers, container tooling, and data movement all get installed and maintained by the customer. Virtualized nodes also need CPU pinning, NUMA-aware placement, huge pages, and SR-IOV or PCI passthrough before tightly coupled jobs perform acceptably.
Ironic removes the hypervisor, so it solves the virtualization overhead problem. It does not solve the workload problem, because the deliverable is still an OS image with the entire HPC and AI stack left to install by hand. Pairing Fuzzball with Ironic adds the turnkey workload layer on top while keeping execution close to the hardware.
It depends heavily on the workload. CPU-bound work sees little difference on modern hypervisors, while memory- and network-bound work carries a measurable residual even after careful tuning, and communication-heavy MPI collectives suffer most. The jitter matters as much as the average, because a tightly coupled job runs at the speed of its slowest rank at every synchronization point.
Both. Service Endpoints serve inference and interactive endpoints alongside batch training steps in one portable workflow. A service runs as an autoscaled pool behind one stable endpoint, which can hold no replicas when idle; the first request after an idle period returns a 503 with a retry interval while a replica starts. Serving keeps the same close-to-hardware performance as the training steps.
No. MPI, Shmem, and other HPC communication libraries run inside Fuzzball’s containers, and NCCL works the same way for multi-GPU training. InfiniBand is auto-detected and GPUs are allocated with topology awareness, so simulation code and distributed training jobs run unchanged.
Fuzzball deploys to AWS, Google Cloud, Oracle Cloud, Azure, and CoreWeave, to on-premises clusters built with Warewulf, VMware, or bare metal, and onto OpenStack-provisioned infrastructure through Nova or Ironic. The same workflow definition runs unchanged in all of them.
Still have questions?