Visual walkthrough — Cost optimization and inference latency
Before we start, three plain-English promises about symbols: every letter gets a picture before it gets an equation, and we walk the safe zone, the danger zone, and the two degenerate ends (empty server, full server).
Step 1 — What is a "request", and what is a "server"?
WHAT. Picture a single coffee counter. Customers walk up (these are requests — one prediction someone wants). There is one barista (this is our server — one GPU worker doing one forward pass at a time). If the barista is busy, new customers wait in a line (the queue).
WHY start here. Every symbol later — , , , — is just a number attached to something in this picture. If we don't nail the picture first, the algebra is meaningless.
PICTURE. Look at Figure s01: customers (coral dots) flow in from the left, wait in a lavender queue, get served by the mint barista, and leave on the right.

Step 2 — Turn "how slow is the barista" into a rate
WHAT. The service time is seconds per customer. It is often handier to flip it into customers per second. We call that flipped number the service rate (mu):
Here (seconds/customer) sits in the denominator so that comes out as customers/second — the reciprocal literally swaps the units.
WHY. We now have two things measured in the same unit (per second): arrivals and the counter's top speed . Same units means we are allowed to compare them by dividing — which is exactly what Step 3 does.
PICTURE. Figure s02: a slow barista ( small, wide gaps between finished cups) vs a fast barista ( large, cups flying out).

Step 3 — Utilization: what fraction of the time is the barista busy?
WHAT. Divide how fast work arrives by how fast the counter can clear it:
The last equality uses from Step 2, so dividing by is the same as multiplying by .
WHY divide, and why is this the key number? Because a ratio strips away scale: whether it's a coffee shop or a GPU farm, answers one universal question — "how close to maxed-out are we?" That single number will turn out to control everything.
Edge check on the definition:
- → nobody arrives, barista always idle.
- → arrivals exactly match top speed; barista never rests.
- → customers arrive faster than they can ever be served → the line grows forever. So we will only ever allow .
PICTURE. Figure s03: a "busy-meter" gauge sweeping from empty (idle) to full (pinned), with the danger zone near 1 shaded coral.

Step 4 — Little's Law: the bridge between "how many waiting" and "how long you wait"
WHAT. Here is a law so simple it feels illegal. Let be the average number of customers in the shop (waiting + being served), and the average time each customer spends in the shop (their total latency). Then:
Reading it term by term: = people inside; = people arriving per second; = seconds each stays.
WHY it's true (and why we need it). Think of it as filling a bathtub. Water arrives at liters/second and each liter stays seconds before draining. The steady water level is arrivals-rate × stay-time = . Nothing about ML, nothing about coffee — just conservation of stuff flowing through. We need this because it is the only bridge connecting a headcount (, easy to reason about) to a wait time (, what we actually care about). See Little's Law and Queueing Theory.
PICTURE. Figure s04: the bathtub — inflow , water level , each drop labelled with its dwell time .

Step 5 — How many are in the shop? The magic
WHAT. For this "random arrivals, random service times, one server" shop (its formal name is an M/M/1 queue — the M's just mean "memoryless / random"), a standard result says the average number inside is:
Here the numerator pushes up (busier = more people), and the denominator (the fraction of time the barista is free) shrinks toward as , which blows up.
WHY this shape — where does come from? Intuitively, whenever the barista finally has a free moment (probability of being free), the backlog gets a chance to drain. As those free moments vanish, so the backlog almost never drains and piles up. That is why the free fraction — not the busy fraction — sits in the denominator.
Edge checks:
- : — empty shop. ✓
- : — on average one person inside.
- : — nine people piled up.
- : — infinite line.
PICTURE. Figure s05: the curve climbing gently, then rocketing to a vertical wall at .

Step 6 — Combine them: the latency formula appears
WHAT. Now we let Little's Law (Step 4) and the headcount (Step 5) collide. Little's Law rearranged gives the wait:
Substitute :
Finally recall from Step 3 that , so . The cancels:
Term by term: is the raw time one customer would take with nobody ahead; the factor is the congestion multiplier — how many times worse the wait gets because the shop is busy.
WHY this is the whole point. The multiplier depends only on how full you run the server. At it equals (no penalty). As it . Same barista, same — busyness alone decides your fate.
PICTURE. Figure s06: the algebra visualized — a base bar of height getting stretched by the congestion multiplier as rises.

Step 7 — Walk the whole curve: safe zone, danger zone, and both degenerate ends
WHAT. Let's plug numbers into with and read off every regime:
| (busyness) | (free) | regime | |
|---|---|---|---|
| ms | degenerate: idle, no penalty | ||
| ms | safe — | ||
| ms | edge of safe — | ||
| ms | danger — | ||
| ms | cliff — | ||
| degenerate: unbounded |
WHY show all of them. The curve is not a straight line — the jump from to (a tiny more busyness) multiplies latency by . This nonlinearity is the cost-vs-latency fact. Notice: going lets you serve the same traffic on about half the machines (you run each twice as full), but latency multiplies by . That is the trap the parent's "max out the GPU" mistake falls into.
The other degenerate end — . If arrivals exceed the max service rate, no steady exists at all: the line grows forever and the formula (which assumed ) simply does not apply. In practice this is where Autoscaling and Horizontal Scaling must add a second barista before reaches .
PICTURE. Figure s07: the full curve with the safe band () shaded mint, the danger band coral, the asymptote dashed, and each table row marked.

The one-picture summary
WHAT. One figure that compresses all seven steps: the coffee-shop picture feeding into the two rates , forming , Little's Law bridging to , and the final exploding curve — with the boxed result stamped on it.

Recall Feynman retelling — the whole walkthrough in plain words
Imagine one barista. Customers arrive at some pace () and each takes some time to serve (). Flip the service time and you get how many the barista can finish per second (). Divide arrivals by that top speed and you get one number, — the fraction of time she's busy. Now the bathtub trick (Little's Law): the number of people hanging around equals how fast they arrive times how long each stays. For a random one-line shop, the crowd size is — and that on the bottom is the fraction of time she's free to catch up. As she gets closer to never resting, that free time vanishes, the crowd blows up, and so does everyone's wait. Divide the crowd by the arrival rate (Little's Law again) and, after the pace terms cancel, you're left with a beautifully simple truth: your wait is just the raw service time stretched by . Run at half-busy? Wait doubles. Run at 99% busy? Wait grows a hundred-fold. So we never chase 100% — we keep some slack, and we add baristas (autoscale) before the line runs away.
Recall Quick self-test
The service time is but the observed mean latency is . What is ? ::: . Why does , not , sit in the denominator? ::: It is the fraction of time the server is free to drain the backlog; as free time the backlog and wait diverge. What happens if ? ::: Arrivals outrun max service; no steady latency exists, the queue grows forever — must add replicas.
See also
Little's Law and Queueing Theory · Autoscaling and Horizontal Scaling · Batching and Throughput · SLA SLO and Monitoring · Model Quantization and Pruning · Roofline Model of Hardware Performance · Model Distillation