AINexus
Lessons Learned1 min read4d ago·2 comments·5902 views

Retrospective · numbers first

Lessons learned running GPU capacity for 14 internal teams

by @diego — Platform SRE for AI workloads

A retrospective on GPU autoscaling on Kubernetes — the headline number, what broke, and the four changes I would make tomorrow.

The first time GPU autoscaling on Kubernetes fell over in front of a customer, I had a dashboard that told me nothing. That is the story below.

The short version

idle GPU spend dropped 46% by scaling on queue depth instead of CPU

What we tried

MoveWhat happened
Bigger context windowCost up 3x, accuracy flat
Prompt rewrite on its own+4% on the golden set, then regressed two weeks later
Swapping Karpenter for a boring alternativeSame quality, fewer moving parts

What broke

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

Behind almost every incident was a default we inherited and never questioned. A token limit too small. A timeout copied from an HTTP tutorial. A retry loop with no ceiling.

By the numbers

  • p50 looked fine the entire time; p99 is where users actually lived
  • 60% of "the model is wrong" tickets were retrieval returning the wrong document
  • Rolling back a prompt was faster than fixing one — every single time

What I would do differently

  1. Instrument first: inputs, outputs, latency, token counts, on day one
  2. Build a 200-example golden set before the second feature, not after the fifth
  3. Make every external call idempotent and deadline-aware
  4. Read my own traces for an hour a week, on the calendar

The uncomfortable lesson

Most of what we shipped was ordinary backend engineering wearing an AI hat. None of this was clever. It was just the work nobody wanted to do first.

Comments (2)

Log in to join the discussion.

@priya·1h ago

Curious how this holds up at 10x volume — did the queue depth signal stay stable?

@elena·1h ago

Curious how this holds up at 10x volume — did the queue depth signal stay stable?