SERVING LAYER · INFERENCE
Large Language Model Serving and Inference: Latency, Throughput and Scaling
Follow a production request from arrival through queueing, prefill, decoding and token streaming while measuring the correct performance signals.
Large language model serving is the infrastructure that handles inference requests—accepting prompts, queueing, batching, running the forward pass and streaming generated tokens back to the client. The key metrics are Time To First Token (TTFT), inter-token latency and throughput. Performance is optimised through continuous batching, KV cache management, quantization and speculative decoding. Capacity planning must account for concurrency, context length and output length to meet latency SLOs.
Serving performance signals
What Happens From Request Arrival to Token Streaming?
Production inference request lifecycle.
Conceptual visualisation — not a live computation.
How Are TTFT, Inter-Token Latency and Throughput Measured?
TTFT (Time To First Token) is the latency from when the client sends the request to when the first token is received. It includes queue time and prefill time—the time to process the entire input prompt in a single forward pass. TTFT is dominated by input length: longer prompts mean more tokens to process in prefill, which increases TTFT.
Inter-token latency is the time between consecutive generated tokens during the decoding phase. It is dominated by the model's forward pass time for a single token step, which depends on model size, batch size and GPU compute. Inter-token latency is relatively stable during generation but can increase if the batch grows (more concurrent requests sharing GPU compute).
Throughput is the total number of tokens generated per second across all concurrent requests. Throughput and per-request latency have a fundamental trade-off: larger batches increase throughput (better GPU utilisation) but may increase per-request latency (more time per token step). The serving system must balance these based on SLOs.
How Do Continuous Batching and KV Cache Work?
Continuous batching (also called in-flight batching or iteration-level batching) dynamically adds new requests to and removes completed requests from a batch at every token generation step. Unlike static batching (which waits to fill a batch before processing), continuous batching starts processing a request immediately and can join new requests mid-generation. This eliminates head-of-line blocking where short requests wait behind long ones.
The KV cache stores the key and value tensors computed during attention for all previous tokens. Without the KV cache, each new token would require recomputing attention over all previous tokens from scratch—an O(n²) cost. With the KV cache, each new token only requires computing attention for that token against the cached keys and values—an O(n) cost. The KV cache is the primary consumer of GPU memory during inference.
Memory management of the KV cache is critical. vLLM uses PagedAttention, which allocates KV cache memory in blocks (like virtual memory paging) rather than contiguously, reducing fragmentation and enabling higher batch sizes. The KV cache grows with context length and batch size—longer contexts and more concurrent requests both increase memory pressure.
Where Do Quantization and Speculative Decoding Help?
Quantization reduces the precision of model weights (and sometimes activations) to reduce memory usage and increase inference speed. Common formats include INT8, FP8 and 4-bit (NF4, GPTQ, AWQ). Quantization reduces VRAM requirements—4-bit quantization can reduce model memory by approximately 4× compared to fp16. The quality cost depends on the quantization method and model size; larger models are generally more robust to quantization.
Speculative decoding uses a smaller, faster draft model to generate candidate tokens, which the larger target model verifies in a single forward pass. If the draft model's tokens are correct, they are accepted at the cost of one forward pass instead of N. If they are incorrect, the target model generates the correct token. Speculative decoding can significantly reduce TTFT and inter-token latency for workloads where a good draft model is available.
Both techniques involve trade-offs. Quantization reduces memory and may increase throughput but can affect output quality—always evaluate on your workload before deploying. Speculative decoding adds complexity (managing two models) and only helps when the draft model is sufficiently aligned with the target model.
How Should Inference Capacity and Autoscaling Be Planned?
Capacity and scaling decisions for production LLM serving.
| Decision | Options | Trade-off | Recommendation |
|---|---|---|---|
| Serving engine | vLLM vs TGI vs SGLang vs llama.cpp | Throughput vs features vs flexibility | vLLM for high-throughput GPU serving; llama.cpp for CPU/edge |
| Batch size | Small (1–8) vs medium (16–32) vs large (64+) | Latency vs throughput | Set by SLO: latency-sensitive = smaller; throughput-focused = larger |
| Quantization | fp16 vs INT8 vs 4-bit | Quality vs memory vs speed | Test 4-bit on your workload; use fp16 if quality drops |
| Autoscaling metric | GPU utilisation vs queue length vs request rate | Reactive vs predictive | Queue length is most directly tied to user-visible latency |
| GPU count per replica | 1 GPU vs 2 GPUs (TP=2) vs 4+ GPUs | Cost vs model size vs latency | Tensor parallelism only when model does not fit on single GPU |
| Max concurrency | Conservative (low queue) vs aggressive (high throughput) | Latency SLO vs cost efficiency | Set max queue depth; reject requests beyond it |
How Should a Large Language Model Server Be Benchmarked?
Serving failure modes
Common production serving failures and their operational responses.
| Failure | Signal | Cause | Containment | Recovery |
|---|---|---|---|---|
| OOM (out of memory) | Server crashes or drops requests; GPU memory exhausted | KV cache + model weights exceed GPU memory; batch too large; context too long | Limit max batch size; cap context length; use quantization | Reduce concurrency; restart server; upgrade GPU |
| Queue timeout | Requests wait too long in queue and time out before processing | Concurrency exceeds capacity; batch processing too slow | Set max queue depth; reject early; autoscale | Scale up replicas; reduce batch size; load shed |
| TTFT regression | Time to first token increases beyond SLO | Longer prompts in workload; prefill compute bottleneck; GPU contention | Monitor prompt length distribution; cap input tokens | Optimise prefill; use speculative decoding; scale out |
| Throughput collapse | Tokens per second drops sharply under load | Memory pressure causing swapping; batch fragmentation; GPU thermal throttling | Monitor GPU temperature and memory; set hard limits | Reduce concurrency; restart; check hardware health |
Key takeaways
- TTFT is dominated by input length (prefill); inter-token latency is dominated by model size and batch size.
- Continuous batching eliminates head-of-line blocking by dynamically managing the batch at each token step.
- KV cache is the primary GPU memory consumer during inference—manage it with paged allocation.
- Quantization reduces memory 2–4× but must be evaluated for quality impact on your workload.
- Speculative decoding can reduce latency when a suitable draft model is available.
- Benchmark with your real workload profile—generic benchmarks do not predict your production performance.
Serving engine capabilities are verified against official vLLM, TGI and SGLang documentation. PagedAttention and continuous batching concepts are established in vLLM documentation and related publications.
- Specific performance numbers depend on hardware, model size and workload—no universal benchmarks apply.
- Newer optimisation techniques (chunked prefill, prefix caching) are evolving; check current docs.
Review cadence: Reviewed every 90 days. Next review by December 2026.
A fast demonstration request is not a production serving strategy. Production performance must hold under concurrency, queueing, long contexts and changing workloads.
In the LLMOps Course, you build the operational layer around large language model, retrieval and agent systems—from inference serving and evaluation gates to observability, release control, security, scaling and cost management.
Twelve-week live program for engineers building and operating production AI systems.
- Tier 1
- Tier 1
- Tier 1