What Does Multi-Tenancy Mean in a GPU Neocloud Context?
Multi-tenancy in GPU Neoclouds and private GPU clouds means different things to different people — but for aarna.ml, it has a clear structure. It includes three tenets: Tenant RBAC/user authorization, IaaS isolation, and PaaS isolation. IaaS multi-tenancy, in particular, can take the form of hard isolation (bare-metal-level separation), soft isolation (Kubernetes-based), or hybrid.
Neoclouds and NVIDIA Cloud Partners (NCPs) require hard isolation for strong tenant separation — often down to dedicated Kubernetes clusters.
Enterprises may use soft or hard isolation depending on industry (multinationals and regulated sectors require hard isolation).
PaaS-only deployments typically rely on soft isolation, especially when no IaaS-level access is provided.
aarna.ml’s GPU Cloud Management Software (CMS) automates multi-tenant isolation at scale, orchestrating compute, GPU, storage, networking, Infiniband, external access, NVLink, and cluster-level policies — offering unmatched hard multi-tenancy across the full GPU cloud stack. aarna.ml GPU CMS also offers soft isolation layered on top of hard isolation for maximum flexibility.
When the topic of multi-tenancy comes up in the GPU Neocloud or NVIDIA Cloud Partner (NCP) context, I’m reminded of the Blind Men and the Elephant story. Each person has their own perception of what multi-tenancy means. For this reason, it seems that a broader discussion is required. I hope you enjoy the blog, please let me know what you think.
What Does Multi-Tenancy Really Mean?
In the context of GPU cloud management, multi-tenancy isn’t just a buzzword — it’s a practical framework that ensures multiple users (or “tenants”) can share cloud infrastructure securely and efficiently.
At its core, multi-tenancy in aarna.ml has three key pillars:
Tenant RBAC and User Authorization:
Role-Based Access Control (RBAC) and strict authorization ensure only the right people access the right resources. By definition this is a pillar of multi-tenancy as multiple personas are involved.
IaaS Multi-Tenancy:
This involves tenant isolation at the infrastructure level — covering Bare Metal-as-a-Service (BMaaS), Virtual Machine-as-a-Service (VMaaS), or dedicated Kubernetes clusters.
PaaS Multi-Tenancy:
Here, we’re talking about isolation for Platform-as-a-Service offerings like job submission, Model-as-a-Service, or AI/ML apps.
RBAC/user auth is always required. IaaS multi-tenancy depends on how you deploy it — and it comes in three flavors:
Hard Isolation:
Strong separation using techniques like CPU bare-metal or virtualization, GPU bare-metal or virtualization using techniques such as MiG, VxLAN for networks, VPCs, Infiniband P-KEYs, storage VRFs, and NVLINK Partitions. For Kubernetes, this means giving each tenant their own dedicated cluster.
Soft Isolation:
Lighter-weight separation using Kubernetes Namespaces or vClusters — no complex datacenter configuration required.
Hybrid:
A blend of hard and soft, depending on your security and flexibility needs.
Finally, if PaaS is made available to users, PaaS isolation is required also.
How This Plays Out in Real Use Cases
To see how this works in practice, let’s look at four common scenarios:
Neocloud or NVIDIA Cloud Partner (NCP)
What it is:
A Neocloud or NCP provides GPU infrastructure to external customers. Security is paramount — each customer wants complete assurance their workloads and data are isolated.
Deployment:
These clouds typically offer a mix of IaaS (BMaaS, VMaaS, dedicated K8s clusters) and PaaS (Job Submission, Model-as-a-Service, and on-demand AI/ML apps).
Isolation needed: Hard isolation — every element from compute to networking to storage must be securely configured. For Container-as-a-Service (CaaS), each tenant gets a dedicated Kubernetes cluster.
Alternative:
Some Neoclouds only offer Model-as-a-Service. Even then, hard isolation is needed for enterprise customers to ensure strong tenant boundaries beyond standard Kubernetes controls. For startups or independent developers, soft isolation or even simple model multi-tenancy will probably work fine.
Enterprise Private GPU Cloud
What it is:
An enterprise runs its own GPU cloud internally. Here, tenants are internal departments or teams — so while security is still important, it may not require the same hard isolation as a public cloud.
IaaS + PaaS: The enterprise mimics a public cloud, offering IaaS and PaaS for teams. Multi-national corporations, government or academic organizations, industries with sensitive data – financial, pharmaceutical, healthcare, etc. – require hard isolation. Other verticals may be fine with soft isolation.
PaaS Only: Some companies only offer Job Submission or Model-as-a-Service, without letting teams spin up IaaS instances. In this case, soft isolation is often sufficient.
How aarna.ml GPU Cloud Management Software (CMS) Makes This Work
So where does aarna.ml come in?
Our core value is delivering hard multi-tenancy at the IaaS layer — at scale. When a tenant or instance is created, our software automatically configures all relevant datacenter elements — compute nodes, GPUs, storage, networking switches and DPU, IB switches, VPCs, and NVLink — to guarantee robust isolation.
To our knowledge, no other solution orchestrates this level of holistic, automated, multi-layer isolation across a modern GPU cloud.
Below is an overview of what we call the seven pillars of hard multi-tenancy — the building blocks that make secure, multi-tenant GPU clouds possible.
Multi-tenancy isn’t one-size-fits-all — but with aarna.ml GPU CMS, you can design it to fit your exact use case, from flexible internal clouds to secure Neocloud offerings. And it all works hand-in-hand with GPU and related hardware for a powerful, enterprise/service provider grade stack.
This content originally published on https://www.aarna.ml/
