GPUnion: Autonomous Campus GPU Sharing

• GPUnion is a campus-scale GPU-sharing platform enabling voluntary, autonomous sharing of GPUs across laboratories with uneven resource distribution.
• It uses container-based task dispatching, a provider-first architecture, and resilient checkpointing to maintain reliable operation amid provider churn.
• Empirical evaluations demonstrated increased GPU utilization (from 34% to 67%) and a 40% boost in interactive debugging sessions in campus deployments.

Searching arXiv for the GPUnion paper and closely related context. arxiv_search(query="GPUnion autonomous GPU sharing campus", max_results=5) GPUnion is a campus-scale GPU-sharing platform designed for environments in which GPU resources are unevenly distributed across laboratories and workstations, with some servers remaining underutilized while other groups lack compute needed for AI research. It is presented as a system for voluntary, autonomous GPU sharing across a trusted campus network, with the explicit goal of preserving full provider autonomy rather than subsuming participating machines into a conventional centrally managed cluster. Its design centers on container-based task dispatching and execution, a resource provider-first architecture, and resilient execution through automatic checkpointing and migration, while also supporting custom data storage and security-oriented container controls such as non-root execution and image attestation (Li et al., 25 Jul 2025).

1. Problem setting and conceptual scope

GPUnion is motivated by a campus-specific resource asymmetry. The paper identifies resource imbalance, temporal idleness, heterogeneous hardware, and access barriers as the relevant structural conditions: some laboratories own multiple GPUs but use them intermittently; GPUs often sit unused between experiments, during breaks, or outside working hours; campus hardware ranges from consumer RTX/3090 cards to A100/A6000-class hardware; and students or smaller groups may need GPU access but cannot afford dedicated machines (Li et al., 25 Jul 2025).

The system is therefore not framed as a generic cloud scheduler. Its intended outcome is a democratized campus GPU commons that improves utilization while preserving the ownership rights of each provider. This governance premise is central: participation is voluntary, availability is dynamic, and machines remain independently managed. A plausible implication is that GPUnion addresses not only scheduling efficiency but also the institutional constraints of academic resource ownership, where the legitimacy of a sharing platform depends on whether providers can reclaim their machines immediately and without prior coordination.

The paper positions this design against existing GPU-sharing models that assume centralized administration, stable membership, and persistent resource availability. GPUnion instead assumes churn as a first-class condition. That distinction shapes both its control plane and its fault-tolerance mechanisms.

2. Design principles and provider-first governance

GPUnion’s design is organized around three named mechanisms: container-based task dispatching and execution, provider-first architecture, and resilient execution with automatic checkpointing and migration (Li et al., 25 Jul 2025).

The provider-first architecture is the distinctive governance model. Providers retain absolute control over their machines and may join, pause, or leave at any time. Each provider machine runs a lightweight agent that advertises GPU capacity and availability, manages job lifecycle actions, exposes REST APIs, and integrates a kill switch so the provider can instantly terminate workloads or leave the platform. The paper describes this as the mechanism that implements provider supremacy: the machine owner always has final authority.

This model is explicitly contrasted with centralized cluster control. Kubernetes is discussed as supporting GPU scheduling via plugins, but as being built around centralized control and expecting nodes to be stable and continuously connected. Reservation-oriented systems such as Slurm or cloud services such as AutoDL are described as poor matches for a setting in which providers may reclaim GPUs immediately. The paper similarly characterizes OpenStack as powerful but too complex and resource-heavy for campus volunteers, while CloudStack and OpenNebula remain primarily VM-centric and do not naturally support dynamic, revocable GPU sharing across independently managed campus machines. The significance of GPUnion, in the paper’s own framing, is that provider autonomy and platform reliability can coexist, thereby challenging conventional centralized paradigms (Li et al., 25 Jul 2025).

3. System architecture and execution model

GPUnion consists of four main functional pieces: a central scheduler and coordinator, provider agents and local control, a containerized execution environment, and distributed monitoring and state management (Li et al., 25 Jul 2025).

The central scheduler tracks available GPUs on the campus network, receives periodic status updates from provider agents, and makes allocation decisions. It supports round-robin for fairness and priority-based assignment for urgent workloads. The paper emphasizes that this scheduler is designed for a volatile environment rather than for the stable-node assumptions of traditional cluster schedulers.

The execution substrate is container-based. Workloads run inside Docker/OCI containers with NVIDIA GPU passthrough via the NVIDIA Container Toolkit. The paper attributes near-native GPU performance and portability across heterogeneous machines to this choice, and it associates isolation with Linux namespaces, cgroups, and Seccomp profiles. Two operating modes are supported: interactive mode, which provides auto-provisioned Jupyter notebook environments, and batch mode, which accepts arbitrary user-defined container images and entrypoints.

Monitoring and persistent state are handled by Prometheus exporters and PostgreSQL. Prometheus collects hardware and application metrics, while PostgreSQL stores node registrations, resource allocations, and historical monitoring data. The implementation is written in Python and is about 5,000 lines of code. Automatic registration scripts generate machine IDs, establish network connectivity, and obtain authentication credentials.

At the provider side, the agent uses PyNVML to monitor GPU state, including memory utilization, temperature, and power consumption. Allocation decisions also consider GPU memory capacity, CUDA compute capability, predicted provider volatility, and network latency. A plausible implication is that GPUnion treats heterogeneity as a scheduling input rather than as an exceptional case, which is appropriate for campus fleets assembled from independently purchased systems.

4. Resilience, storage, and security mechanisms

Resilient execution is required because providers can leave unexpectedly. GPUnion therefore combines state-aware checkpointing, failure detection, automatic migration, and storage flexibility into a single execution model (Li et al., 25 Jul 2025).

For long-running or stateful jobs, checkpointing can capture CPU and memory state, file system state, and GPU memory state, if feasible. Checkpoints may be stored on a LAN-accessible distributed file system or on a specific node chosen by the user. This storage model is explicitly user-defined: users can specify preferred storage locations for workload data, checkpoints, and outputs. The paper notes that this is useful when some workloads need local storage for speed while others require persistent campus file systems or placement constraints for sensitive data.

Failure detection is heartbeat-based. If a node misses three consecutive heartbeats, it is marked unavailable. When a provider leaves or fails, the scheduler relaunches the job on another node using the latest checkpoint; stateless jobs are requeued and redelivered. When providers exit voluntarily, workloads are given time to checkpoint before termination through configurable checkpointing grace periods.

The security model is framed as an improvement for containerization rather than as full virtualization. The paper explicitly mentions non-root execution, image attestation, SHA256 verification of container images, and a trusted allow-list of base images. These controls are layered on top of the Linux isolation primitives already used by the container runtime. This suggests a design that prioritizes lightweight deployment over VM-style isolation, while still attempting to reduce the risk surface associated with running third-party workloads on voluntarily contributed machines.

5. Empirical evaluation and reported outcomes

The evaluation is organized around campus deployment studies and resilience experiments. In the main campus network deployment, the system included 12 GPU services: 8 workstation servers each with one NVIDIA 3090, 1 server with 8×4090 GPUs, 1 server with 2×A100 GPUs, 1 server with 4×A6000 GPUs, and 1 CPU-only central coordinator. These machines had previously been managed manually, and GPUnion agents were added alongside existing tools to permit incremental adoption (Li et al., 25 Jul 2025).

In that deployment, average GPU utilization increased from 34% to 67% over six weeks. The abstract summarizes the result as 30% more GPU utilization improvement. The paper also reports that interactive debugging sessions increased by 40%, attributing this to improved access to temporarily idle GPUs and reduced manual coordination overhead. In a smaller lab scenario with 2 GPU servers and 6 total GPUs—2 A100 and 4 A6000—for 10 students and one faculty member, average GPU utilization rose from 67% to 81%, with the same reported 40% increase in interactive debugging sessions.

The resilience study used 20 deep learning training jobs, specifically PyTorch CNNs and transformers, distributed across 2 volunteer provider nodes over one week. Three interruption types were simulated: scheduled departure, emergency departure, and temporary unavailability, at frequencies from 0.5 to 3.2 events/day/node. For scheduled departures, 94% of workloads successfully migrated within the specified time with minimal data loss. For temporary unavailability, 67% of displaced workloads were migrated back to their original nodes after reconnection. Emergency departures limited work loss to approximately the checkpoint interval. Jobs experiencing 2–4 interruptions saw only 3%–7% increase in total training time, with the paper noting that memory-intensive models are more sensitive because checkpoint creation takes longer. Checkpoint traffic consumed less than 2% of available campus bandwidth at peak.

These results characterize GPUnion not merely as a scheduler but as a campus operational system whose measured benefits combine higher utilization, greater interactive access, and continuity under provider churn.

6. Position within the GPU-sharing landscape and stated limitations

GPUnion is explicitly formulated as an alternative to centralized, reservation-oriented, or VM-heavy systems. The paper argues that existing platforms optimize for centralized control or static reservations, whereas campus sharing requires autonomy, lightweight deployment, and resilience to churn (Li et al., 25 Jul 2025).

This positioning is important because it defines what GPUnion does not attempt to be. It is not a conventional campus Kubernetes deployment, because it does not assume stable nodes or centralized operational authority. It is not a Slurm-style reservation system, because providers may revoke access immediately. It is not primarily a VM-oriented IaaS platform, because the execution unit is an OCI container with GPU passthrough and relatively lightweight isolation. Its core novelty lies in combining provider supremacy with automatic checkpointing and migration so that voluntary participation does not require surrendering machine control.

The paper also states several future directions and one current limitation. Future work includes heterogeneous large-model deployment, especially model partitioning and layer placement for mixed GPU types; incentive mechanisms such as compute-time-based credits and auction or floating-rate schemes; user-transparent resource invocation through easier APIs; inter-campus federation; and pluggable scheduling for campus-specific policies. The stated current limitation is that users currently need to estimate their own resource requirements, which the paper describes as cumbersome and potentially harmful to efficiency.

Taken together, these limitations indicate that GPUnion is a deployment-oriented platform rather than a completed resource market or a fully automatic heterogeneous scheduling system. Its significance lies in demonstrating, within a campus network, that autonomous provider control and reliable GPU sharing are not mutually exclusive.