How fast is Qwen3.8-27B really? What local benchmarks actually show

Updated 18 September 2026

"Qwen3.8-27B gets 40 tokens a second" and "Qwen3.8-27B gets 127 tokens a second" are both true statements, about the same model, sometimes on the same GPU. The gap isn't the hardware. It's almost entirely how much engineering work went into the serving setup, and most people never see the high end of that range.

One model, four very different numbers

Independent local benchmarks for Qwen3.8-27B, run on a single 24GB-class consumer card, land anywhere from the mid-30s to the low 40s tokens/second with a default setup, up past 120 with a heavily customized one. NeverMetered's own measured speed for the same model on its hosted servers is 42 tokens/second on a single stream, published on the model page alongside the benchmark scores. That's not a coincidence worth hiding: it sits right in the default-setup range, not the tuned one, and it's worth explaining exactly why.

Single-stream tokens/second for Qwen3.8-27B, same model, same class of 24GB consumer GPU, at increasing levels of setup effort. NeverMetered's hosted figure sits close to what a default local setup gets.

What a default local setup actually gets you

Run Qwen3.8-27B with a common, off-the-shelf local inference stack on a 24GB-class card and independent tests report just over 40 tokens/second at short context, dropping to somewhere in the mid-30s once the context grows to 64K tokens. That's the number most people running this model locally actually see: whatever a popular inference tool does by default, with no custom patches, no speculative decoding, no requantization work.

What tuning buys you, and what it costs

The higher numbers are real, and they come from real engineering, not a different GPU. One documented technique, speculative decoding via multi-token prediction (MTP), lifts the same default setup from about 41.6 to 66.4 tokens/second on the same card, a 59.8% jump. That's a meaningful, achievable upgrade for someone willing to enable and tune it.

The high end of the range, 114 to 127 tokens/second single-stream, comes from a much deeper project: a patch series against a specific inference engine build, a requantized model head, a calibrated draft vocabulary for speculative decoding, and split-KV verification attention, published as an open GitHub project specifically to reach that number on one 24GB-class card. It's real and reproducible if you follow the recipe. It is also not what you get by installing the tool and running it, and a mainstream hardware outlet covering this same model reached a similar conclusion independently: raw VRAM capacity isn't the bottleneck, the inference engine and how well it's tuned is.

Where hosted sits, and the actual tradeoff

A shared, multi-tenant hosted service is architecturally closer to the default case than the tuned one, and that's a fair thing to be upfront about. NeverMetered's 42 tokens/second single-stream figure isn't the theoretical ceiling for this model, the custom-tuned local setup runs meaningfully faster on the same class of card. What hosted setup trades for that: no patch series to apply, no model requantization to run yourself, and real parallel capacity instead of one exclusive stream, up to 8 concurrent requests per server rather than a single GPU serving one session at a time. If you're the kind of person who'd actually build and maintain the tuned setup, the honest advice is to do it, you'll likely beat a shared hosted service on raw single-stream speed. If you'd rather not run an inference stack at all, current plans show what the flat-rate version costs instead.

Is NeverMetered's speed figure directly comparable to these local benchmarks?
Roughly, with a caveat: these are all single-stream numbers on a 24GB-class card, which is the fairest comparison, but exact figures depend on quantization, context length, and prompt content, so treat any of these as a ballpark rather than a lab-controlled result.
Why doesn't NeverMetered apply the same tuning a custom GitHub project uses?
Some of it, like better quantization and KV-cache handling, already factors into how the servers are run. The most aggressive techniques, like a custom draft vocabulary calibrated for one exact use case, are built for a single dedicated GPU serving one user; they don't translate directly to a server sharing capacity across multiple concurrent requests the same way.
Does speculative decoding (MTP) work the same way for coding tasks?
The published gains are on general benchmarks; agentic coding workloads that read a lot of file content and vary output length turn by turn may see a different real-world uplift than a controlled benchmark does. Worth testing on your own workload before assuming the full 59.8% carries over.
If I want the fastest possible local Qwen3.8-27B, what should I look at?
The GitHub project cited above documents the full patch series and requantization steps for reaching the highest reported single-stream numbers on a 24GB-class card. It's a real, from-scratch inference engineering project, not a toggle.
Does slower single-stream speed matter if I run multiple agents at once?
Less than you'd think for that case specifically. A single dedicated GPU serves one stream at a time; going from 1 to 3 concurrent local sessions on the same card generally means each one gets a smaller share of that one GPU's throughput. A server built for concurrent requests, hosted or self-run, handles parallel sessions differently than a single consumer card does.