AI Systems Reference/Deep Cuts (Inference Infra)

Disaggregated Inference

Splitting prefill and decode across pools, dedicated embedding/reranker tiers, and the emerging disaggregated serving architectures used at hyperscale.

5/5Overview: 30m

Monolithic vs disaggregated serving

Monolithic: one GPU pool runs prefill + decode for every request.

Disaggregated: separate prefill workers and decode workers — optimize each pool for its bottleneck (compute vs memory bandwidth).

Papers to know: DistServe, Splitwise — prefill-heavy and decode-heavy phases scale independently.

Why disaggregate

Workload shapeDominant phaseDisaggregation benefit
Long RAG context + short answerPrefillScale prefill GPUs without over-provisioning decode
Chat with long multi-turn historyMixedPool sizing per phase
Batch summarization (long docs)PrefillBurst prefill without blocking chat decode

Goodput (tokens delivered per GPU-second at SLO) improves when you right-size each phase instead of one pool sized for worst-case combined load.

Architecture sketch

Request → Router → Prefill pool (compute-heavy, batch long prompts) ↓ KV transfer Decode pool (bandwidth-heavy, many concurrent short decodes) ↓ Response

KV transfer between pools is the engineering cost — network bandwidth, serialization, colocation in same AZ.

Dedicated embedding and rerank tiers

Disaggregation isn't only prefill/decode. At RAG scale (Topic 4), teams often run:

TierModel typeSLA
EmbeddingBi-encoder (e.g., e5, voyage)High QPS, low latency, cheap GPUs
RerankCross-encoderLower QPS, runs on top-k only
GenerationLLMHighest cost, strict p95

Separating embedders from LLMs prevents embedding batch jobs from starving chat latency.

Link to Topic 4 (Knowledge Pipelines) — ingestion uses embedders offline; query path uses them online. Same model family, different scaling profile.

Link to Distributed Systems

Disaggregated serving is microservices for GPU phases — load balancing, backpressure, and partial failure between prefill and decode pools.

When to stay monolithic

  • Low traffic — ops complexity isn't worth it
  • Small models on single GPU — no phase bottleneck split
  • Hosted API — vendor handles internally

Interview answer template

"Our RAG workload has 4k-token prefill bursts but 100-token answers — I'd trial disaggregated prefill/decode pools. Embedders on a separate CPU/GPU tier with autoscale on embedding queue depth. LLM pool autoscales on decode wait time."

Further Reading

Hands-On Tasks (Optional)

Design drills and architecture sketches — gateway SLOs, eval gates, rollout plans. Assumes AI Engineering fundamentals are already in place.

  • When to disaggregate prefill and decode

    Workload: bursty chat (short outputs) vs batch doc summarization (long prefill, medium decode). For each, argue for monolithic vs disaggregated serving and name the bottleneck phase.

    15m