Two things are true about self-hosted inference in the summer of 2026, and they point in opposite directions. The first: vLLM and SGLang have converged on throughput. In the same week — vLLM v0.25.0 on July 11, SGLang v0.5.15 on July 10 — both engines shipped a headline win that came from killing the same host–device synchronization stall, not from a hotter kernel. Peak tokens per second is no longer where they differ.

The second: that makes "which is faster" the wrong question. When two engines are within noise of each other on generic traffic, the benchmark that decides your bill is the one run on your prompts. And the variable that swings that benchmark hardest isn't in either changelog. It's how much of every request is the same.

The one number that actually decides it: your prefix share#

Look at what your engine receives on a typical turn. An agent replays its system prompt, its tool schemas, and a growing scratchpad of prior steps on every call. A RAG endpoint prepends the same instructions and, often, an overlapping retrieved context. A sampler asks for eight completions of one prompt. In all three, a large chunk of each request is identical to the last one — that fraction is your prefix share, and it's frequently the majority of your tokens.

This is exactly the workload SGLang was built for. RadixAttention — its core design since launch — keeps the KV cache of shared prefixes in a radix tree and reuses it automatically across requests, including branching ones. Parallel samples share the trunk. A multi-turn agent loop reuses the whole conversation prefix instead of recomputing it. It's on by default; you turn it off with --disable-radix-cache if you want to measure what it bought you.

vLLM has automatic prefix caching too, and for the common case — many requests sharing one linear prefix — it does the job. The distinction that matters is that SGLang's tree-aware reuse is more aggressive by default and handles the branching shapes agent traffic actually produces. If your prefix share is high, that reuse is the single biggest lever you have, and it lives in one engine more than the other.

vLLM's edge is reach, not raw speed#

So why is vLLM still the right default for most founders? Because most founders' real constraint isn't a shared prefix — it's churn. A new open-weight model drops on a Thursday and you want to serve it on Friday. You have whatever accelerators you could get. You have no time to babysit a serving stack.

That's vLLM's home turf. Its v0.25 release made the Transformers backend reach parity with native implementations, which means a model that ships with only a Hugging Face implementation is servable at full speed on day one — no waiting for hand-written engine support. Its hardware and backend coverage is the widest in the field. And the install-to-first-token path is the shortest and most boring, which is a feature when you're a team of one.

# vLLM — the boring default; automatic prefix caching handles linear prefixes
vllm serve meta-llama/Llama-3.3-70B-Instruct --tensor-parallel-size 2

# SGLang — RadixAttention is on by default; best when a big prefix is shared
python -m sglang.launch_server \
    --model-path meta-llama/Llama-3.3-70B-Instruct --tp 2

Both commands are one line. The difference isn't the command — it's which one is quietly reusing the 3,000 tokens of system prompt your agent sends on every single turn.

The rule, and the test that beats the rule#

But the rule is a starting point, not an answer. The crossover between these two depends entirely on your prefix share, your batch sizes, and your hardware — none of which a third-party benchmark knows. So do the thing that actually settles it: replay a few hundred of your own real requests through both engines and read your tokens per second and your time to first token. The winning engine in 2026 isn't the one with the better changelog. It's the one that recognizes how much of your traffic it has already seen.