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.

Cluster
LLMOps
Owner Course
LLMOps Course
Updated
2026-09-01T05:30:00+05:30
Type
Core Guide
Direct Answer

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

TTFT
Time To First Token—latency from request arrival to first generated token.
Prefill latency
Inter-Token Latency
Time between consecutive generated tokens during decoding.
Decoding latency
Throughput
Tokens generated per second across all concurrent requests.
Tokens/sec
KV Cache
Cached key-value tensors from attention layers to avoid recomputing past tokens.
Memory: layers × heads × dim × ctx
Continuous Batching
Dynamically adds and removes requests from a batch at token-level granularity.
In-flight batching
Queue Time
Time a request waits before being admitted to a batch.
Wait → prefill → decode

What Happens From Request Arrival to Token Streaming?

Production inference request lifecycle.

Arrival
Client sends prompt + parameters (max tokens, temperature).
Queue
Request waits for a batch slot. Queue time depends on concurrency.
Prefill
Process the entire input prompt—compute KV cache for all input tokens.
First Token
Generate first output token. TTFT = queue + prefill time.
Decode
Generate subsequent tokens one at a time, updating KV cache.
Stream
Tokens are streamed to client as they are generated.
Done / Stop
Generation ends: stop token, max tokens reached, or client disconnect.

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.

DecisionOptionsTrade-offRecommendation
Serving enginevLLM vs TGI vs SGLang vs llama.cppThroughput vs features vs flexibilityvLLM for high-throughput GPU serving; llama.cpp for CPU/edge
Batch sizeSmall (1–8) vs medium (16–32) vs large (64+)Latency vs throughputSet by SLO: latency-sensitive = smaller; throughput-focused = larger
Quantizationfp16 vs INT8 vs 4-bitQuality vs memory vs speedTest 4-bit on your workload; use fp16 if quality drops
Autoscaling metricGPU utilisation vs queue length vs request rateReactive vs predictiveQueue length is most directly tied to user-visible latency
GPU count per replica1 GPU vs 2 GPUs (TP=2) vs 4+ GPUsCost vs model size vs latencyTensor parallelism only when model does not fit on single GPU
Max concurrencyConservative (low queue) vs aggressive (high throughput)Latency SLO vs cost efficiencySet max queue depth; reject requests beyond it

How Should a Large Language Model Server Be Benchmarked?

1
Define workload profile
Benchmarks are meaningless without a defined workload.
2
Set SLOs
SLOs determine whether the server is production-ready.
3
Run load test
Gradual ramp reveals the breaking point and performance curve.
4
Measure under load
Metrics under load reveal the real performance envelope.
5
Test edge cases
Edge cases expose failure modes that average load tests hide.
6
Record and document
Benchmark results must be reproducible for regression testing.

Serving failure modes

Common production serving failures and their operational responses.

FailureSignalCauseContainmentRecovery
OOM (out of memory)Server crashes or drops requests; GPU memory exhaustedKV cache + model weights exceed GPU memory; batch too large; context too longLimit max batch size; cap context length; use quantizationReduce concurrency; restart server; upgrade GPU
Queue timeoutRequests wait too long in queue and time out before processingConcurrency exceeds capacity; batch processing too slowSet max queue depth; reject early; autoscaleScale up replicas; reduce batch size; load shed
TTFT regressionTime to first token increases beyond SLOLonger prompts in workload; prefill compute bottleneck; GPU contentionMonitor prompt length distribution; cap input tokensOptimise prefill; use speculative decoding; scale out
Throughput collapseTokens per second drops sharply under loadMemory pressure causing swapping; batch fragmentation; GPU thermal throttlingMonitor GPU temperature and memory; set hard limitsReduce 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.

MOVE FROM A WORKING MODEL TO AN OPERABLE SYSTEM

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.

Inference gatewayEvaluation pipelineRelease controlTrace dashboardReliability evidence

Twelve-week live program for engineers building and operating production AI systems.

Sources and technical review
Last reviewed: 2026-09-01
Technical review: scai-llmops-engineering