Drawn from live demos and sales calls with platform engineers and CTOs at GPU-heavy companies.
Noisy-neighbor isolation is enforced at the scheduler level, not by hope. GPUForge's scheduler runs a tenant-quota check on every cycle (every 30 seconds): for each job, gpu_in_use + gpu_count ≤ gpu_quota is evaluated against the tenant's quota, and jobs that fail the check stay queued or flip to blocked with block_reason = quota rather than stealing capacity from another tenant. The full quota-enforcement flow, atomic-allocation guarantees, and per-tenant alarm thresholds (including the quota_breach warning at >90%) are documented in the architecture overview, which walks the production stack and explains where the boundary is enforced.
GPUForge targets three surfaces — EKS on AWS, GKE on GCP, and on-prem bare metal / VM with SLURM — and the same control plane runs across all three. Our deployment research walks the trade-offs side-by-side, including price-per-hour on each, GPU availability and quota lead times (especially for H100 / p5), SLURM+K8s fit, air-gapped fit, and egress. Pick EKS when your data lives in AWS, GKE when GCP-native services are central, and on-prem when data sovereignty or air-gap is a hard requirement. Read the full comparison in the deployment insights page.
Costs on the deployment surface you choose are visible end-to-end. On managed Kubernetes (EKS / GKE), per-GB egress is billed by the cloud provider after a monthly free tier — cloud-to-same-region or cross-AZ is commonly free, cross-region is not, and cloud-to-cloud traffic to another provider bills at that provider's internet-egress rate. On on-prem, zero egress — every byte of telemetry, dataset, and checkpoint stays inside the customer network. The comparison table sets all of this out explicitly across the three surfaces. For the full DIY-vs-GPUForge pricing breakdown, see our H100 vs H200 TCO comparison.
The support surface is the same as the operations surface: alerting with hysteresis and deduplication is documented in the HLD, the horizontal-scale ceiling is published (~50 operators, ~200 tenants, ~10,000 GPUs per instance before a service split is needed), and the production auth roadmap (SSO/SAML for operators, JWT-based tenant auth, RBAC with per-tenant scopes, OAuth2 for cloud-provider creds) is laid out alongside the rest of the operational design. Everything we promise operationally is in writing there — not in a marketing deck.
Yes — the low-level design is the authoritative source. The LLD covers the full security model: hashed API keys (SHA-256 of the raw key, hex, stored with revoked_at IS NULL; the raw key is returned once at creation and never persisted), the auth middleware chain in server.js, the session model, and the row-level constraints that bind roles to endpoints. Every endpoint's authentication requirement (Auth: required / Auth: optional / Auth: none) is annotated on the API page.