ai-cloud

Reserved GPU Capacity for AI Clouds

Build reserved GPU services around dedicated workers and retention policies. vMetal provisions capacity, and vCluster assigns Private Nodes; operators define reservation terms and availability.

Trusted by the fastest-growing AI cloud providers
Problem

Why Reserved GPU Capacity Is Hard

Reserved GPU services need clear ownership of worker capacity and a consistent way to deliver it to tenant clusters.

Separate Management Stacks Add Work

A separate Kubernetes management stack for every tenant increases infrastructure and operational work.

Namespaces Do Not Dedicate Workers

Namespace-only designs do not dedicate worker capacity or provide a separate tenant control plane.

Custom Capacity Workflows Add Handoffs

Custom capacity workflows create manual handoffs between tenant requests, Machine provisioning, and cluster attachment.

Solution

Dedicated Workers with Explicit Reservation Policies

Private Nodes dedicate workers to a tenant; operators define reservation duration and availability. Configure retained or minimum capacity and release policies to preserve commitments, with vMetal provisioning additional inventory-backed machines. vCluster Labs software powers 100K+ GPUs.

Built for Reserved GPU Capacity

Reserved GPU capacity combines dedicated Private Nodes, tenant control planes, capacity policy, and optional Machine provisioning.

Tenant Isolation

Private Nodes for Reserved GPU Capacity

Private Nodes dedicate worker capacity to one tenant cluster, with its own CNI and storage configuration. For reserved worker services, select physical servers or VMs according to the required infrastructure boundary.

  • Dedicated worker nodes per tenant
  • Tenant-owned CNI and storage configuration
  • Physical servers or supported VMs
Control Plane

Separate Tenant Control Planes

Each tenant receives its own virtualized Kubernetes control plane, API server, and RBAC boundary.

  • Independent tenant API and data store
  • Tenant-scoped scheduling on Private Nodes
  • No dedicated control-plane servers per tenant
Dynamic Provisioning

Capacity Requests Through Auto Nodes

Auto Nodes manages worker capacity through configured provisioning and release policies. For reserved services, retain the promised minimum or static capacity and prevent idle scale-down from releasing customer commitments.

  • Karpenter-based node management
  • Supported infrastructure provider integration
  • Inventory-aware capacity policies
Bare Metal Layer

Bare Metal Machines Through vMetal

vMetal exposes one Machine API above bare metal and VM provisioning drivers. Registered inventory, images and credentials enable repeatable machine lifecycle workflows for reserved worker services. Network automation uses supported integrations such as Netris.

  • Stable Machine API
  • Bare metal and VM provisioning
  • Driver-specific lifecycle automation
Platform Operations

Central Tenant and Capacity Management

Coordinate tenant environments for reserved worker services through one UI, CLI and API. Templates, access policies and quotas provide central operator controls while tenant Kubernetes APIs and dedicated production workers remain separate.

  • Central UI, CLI, and API
  • Quota and capacity management
  • SSO and cluster templates included

Why vCluster

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.

100K+
GPUs Powered
50+
GPU Clouds & F500s
<45
Days to Launch
30K
GitHub Stars

Get Started in 3 Steps

1
Schedule a Demo

Talk to our team about your stack

2
Deploy vCluster

Deploy vCluster on your infra in minutes

3
Onboard Your Tenants

Go live with a hyperscaler-grade tenant experience in days

FAQs

How can operators build reserved GPU services with Private Nodes?

Private Nodes dedicate worker capacity to a tenant, but do not alone define a reservation contract or duration. Operators set the commercial commitment and configure retained or minimum capacity, inventory allocation and release policies accordingly. vMetal can provision available machines. Confirm that idle scaling and machine release cannot remove capacity you have promised to retain for that customer.

Do I need separate physical clusters for each tenant's reserved GPU capacity?

vCluster gives each tenant an independent Kubernetes API, data store and RBAC scope. Private Nodes dedicate worker capacity to that tenant, including its own CNI and storage configuration. vMetal orchestrates the machines underneath. This separates tenant administration and worker placement; shared infrastructure, application permissions and network policies still require an explicit security design.

What workloads can use a dedicated tenant’s reserved GPU workers?

Reserved dedicated workers can run a tenant’s supported Kubernetes workloads, including training, Ray applications and inference services. GPU allocation remains the responsibility of configured drivers and workload scheduling. The operator must preserve reserved capacity through retention and release policies. A separately packaged managed Slurm offering remains planned and should not be presented as available reserved-capacity inventory.

How quickly can I launch reserved GPU capacity for clients?

A tenant control plane and its worker capacity have different readiness requirements. Existing provisioned workers can shorten onboarding, while new machines require the selected infrastructure driver's provisioning workflow. Templates, networking, storage and GPU drivers must also be ready before workloads can run. Configure Private Nodes when creating the tenant cluster, and validate application readiness separately from Kubernetes API availability.

How does vCluster handle network isolation for reserved GPU capacity?

Private Nodes give a tenant its own worker networking configuration. Supported Netris integrations can add Ethernet segmentation through VLANs, VRFs and ACLs on compatible infrastructure. These controls require explicit setup and do not reserve all fabric bandwidth. InfiniBand uses partition keys and fabric management rather than Ethernet segmentation; design the relevant fabric controls alongside tenant cluster access policies.

What evidence supports vCluster for GPU capacity at scale?

vCluster Labs software powers 100K+ GPUs and 1M+ CPUs, serving 50+ GPU clouds & Fortune 500s combined. In production, Lintasarta operates 170+ tenant clusters, while Boost Run completed its managed Kubernetes launch in under 45 days from the decision. These named deployments provide scale and launch examples for teams evaluating the platform for their own infrastructure.

Start Offering Reserved GPU Capacity Today

See how vCluster Platform turns dedicated GPU nodes into reserved capacity you can sell per tenant.