GPU Cluster Foundation
Jobs wait on one server while another sits idle
Service2 to 3 weeks, to be confirmed
GPU Cluster Foundation →Kubernetes and GPU operations made easy
Wave sizes, scales, and diagnoses your Kubernetes workloads inside your own cluster. Your team gets right-sized requests, replicas that follow traffic, and the cause of each failure, all in one console.
Without Wave
Each part works alone. Nobody sees the whole cluster.
~30s and ~31s from Wave feature pages. Pod and GPU counts are illustrative.
With Wave
One layer sees the whole cluster and acts on it.
~10s from the Autopilot feature page. Kubernetes icons: Kubernetes community, Apache-2.0.
Products
From everyday workloads to GPUs and AI infrastructure
Software
Wave GPU
Share one GPU across several workloads, with memory and priority set per pod.
Service
AI Infrastructure Professional Service
Engineers install, configure, and customize a GPU cluster, LLM serving, or a Run:ai platform on your GPUs.
Software
Wave
Size, scale, and diagnose Kubernetes workloads in one console.
Coming: Wave AI Agent (2026 Q4) · Learn more →
Where to get Wave
Install Wave from the marketplace you already use
Amazon EKSAWS MarketplaceNo license key. Free under 200 vCPUs, then billed through your AWS account.Start on Amazon EKS →
Red Hat OpenShiftRed Hat Ecosystem CatalogA Red Hat certified Helm chart with UBI-based images. Free under 200 vCPUs with a license key.Start on OpenShift →
Other KubernetesAKS, GKE, OKD, Rancher, and moreInstall from GHCR, or mirror the images for air-gapped clusters. Free under 200 vCPUs with a license key.Start on your cluster →GPU and AI infrastructure
Five GPU problems, and what we set up for each
Each one can be adopted alone, or set up together.
LLM Serving
The in-house LLM slows down as users grow
Service2 to 3 weeks, to be confirmed
LLM Serving →AI Platform (Run:ai)
Teams do not share GPUs or tools
Service2 to 3 weeks, to be confirmed
AI Platform (Run:ai) →HAMi Enterprise
A small job takes a whole GPU card
License3-week pilot first
HAMi Enterprise →Wave GPU
No one knows who uses which GPU
License3-week pilot first
Wave GPU →Not sure where to start?
Tell us about your GPU servers and main workloads.
Talk to usEnterprise challenges
Six problems you can check in your own cluster
Each card starts with a number from a named source. Open a card to see what Wave changes.
Wave Sizing
You pay for 10 CPU cores and use 1
Pods request far more than they use, and nobody knows which value is safe. Memory use averages 23%.
CAST AI, 2025 Kubernetes Cost Benchmark Report
Smart Sizing →Wave Diagnosis
The Pod restarts every 5 minutes, and kubectl get shows only CrashLoopBackOff
A high-impact Kubernetes outage takes a median of 51 minutes to resolve, and 39% take an hour or more.
kubernetes.io, Pod Lifecycle; Komodor, 2025 Enterprise Kubernetes Report
Pod / Container Failures →Platform & Observability
Which Pod serves /checkout? 6 kubectl lists to find out
Gateway, HTTPRoute, Service, EndpointSlice, Pod, and Node are separate lists. Engineers already spend 33% of their time addressing disruptions.
Kubernetes Gateway API and core API; New Relic, 2025 Observability Forecast
Cluster Map →Wave Karpenter
The new Pod sits in Pending for 31 seconds while a node starts
By default, Karpenter launches a node only after a Pod is Pending. In one Wave benchmark run, the first new Pod waited 31 seconds for the node and its image.
Wave 3.1.0 release post, one benchmark run, first new Pod
Node Warmup →Wave Autoscale
Logins peak at 9:00: HPA takes 30+ seconds to go from 10 to 80 Pods
You know the peak is coming, but HPA starts only after the load arrives, and it can at most double the pods every 15 seconds.
Calculated from the kubernetes.io HPA defaults, starting at 10 pods
Autopilot Scheduler →Wave Flow
A ticket sale opens, and traffic hits 4x the previous peak
Bots and fans without codes drove 3.5 billion requests, 4x Ticketmaster's previous peak.
Ticketmaster, Eras Tour presale, Nov 2022
Wave Flow →HOW IT WORKS
How Wave runs in your cluster
Wave reads metrics, logs, and Kubernetes state from every node, GPU nodes included. It decides what to change and applies the change through the Kubernetes API.
1 Read, 2 Decide, 3 Change. Every change goes through the Kubernetes API. GPU request changes wait for your approval.
Powered byWave GPUAutopilotSmart SizingKarpenterFlowDiagnosis
Trusted by Leading Organizations
Getting started
3 simple steps to production
Works on EKS, GKE, AKS, OpenShift, and self-managed Kubernetes 1.26+.
1
Request a license key
Free for clusters under 200 vCPU. Two install methods issue the key by email in seconds. The rest are answered by a person.
Request free key →2
Install via Helm
One values file with your key and storage class, one helm install. Air-gapped clusters supported.
$ helm repo add wave-autoscale-helm \ https://release.waveautoscale.io/helm-chart$ helm install wave-autoscale-helm \ wave-autoscale-helm/wave-autoscale-helm \ -f values-ghcr.yaml \ -n wave-autoscale --create-namespace
3
Open the console
Port-forward, sign in, and Wave starts auto-discovering workloads. Autopilot can run in observe-only mode first.
$ kubectl port-forward -n wave-autoscale \ svc/wave-autoscale-svc 3025:3025# open http://localhost:3025
Default login · admin / waveautoscale
FAQ
Common questions, clear answers
We already use HPA — why do we need this?
HPA only watches whether resource usage crosses a threshold, not how your workload actually performs. Wave Autopilot uses ML-based workload performance modeling to reach scaling decisions in about 10 seconds — roughly 2× faster than HPA, without threshold tuning.
Isn't KEDA the same thing?
No. KEDA specializes in event-driven workloads (Kafka, queues) — a different objective. KEDA complements HPA and Wave Autopilot rather than replacing them. Wave Autopilot scales long-running services based on workload performance, which is a separate problem.
How is this different from VPA for resource sizing?
VPA uses CPU percentile statistics alone, so a fixed CPU allocation can't adapt to sporadic request surges. Wave Smart Sizing factors in both CPU percentiles and real-time workload demand, maintaining optimal success rates — for example allocating 2.0 cores instead of 1.5 when bursts demand it.
Does Wave Flow replace Istio?
No. Wave Flow runs on top of Istio — adding priority shaping, a virtual waiting room, and visibility through Envoy filters and control-plane extensions. Your existing Istio mesh is untouched; Wave Flow makes overload behavior graceful instead of treating every request equally.
We use Karpenter already. What does Wave Karpenter add?
Three things. Karpenter Dashboard shows nodes, cost per hour, Spot ratio, and thrashing for each NodePool in Wave Console. Node Warmup starts a node before the next Pod needs one: in one Wave benchmark run, the first new Pod was ready in 3 seconds instead of 31. Spot Workload Placement keeps Pods up to a threshold on On-Demand and puts the rest on Spot, by replica number, with no change to your YAML.
We already have Grafana — why Wave Diagnosis?
Grafana shows you the metrics, but you still have to guess what's wrong. Threshold alerts miss slowly-progressing issues until they become incidents. Wave Diagnosis ships with five ML diagnostics — cluster resource forecasting (7–60 days out), memory leak detection, CPU utilization analysis, pod scheduling delay detection, and idle node detection — so you can shift from reactive to proactive operations.
Will this work in our air-gapped or on-prem environment?
Yes. Wave runs entirely inside your cluster with no external dependencies. Air-gapped environments are fully supported, including private container registries. Wave is an AWS EKS Service Ready Partner and a Red Hat Certified Partner, and also runs on bare-metal Kubernetes.
Ready to operate Kubernetes the right way?
Start with a free Smart Sizing Report on your own cluster. No credit card. White-glove onboarding included.