How would you design AI inference infra with GPU queue and KV-cache?
376 views
86 of 106
1
The problem
Question presented to candidate:
"We are launching a chat and API product on top of a 70-billion-parameter open model that we host ourselves on GPUs. Expect around 20 million requests a day, with long system prompts and streamed answers. Design the serving infrastructure: how requests are queued, how GPUs are used efficiently, how the KV-cache fits in, and how it scales."
What a strong answer should cover:
GPU capacity math: weights size, KV-cache bytes per token, how many tokens fit beside the weights, and why decode is memory-bandwidth bound
The latency metrics that matter: time to first token (prefill) and time per output token (decode), and the throughput versus latency trade-off of batch size
A token-aware queue in front of the GPUs: admission by estimated tokens, priority classes, per-tenant fairness, deadlines and load shedding instead of unbounded queues
Continuous batching inside each replica and paged KV-cache allocation, versus static batching and reserving maximum context per request
Prefix-aware routing so requests sharing a system prompt land where its KV-cache already is, balanced against load; autoscaling on queue depth and KV usage with slow cold starts
Clarifying questions expected:
Which model and context length, and is quantization acceptable?
What latency targets: time to first token and tokens per second per user? Interactive only, or also offline batch traffic?
How much of each prompt is shared (system prompts, documents, multi-turn history)?
Code / implementation expected: Optional โ the example works the GPU capacity numbers, simulates static versus continuous batching, compares KV reservation with paged allocation, and compares three routing policies for prefix-cache hits.
ai-inference
gpu
kv-cache
2
Try it yourself
Sketch your approach before you read the solution. That is what the interview tests.
Stuck? Get a hint.
A short nudge toward the approach. It will not give the answer away.
3
Solution
Target Audience: Engineers preparing for a system design round who may never have served a model. GPUs, tokens, prefill, decode and the KV-cache are explained from zero.
Difficulty: Hard
Verified with: Node 22 and Python 3.12 (identical output). Paper and product facts (Orca, vLLM, model shapes, GPU memory) are cited inline, checked in October 2026; throughput per node is an assumption, stated as such.
How to read this doc: Plain language first, then ๐ Interview term: callouts with the words an interviewer expects. All numbers come from the example program and are quoted in full in the Verified section. The KV-cache itself (what it stores, why it is valid, how prefix caching hashes blocks) has its own page: what the KV-cache is and how prefix caching works. This page i
The solution is hidden so you can try first
18 min read ยท 15 sections
4
Read the code
LLM serving fleet: GPU capacity math, static vs continuous batching, paged KV admission and prefix-aware routing