LLM inference infrastructure, explained: GPUs, the KV cache, batching, the network and load balancing

The whole stack behind a language model's answer, from one model file to a fleet: why decode is memory-bound, how the KV cache sets capacity, what batching really buys, how models are split across GPUs, the RDMA fabric behind them, and why round-robin load balancing fails for inference.
Hand-drawn GPU: compute on top, high-bandwidth memory below, the bandwidth arrow between them

On this page

This post goes with a deep-dive video on the LevelUP I.T. YouTube channel. It builds the infrastructure behind a language model's answer from the bottom up: one model file, one GPU, one request, then batching, multiple GPUs, the network that joins them, and the load balancer in front. Every number is either measured on screen or taken from a published specification, and each one says which.

One request to a 7-billion-parameter model (Qwen2.5-7B, FP16): a 2,150-token prompt, then 256 generated tokens. The server read the prompt at 789 tokens per second and wrote the answer at 29.6. Same weights, same chip, same request: reading was 27 times faster than writing. The rest of this post explains why, and what that one fact does to every layer of AI infrastructure.

One request, two phases: prefill at 789 tokens/s, decode at 29.6
One request, two phases: prefill at 789 tokens/s, decode at 29.6

The whole stack in one picture

This is the map for everything below. Requests arrive over the front-end network at a gateway; an endpoint picker chooses a replica from the model servers' own signals (queue length, KV cache use, cached prefix); GPU servers run the model in a prefill pool (reading prompts, compute-bound) and a decode pool (writing tokens, memory-bound), each with eight GPUs joined by NVLink and HBM holding the weights plus the KV cache; and a back-end RDMA fabric moves the KV cache between them. The two lines underneath are the rules that size it. Each section of this post takes one part of the picture, starting from the GPU.

LLM inference infrastructure, the whole stack: front-end, gateway and endpoint picker, prefill and decode pools on GPU servers, and the back-end RDMA fabric
LLM inference infrastructure, the whole stack: front-end, gateway and endpoint picker, prefill and decode pools on GPU servers, and the back-end RDMA fabric

What you'll find here

  • What a model physically is, and the arithmetic that sizes it.
  • Prefill and decode, and the two latencies users feel.
  • The three numbers of a GPU, the roofline, and why decode is memory-bound.
  • The decode ceiling, predicted and then measured on three models.
  • The KV cache: exact sizing, grouped-query attention, prefix caching.
  • Batching, continuous batching, PagedAttention, and the real batch-size limit.
  • Splitting models across GPUs, and the traffic each split puts on the network.
  • The back-end fabric: RDMA, RoCEv2, rails, lossless and loss-tolerant designs.
  • Why round robin and least connections fail for inference, and what replaces them.
  • Disaggregated prefill and decode, autoscaling, and goodput.

This post is for paying subscribers only

Subscribe to LevelUp I.T. newsletter and stay updated.

Don't miss anything. Get all the latest posts delivered straight to your inbox. It's free!
Great! Check your inbox and click the link to confirm your subscription.
Error! Please enter a valid email address!