Three Cluster Types
ResonTech provides three execution modes — same API surface, fundamentally different architecture and guarantees. Choose based on isolation requirements, data residency, and commitment level.
Public Pool
Shared · multi-tenant · ephemeral. Jobs route to any available GPU node in the network. Strict workload isolation, FIFO queue with configurable priority lanes. The node is wiped clean after job completion.
- Jobs routed to any available GPU node in the network
- Multi-tenant with strict workload isolation
- Ephemeral compute — no persistent state between jobs
- Node capacity reported in real-time by the kernel
- FIFO queue with configurable priority lanes
Data flow: Workers pull training data and scripts from your S3 bucket at job start. Outputs are written back to your bucket. The node is wiped clean after job completion.
Managed Cluster
Dedicated · reserved · persistent. Nodes reserved exclusively for your organization. No job queue contention. Persistent volumes survive between jobs — checkpoints accumulate across runs.
- Nodes reserved exclusively for your organization
- No job queue contention with other teams
- Persistent node state between jobs (optional)
- Custom GPU configurations available
- Kernel aware of your specific hardware topology
Data flow: Workers pull from your S3 bucket. Checkpoints accumulate across runs and are written back to your bucket. Your cluster has a dedicated network segment.
Private Cluster
Sovereign · air-gapped · on-prem. ResonTech worker installed on your existing GPU nodes. The kernel runs entirely within your network perimeter — zero data egress, air-gapped mode available.
- ResonTech worker installed on your existing GPU nodes
- Kernel runs entirely within your network perimeter
- Zero data egress — compute and storage stays local
- Air-gapped mode: no inbound internet required after setup
- Your nodes join as a private pool visible only to your org
Data flow: Jobs never route outside your declared nodes. Training data, weights, and artifacts never leave your infrastructure. ResonTech only receives job telemetry — never data content.
| Feature | Public Pool | Managed Cluster | Private Cluster |
|---|---|---|---|
| Data stays on your infra | ✗ | ◑ | ✓ |
| Dedicated capacity | ✗ | ✓ | ✓ |
| No queue contention | ✗ | ✓ | ✓ |
| Custom GPU config | ✗ | ✓ | ✓ |
| Air-gapped mode | ✗ | ✗ | ✓ |
How the Network Aggregates Compute
GPU capacity is aggregated across a distributed network — better availability, broader hardware diversity, no single vendor lock-in. The kernel manages job routing from submission to completion.
| Step | What happens |
|---|---|
| Nodes Register | GPU suppliers install the ResonTech worker. It reports GPU specs, VRAM, network speed, and availability to the kernel. |
| Smart Matching | When a job is submitted, the kernel matches it to optimal nodes — by GPU type, locality, bandwidth, and current load. |
| Distributed Execution | Large jobs are split across multiple nodes. Data is sharded. Workers communicate via high-bandwidth interconnects. |
| Self-Healing | Heartbeat monitoring detects node failure in seconds. Jobs reschedule automatically to healthy nodes, resuming from checkpoint. |
Performance Characteristics
Four kernel-level optimizations drive throughput and recovery performance.
| Optimization | How it works | Result |
|---|---|---|
| Multi-node automatic distribution | Submit with a GPU count and the kernel splits your job across nodes automatically — no manual NCCL setup, no rank configuration. | 8× throughput gain |
| Topology-aware scheduling | Multi-node jobs are placed on nodes with high-bandwidth interconnects — NVLink, InfiniBand. Slower nodes picked last. | < 15s node selection |
| Data sharding | Your dataset is automatically sharded across worker nodes at job start. Workers pull their shard directly from your bucket in parallel. | 3× data throughput |
| Checkpoint-aware recovery | Node failure triggers automatic rescheduling. Job resumes from last checkpoint — not epoch 0. Zero lost compute. | 100% recovery success |
Kernel Intelligence Features
| Feature | Description |
|---|---|
| GPU affinity routing | Jobs requesting specific GPU types are routed to matching nodes first |
| Topology-aware placement | Multi-node jobs prefer nodes with NVLink or InfiniBand interconnects |
| Preemption + recovery | Lower-priority jobs yield to high-priority ones; they resume from checkpoint |
| Elastic scaling | Inference endpoints scale replicas up/down based on request throughput |
| Spot reclamation handling | Reclaimed spot nodes trigger automatic rescheduling, not failure |
| Cost-aware scheduling | Kernel can prefer cheaper nodes when latency is not the constraint |
Becoming a Supplier
Have idle GPUs? Install the ResonTech worker and your nodes join the distributed GPU pool, running real ML workloads for users on the platform.
| Step | What to do |
|---|---|
| 01 · Register | Sign up as a GPU supplier. Provide hardware specs, location, and availability windows. |
| 02 · Install | One-line install of the ResonTech node worker. It registers your GPU into the network and handles job routing. |
| 03 · Configure | Define GPU availability windows and resource allocation. The kernel registers your node capacity and factors it into job routing. |
| 04 · Monitor | Jobs route to your hardware automatically. Full dashboard visibility into node utilization, job history, and resource metrics. |
Hardware Requirements
Requirements for running jobs on the network and for supplying GPUs to the network.
| Component | Minimum | Recommended |
|---|---|---|
| GPU | GTX 1080 Ti | RTX 3090 / A100 |
| VRAM | 8 GB | 24 GB+ |
| RAM | 32 GB | 128 GB+ |
| Storage | 100 GB NVMe | 200 GB NVMe |
| Network | 100 Mbps | 10 Gbps (for multi-node) |
| OS | Ubuntu 20.04 | Ubuntu 22.04 |