Ephemeral Hardware Leasing: GPUs, SSD Pools & RISC‑V

Orchestrate on-demand GPUs, NVLink groups, SSD pools and RISC‑V nodes with time-boxed leases to cut cost and stabilize performance tests.

Hook: Stop wasting cloud budget on long-running test VMs — lease real hardware just-in-time

If your team is running expensive performance tests on GPUs or fast NVMe racks and those resources sit idle between runs, you know the pain: unpredictable cloud bills, flaky CI feedback, and complicated test setup that slows releases. In 2026, with hybrid racks (NVLink Fusion connecting RISC-V CPUs to NVIDIA GPUs) and cheaper PLC-derived SSD capacity entering the market, the opportunity to run ephemeral hardware tests on demand is real — but you need robust orchestration patterns to do it safely, repeatably, and cost-efficiently.

Why ephemeral physical hardware leases matter in 2026

Late 2025 and early 2026 brought two important trends that change how teams should approach hardware-based testing:

Heterogeneous topology growth: SiFive announced integration with NVIDIA's NVLink Fusion (Forbes, Jan 2026), meaning RISC-V nodes will increasingly sit next to GPUs with coherent interconnects. Tests that must validate GPU+CPU communication now require topology-aware placement.
More SSD capacity and specialization: Memory and SSD supply improvements (SK Hynix PLC advancements, 2025) and NVMe-oF improvements make it viable to host high-performance ephemeral SSD pools for I/O-heavy benchmarks without owning the full capacity year-round.

These shifts make it practical — and necessary — to orchestrate ephemeral physical resources: GPUs (including NVLink groups), fast local SSD pools, and emerging RISC-V nodes for hardware-in-loop tests.

High-level orchestration pattern: Lease → Bind → Use → Release

Every orchestration model for ephemeral physical hardware should implement four clear phases:

Lease: Reserve a resource slice for a bounded time window.
Bind: Make the resource discoverable and attach it to the test environment.
Use: Run tests; monitor health and usage metrics.
Release: Tear down, flush state, and return the resource to the pool.

Core components of the system

Lease Service (REST/gRPC): authorizes, issues and revokes time-bound leases.
Resource Broker: maps logical requirements (e.g., 2x A100 with NVLink) to physical nodes/topologies.
Node Agent (per-rack): performs attach/detach, exposes device plugins, manages SSD pool mounts.
Scheduler Plugin: integrates with your CI/CD system (GitHub Actions, Tekton, Jenkins) to request leases as pipeline steps.
Monitoring & Cost Engine: tracks utilization, lease durations, and cost allocations for chargebacks.

Pattern 1: Topology-aware GPU leasing (NVLink and MIG)

GPU-based performance tests are expensive and often require tight coupling — for example, NVLink-connected pairs or NVSwitch domains. Mis-allocating GPU devices can yield huge variance in benchmark results. Use these practices:

Advertise topology metadata: Node Agents must report GPU topology (NVLink groups, NUMA nodes, MIG instances) to the Resource Broker.
Require a topology contract: Tests declare requirements like "NVLink group with 4 GPUs" or "two GPUs with NVLink and local 2TB NVMe"; the broker returns matching allocations.
MIG & isolation: For lower-cost runs, prefer NVIDIA MIG slices. For full isolation and peak throughput, lease whole GPUs that include NVLink paths.
Pre-warm & run-book: Include pre-warm steps (CUDA cache, memory pinning) as part of the lease use window; benchmark warm-up reduces noise.

Example: Lease API call (simplified)

POST /v1/leases
{
  "resource_type": "gpu",
  "topology": {
    "nvlink_group": 1,
    "min_gpus": 2,
    "modes": ["mig", "full"]
  },
  "duration_minutes": 45,
  "tags": ["perf-test", "CI-42"]
}

Response:
{
  "lease_id": "lease-9f2a",
  "node": "rack-12-node-03",
  "devices": ["GPU0", "GPU1"],
  "expires_at": "2026-01-18T14:23:00Z"
}

Kubernetes-aware binding

If you run tests inside Kubernetes, the controller should inject a lease ID and node affinity so the Pod runs on the leased node and uses device plugin resources:

apiVersion: v1
kind: Pod
metadata:
  name: gpu-perf-test
  annotations:
    lease-id: "lease-9f2a"
spec:
  nodeSelector:
    leased-node: "rack-12-node-03"
  containers:
  - name: test
    image: myorg/perf-bench:latest
    resources:
      limits:
        nvidia.com/gpu: 2

Pattern 2: Ephemeral SSD pools (local NVMe, NVMe-oF)

IO-bound tests must reproduce high-throughput, low-latency storage conditions. Ephemeral SSD pools let you create fast, short-lived storage environments without owning excess capacity. Two common approaches:

Local ephemeral NVMe: attach local NVMe to test nodes and format+mount during lease; fastest but limited capacity.
NVMe over Fabrics (NVMe-oF): present remote volumes from a pool (thin-provisioned) across the rack; more flexible and shareable.

Operational steps for SSD pool leases

Broker picks a pool with required bandwidth and latency SLAs.
Node Agent receives a request to map an iSCSI/NVMe-oF target to the leased node.
InitContainer on the test Pod runs formatting, FIO warm-up patterns, and snapshot creation (if needed).
On release, the pool is zeroed (or snapshotted and scrubbed) and reclaimed.

Example NVMe-oF attach script (initContainer)

#!/bin/bash
set -e
# attach NVMe-oF target published by Node Agent
nvme connect -t tcp -n nqn.2026-01.io.pool:target -a ${POOL_IP} -s ${POOL_PORT}
mkfs.ext4 /dev/nvme0n1
mount /dev/nvme0n1 /mnt/fast
# optional: warm up with fio
fio --name=warm --filename=/mnt/fast/testfile --bs=1m --size=1G --rw=write --numjobs=4

Pattern 3: Leasing RISC-V nodes for ISA-sensitive tests

RISC-V silicon is becoming production-ready for many workloads. With SiFive and NVIDIA NVLink Fusion (2026), teams will need to validate system-level behaviors on RISC-V + GPU topologies. Key practices:

Cross-architecture build artifacts: Build pipelines must produce RISC-V compatible binaries or container images. Use multi-arch manifests or QEMU in CI for small unit tests, but run performance tests on native RISC-V hardware.
Topology contracts: For NVLink-connected RISC-V nodes, include both CPU ISA and NVLink group in the lease constraints.
Firmware & BIOS versioning: Because ISA-level behavior can change between firmware revisions, include firmware version pins in the lease metadata and fail allocations if the firmware diverges.

Sample lease request for RISC-V + GPU

POST /v1/leases
{
  "resource_type": "heterogeneous",
  "requirements": {
    "cpu_arch": "riscv64",
    "gpu_nvlink": true,
    "min_gpus": 1
  },
  "duration_minutes": 60
}

Cost-control and backfill strategies

Controlling cost with physical hardware pools means maximizing utilization while preventing long-held leases. Use these strategies:

Time-boxed leases: Default leases to short durations (e.g., 30–60 minutes) with renewals requiring explicit reauthorization. Enforce hard cutoffs.
Preemption & graceful eviction: Support a preemption signal so a longer-priority job can request a resource and the current lease gets a short eviction window (e.g., 2–5 minutes) to upload logs and health dumps.
Backfilling: Allow micro-tests to backfill small idle intervals between heavy leases. The broker should pack workloads into leftover time windows. Smaller tests can run as batch jobs when they fit into a remaining lease span.
Spot pricing & incentives: If you run hybrid cloud+on-prem, treat on-prem resources as fixed cost and cloud GPUs as spot/preemptible capacity; allocate non-critical loads to spot instances with fallbacks.
Telemetry-driven capacity planning: Use observed lease utilization and test queue waiting times to justify adding or shrinking hardware racks.

Monitoring & chargebacks

Expose metrics for:

Lease utilization rate (per hour/day/week)
Average idle time after release
Cost per test run and cost per percentile of runs

Integrate these metrics with Prometheus and Grafana and feed the cost data to a chargeback pipeline to tag team budgets.

Practical CI/CD integration recipes

Make the lease lifecycle part of your pipeline as an explicit step. Example patterns:

1) Pipeline-first lease

Request a lease at the start of a pipeline stage. If the lease fails, skip the stage (or run in emulation mode).

2) Job-scoped lease

For short tests, have the job request and immediately bind the lease. When the job completes or fails, the pipeline step calls the release API in a finally/failure block.

3) Warm pool workers

Maintain a small number of warm workers (pre-warmed nodes) that are charged at low allocation rates. Use them to reduce cold-start variance, but keep them capped.

Sample GitHub Actions step (job-scoped)

- name: Request hardware lease
  id: lease
  run: |
    resp=$(curl -s -X POST $LEASE_API/v1/leases -d '{"resource_type":"gpu","min_gpus":1,"duration_minutes":30}')
    echo "lease_id=$(echo $resp | jq -r '.lease_id')" >> $GITHUB_OUTPUT

- name: Run perf test
  if: steps.lease.outputs.lease_id != ''
  run: |
    export LEASE_ID=${{ steps.lease.outputs.lease_id }}
    ./run_perf.sh --lease $LEASE_ID
  continue-on-error: false

- name: Release lease
  if: always()
  run: |
    curl -X POST $LEASE_API/v1/leases/${{ steps.lease.outputs.lease_id }}/release

Health, safety, and reproducibility concerns

Physical resources require extra safeguards:

Automated health checks: Node Agent runs pre-lease diagnostics; fail loudly if thermal thresholds, ECC errors, or NVMe SMART alerts are present.
Immutable images and environment snapshots: Use image pins and runtime environment snapshots (container image digest + kernel/driver versions) to ensure reproducibility of benchmarks.
Test artifacts & provenance: Store logs, hardware topology, and driver/firmware versions with every test run to make results auditable.

"Topology, firmware, and storage semantics are as critical as code when you run hardware-level performance tests — and you must version them."

Failure modes and mitigation patterns

Lease expiration during TTL-sensitive runs: Implement soft-extend with a limit and require human approval for long extensions.
Node failure mid-run: Run test checkpoints and periodic state uploads to object storage so that interrupted long tests can be resumed or analyzed.
Resource fragmentation: Use compaction jobs that temporarily evict low-priority workloads and consolidate free capacity during low-traffic windows (nightly).

Implementation checklist (step-by-step)

Follow these to implement ephemeral hardware leasing in your organization:

Inventory hardware and capture metadata: CPU ISA, GPU topology, NVMe capacity, firmware versions.
Design the Lease API and Resource Broker. Start small (GPU-only) and add SSD pools and RISC-V later.
Implement Node Agent: expose device plugins and attachments for NVMe-oF and PCIe passthrough.
Integrate with your CI/CD and create pre-warm init steps to stabilise benchmarks.
Add monitoring, cost accounting and an eviction/preemption policy.
Create run-book and SLAs for rare human interventions (e.g., hardware maintenance, firmware updates).

Case study (hypothetical, practical)

AcmeAI runs nightly model training validation that requires two NVLink-connected A100 GPUs and a 4TB local NVMe scratch. Previously, they reserved a dedicated machine 24/7. After adopting ephemeral leasing:

They scaled to 10x more validation runs per week because hardware was available to more teams.
Average GPU idle time dropped from 18 hours/day to 2 hours/day.
Cost per validation run dropped 45% due to time-boxed leases and backfilling.
Test variance decreased after they enforced topology contracts and firmware pins.

Security considerations

Physical resource reuse carries security risks. Address them with:

Automatic disk scrubbing or re-imaging between leases for storage devices.
Hardware attestation and secure boot enforcement for RISC-V nodes used in safety-critical verification.
Least-privilege for service accounts that can issue or extend leases.

Trends to watch in 2026 and beyond

NVLink Fusion & RISC-V adoption: As SiFive’s NVLink work matures, expect more hybrid racks requiring topology-aware orchestration for reproducible GPU+CPU tests (Forbes, 2026).
SSD economics: PLC and denser flash will keep making high-throughput ephemeral SSDs cheaper; orchestration will tilt to NVMe-oF-based shared pools (2026).
Standardized lease semantics: Expect tools and standards to emerge around resource lease primitives (start, heartbeat, graceful-evict, snapshot), similar to existing cloud spot/interrupt semantics.

Actionable takeaways

Start with a minimal Lease Service that supports time-boxed leases and topology metadata.
Instrument every lease with telemetry — utilization and cost — to drive capacity decisions.
Use MIG and NVMe-oF to lower per-test cost and increase multiplexing of scarce physical hardware.
For RISC-V + GPU tests, pin firmware and driver versions in the lease metadata to ensure reproducible results.
Integrate lease request/release steps directly into CI pipelines, and treat pre-warm + post-teardown as mandatory steps.

Call to action

If you manage test infrastructure and want a pragmatic next step, run a two-week pilot: implement a Lease Service for one rack (GPU-only), integrate it into a single CI job, and track utilization and cost. Need a starting template or guidance? Contact our team at mytest.cloud for a hands-on workshop that includes a reference Lease API, Node Agent template, and CI integration examples — and get your first pilot ready in under 5 working days.