On one RTX 5090, serving the same 27B model at a 32K context to one user, SGLang with a drafter generated text fastest: 139.7 tok/s, against 100.8 for vLLM with the model’s own draft head and 84.5 for vLLM without speculation. vLLM read long prompts slightly faster, reached the longest window and gave the steadiest numbers. Choose by job, not by engine.
§1What was matched, and what was not
Both engines served the same checkpoint: Qwen 3.8 27B in ModelOpt NVFP4, prepared for the RTX 5090’s 32 GB. Every run used a 32,768-token context, an FP8 KV cache, one request at a time and the same local benchmark suite on a warm server, on 22 August 2026. Each profile had to return a real completion before its suite started, and to pass recall, tool-call, vision, reasoning and repeated-stability checks before its speed counted.
The acceleration could not be matched. SGLang ran separate drafter models; vLLM ran the draft head built into the model, known as multi-token prediction (MTP). So this compares each engine with the best acceleration I could run for this model on this card. That is the choice you actually face; it is not a contest between two engines in a vacuum.
| Dimension | SGLang | vLLM | Matched? |
|---|---|---|---|
| Model and weights | Qwen 3.8 27B · NVFP4 | Qwen 3.8 27B · NVFP4 | Yes |
| Context and KV cache | 32,768 · FP8 | 32,768 · FP8 | Yes |
| Requests at a time | 1 | 1 | Yes |
| Speculation | D-Flash 2 or DSpark drafter | Native MTP, or none | No |
| Tool-call parser | qwen3_coder | qwen3_xml | No: each engine’s parser for this model |
§2Generation speed: SGLang leads with a drafter
| Profile | Acceleration | Sustained output | Mean accepted length | Spread over 5 runs |
|---|---|---|---|---|
| SGLang · D-Flash 2 | External drafter | 139.7 tok/s | 2.95 | ±37.0 tok/s |
| SGLang · DSpark v2 | Target-matched NVFP4 drafter | 110.2 tok/s | 2.05 | ±20.2 tok/s |
| vLLM · native MTP | The model’s own draft head | 100.8 tok/s | 2.29 | ±11.7 tok/s |
| vLLM · baseline | None | 84.5 tok/s | — | ±1.4 tok/s |
Against the same control, vLLM without speculation, SGLang’s D-Flash 2 profile generated 65% faster, DSpark 30% faster and vLLM’s MTP 19% faster. The lead tracks the drafter: D-Flash 2 had 2.95 tokens accepted per step against MTP’s 2.29. Most of SGLang’s advantage here is that it could run a strong external drafter for this model.
One later result stays outside the table. An isolated vLLM pass moved MTP from three draft tokens to four and lifted it from 112.8 to 120.5 tok/s, with unchanged outputs. It came from a different test, so it is not matched against the numbers above, but it narrows the gap.
§3Reading the prompt: close, and tunable
Time to first token is where the two engines sit closest. On a short chat message SGLang answered first. On a 10,553-token prompt the plain vLLM profile was quickest, and every profile passed the recall check.
| Profile | Short chat prompt | 10,553-token prompt |
|---|---|---|
| SGLang · DSpark v2 | 0.065 s | 0.925 s |
| SGLang · D-Flash 2 | 0.115 s | 0.993 s |
| vLLM · baseline | 0.138 s | 0.862 s |
| vLLM · native MTP | 0.143 s | 0.953 s |
At 44,031 tokens the pattern held: vLLM’s long-context profile read the prompt in 5.40 s and SGLang’s DSpark profile in 6.28 s.
Prompt speed is also the most tunable number. A later pass on SGLang’s DSpark profile changed the prefill chunk from 1,024 to 2,048 tokens. That cut median time to first token from 0.722 to 0.645 s on 8K prompts and from 4.286 to 3.837 s on 35K prompts, about 9,100 tok/s of prefill. That pass was not re-run against vLLM, so read it as a direction, not a verdict.
Both engines can reuse a cached prompt prefix, and that mattered more than either engine’s raw prefill. On this card a warm, shared prefix of about 16K tokens cut time to first token from 2.891 s to 0.283 s, a 90% cut. Keep system prompts stable: a timestamp at the top invalidates the cache.
§4Memory and context: different dials
The engines reserve memory differently, so “VRAM used” is partly a setting. vLLM takes a fixed share of the card up front, 92% for the MTP profile and 94% for the baseline, and fills it with KV cache. SGLang’s static share was 85–86%, and its DSpark profile ended the suite holding 26,494 MiB, about 4 GB less than vLLM’s baseline.
| Profile | VRAM after suite | Validated context |
|---|---|---|
| SGLang · D-Flash 2 | 29,150 MiB | 32K |
| SGLang · DSpark v2 | 26,494 MiB | 32K · 64K · 112K |
| vLLM · native MTP | 30,293 MiB | 32K |
| vLLM · baseline and long | 30,503 MiB | 32K · 64K · 128K · 262K |
The context ceiling followed the drafters. With no second model to hold, vLLM’s long profile could reserve the biggest windows: it read an 88,203-token prompt in 16.3 s and a 178,014-token prompt in 53.4 s, and recalled all three planted facts each time. SGLang’s DSpark profile, with its small drafter, validated 112K and read 77,187 tokens in 14.8 s. The fastest profile, D-Flash 2, stayed at 32K.
The real limit is the KV pool the loaded engine actually holds, not the number you pass at launch. One obvious-looking flag change on SGLang, a bigger prefill chunk, silently disabled the drafter’s CUDA graph: decode fell from about 109 to 19 tok/s. The repair then shrank the 114,688-token pool to 89,528. Gate every flag change on the startup log, the pool size and a real decode test.
§5Stability and start-up
All four profiles completed 5 of 5 repeated runs and passed the same recall, tool-call, vision, reasoning and quality checks. What differed was the spread: ±1.4 tok/s for vLLM without speculation, ±11.7 with MTP, ±20.2 for SGLang with DSpark and ±37.0 with D-Flash 2. Speculation makes speed depend on how predictable the text is, so a drafter’s headline number is the average of a wider range.
Switching profile has a cost too. From the switch to a verified ready server, measured once each that day: 33 s for SGLang D-Flash 2, 62 s for the vLLM baseline, 129 s for vLLM MTP and 136 s for SGLang DSpark. Treat those as orders of magnitude, because a warm file cache flatters whichever profile loads later. Plan for minutes, not seconds, if you swap engines on demand.
§6What actually decided it
- Drafters. SGLang ran an external drafter for this model (D-Flash 2) and a target-matched NVFP4 one (DSpark). vLLM drafted with the model’s own MTP head, so there was no second model to load. More acceptance bought more speed; the second model cost memory and steadiness.
- Tool calls. This model writes its tool calls in an XML format, and each engine needs its own parser for it:
qwen3_coderon SGLang,qwen3_xmlon vLLM. With the wrong parser both engines still return fluent text while the tool calls quietly fail to parse. Test a real tool call, not just a chat. - KV precision. Both ran an FP8 KV cache, which was effectively free here. A 4-bit cache is a different bet; the KV cache precision note shows why.
§7Which one to pick
- Fastest replies for one person: SGLang with a strong drafter.
- A drafter and long agent context on 32 GB: SGLang with a small target-matched drafter (DSpark here, at 112K).
- Speculation without a second model to manage: vLLM with the model’s MTP head.
- The longest windows, the steadiest numbers and a clean control: vLLM without speculation.
- Long documents: either engine. A stable, cached prefix matters more than the engine.
That is why I keep both, as named profiles for named jobs. The model-specific launch flags and the tuning traps are in the RTX 5090 serving recipes.
§8The questions people ask
Is SGLang faster than vLLM?
For generating text with a drafter, yes in these runs: 139.7 tok/s against vLLM’s best of 100.8 at the same 32K context. Most of that gap is the drafter. For reading long prompts, vLLM was slightly faster.
Which uses less GPU memory?
SGLang’s DSpark profile ended at 26,494 MiB, about 4 GB under vLLM’s baseline. Part of the difference is a setting: vLLM reserves a fixed share of the card up front.
Which handles longer context?
vLLM without speculation: 262K configured, with a 178,014-token prompt read in 53.4 s and full recall. SGLang validated 112K with its smaller drafter.
Which is better for agents and tool calling?
Both passed the same tool-call checks, each with the right parser for this model. For long agent sessions with a drafter I used SGLang with DSpark at 112K; for the longest single context, vLLM.
Can I reproduce these numbers?
The launch scripts, the benchmark harness and the raw runs are on GitHub. They are one person’s measurements on one card, and some flags were tuned after these runs, so re-measure on yours.
The comparison in one view
- There is no single winner: SGLang with a drafter for speed, vLLM for the longest window and the steadiest numbers.
- Compare engines with the acceleration you would actually run, and say so.
- Prompt speed is close and tunable; a cached prefix beats both engines.
- “VRAM used” is partly a setting; the KV pool the engine actually holds is the truth.
- Check a real tool call with the right parser before trusting any speed number.
How these figures were gathered. All numbers come from my own runs on one RTX 5090 (32 GB) on 22 August 2026: the same local benchmark suite, one request at a time, a warm server, and Qwen 3.8 27B in NVFP4 with an FP8 KV cache. The long-context rows come from three-needle recall tests at the stated prompt lengths. The DSpark chunk-size and MTP draft-token results come from later, separate passes, as noted.