GPU sharing splits the hardware between workloads. Splitting the cluster between customers is a different problem. vCluster gives every tenant their own API server, RBAC, and control plane on the same GPU fleet, with Private Nodes (the production default) assigning dedicated worker nodes per tenant.
Dividing a GPU is well understood. Handing the pieces to customers who don't trust each other is where teams get stuck.
MIG, vGPU, and time-slicing divide GPU capacity between workloads. Nothing in that layer decides which customer a slice belongs to, or what happens when one of them misbehaves.
Namespace boundaries still let tenants see cluster-wide agents, nodes, and each other's workloads, however finely you slice the GPUs underneath.
Provisioning separate physical clusters restores the boundary but erases the density gains that made GPU sharing worth doing.
GPU sharing stays where it belongs, with MIG, vGPU, time-slicing, and DRA at the GPU layer. vCluster works above that: each tenant gets a real, CNCF-certified Kubernetes cluster with its own API server, etcd, and RBAC, running as a lightweight pod on your shared GPU fleet. For production tenants, Private Nodes (the production default) assign dedicated worker nodes with per-tenant CNI and storage. Production-proven across 100K+ GPU nodes.
vCluster layers over whatever GPU partitioning you already run. Control plane, node model, workload runtime, and conformance, each matched to how much you trust the tenant.
Each tenant gets their own Kubernetes API server, etcd, scheduler, and RBAC as a lightweight pod. They share the GPU hardware underneath and nothing else: no visibility into other tenants' nodes, workloads, or your platform internals.
Private Nodes, the production default, joins dedicated worker nodes into each tenant cluster over an encrypted WireGuard VPN, with per-tenant CNI and storage. No cross-tenant scheduling, and isolation that approaches a dedicated physical cluster.
Where density matters more than a hard boundary, tenants share GPU nodes with quotas enforced at the platform level, layered over whatever partitioning you run: Run:AI, MIG, or time-slicing. Suited to development, testing, CI/CD, and trusted internal teams.
vNode wraps each workload in kernel-native isolation using seccomp, cgroups, namespaces, and AppArmor, giving container breakout protection at bare metal GPU speed. It hardens the workload itself; the GPU stays partitioned by MIG, vGPU, or DRA.
Every tenant cluster is CNCF-certified and comes with cluster-admin rights, so tenants install their own GPU operator, device plugin, and MIG profiles without touching your control plane cluster or anyone else's configuration.
This isn’t a side project. Behind every vCluster deployment is 5+ years of deep K8s engineering, security hardening, and battle-tested infrastructure work at massive scale.
Talk to our team about your stack
Deploy vCluster on your infra in minutes
Go live with a hyperscaler-grade tenant experience in days
GPU sharing lets multiple workloads use the same physical GPU. It happens at the GPU layer through MIG (Multi-Instance GPU), vGPU, time-slicing, and DRA (Dynamic Resource Allocation), often driven by a scheduler such as Run:AI. Those mechanisms decide how GPU capacity gets divided. Ownership of each slice is a separate, Kubernetes-level question, and that's where most teams looking into GPU sharing actually get stuck.
No. GPU partitioning is handled by MIG, vGPU, time-slicing, and DRA. vCluster is the isolation envelope layered over them: each tenant gets a genuine Kubernetes cluster, so the partitions you hand out land inside a real boundary with their own API server, RBAC, and, with Private Nodes, their own hardware. It complements a GPU sharing strategy rather than competing with one.
vCluster supports a flexible isolation spectrum. Private Nodes, the production default, assigns dedicated worker nodes joined privately into each tenant cluster with per-tenant CNI and storage, which removes noisy-neighbor contention. Shared Nodes put several tenants on the same GPU hardware with resource quota boundaries, suited to dev, test, CI/CD, and trusted-team workloads. vNode adds kernel-native workload isolation using seccomp, cgroups, and AppArmor for container breakout protection across either model.
vCluster control planes run as lightweight pods with minimal overhead. There is no hypervisor layer or VM tax between workloads and the GPU. Combined with vNode for workload isolation, the stack relies on kernel-native mechanisms like cgroups and namespaces rather than full VMs, so bare metal GPU throughput is preserved. vCluster powers 100K+ GPU nodes in production across 50+ GPU cloud customers.
Yes. Every tenant cluster is a fully CNCF-certified Kubernetes environment with cluster-admin permissions. Tenants can install their own CRDs, GPU operators, device plugins, MIG configuration, and RBAC policies without affecting other tenants or the underlying control plane cluster. CRD and resource syncing between the tenant cluster and the control plane cluster is also supported for advanced configurations.
Yes. vCluster powers 100K+ GPU nodes in production and is deployed across 50+ GPU cloud providers and Fortune 500 customers, including CoreWeave and Nscale. It is named in the NVIDIA DGX SuperPOD reference architecture.
See how vCluster puts a real tenant boundary around your shared GPU fleet.
