Infrastructure

Three GPU Runtime Pools

ResonTech exposes three distinct GPU execution environments. Each serves a different workload profile, with a consistent API surface across all three — resontech submit and resontech infer work identically regardless of which pool you target.

Shared Pool (Public Pool)

Multi-tenant GPU pool. Instant provisioning.

Jobs are routed to any available GPU node in the shared network. Each job runs in its own Kubernetes namespace with strict workload isolation — other tenants cannot observe or interfere with your workload. Ephemeral compute: no persistent state between jobs.

How it works

• Submit a job → Coordinator selects the N best available nodes in real time
• Dispatcher provisions a dedicated K8s namespace and network policies
• Cold start under 60 seconds from submission to first training step
• Cluster is torn down immediately after job completion or cancellation
• Inference endpoints scale to zero between requests — no idle GPU cost

Billing

Pay-as-you-go for actual GPU time used, from job start to job end. Zero idle cost between runs. Inference endpoints scale to zero — billing stops when no requests are in flight.

Best for

• Experiments, prototyping, hyperparameter sweeps
• One-off training runs and bursty research workloads
• Teams without predictable GPU demand
• Getting started without infrastructure commitment

Managed Cluster (Dedicated)

Reserved nodes. Isolated kernel. Production SLA.

Nodes reserved exclusively for your organization. An isolated job kernel with persistent node state between jobs. Custom GPU configurations available with topology-aware placement. No queue contention with other teams — your jobs always run immediately on your reserved capacity.

How it works

• Reserved GPU nodes are allocated exclusively to your organization
• A dedicated kernel instance manages job scheduling within your cluster
• Node state can persist between jobs (pre-loaded CUDA environment, warm model caches)
• Topology-aware placement: multi-node jobs placed on nodes with NVLink or InfiniBand interconnects
• Priority queue: managed cluster jobs always preempt shared pool jobs for the same hardware

SLA

• 99.9% uptime on reserved node availability
• Priority queue access — no waiting behind shared pool jobs
• Dedicated support channel and account manager

Best for

• Production training pipelines with predictable GPU demand
• Continuous model retraining on a schedule
• Inference serving at production scale with uptime guarantees
• Teams that need consistent performance without queue variability

Private Cluster (Sovereign Mode)

Your hardware. Your data. Your compliance team won't complain.

The ResonTech worker agent is installed on your existing GPU nodes. The kernel runs entirely within your network perimeter. Zero data egress — compute and storage stay local. Air-gapped mode is available: no inbound internet required after initial setup.

How it works

• Install the ResonTech worker agent (Docker container) on your GPU nodes
• Agents register with your private Coordinator instance, deployed within your perimeter
• The kernel orchestrates jobs across your nodes — same API, same dashboard
• Training data never leaves your network — workers access local storage directly
• In air-gap mode: after initial deployment, no external internet connectivity required

Compliance

• HIPAA, SOC 2, GDPR, DORA configurations available
• Full RBAC and SSO integration with your identity provider
• Complete audit logs for all job submissions, data access, and model outputs
• Data residency: compute and storage remain within your jurisdiction

Best for

• Organizations with strict data residency or sovereignty requirements
• Healthcare, finance, defense, and government ML teams
• Enterprises with existing GPU fleets that want orchestration without migration
• Teams training on sensitive data (PII, PHI, proprietary datasets)

NVIDIA FLARE Architecture

ResonTech uses NVIDIA FLARE (NVFlare) as the production-grade distributed training framework for federated learning workloads. It manages all execution on the GPU cluster provisioned by the Dispatcher.

Why federated learning?

• Privacy by architecture — Data shards stay on individual worker nodes. Only model weights travel between nodes and the aggregation server.
• Heterogeneous hardware compatibility — Federated learning's round-based communication model is tolerant of heterogeneous hardware and variable network quality.
• Enterprise & regulatory compliance — Training on sensitive data is only possible if that data never moves. The federated paradigm satisfies strict data residency requirements.

FLARE concepts in ResonTech

Training round sequence

• FL Server starts → CustomPersistor instantiates the model (e.g., ImageNet pretrained backbone)
• Server sends initial weights to all FL clients via gRPC
• Each client calls fl_train_model(payload, ...) with the global weights
• Each client trains locally on its shard for N local epochs
• Each client returns updated weights + sample count
• Server aggregates all updates (FedAvg) → saves new global model → begins next round

Kubernetes Isolation & Security

Each training job and inference endpoint runs in its own isolated Kubernetes environment. Per-job isolation provides strong security boundaries and resource guarantees.

• Dedicated Kubernetes namespace per job — no resource sharing with other jobs
• Network policies enforce zero cross-namespace traffic
• Resource quotas prevent runaway jobs from starving other workloads
• Cluster teardown is automatic after job completion — no orphaned pods
• Client data stays in client workspace — only encrypted gradients cross boundaries

Communication architecture

Performance Characteristics

Hardware Requirements (GPU Providers)

GPU providers join the network by installing the ResonTech worker agent. Supported hardware spans all NVIDIA GPU generations — from GTX 1080 Ti gaming cards to H100 data center nodes.

Provider availability tiers