🎯Core Definition
Prefill/Decode disaggregation (PD split) = running the two phases of a request on different instance types: Prefill processes the whole prompt in parallel — matrix-matrix (GEMM) work that is compute-bound with high GPU utilization; Decode generates one token at a time — a matrix-vector (GEMV) step per token that is bandwidth-bound, reading the full weight set to emit a single token, with low utilization. After the split, Prefill instances turn prompts into KV caches and ship them over high-speed networks (RDMA/InfiniBand) to Decode instances, which focus purely on low-latency batched generation. Scheduling: the two pools scale independently; Decode instances are load-balanced by occupied KV size / sequence length (not connection count), with token-level scheduling and pipelined KV transfer.
💡Use Cases
high-concurrency online serving (chat/agent workloads mixing long prompts and long outputs) that must keep both TTFT and ITL low; vLLM/SGLang have native PD support and top vendors like DeepSeek run this architecture in production; interview favorites: why Prefill and Decode have different bottlenecks, and what PD split solves.
⚡Key Problems Solved
when colocated, Prefill bursts (large batches of big prompts) saturate compute and wreck the TTFT/ITL of in-flight Decode requests — the two loads interfere and their scheduling goals conflict. Splitting them: ① each pool is provisioned and scaled to its own bottleneck (compute vs bandwidth), raising GPU utilization; ② TTFT is decided by Prefill instances, ITL by Decode instances, so latency targets are independently tunable; ③ bursts are absorbed by the Prefill pool while Decode stays stable — at the cost of KV transfer over the network and more complex scheduling.