Three runnable surfaces — managed Kubernetes on GCP, managed Kubernetes on AWS, or on-prem bare-metal/VM — each with different trade-offs around pricing, GPU availability, quota lead times, scheduler fit, and data sovereignty. This page distills the research we did before shipping our V1 demo so evaluators can pick with eyes open.
Pricing, GPU availability, quota lead times, SLURM + K8s fit, air-gapped fit, and egress — sourced from our V1 deployment research (kubernetes-deployment.md, devops-guide.html).
| Dimension | GKE (GCP) | EKS (AWS) | On-prem (bare metal / VM) |
|---|---|---|---|
| Pricing tiers | On-demand per-second billing on A2 / G2 families; committed-use discounts (1- and 3-year) up to ~57% on GPUs; spot (preemptible) pricing exists but historically thinner spot market than AWS for H100. | On-demand per-hour billing on g4dn, p4d, p5 families (e.g. g4dn.xlarge $0.526/hr; p4d.24xlarge $32.77/hr; p5.48xlarge $98.32/hr); Savings Plans up to ~40%; spot floor ~$0.157/hr on T4 and ~$9.83/hr on A100. |
Capex — hardware amortization + power + cooling + colo/space. $/hr is operator-defined and stable across the hardware's life; no spot/preemptible market. |
| GPU availability | T4 / A100 / H100 generally available on-demand; H100 capacity in some regions requires quota increase or committed-use reservation. Lead times for new instance types measured in weeks to a few months. | T4 and A100 broadly on-demand; p5.48xlarge (H100) is not generally available on the spot market — capacity must be reserved via EC2 Capacity Blocks for ML. Lead times on new H100 capacity blocks: weeks to months. |
Whatever you buy or lease. H100 procurement historically runs 3–9 months from order; A100 / L40S generally faster. No capacity-block requirement. |
| Quota lead times | GCP quota increase for GPU families handled in-console; typical turn-around is a few business days for small bumps, longer for region+SKU-specific increases. | AWS quota increase for instance-type/vCPU counts submitted via Service Quotas console; turn-around for GPU quotas is days to weeks depending on account history. EC2 Capacity Blocks for ML require a separate reservation request. | No cloud quota — but hardware procurement is the analog. Lead times dominated by supplier (NVIDIA / OEM / integrator) and can be months for H100. |
| SLURM + K8s fit | GKE + NVIDIA GPU Operator; SLURM is third-party and not a first-class citizen. Customers running SLURM typically do it on GCE VMs (not GKE), mirroring an on-prem SLURM cluster. | EKS + NVIDIA GPU Operator (Helm, pinned v26.3.3 in our guide) — first-class fit. SLURM as primary scheduler is out of scope for our EKS reference; customers run SLURM on EC2 parallel to the cluster when needed. |
SLURM is the natural primary scheduler for single-server V1 deployments — Docker Compose stack with slurmctld and slurmd containers. Kubernetes is deliberately not part of V1; K8s adds operational complexity without benefit on a single-server install. |
| Air-gapped fit | Not supported out of the box; GPU Operator pulls NVIDIA container images at install time. Disconnected installs require an internal mirror and image allowlist — typically out of scope for managed-GKE reference architectures. | Explicitly out of scope in our EKS guide: air-gapped installs, OpenShift, on-prem Kubernetes, GCP/Azure GPU node types are listed as out of scope. EKS itself is internet-coupled; air-gapped GPU Operators require a private OCI mirror plus AL2023 AMI bundling. | Air-gap is the default. The V1 on-prem stack pulls images once into a local registry and never reaches the public internet. Regulated workloads (gov, finance, healthcare, defense) are the canonical fit. |
| Egress | GCP-to-internet egress billed per GB after a monthly free tier. GCP-to-GCP in same region is free; cross-region is not. | AWS-to-internet egress billed per GB (tiered). Cross-AZ traffic is free; cross-region is not. Cloud-to-cloud traffic to GCP or Azure bills at the respective provider's internet egress rate. | Zero egress. Every byte of telemetry, dataset, and checkpoint stays inside the customer network. |
For platform engineers and CTOs at GPU-heavy companies — the audience GPUForge is built for — the choice usually comes down to one question: where does the data already live?
Your fleet lives in AWS already and you want a managed control plane without owning the etcd tier.
eksctl create cluster to running pod in < 1 hourYou want managed Kubernetes plus tight integration with GCP-native data and ML services.
Data sovereignty, predictable $/hr, or existing SLURM investment make the cloud a poor fit.