Tutorial: scale GPU inference workers on queue depth with KEDA

Before you start — about 45 minutes · Karpenter · DCGM exporter · KEDA

We rebuilt GPU autoscaling on Kubernetes three times before it held. The version below is the one that survived a bad Tuesday and a worse Friday.

Step 1 — Decide what "working" means

Before touching code, write down three numbers: worst acceptable latency, cost per request, and what should happen when the upstream is unavailable. Everything after this is implementation.

Step 2 — Wire Karpenter

The whole flow is one path. No special branches for "large" inputs — express those as different limits, not different code.

# scale the worker deployment on queue depth, not on CPU
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata: { name: inference-workers }
spec:
  scaleTargetRef: { name: inference-workers }
  minReplicaCount: 1
  maxReplicaCount: 12
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus:9090
        query: sum(vllm:num_requests_waiting)

Why this works

The limit is enforced before the expensive call, not after it. Reserving budget up front means a burst degrades the caller that caused it instead of everyone downstream.

Step 3 — Guard the failure path

CPU-based HPA never triggers for GPU pods, because the model is not CPU-bound

Write that guard before you write the feature. It costs an hour and saves a postmortem.

Step 4 — Verify it

kubectl get hpa,scaledobject -n ai && kubectl top pods -n ai

• Lower the limit and confirm the command fails loudly
• Kill the upstream and confirm you get a typed error, not a timeout
• Check the metric you emit per outcome: ok, throttled, upstream_error

Tuning knobs

Knob	Default	What we run	Why
concurrency	8	24	Most of the wait is network, not compute
retry budget	infinite	2, with jitter	Unbounded retries turn an outage into an avalanche
timeout	30s	8s, inherited from the caller	Nobody waits 30s for a chat reply

None of this was clever. It was just the work nobody wanted to do first.