Qwen3.8-27B vs Muse Glimmer 30B: Same 10/10, One Is 10× Faster

Two open models landed within days of each other, both sized for a single RTX 5090, both chasing the same job: agentic and coding work on hardware you own. Muse Glimmer 30B from Meta Superintelligence Labs, and Qwen3.8-27B from Alibaba.

So we put them on the same card — same quantisation, same llama.cpp build, same executable test suites — and let them race.

Neither model got a single task wrong. One of them finished ten times sooner.

The more useful finding is underneath that. We ran three independent suites — algorithm tasks, real production bug fixes, and 200 GSM8K word problems — and all three came out ties. The speed gap, meanwhile, is almost entirely one feature rather than one model being better, and it collapses from 10.6× to about 3× as soon as the work stops being textbook.

Update, 2026-08-22. The central claim below — that llama.cpp cannot drive Qwen3.8's built-in drafter — was wrong when we published it. The flag was already in the binary, and turning it on takes Qwen3.8 from 66 to roughly 150 tok/s on this same card, which closes most of the gap this article measures. Everything below still describes a non-speculating Qwen3.8 against a speculating Muse — which is what you get by default, and so still worth reading — but the 10.6× and "about 3×" headlines are no longer the state of the art. The correction, with measurements, is in Qwen3.8-27B Is 2.3× Faster With One Flag. The drafter section further down has been rewritten; the rest is unchanged.

The short version

Both are Q4_K_XL GGUF on llama.cpp 153d324bc, temperature 0, RTX 5090. They cannot both be resident — 24.5 GiB and 22.8 GiB do not fit in 32 GB — so every run alternated.

Coding: the suite cannot tell them apart

task                  Qwen3.8-27B      Muse Glimmer
two_sum                      PASS              PASS
binary_search                PASS              PASS
lru_cache                    PASS              PASS
edit_distance                PASS              PASS
merge_intervals              PASS              PASS
is_balanced                  PASS              PASS
parse_log                    PASS              PASS
spiral_order                 PASS              PASS
fix_bug                      PASS              PASS
group_anagrams               PASS              PASS
SCORE                       10/10             10/10
MEAN tok/s                   68.3             349.9
THINK tok (mean)              333               129

Every task is scored by executing the generated code against hidden assertions — pass or fail, no style marks.

Report the ceiling, not just the score. DeepSeek-V4-Flash also scores 10/10 on this suite, thinking on or off. When three models all score full marks, the suite has stopped measuring the models and started measuring itself. It is asking "can you do first-year algorithms," and everyone can. That is a regression check, not a ranking.

So the honest reading of that table is not that the two models are equally good at code. It is that neither is broken. Those are different claims, and only the second one is supported.

The harder suite did not discriminate either

So we built a harder one, from six real functions in a production codebase — each carrying the bug its own comment records as having actually happened.

A round where the code must floor to a tile boundary. A cache key missing the prompt. A reachability cache keyed on address but not credential. A dropdown filter that silently drops local rows. A unit-step off-by-one at exactly 1024. A resolver that raises on an unknown id instead of degrading gracefully.

These are not puzzles. They are mistakes that shipped. A self-test proves each planted bug fails the assertions and each reference fix passes them, before any model is asked.

task                    Qwen3.8-27B       Muse Glimmer
fit_patches                    PASS               PASS
cache_key                      PASS               PASS
reachable_cache                PASS               PASS
configured_rows                PASS               PASS
human_size                     PASS               PASS
engine_get                     PASS               PASS
SCORE                           6/6                6/6
MEAN tok/s                     70.4              209.6
THINK tok (mean)                420                452

6/6 each. The suite failed at its one job.

Which is a fact about the suite, not a verdict on the models — two 30B-class models fixed every bug a real codebase had shipped, first try, at temperature 0. Worth saying out loud, because a suite that saturates should be retired from ranking duty rather than quietly cited as a tie.

But the harder tasks moved the numbers, and that is the real result

Qwen3.8 decodes at the same rate whatever it is asked, because nothing is speculating for it. Muse loses nearly half its throughput, because DFlash acceptance falls when the target distribution is less predictable — harder problem, less guessable next token, fewer drafts accepted. Muse also overtakes Qwen3.8 in thinking tokens on these tasks, reversing the easy suite.

Muse's advantage is real but task-dependent, and it shrinks exactly where the work gets interesting — 10.6× on textbook algorithms, 3.4× on production bug-fixing, and 3.1× on GSM8K word problems. Three independent measurements now agree that roughly 3× is the honest figure for real work. Quoting the 10.6× would overstate it threefold.

General reasoning: GSM8K, 200 problems

Two saturated coding suites can always be blamed on badly chosen tasks. So the third test left code behind entirely: 200 grade-school word problems, same prompt, same scoring, temperature 0, max_tokens 3000, reasoning effort dialled to low on both.

A 1.5-point gap against a ±3.0-point confidence interval is not a result. Qwen3.8 is nominally ahead, and one of its three misses was an answer cut off at the 3,000-token ceiling rather than a wrong one — so its true score sits somewhere in 98.5–99%. That still does not clear the error bar. This is a third tie, not a win.

One detail is quietly impressive. Strict and flexible scoring agreed exactly for both models: every answer either arrived in the #### <number> format the prompt asked for, or was wrong. Neither model needed the lenient scorer to look good, and instruction-following was perfect across 400 answers.

GSM8K is saturated at this scale too. Grade-school maths separates two 2026-era 30B models no better than first-year algorithms did. Three suites, three ties — at some point that stops being a gap in the testing and starts being the finding: both models are correct on this class of work, and the choice is a speed and capability question rather than a quality one.

Muse is 3.1× faster on wall clock here. Narrower than the 10.6× on textbook code, close to the 3.4× on bug-fixing, and the third measurement now pointing at roughly 3× as the honest figure for real work.

The speed gap is real, and flattered

Where does 10.6× come from? Raw decode accounts for half of it — 349.9 against 68.3 is 5.1×. The token counts supply the rest: Qwen3.8 spends 5,308 tokens where Muse spends 2,561, for answers that pass the identical assertions. Faster per token, and fewer tokens.

Two things inflate Muse's half, and both deserve stating.

Temperature 0. Muse's DFlash drafter measures 434.75 tok/s on code at temperature 0 against 231.58 at Meta's recommended sampling — a 47% drop, because draft acceptance is highest under greedy decoding. This harness uses temperature 0 for reproducibility, so Muse is being measured near its best case. At realistic sampling the gap narrows to roughly 3×.

The drafter is the entire gap. Muse's no-drafter baseline is 77.2 tok/s — within 13% of Qwen3.8's 68.3. The two models decode at almost the same speed. What separates them is that one has a working speculative decoder and the other does not.

That reframes the whole comparison. This is not a story about one model being faster. It is a story about one model having a feature the other's runtime cannot use.

Qwen3.8 ships a drafter, and llama.cpp does drive it — corrected

This section originally said the opposite, and it was the most consequential error in this article.

What we published was that Qwen3.8's checkpoint contains a multi-token-prediction head — mtp_num_hidden_layers: 1, fifteen tensors surviving quantisation at block 64 — which llama.cpp discards at load with a one-line notice:

unused tensor blk.64.nextn.* -- ignoring

That notice is real. The inference we drew from it was not. llama.cpp implements the MTP head; it simply does not use it unless you ask, and the asking is --spec-type draft-mtp. There is no draft file and no second set of weights — the drafter ships inside the checkpoint. We read a loader message, wrote down "unimplemented", and quoted our own note forward for weeks without once testing it.

Turning it on lifts Qwen3.8 from 66.29 tok/s to between 146.8 and 158.7, a 2.21× to 2.39× range on the same card and the same build used here. Against Muse's 349.9 tok/s on the algorithm suite that is still a gap, but a far smaller one — and on the harder bug-fix workload, where Muse's own DFlash acceptance falls away, the two land much closer to parity than the table above implies. We have not re-run the full head-to-head with MTP engaged; when we do, it will be a new article rather than an edit to this one.

So the sentence this section used to end on — "if llama.cpp ever implements the MTP head, this comparison changes shape rather than degree" — was right about the consequence and wrong about the tense. It already had. What remains true is the framing: the hardware was never the limit here, and neither was the model. Anyone reporting "Qwen3.8 is slow" is reporting a default, not a ceiling.

vLLM registers the same head as Qwen3_5MTP. It is the same class of trick DeepSeek-V4-Flash uses with DSpark, where we measured 4.86 accepted tokens per step — a drafter living inside the checkpoint rather than beside it. The full measurements, including what MTP costs in VRAM, what it does to vision latency, and why DFlash2 is the wrong answer for this model despite being faster, are in Qwen3.8-27B Is 2.3× Faster With One Flag.

The architectures are not the same shape

The two models look similar on a spec sheet and are built quite differently underneath, which explains both the context figures and part of the speed.

Muse Glimmer is a conventional dense transformer. Qwen3.8 is a hybrid: 64 layers in a repeating period of four — three Gated DeltaNet (linear attention) layers, then one full-attention layer.

Only 16 of 64 layers hold a KV cache, which is what lets a 27B model serve 128K context inside a 32 GB card at all. A conventional 27B would need roughly 34 GB of KV alone at that length and simply would not fit.

The hybrid costs something on the other side. Measured against the 5090's 1,792 GB/s of bandwidth:

Seven points of bandwidth efficiency, most plausibly the hybrid itself — more layers, and the Gated DeltaNet path is recurrence and gating rather than the clean large matrix multiplies a dense attention block reduces to.

There is a practical lesson in that gap for anyone estimating throughput from a spec sheet: anchoring a prediction across architectures is worth about ±15%; anchoring within one is tighter. Our own prediction for Qwen3.8, scaled from Muse's measured figure, came out 13% high for exactly this reason.

Fidelity: a flaw that does not reproduce in text

Qwen3.8 has a habit worth knowing about: it tidies up.

Shown a document printing the brand Bascus, it produced Baseus — the real company, correctly spelled, and not what was on the page. It did this in both runs, against an explicit instruction not to correct spelling. The model was being helpful in precisely the way you do not want when the job is transcription.

We built a text-only version of that test: eight lines each containing something a helpful model wants to fix — a misspelling, a letter/digit confusion, an inserted hyphen, and a subtotal whose arithmetic is deliberately wrong.

Both perfect — including Subtotal 2,390 + 2,590 = 4,970, which neither model corrected.

So the tidy-up is not a general instruction-following weakness. Given clean text and told to copy it, Qwen3.8 copies it. The failure is specific to the vision path: when a glyph is ambiguous the model resolves it toward a plausible word rather than toward what the pixels say, and no instruction prevents that, because the model does not experience it as disobedience.

That narrows the risk usefully without removing it. If your input is pixels, this is a real exposure. If your input is text, it is not.

The benchmarks that do separate them

Our suites tie. Alibaba's do not.

Its launch table for Qwen3.8-27B includes a Muse Glimmer-30B column, and on the harder agentic benchmarks the gap is not subtle:

Read that as a vendor table, because it is one. Alibaba chose the benchmarks, ran both models, and published the result — and the rows where Muse Glimmer leads are simply not in it. Meta's own launch table put Muse ahead of the Qwen line on MCP Atlas, 75.5 against 62.5. Each vendor picks the ground it wins on. That is not dishonesty, it is marketing, and it is why we run our own tests.

Two things make this table worth citing anyway.

It corroborates a figure we hedged. When we covered Muse Glimmer we quoted its Terminal Bench 2.1 score as "~51.7, community testing, treat as directional" because no vendor had published one. Alibaba's table reports 51.7. An independently arrived-at match on a number we flagged as soft is worth more than either source alone.

The gaps survive discounting. Twenty-one points on terminal coding and ten on SWE-bench Pro are wide enough that even a sceptical haircut leaves them pointing the same way.

So this does not contradict our results — it explains them. Our three suites saturated because they ask whether a model can do first-year algorithms, fix a shipped bug, and solve grade-school arithmetic. Both models can. Benchmarks built to be hard in 2026 — multi-step terminal work, repository-scale patches — still have room, and there Qwen3.8 is ahead.

The honest synthesis: on the work we could measure, the two are interchangeable and Muse is roughly three times faster. On work hard enough to still discriminate, the published evidence favours Qwen3.8. Where your own tasks fall on that line is the question worth answering, and it is not one a benchmark table can answer for you.

Which one to run

With three measurements of our own, plus the vendor numbers above, the decision rule is clearer than any single figure:

Muse Glimmer, for code and general text — on speed, not on quality. Roughly three times the throughput on realistic work, 131,072 context against 65,536 as served, and a drafter that verifiably works. That three-times figure assumes a Qwen3.8 with no drafter engaged; with --spec-type draft-mtp on, most of it goes away, and this bullet is the part of the recommendation that the update at the top revises. What that buys is output of equal measured correctness produced sooner. On saturated suites, "equal measured correctness" means only that neither is broken — and on the harder published benchmarks it is Qwen3.8 that leads.

Qwen3.8-27B, when there is an image. It carries a 27-layer vision tower and reads documents well — it beat Qwen3-VL 32B on a hard scan at four to six times its speed. Muse ships a projector and can be started with vision at about +3.6 GiB, but it was not built as a document reader and has not been measured as one.

Qwen3.8-27B, when you need context beyond 128K. 262,144 native, and up to a million with YaRN. Nothing in this comparison exercised that, but it is a capability the other model does not have.

Not both at once. 24.5 + 22.8 GiB does not fit in 32 GB. On a single 5090 this is an either/or, and switching means restarting a server.

What we did not test

Being explicit about this, because two saturated suites invite over-reading:

• Which model is actually better, measured by us. Sixteen coding tasks each, plus 200 GSM8K problems each: three suites, three ties. A discriminating benchmark needs tasks at least one current model fails, and after three attempts none of ours qualified. The vendor figures above fill that gap with someone else's evidence — useful, but not ours, and selected by a party with an interest in the answer.
• Long-context comprehension. Every suite here asked short questions. 65,536 against 131,072 is a difference nothing exercised, and with three saturated suites behind us it is now the most promising untried axis — the one place the two models have a structural difference rather than a measured one.
• Muse with vision enabled, which would decide whether Qwen3.8 is needed on this card at all.
• Non-English documents. Qwen3.8's OCR was checked on English only.

One note on method, since it changed a number: an unrelated GPU job appeared on the card minutes into the first bug-fix runs, so both were repeated on a verified-clean machine. Qwen3.8 went 69.2 → 70.4 tok/s (+1.7%), Muse 192.8 → 209.6 (+8.7%), scores 6/6 either way. Contention had understated Muse by about 9%. Worth knowing that VRAM is not evictable — a late-arriving job cannot take an allocation llama-server already holds, so the only available contamination was SM contention, which can only ever make a number worse.

Related reading

• Qwen3.8-27B Is 2.3× Faster With One Flag — Do You Need DFlash2? — the flag that corrects this comparison, measured
• How to Run Meta Muse Glimmer 30B on an RTX 5090 — the full measurements behind Muse's half of this comparison
• Qwen 3.6 27B: a Local Coding Model You Can Actually Run — the previous generation of Qwen's local coding model
• DeepSeek-V4-Flash on Two GB10s: 304B Params, 1M Context, 83 Watts — the third model that scores 10/10 on this suite
• AI Workstation Comparison: RTX 5090 vs GB10 (HP ZGX) — choosing the hardware underneath
• Will This LLM Fit My GPU? VRAM Requirements for Every Model Size — the arithmetic behind "they cannot both be resident"