Solutions · HPC clusters
Put Supercomputing Capacity on the Marketplace
HPC clusters are among the most valuable compute assets in existence, and most run with idle cycles. VirtEngine's HPC module brings scheduler-backed batch capacity into the marketplace natively — your SLURM, MOAB, or Open OnDemand cluster stays exactly as it is.
Who this is for: University, national-lab, and commercial HPC facilities running batch schedulers.
At a glance
The short version for hpc clusters
-
Integration
No re-platforming the cluster
Native adapters for SLURM, MOAB, and Open OnDemand — your scheduler, partitions, and auth stay exactly as they are.
-
Model
A job marketplace, not a container shim
On-chain HPC jobs carry resource, walltime, and partition requirements — batch work expressed natively, priced through the same exchange.
-
Payout
Standard settlement rails
HPC usage flows into the usual pipeline: signed records, 24-hour dispute window, escrow release. Finance sees settled payments, not a new billing system.
The problem
The problem: batch capacity doesn't fit cloud leases
HPC operates on jobs, allocations, partitions, and walltime — not long-running container leases. Generic cloud marketplaces can't express that model, so cluster operators wanting to monetize spare cycles have had no marketplace that speaks their language.
External users, meanwhile, face months-long allocation processes to access supercomputing capacity that may be idling right now.
In one view
Audience-specific visual
Each solution gets its own explanatory figure — not the same template art.
- Queue: gpu — 14 pending
- VirtEngine job → scheduler submission
- Local policy unchanged
- HPC guide →
The mechanism
How the protocol carries it
How VirtEngine addresses it
Grounded in what the protocol actually does
A job marketplace, not a container shim
The x/hpc module models batch work natively: on-chain HPC jobs with resource, walltime, and partition requirements, offered and priced through the same exchange economics as the rest of the marketplace.
Native scheduler adapters
The provider daemon's HPC integration speaks to your existing controller — munge or JWT auth for SLURM, per-partition configuration — and executes on-chain jobs on your cluster with configurable concurrency limits, timeouts, and crash-safe state recovery.
- SLURM adapter with munge/JWT authentication and per-partition configuration
- MOAB and Open OnDemand adapters for existing deployments
- Job lifecycle service with polling, dispatch, tracking, and recovery
- Dedicated audit log for job events, security events, and usage
Same settlement rails as everything else
HPC usage batches flow into the standard usage-settlement pipeline: signed records, 24-hour dispute window, escrow release. Your finance office sees settled payments, not a new billing system to run.
How it works
The path through the protocol, step by step
Select each step — the panel walks the sequence in order, from first action to settled outcome.
Step 1 · Review
Review the HPC provider docs
The HPC provider operations documentation covers the full operational model — adapters, auth, concurrency, and recovery.
Step 2 · Register
Register as a provider
Declare HPC attributes on-chain: scheduler type, partitions, and hardware.
Step 3 · Connect
Configure the scheduler adapter
Connect the daemon's adapter to your controller with munge or JWT auth, per-partition configuration, concurrency limits, and timeouts.
Step 4 · Expose
Expose partitions
Choose which partitions and job classes the marketplace may schedule into — primary allocations stay untouched.
Step 5 · Settle
Serve jobs and settle
On-chain jobs dispatch through your scheduler with crash-safe recovery; usage settles from tenant escrow.
Economics
Economics
Jobs are paid from tenant escrow like any lease, at the full agreed amount. Facilities set their own pricing per partition and job class — spare-cycle monetization at prices you control, without disturbing allocation commitments to primary users. Validator transaction fees apply only to chain operations.
Getting started
The path in
-
Review the HPC provider docs
docs/hpc-provider-operations.md covers the full operational model.
-
Register as a provider
Declare HPC attributes — scheduler type, partitions, hardware — on-chain.
-
Configure the HPC integration
Connect the daemon's scheduler adapter to your controller with munge or JWT auth.
-
Expose partitions
Choose which partitions and job classes the marketplace may schedule into.
-
Serve jobs and settle
On-chain jobs dispatch through your scheduler; usage settles from escrow.
Questions
Asked about hpc clusters
Which schedulers are supported?
SLURM with munge or JWT authentication and per-partition configuration, plus MOAB and Open OnDemand adapters for existing deployments. A job lifecycle service handles polling, dispatch, tracking, and recovery, with a dedicated audit log for job and security events.
How are HPC jobs priced?
Facilities set their own pricing per partition and job class, offered through the same exchange economics as the rest of the marketplace. Jobs are paid from tenant escrow like any lease, at the full agreed amount.
Will marketplace jobs disturb our primary allocations?
Only the partitions and job classes you expose are schedulable from the market. Allocation commitments to primary users stay under your scheduler's control; the marketplace sees spare cycles, nothing more.
Related
Continue from here
More solutions