autoscaling

GPU spend is typically the largest line item in an AI org, and this question tests whether you reason in utilization rather than just capacity. The signal is wringing out per-unit cost (utilization, right-sizing, spot, quantization) before scaling out.

A Deployment and a Service will serve a model, but GPUs upend every Kubernetes default: scheduling, probes, autoscaling signals, and rollouts. Here is the setup that survives production, and when KServe earns its complexity.

Autoscaling GPUs is nothing like autoscaling web servers: GPUs are scarce and expensive, model loading is slow, and the right signal is not CPU. The signal is scaling on queue and GPU metrics, taming cold starts, and the scale-to-zero economics.

A newly booted replica is sluggish on its opening requests while weights load and kernels compile, which fights with reactive autoscaling. The signal is identifying where cold start comes from plus the warmup and provisioning remedies.

CPU-based autoscaling that suits a web tier quietly breaks on GPU inference: the signal is wrong, and replicas need minutes to warm. The interviewer wants the signals you genuinely scale on and how you mask the cold start.

Autoscaling reacts in minutes, but a burst lands in seconds, and the gap is where your tail latency dies. Absorbing bursts is about buffers and shedding, not just adding replicas. Here is the playbook.

Raw tokens per second is gameable: crank the batch size and the dashboard looks great while every request misses its latency target. Goodput is the throughput that actually meets your SLOs, and it is the number you size and autoscale on.