🚀 Wave Autoscale 3.2.0: GPU-Aware Autoscaling and OpenShift Support

Author: Hwansoo Kim (opens in a new tab)
Date: April 29, 2026

TL;DR: Wave Autoscale 3.2.0 closes two real cost-and-coverage gaps from the 3.x line. GPU workloads now have a full optimization stack — NVIDIA DCGM (opens in a new tab) metrics collected by the Agent, cost tracking, waste detection, and a dedicated GPU view in the Web Console. And OpenShift is now a first-class deployment target: DeploymentConfig joins Kubernetes Deployment and Argo Rollouts as a recognized workload type, and the Helm chart is now distributed through a Red Hat-certified pipeline.

🛤️ From Workload and Node to GPU and OpenShift

Wave Autoscale 3.0 delivered workload-level intelligence — Autopilot for ML-driven autoscaling, Smart Sizing for automated rightsizing, and PV management for storage. Wave Autoscale 3.1 extended that intelligence down to the node layer, taking control of Karpenter on Amazon EKS (opens in a new tab).

Two gaps remained for the customers we talk to most.

The first is GPU. GPU instances are now the most expensive part of a typical AI-heavy cluster, and they're also the most over-provisioned. The standard Kubernetes metrics — CPU, memory, pods — say nothing about GPU utilization. Teams running training and inference workloads were flying blind on the line item that dominates their monthly bill.

The second is OpenShift. Many of our enterprise customers run Red Hat OpenShift (opens in a new tab) in regulated or on-prem environments. OpenShift's DeploymentConfig is a first-class workload object alongside Deployment and Rollout, but Wave Autoscale only recognized the latter two. That meant DC-based services were invisible to autopilot and Smart Sizing — exactly the workloads that need them most.

Wave Autoscale 3.2.0 closes both gaps.

🎯 GPU-Aware Autoscaling: Closing the Cost Blind Spot

GPUs are different from CPUs in ways that matter for cost optimization. CPU utilization is a single number with a clear meaning. GPU utilization is at least three numbers — SM (streaming multiprocessor) activity, memory utilization, memory bandwidth — and they don't move together. A pod can hold 80GB of GPU memory while doing almost no compute, or burn 100% SM activity on a fraction of the memory. Stock cluster monitoring shows neither.

NVIDIA's solution is the Data Center GPU Manager (DCGM) exporter (opens in a new tab): a Prometheus-style collector that pulls per-GPU metrics directly from the driver. Most platform teams have heard of it; many have it scraping into Prometheus already. The hard part isn't the metrics. It's turning them into autoscaling, sizing, and FinOps decisions.

What Wave Autoscale 3.2.0 ships:

• DCGM collection in the Wave Agent. The Agent now scrapes DCGM exporter endpoints alongside the existing CPU/memory/network metrics, and writes them through the same path into our embedded analytical store.
• GPU cost tracking tasks. Every GPU-attached pod is mapped to its node's instance type and on-demand/spot pricing, then aggregated into per-workload, per-namespace, and per-cluster GPU cost views.
• Waste detection. A scheduled task surfaces GPUs that are allocated but idle — cases where a pod is reserving a full A100 or H100 but using less than a configurable threshold of SM activity over a configurable window. This is the most actionable single signal for GPU FinOps.
• GPU resources in the Web Console. A new view in the console shows per-node GPU inventory, per-pod GPU consumption, and the waste-detection results, with drill-down to the underlying DCGM time series.

The GPU stack is built on the same primitives as the rest of Wave Autoscale: the Agent collects, the analytical layer stores, and the tasks turn raw metrics into recommendations. If your DCGM exporter is already running, the upgrade picks it up automatically.

🟥 OpenShift Support: Meeting Teams Where They Run

Red Hat OpenShift is the dominant Kubernetes distribution for regulated and on-prem deployments. It ships with DeploymentConfig (DC), an OpenShift-native workload object that predates Deployment and is still in widespread production use — even though Red Hat marked it deprecated in OCP 4.14 (opens in a new tab) and recommends migrating. Until that migration is universal (which it isn't), supporting DC is the price of admission for OpenShift.

DC is not just "Deployment with a different name." The lifecycle model is genuinely different:

The deployer pod is the trickiest part. Each new revision spawns a one-shot pod named <dc>-<revision>-deploy that orchestrates the rollout, then exits with status Completed (0/1). From a naive workload-tracking perspective, those pods look like real workload pods that keep dying. They're not — they're rollout machinery. Treating them as the workload would skew utilization data and confuse Smart Sizing.

What Wave Autoscale 3.2.0 handles:

• DeploymentConfig recognized as a first-class workload type in the deployment list and detail views, alongside Kubernetes Deployment and Argo Rollouts.
• Deployer pod filtering. *-deploy pods are detected by the openshift.io/deployer-pod-for.name label and the suffix pattern, then excluded from utilization aggregation and Pod Placement views.
• Autopilot and Smart Sizing wired through. DC workloads now flow through the same autoscaling and rightsizing recommendations as any other workload type.
• Red Hat-certified Helm chart on S3. The OpenShift Helm chart now ships through a GitHub Actions pipeline (opens in a new tab) that uploads to S3 after passing Red Hat's chart certification, and the build authenticates with Red Hat's Hybrid Cloud Console using a service account (replacing the deprecated offline-token flow).

If your platform mixes EKS, ROSA, and on-prem OpenShift, you can now manage all of it through one Wave Autoscale control plane.

📐 Smart Sizing: Two Modes, Clearly Surfaced

Smart Sizing has been in the product since Wave Autoscale 3.0, but the way it works wasn't always visible in the console. It originally targeted StatefulSets and DaemonSets — workloads that don't normally scale out — then extended to Deployments without HPA or Wave Autopilot. We also added a second path for Deployments that do run Autopilot, where the sizing math is different because horizontal scaling is in play.

The 3.2.0 Web Console makes those two operating modes explicit:

• Static Smart Sizing for non-scaling or non-Autopilot workloads — recommendations are computed from observed historical usage, P99-ish, with safety margins.
• Autopilot Smart Sizing for workloads where Autopilot owns horizontal scaling — recommendations are computed against the per-replica steady-state, not raw demand, so the two systems compose correctly.

Both modes write to the same recommendations surface, but the console now labels which path produced each one — useful for debugging and for trust.

📈 Forecasting and Wave Agent Updates

Two smaller but operationally meaningful changes:

• Forecast horizon default reduced from 30 days to 7 days. The 30-day horizon was set conservatively when the forecasting models were new; in practice, the 7-day forecast is what teams act on, and the longer horizon was generating ignored noise. The WA_CLUSTER_STATUS_FORECAST_HORIZON_DAYS env var still lets you override.
• Wave Agent telemetry improvements. Continuing the agent work from 3.1.0's gRPC pipeline, 3.2.0 ships incremental reliability and observability improvements to the Agent's internal task scheduler.

🔭 What's Next

3.2.0 is the closing point of the 3.x platform-breadth work. With GPU and OpenShift now first-class, the focus shifts back to depth: improving the recommendation quality of Autopilot and Smart Sizing for the now-broader workload universe, sharper waste detection for GPU and storage, and a tighter feedback loop between observed outcomes and the recommendations themselves.

If you're running GPUs in production and don't yet have per-workload visibility into utilization and cost, or if you're managing OpenShift workloads outside your existing autoscaling stack, the 3.2.0 upgrade is the one to take. Get in touch (opens in a new tab) if you want to talk through what changes for your environment.