Choose by workload, not by benchmark headline
A serving benchmark is only useful when its prompt lengths, output lengths, concurrency and hardware resemble production. Time to first token matters for chat; inter-token latency controls perceived streaming quality; aggregate token throughput drives cost at sustained load. An engine can win one metric and lose another.
Use a representative request sample and report TTFT, inter-token latency, end-to-end latency and output throughput together. SGLang's official benchmark utility supports multiple backends, including SGLang, vLLM and TensorRT-LLM, which makes it a practical starting point for a controlled comparison.
- General CUDA service with fast model iteration: benchmark vLLM first.
- Stable NVIDIA-only fleet with a performance engineering team: include TensorRT-LLM.
- Repeated system prompts, agent traces or long shared documents: test prefix-cache behavior in SGLang and vLLM.
- Laptop, CPU or Apple silicon deployment: start with llama.cpp; use Ollama when developer convenience matters most.
What the leading engines actually optimize
vLLM documents continuous batching, chunked prefill, PagedAttention and automatic prefix caching. These features target the two recurring sources of waste in LLM serving: under-filled batches and repeated KV-cache work. TensorRT-LLM exposes in-flight batching, paged attention, chunked context, KV-cache reuse, quantization and speculative decoding, with deep optimization for NVIDIA GPUs.
SGLang combines serving with structured-generation and cache-aware execution. The practical implication is not that one engine is universally fastest. It is that the best engine depends on whether your workload is dominated by prefill, decode, shared prefixes, structured outputs or operational portability.
A defensible evaluation process
Freeze one model revision, tokenizer, quantization format and hardware shape. Replay at least three traffic levels: low concurrency for latency, expected concurrency for normal cost, and a burst case for tail behavior. Keep quality evaluation separate from systems benchmarking so a smaller or more aggressively quantized model does not appear to win by silently changing output quality.
Select the simplest engine that meets the service-level objective with headroom. Re-run the same harness after every engine or driver upgrade; inference software changes quickly, so this page records capabilities rather than declaring a permanent benchmark winner.