inference/research
verifiedmedium · 0.70minorupdated 2026-10-04

Consensus: vLLM is what production teams reach for by default on datacenter NVIDIA, because of Day-1 model support and ecosystem size - not because it benchmarks best

[minor] toolchain

Fields

id
gotchas/sent-vllm-enterprise-default-consensus
Class
toolchain
Severity
minor
Concepts
engine-selectionday-one-model-supportecosystem-sizerayslurmtechnical-debt
Symptom
Asked what stacks the industry actually uses, the highest-scoring answer (63 upvotes) from a working ML engineer says: 'Infra for inference wise most production apps use Nvidia TensorRT LLM or vLLM, combined with nvidia triton server usually... vLLM feels less professional but it's ez to setup.' Asked directly about vLLM vs SGLang by a practitioner running 70B+ at tp=4 to tp=16, the answer is about organizational fit, not throughput: 'A lot of labs have standardized on vLLM/work with so you get Day 1 support for Mistral, Gemma 3 models for example. I'd recommend having envs w/ both SGLang and vLLM (stable and nightlies) to be able to swap off as necessary.' That last clause is the actual practitioner position: run both.
Root cause
The stated reason is Day-1 model support and contributor headcount, and the headcount claim is quantitative even though it is not a benchmark: 'Explicitly an order or two orders of magnitude of people work directly on vLLM full-time vs llama.cpp.' When asked for raw speed the same practitioner declines to name a winner: 'When DeepSeek-V3 first came out SGLang was much faster than vLLM, but they are now neck and neck,' and 'any shootoff will be "it depends" rather than a A or B is better.' So vLLM's default status is an ecosystem fact, not a performance fact.
Workaround
If you are self-hosting in production on NVIDIA, run vLLM and keep an SGLang environment alongside it. The corpus explicitly recommends this rather than a single-engine commitment.
notes
Same practitioner, same comment: vLLM 'has been carrying a fair amount of technical debt, and a lot of settings required for tuning perf', and a single config change has been observed to move numbers '2-3X'. The default choice is defensible; treating any published vLLM throughput number as your number is not.

Notes

Same practitioner, same comment: vLLM 'has been carrying a fair amount of technical debt, and a lot of settings required for tuning perf', and a single config change has been observed to move numbers '2-3X'. The default choice is defensible; treating any published vLLM throughput number as your number is not.

Cross-references