Distributed Compute Aggregation

One management plane for GPU compute from every source you own or contract. Whether that is a cloud region, a co-located data center, or a compute supplier, each site runs a Standalone control plane cluster. Your central Platform instance sees the full fleet.

Customer access model: Each tenant gets an isolated cluster on dedicated GPU nodes, regardless of which compute source backs it. Worker-node model: Private nodes per tenant cluster at every site.

Typical stack: Central Platform (global). Per-DC Standalone control plane cluster. Private GPU nodes co-located with each Standalone instance. vMetal for owned bare metal sites.

Central control plane managing tenant workloads across distributed compute capacity sources

What makes this path different: Every compute source, regardless of where it lives or who operates it, follows the same onboarding playbook. One ops team, one management plane, no per-provider tooling. This architecture also maps to the cluster-level isolation criteria that AI cloud buyers evaluate in frameworks like ClusterMAX.

Day 0: Design decisions

Decision	Read next	Outcome
Design the central-regional topology	Multi-region Platform, Standalone deployment	Central Platform registers each DC's Standalone instance as a connected cluster. Tenant control planes run co-located with their GPU nodes at each site.
Define the supplier onboarding playbook	Standalone HA, Private Nodes, Auto Nodes	Standardize the steps to register a new compute source: install Standalone, connect to central Platform, join GPU inventory, validate.
Plan networking between sites	VPN	Each site's tenant clusters connect to their private nodes over VPN. Define whether tenants can span sites or are bound to a single DC.
Define the default network policy posture	Network policy	Set a default-deny east-west posture per tenant template at every site and confirm each site's CNI enforces it. Some CNIs accept NetworkPolicy objects without enforcing them.
Define tenant isolation at each site	Private Nodes, vNode docs	Each tenant cluster at a site gets its own dedicated GPU nodes. vNode adds runtime isolation for untrusted workloads.
Choose the GPU scheduling model	DeviceClasses, DRA ResourceClaims	Device-plugin-style DeviceClass sync covers simple, whole-GPU allocation. DRA ResourceClaim sync (Pro) supports fine-grained and shared GPU allocation, consistently across every compute source.
Plan tenant storage per site	Storage classes from host, CSI storage capacities	Decide which storage classes are available at each site, since local NVMe or shared storage availability can differ by compute source, and whether to sync host CSIStorageCapacity for scheduler-aware placement.
Plan security hardening and audit logging	Security baseline, CIS hardening guide, Platform audit logging	Apply a consistent CIS benchmark baseline across every site's control plane cluster and decide audit log retention and SIEM integration before onboarding tenants.

Day 1: Stand up the first compute source

1. Deploy vCluster Platform in the central region. Configure Platform HA and backup.
2. At the first compute site, install vCluster Standalone and move to HA.
3. Register the site's Standalone control plane cluster with central Platform.
4. Join the site's GPU inventory as private nodes. Configure Auto Nodes or vMetal for automated provisioning and reclaim.
5. Configure templates and quotas in central Platform for this compute source.
6. Apply a default-deny network policy in the site's template and confirm the site's CNI enforces it.
7. Configure per-site storage classes for the template.
8. Configure GPU scheduling: sync DeviceClasses for device-plugin allocation, or enable DRA ResourceClaim sync for fine-grained allocation.
9. Apply the CIS hardening baseline to the site's control plane cluster and enable Platform audit logging.
10. Provision a test tenant cluster at the site. Validate that it appears in central Platform and that workloads land on the correct GPU nodes.
11. Document the supplier onboarding playbook. Repeat steps 2-10 for each additional compute source.

Day 2: Operate

Operation	Read next
Monitor the distributed fleet	Fleet monitoring
Onboard a new compute source	Supplier onboarding playbook (internal), Standalone deployment
Upgrade across sites	Upgrade vCluster, upgrade Platform
Handle site failures	Platform HA, multi-region Platform
Track GPU utilization and faults across sites	GPU observability templates, NVSentinel GPU observability
Review audit logs and security posture across the fleet	Platform audit logging, security baseline