SKILLUMEN
Try for free
Interview Questions  ›   Tuning and serving

KV-Aware Serving

6 interview questions you should be able to answer.
3 worked answers   •   3 practice questions   •   Advanced
Memory fills up
before compute
  runs out.↘
Updated Sep 2026
01 CORE
1 / 6

How does the KV cache shape production serving,
and what two generation phases does it split into?

Think about your answer before revealing.
Give it a try!
Interview answer
◷  ~ 30 seconds

The KV cache is the model's running memory of everything it has read, one entry per token, and it dominates serving because it grows with context and eats GPU memory.

Generation splits into two phases around it. Prefill reads the whole prompt in one pass to build the initial cache, and it is compute-bound.

Then decode emits tokens one at a time, each re-reading the growing cache, and it is memory-bandwidth-bound. Because they bottleneck on different resources, the whole serving stack is organized around them.

PREFILL DECODE whole prompt one pass over the whole prompt · compute-bound then one token per step, each re-reading the growing cache memory-bandwidth-bound
What the interviewer is testing
▣
Prefillcompute-bound
▥
Decodememory-bound
▤
KV cachegrows with context
Follow-up they may ask
02 DESIGN
2 / 6

How do prefill and decode differ in what they bottleneck on,
and why does mixing them on one GPU cause problems?

Name each phase's bottleneck before revealing.
Interview answer
◷  ~ 30 seconds

Prefill is one big matrix-heavy burst over every prompt token, so it saturates compute. Decode does tiny per-step math but drags the whole growing KV cache in and out, so it's limited by memory bandwidth.

On a single shared GPU they collide: a user with a 100k-token prompt hogs the compute during prefill and creates head-of-line blocking, stalling everyone else's streaming decode. You get poor utilization and jittery latency because one workload starves the other.

PREFILL
One big
matrix burst
Every prompt
token at once
Saturates
compute
DECODE
Tiny per-step
math
Drags the KV cache
in and out
Memory-bandwidth
bound
03 DEEPER
3 / 6

What problem does disaggregation solve by running prefill and decode
on separate GPU pools linked by a fast connection?

Think about your answer before revealing.
Interview answer
◷  ~ 30 seconds

Disaggregation puts prefill on one GPU pool and decode on another, shipping the KV cache between them over a fast interconnect like RDMA or NVLink. That fixes the collision: a giant prompt keeps its prefill on pool A without stalling the token streaming on pool B, so you kill head-of-line blocking.

It also lets you tune each pool for its bottleneck: compute-heavy hardware for prefill and memory-bandwidth-heavy hardware for decode, scaled independently. NVIDIA Dynamo and the CNCF's llm-d orchestrate exactly this at cluster scale over engines like vLLM and SGLang.

PREFILL POOL compute-heavy DECODE POOL bandwidth-heavy KV cache over RDMA / NVLink ✓ no head-of-line blocking
More questions
04What does prefix caching, like SGLang's RadixAttention, reuse across requests, and how does KV-cache-aware routing exploit it?
05Why is the KV cache, rather than raw compute, usually the real constraint in a serving design?
06Given a workload where many requests share a long system prompt, which serving techniques would you reach for and why?
These run inside Skillumen with graded answers.

This is a small sample.
600+ interview questions live inside Skillumen.

Every concept card carries its own interview questions, graded as you answer.
Free to start.

See more interview questions