inference-serving-topologylisted

# Inference Serving Topology ## The three layers (name which you're designing) 1. **Engine** — executes the model on accelerators: **vLLM**, **SGLang**, **TensorRT-LLM**. Owns paged **KV-cache**, **continuous (in-flight) batching**, quantization. This is where throughput/latency is won. 2. **Serving** — request routing, batching policy, API contract, metrics, rate limiting: **Triton** (production shell around an engine), **KServe**, **LiteLLM/Envoy AI Gateway**. 3. **Orchestration** — scaling, health, placement: **Kubernetes + KEDA**, **Ray Serve**, llm-d, GKE Inference Gateway. A common 2026 pairing: **vLLM as the token engine + Triton as the production shell**; **Ray Serve** when you need multi-GPU/multi-node distributed strategies. ## Levers that decide the topology - **KV-cache** is the memory bottleneck for LLMs → paged KV (vLLM), cache reuse, quantized KV. Drives max batch / context. - **Continuous batching** (vs static) is mandatory for throughput. - **Prefill–decode disaggregation**: split the compute-bound prefill from the memory-bound decode onto different pools → better utilization at scale. - **Parallelism**: tensor / pipeline / expert (MoE) / data-parallel attention — chosen by model size vs GPU memory. - **Targets**: state TTFT (time-to-first-token, low hundreds of ms) and inter-token latency (tens of ms) goals — they drive batching/parallelism. ## Scale ladder Single GPU + vLLM → multi-GPU one node → Ray Serve/KServe multi-node + KEDA