You license a general-purpose, multi-tenant stack, deploy it on hardware you already own, and let your tenants provision compute, network and storage themselves through your portal and your API. The IaaS layer gives them virtual machines or whole bare-metal nodes, per-tenant networking, and block, S3-compatible object and POSIX file. The platform layer above it covers managed Kubernetes, Slurm, notebooks and model serving; anything past that is a product you would build on top, and we say so rather than let it sit implied in a title. What you buy is software — not capacity, not hosting, not a managed service.
You run one cluster for many tenants, each in its own environment. Partition keys on the fabric, per-tenant network segmentation, and namespaces with per-tenant credentials and quotas in storage enforce the boundary. Whether a node is shared between tenants or handed over whole is settled: a node is never split, it is handed over whole, and device memory is wiped between leases. Multi-tenancy is a property of the cluster: several sites means several clusters.
Your tenants create, scale and shut down their own environments under your brand, against an IAM and organisation model cut to the shape buyers know from AWS accounts, roles and policies.
You price consumption the way the tenant wants to buy it — on demand or on contract, per node, per hour or per token — and every unit is measured. Per-token capacity runs behind a per-tenant request boundary, a different isolation mode from reserved capacity.
Your tenants get block, S3-compatible object and POSIX file — Ceph RBD, Ceph RGW and VAST — as three services behind one API and one meter, each with per-tenant credentials and quotas.
Yes, within a list you can read before you call us: the Genesis Grid hardware compatibility list names the accelerators, hosts, fabric and subnet manager we support, and the storage releases we test against. Mixed vendors and mixed generations serve tenants from the same cluster. What mixing does not do is put two accelerator generations inside one training job, and we would rather write that down than let a tenant discover it.
.svg){kind=small}
Uptime Institute Tiers I to IV describe topology — redundancy, and whether you can maintain power and cooling while the site runs. They are not availability percentages, and Uptime has not published percentages for years. Software resilience changes how much redundancy the building has to carry for a given class of tenant; it does not replace a second power path. A deployment is one cluster in one building: lose the power there and the cluster goes with it. If you sell availability that depends on maintenance while the site runs, you need a facility that delivers it, and we will say so before you write it into an SLA.
No. You operate it, and we license you the software and ship releases. We ran it ourselves for eight years — our own sites were tenant zero and we carried the on-call rota — which is why the operational knowledge sits in the product. Volta is the licensee we may name, and Volta runs its own clusters itself.
You do. It stays your brand, your contract and your tenant relationship, and you get the isolation, the headroom and the telemetry to stand behind it. Underneath, we commit 99.9 % for the control plane, the portal and the meter, and a 30-minute severity-one response, 24/7, for support. Availability of a tenant environment is a product of your building, your hardware and this software, so it is agreed per deployment.
A platform upgrade costs your control plane, portal and meter under 15 minutes; instances already running are untouched. Node maintenance is a different thing: you cordon the node, the tenant is notified 72 hours in advance, and the workload either migrates live or resumes from its last checkpoint.
