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

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

We ran both on the same card, same quantisation, same llama.cpp build, against the same executable test suites. The headline is that neither model gets a coding task wrong, and one of them finishes ten times sooner.

The more useful finding is underneath that: the gap is real, it is almost entirely one feature rather than one model being better, and it shrinks by three-fold the moment the work stops being textbook.

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. Three models at full marks means the suite is measuring "can you do first-year algorithms," and all three can. It 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

To break the tie we built a second suite from six real functions taken from 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 without credential, a dropdown filter that silently drops local rows, a unit-step off-by-one at exactly 1024, and a resolver that raises on an unknown id instead of degrading. 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. That is a fact about the suite rather than a finding about the models — two 30B-class models fixed every bug a production codebase actually shipped, first try, at temperature 0. Worth recording, 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. Extrapolating the first number to real work would overstate it by three-fold.

The speed gap is real, and flattered

349.9 against 68.3 is 5.1×, and the token counts double it: Qwen3.8 spends 5,308 tokens where Muse spends 2,561 for answers that pass the same assertions. That is where 10.6× on wall clock comes from.

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 that llama.cpp throws away

Qwen3.8 does not lack speculation. Its checkpoint contains a multi-token-prediction head — mtp_num_hidden_layers: 1 — and llama.cpp discards it at load with a one-line notice:

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

vLLM registers it 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.

So if llama.cpp ever implements the MTP head, this comparison changes shape rather than degree. The hardware is not the limit here; the loader is. Anyone reporting "Qwen3.8 is slow" is really reporting "llama.cpp doesn't drive Qwen3.8's drafter yet," and those will stop being the same statement.

The architectures are not the same shape

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 documented tendency to tidy its input. On a document scan it rendered a brand printed as Bascus into the real-world Baseus, in both runs, against an explicit instruction not to correct spelling.

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.

Which one to run

Muse Glimmer, for code and long text — on speed, not on quality. Ten times the throughput on the easy suite, three times on the hard one, 131,072 context against 65,536 as served, and a drafter that verifiably works. What that buys is code of equal measured correctness produced far sooner. On a saturated suite, "equal measured correctness" means only that neither is broken.

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 writes better code. Twelve tasks across two suites, thirty-two of thirty-two passed between them. The honest decision rule is choose on speed and context, because correctness did not separate them — not they are equally good, which neither suite can support. A discriminating benchmark needs tasks at least one current model fails, and after two attempts none of the obvious candidates qualify.
• Long-context comprehension. Both were asked short questions. 65,536 against 131,072 is a difference nothing here exercised, and it is the most promising untried axis.
• 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

• 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"