Muse Glimmer 30B: 4× Faster Than a 304B Model, and 22% Slower — By Default

Meta Superintelligence Labs released Muse Glimmer on 10 August 2026: 30 billion parameters, Apache 2.0, and small enough to run on a single RTX 5090 at its full 131,072-token context. It is distilled from Muse Spark, and it is built for one job — agentic workloads on hardware you own.

We ran it against DeepSeek-V4-Flash — a 304B mixture-of-experts model spread across two GB10 machines — over the same ten Python tasks, each scored by executing the generated code against hidden assertions. Both models went 10 out of 10. Muse Glimmer decoded four times faster, 268.3 tokens per second against 67.8, and finished the set 22% slower: 27.16 seconds against 22.34. It spends the entire advantage on thinking tokens.

Then we found the setting that undoes it. Muse Glimmer ships with reasoning effort on high; drop it to low and the same ten tasks finish in 7.92 seconds — 2.82× faster than V4-Flash, still 10 out of 10, with no task regressing. The most consequential performance setting on this model is not the quantisation, the drafter or the hardware. It is a string in the chat template that almost nobody documents.

That is the most useful thing we learned, and the reason to distrust any benchmark number quoted without the settings that produced it — including two of our own, which we correct below. The comparison is below, along with why a model ten times smaller ties at all.

The rest is what it takes to run the thing: VRAM, the build, and the exact llama.cpp invocation — including one flag that silently costs you most of your throughput if you leave it out.

How to run Muse Glimmer 30B on an RTX 5090

What you need: VRAM and file sizes

Real file sizes, not estimates:

Minimum: 16 GB. A 3-bit quant plus a small KV cache will load. Expect quality loss — Meta's own figures put their 24 GB-target quant at about 1.0% average degradation against 0.2% for the 32 GB one, and below 3-bit it gets worse quickly.

Recommended: 32 GB. On an RTX 5090 we measured 20,489 MiB with the model loaded at the full 131,072-token context, and 22,792 MiB with the speculative drafter resident as well. That leaves real headroom. This is the configuration the model was designed for.

24 GB (RTX 4090, 3090) should work at 4-bit — weights, drafter and KV come to roughly 19 GiB before compute buffers — but use the k-quantised vision projector rather than the BF16 one, and expect to trim context. We did not test this directly.

Full precision needs 55+ GB, so a DGX Spark, a GB10 machine, or multiple cards.

A note on "4-bit," because three different numbers circulate and they are not the same thing: the GGUF k-quant is 14.79 GiB, Meta's mixed NVFP4/MXFP8 recipe is 18.3 GiB, and vLLM's NVFP4 W4A4 checkpoint is 25.42 GB. Always say which one you mean. That last one matters practically — vLLM's NVFP4 plus its drafter comes to about 28.4 GiB of weights, which does not leave room for a KV cache on a 32 GB card. On consumer hardware, llama.cpp is the better route — and unsloth's own NVFP4 guide currently carries a "work in progress, does not work for now" banner, which is independent confirmation rather than just our preference. (If you want the arithmetic behind these numbers, we wrote it up in Will This LLM Fit My GPU?.)

Getting the weights

Start with the thing that will not work: ollama pull muse-glimmer:30b-q4_K_M returns HTTP 412 on Ollama 0.32.7, the newest public stable release at the time of writing. Upgrading does not help, because no public build has the required support yet — llama.cpp merged Muse Glimmer on 10 August, the same day Ollama 0.32.7 shipped, and Ollama vendors llama.cpp at an earlier commit.

The manifest is fetchable with plain curl, so it is tempting to assemble the blobs by hand. Don't. The registry is gating on a capability the client genuinely lacks. The model would load and produce fluent text on an engine with no implementation of the NoPE global-attention layer — plausible output with silently broken long-range attention, which is far worse than a clean failure.

Build llama.cpp from source instead. On a current Linux box with CUDA installed it took us four minutes:

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=120
cmake --build build --config Release -j

120 targets sm_120a, which is Blackwell — adjust for your card. You need a commit at or after 62bf73d2 ("model: Muse Glimmer Support", PR #26841). Pull the UD-Q4_K_XL GGUF and the dflash-kquant.gguf drafter from Hugging Face.

The command that actually works

llama-server -m Muse-Glimmer-30B-UD-Q4_K_XL.gguf \
             -md dflash-kquant.gguf \
             -ngl 99 -ngld 99 -c 131072 \
             --spec-type draft-dflash --spec-draft-n-max 16

On load it reports block_size=16, mask_token_id=201818, n_extract=5 and clamps n_max from 16 to 15, warning that the request "exceeds the trained block size." That 15 is exactly the num_speculative_tokens value vLLM's own recipe documents — the two stacks agree on the drafter's real geometry, which is a good sign you are on the right path.

Three traps that silently disable speculation

This is the part worth the most to anyone repeating this. All three failure modes produce a working server that does not speculate, running at exactly baseline throughput, with no error message.

1. --spec-type draft-dflash is mandatory, and it defaults to none. Passing -md dflash-kquant.gguf alone loads the draft model, logs "loading draft model," allocates memory for it, and never speculates. The only symptom is a single INFO line at verbosity 5: no implementations specified for speculative decoding. A recent refactor made the implementation explicit, which means every tutorial written before it is now wrong.

2. Flags were renamed. --draft-max and --draft-min have been removed in favour of --spec-draft-n-max and --spec-draft-n-min. --ctx-size-draft does not exist at all and will abort startup.

3. Verify rather than assume. GET /slots reports "speculative": true or false per slot. Check that field before recording a single number. It is the only cheap ground truth, and it is how we caught this.

What you actually get

Everything above this line you could have worked out from documentation. What follows is ours.

Setup

llama.cpp  HEAD 153d324b (contains 62bf73d2, "model: Muse Glimmer Support" #26841)
build      -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=120  → sm_120a
           CUDA 13.3.73, GCC 15.3.0 host compiler, ~4 minutes on 24 cores
model      Muse-Glimmer-30B-UD-Q4_K_XL.gguf (14.79 GiB)
drafter    dflash-kquant.gguf (1.52 GiB)
GPU        RTX 5090, 32,146 MiB, driver 610.43.03
server     llama-server -ngl 99 -c 131072

Method: /completion with n_predict: 256, ignore_eos: true, cache_prompt: false. One warm-up run discarded, then three repeats per workload. Fixing the output length means every run generates exactly 256 tokens, so decode rate is comparable across workloads.

We ran everything twice: at temperature 0, for reproducibility, and at Meta's recommended temperature 1.0 / top_p 0.95 / top_k 64. That mattered more than we expected, and both regimes are reported below. Reasoning effort sat at its default of high for these decode measurements — it does not change the decode rate, only how many tokens get generated, which turns out to be a separate and larger finding. One warm-up run discarded, then three repeats per workload. Fixing the output length means every run generates exactly 256 tokens, so decode rate is comparable across workloads.

Baseline: drafter off

Spread: 1.003×. Flat to a third of one percent.

Two things to say honestly about this. First, it validates the bench: Meta publishes 74.9 tok/s as its no-drafter figure for a 5090, and we measured 77 with no tuning. Agreement that close means the rig is measuring the real thing.

Second, this flatness is a control, not a discovery. With fixed output length and no speculation, every token costs exactly one forward pass through the same weights. Flat is what theory predicts. Its value is not that it is surprising — it is that it makes the next measurement airtight.

Why speculation helps at all

Before the numbers, it is worth understanding why this trick works, because the reason is counterintuitive and it explains everything that follows.

Generating a token is not limited by arithmetic. It is limited by memory bandwidth. To produce one single token, the GPU must read every active weight out of VRAM — for Muse Glimmer at 4-bit, that is 14.8 GiB moved across the memory bus to emit perhaps two characters of text. While that transfer happens, the card's arithmetic units are mostly idle. You are paying for a lorry to deliver one envelope.

Which leads to the useful observation: checking sixteen tokens costs almost the same as generating one. The weights get read once either way. Verifying a batch just makes each matrix multiplication slightly wider, and extra arithmetic is nearly free when bandwidth is the bottleneck. The lorry was going to make the trip regardless, so you may as well fill it.

Speculative decoding exploits exactly that. A small, cheap drafter model guesses the next block of tokens — DFlash proposes sixteen at a time. The full model then reads its weights once and checks all sixteen guesses simultaneously. Every guess it agrees with is a token you got for free.

Two things follow, and both matter:

The output does not change. This is not an approximation or a quality trade. The large model only accepts tokens it would have generated itself, and discards the rest. You get identical text, sooner.

The benefit depends entirely on how good the guesses are. That is the acceptance rate, and it is a property of the content, not the hardware. Boilerplate, JSON and idiomatic code are highly predictable, so most guesses survive and you collect many tokens per pass. Original prose is not, so more guesses are discarded and you slide back toward one token per pass — which is exactly the un-accelerated case.

So speculation converts predictability into speed. Hold that thought while reading the next table.

Drafter on

Same script, same server, one flag changed. Temperature 0 throughout — hold that thought, it turns out to be worth 47%.

Standard deviation stayed at or below 1.44 tok/s on every cell.

Identical dense weights on an identical machine go from perfectly flat latency to a 3.0× content spread, with speculative decoding as the only variable.

This is the acceptance rate made visible. Code is the most predictable thing a language model writes, so the drafter's guesses mostly survive and the tokens arrive in batches. Prose is the least predictable, so more guesses are thrown away and the model slides back toward one token per pass. The spread is not a quirk of the implementation — it is what speculation fundamentally does. Any model with a drafter will show it. Ours simply has a clean enough baseline to prove it.

Two secondary results:

Sampling moves this as much as content does. Every figure above is at temperature 0. At Meta's recommended sampling the same runs look materially different:

As speedups over the 77.2 tok/s baseline: code falls from 5.64× to 3.00×, structured from 3.35× to 2.77×, prose from 1.87× to 1.27×. Run-to-run standard deviation also rose from ≤1.44 tok/s to between 8.7 and 25.1, because acceptance now varies with sampling instead of being pinned by greedy decoding.

The cause is the same acceptance rate as before. Greedy decoding is the friendliest possible case for a drafter — it only has to match the single most likely token. Widen the distribution and more proposals get rejected.

This corrects something we got wrong. An earlier version of this article said Meta undersells its own drafter, on the grounds that they publish 3.1× and we measured 5.64×. That gap was entirely an artifact of our temperature. At Meta's own recommended settings we measure 3.00× on code — their published figure. The vendor number is accurate and was presumably taken at the sampling they recommend.

The surviving claim is the more useful one: a speculative speedup is meaningless without the temperature beside it. The same model, drafter and hardware give 5.64× or 3.00× on the same workload depending on one sampling parameter.

Speculation never loses. The worst case — prose at temperature 1.0 — is still 1.27×, and at temperature 0 the worst case is 1.87×. The trade is not speed against risk; it is how much you win.

Reasoning effort is a dial, and almost nobody turns it

This is the single most useful thing we found, and it is undocumented in the places most people will look.

Muse Glimmer's chat template accepts a reasoning_strength variable with four settings — low, medium, high, xhigh. You can set it per request through llama.cpp's chat_template_kwargs:

{"model": "muse-glimmer-30b", "messages": [...],
 "chat_template_kwargs": {"reasoning_strength": "low"}}

Same prompt, temperature 0, drafter on:

low is 3.9× faster end to end than the default, and its answer is not shorter — 359 characters against 306. Thinking scales roughly 5× across the range while the answer stays flat at 310–360 characters. On this prompt, every second beyond the first was spent deliberating toward the same result.

That will not hold on genuinely hard problems, which is what the higher settings are for. But it means the default is a poor choice for the routine work that fills most of a coding session, and switching to low costs one line of JSON.

One thing we checked rather than assumed: a single-prompt probe initially suggested the default behaved like xhigh rather than the high its template claims. Across the full ten-task set the two came out at 27.16 s and 27.06 s — a 0.4% difference. The default is high, exactly as documented; the earlier discrepancy was single-prompt variance.

Two more things that will bite you

It is a reasoning model, and it will break your harness. The API returns content and reasoning_content separately. Asked to reverse a string, it produced 826 characters of deliberation and 67 characters of code. At max_tokens: 150, content came back completely empty with finish_reason: length — the thinking consumed the entire budget. A test harness that reads content and caps tokens conservatively will score zero and report it as model failure. Raise the limit, and treat finish_reason: length as an invalid run rather than a wrong answer.

Prefix caching is on by default. Our second identical request reported 68 of 73 prompt tokens served from cache. For single-stream decode measurements this is harmless, but for concurrency testing it will inflate your results — it is exactly what distorted one of our figures in the V4-Flash writeup. Use distinct prompts or disable it.

A dead end, documented

Our first hypothesis for why speculation was off was that sliding-window attention blocks the partial sequence removal that speculative decoding needs. We tested --swa-full, which makes the windowed layers keep a full cache.

It did not enable speculation. But VRAM rose from 20,567 to 25,181 MiB — +4.6 GiB, against the +4.8 GiB our KV arithmetic predicted for switching 39 windowed layers to full attention. A wrong hypothesis that independently confirmed the memory model. Leave --swa-full off: it costs 4.6 GiB and buys nothing here.

What is actually inside it

The important architectural fact is that Muse Glimmer is dense. Every parameter participates in every token. There is no routing, no expert selection, no per-token variance in which weights get touched. That is a deliberate reversal of the industry's direction of travel, and Meta is explicit about why — predictable behaviour on fixed local hardware matters more, for this use case, than the efficiency sparsity buys you.

It is also quietly multimodal. A roughly 1.8B-parameter ViT-G/14 perception encoder handles image input, up to 4,096 visual tokens per image. Text and images in, text out. No audio, and despite what you may read elsewhere, no video — more on that below. Context is 131,072 tokens. Vocabulary is 202,048. Knowledge cutoff is 4 January 2026.

The lineage, written in the source

Here is something you can verify yourself, because the receipt is in the source. Open modular_muse_glimmer.py in Hugging Face transformers and the model's ancestry is written out in the class declarations:

A 2026 open model assembled from parts of five other open models. The Gemma 2 fingerprint is still visible in the config — final_logit_softcapping: 20.0.

One caveat, and it matters: modular_*.py is a code-generation convention. Subclassing means "architecturally close enough to reuse the implementation," not "Meta copied anyone's weights." This is a claim about shape, not provenance.

The cleanest illustration of that distinction is the video processor. The transformers implementation defines MuseGlimmerVideoProcessor and a patch_temporal setting, which looks like video support. It isn't. That plumbing is inherited from the Kimi K2.5 wrapper, which does do video. Muse Glimmer's model card says image and text in, text out. Inherited code is not a capability.

Why it fits on one card

Three layers of local attention with a 2,048-token sliding window and rotary position embeddings, then a fourth layer of full attention with no positional embedding at all. That pattern repeats across all 52 layers. Combine it with grouped-query attention at an aggressive 32 query heads to 2 key-value heads, and the KV cache gets remarkably small.

Per token, per layer: 2 KV heads × 128 head dimensions × 2 (K and V) × 2 bytes = 1 KiB at FP16. With 13 global layers and 39 windowed ones:

• Global: 13 × 131,072 × 1 KiB ≈ 1.63 GiB
• Local: 39 × 2,048 × 1 KiB ≈ 0.08 GiB
• Full 128K context: about 1.7 GiB

That is why a 30B model at full context leaves headroom on a 32 GB card — and it is not the reason most people assume. The weights are the big number; the context is almost free.

It is worth being concrete, because the natural assumption is that a 128K window must be what fills the card. It isn't. Weights, drafter and the entire 131,072-token context together measured 22,792 MiB of the 5090's 32,146 MiB — about 9 GiB spare. You can run the full window and still load the BF16 vision projector on top. What does not fit is a different quantisation, not a longer context: vLLM's NVFP4 checkpoint plus its drafter is roughly 28.4 GiB of weights before a single token of KV cache.

How it compares on benchmarks

Tool calling is the headline strength. On MCP Atlas, Muse Glimmer scores 75.5 against Gemma4-31B's 54.2 and Qwen3.6-27B's 62.5. That is not a rounding-error lead, and it lines up with what practitioners reported within a day of release. For agentic work, where a model has to hold a schema across a long multi-step workflow and recover when a call fails, this is the metric that decides whether the thing is usable.

Reasoning is terse. It emits thinking traces, but short ones, without the circular self-correction loops that make some competitors expensive to run.

Long-context handling holds up — 80.0 on AA-LCR, which is respectable for a model this size, and interesting given that 39 of its 52 layers only ever see a 2,048-token window.

The honest comparison is Qwen3.6-27B. It is dense, it fits the same card, and it is the model Meta chose to benchmark against. The result is genuinely split, which is more useful than a clean win would be:

Muse Glimmer wins tool calling decisively. Qwen wins computer-use and terminal work. Pick on workload, not on a headline.

Two warnings about numbers you will see quoted elsewhere. First, SWE-Bench Pro is not SWE-Bench Verified — Muse Glimmer's 51.2 is Pro, Qwen's 77.2 is Verified, and several outlets have already put them side by side as though they were comparable. They are not. Second, the TerminalBench figure above comes from community testing rather than a vendor table, so treat it as directional.

If you are comparing on the vision axis instead, the local match is Qwen3-VL 32B — a different model from Qwen3.6-27B, and worth keeping straight.

What to use it for

• Local coding agents. The intended use, and where our measurements land best.
• MCP and tool-calling agents. Its strongest benchmark by a wide margin.
• LLM-as-a-judge and evaluation pipelines, where sending data to an API is either expensive at volume or not allowed.
• Document and screenshot understanding, via the vision encoder.
• Always-on background agents, where a model that stays resident on your own hardware beats per-token billing.

It is not a frontier model, and it is not trying to be. It is a model you leave running.

Muse Glimmer against DeepSeek-V4-Flash

These are about as different as two local deployments get. V4-Flash is a 304B sparse mixture-of-experts model spread across two GB10 machines with unified memory. Muse Glimmer is 30B dense on one consumer graphics card. Ten times the parameters, two machines instead of one, sparse instead of dense.

The spread, and what we got wrong about MoE

When we benchmarked V4-Flash we found a 2.7× spread in throughput depending on content, and attributed it to mixture-of-experts routing: different tokens activate different experts, so throughput varies.

That test could not isolate the variable. V4-Flash is sparse and uses speculative decoding, and you cannot turn the sparsity off. Muse Glimmer settles it, because it is dense — sparsity is out of the picture entirely — and its DFlash drafter ships as a separate file you can simply not load.

The dense model with speculation is more content-sensitive than the sparse model it was supposed to contrast with — at matched greedy sampling. A dense model, where routing cannot possibly be a factor, produces a larger spread the moment speculation is switched on, and a flat one when it is switched off. Our original reading was reasonable and we think it was wrong. The far simpler explanation is that both models were measuring the same thing: draft acceptance rate.

There is a corroborating detail in the llama.cpp source. The DFlash architecture Muse Glimmer uses is not new — the implementation carries explicit handling for "DSV4 DSpark drafters," meaning the same family of block-speculation machinery was built for DeepSeek-V4 first. The two models we compared were not just both using speculation; they were using close relatives of the same technique.

Some care is required here. The two runs used different hardware, different quantisation and different serving stacks, so we are deliberately not comparing absolute tokens per second between them — those numbers do not survive the change of setup. The spread ratio does, because it is normalised within each model: it is that model's fastest workload divided by its slowest, on its own hardware. That is the only figure we are putting side by side.

One honest qualification, since this article's own lesson is to state your settings. The spread ratio is sampling-dependent too: at Meta's recommended temperature 1.0, Muse Glimmer's spread falls to 2.365×, which is below V4-Flash's 2.7× rather than above it. So "dense spreads wider than sparse" holds at temperature 0 and narrows at recommended sampling. What does not depend on any of that is the finding underneath it: the drafter-off control is flat to 0.3% regardless, so the spread is produced by speculation and not by routing. That conclusion survives the sampling change; the league table of which model spreads more does not.

The same ten coding tasks, on both machines

We did run both models through an identical test: ten Python problems, each scored by executing the generated code against hidden assertions. Not style marks — pass or fail. Muse Glimmer local on the 5090 with its drafter enabled, V4-Flash live on the dual GB10 over a LAN with sub-millisecond latency.

Both scored 10 out of 10. The interesting result is underneath that tie.

Muse Glimmer decodes four times faster and finishes twenty-two percent slower.

Both models ran at their default settings — the fairest like-for-like comparison, and what anyone gets out of the box. Hold onto that qualifier. It turns out to be doing an enormous amount of work.

It spends the entire advantage on thinking. The starkest case was the bug-fixing task: 2,227 output tokens, of which 1,814 were reasoning. A 3.4× decode-rate advantage turned into a 6.4× wall-clock defeat — 10.15 seconds against 1.58. On four of the ten tasks Muse Glimmer did finish first, most convincingly on the LRU cache implementation, so this is not a uniform loss. But across the set, the model with the far better tokens-per-second number is the one you wait longer for.

The same ten tasks, swept by reasoning effort

Muse Glimmer ships with reasoning effort set to high. That is a default, not a law. Re-running the identical ten tasks at each level, against V4-Flash's reference 10/10 in 22.34 s:

The result inverts. At low, Muse Glimmer finishes in 7.92 seconds against V4-Flash's 22.34 — 2.82× faster, having been 1.21× slower one row down. Thinking falls 4.3×, from 2,071 characters per task to 477, and not one task regresses. Same 10 out of 10 at every level.

On this task set, high reasoning effort buys precisely nothing and costs 3.4× the wall-clock.

That will not generalise to genuinely hard problems — the higher settings exist for a reason, and ten classic algorithm exercises are not where they earn it. But the shipped default is the wrong choice for the routine work that fills most of a coding session, and correcting it costs one line of JSON.

This is the practical lesson of the whole exercise, and it has two halves.

Throughput is not latency. A model that generates four times faster while generating six times more tokens has not made you more productive. Any benchmark table quoting 268 against 68 without a wall-clock column is telling you something true and useless.

And the wall-clock cost of reasoning is a dial you control. Muse Glimmer ships on high. At that default it loses a race to a 304B model despite decoding four times faster, because it spends the difference thinking. Move one parameter to low and it wins the same race by 2.8× with identical correctness. The most consequential performance setting on this model is not the quantisation, the drafter, or the hardware — it is a string in the chat template that almost nobody documents.

If Muse Glimmer feels sluggish beside a non-reasoning model, check that string before blaming the model.

One caveat on that table: V4-Flash's zero thinking tokens may be a configuration artifact rather than a property of the model, since vLLM only reports reasoning separately when a parser is configured. Its much shorter outputs support the reading, but we cannot state it flatly.

Why doesn't the ten-times-bigger model win?

This is the obvious objection, and it deserves a straight answer: a 304-billion-parameter model tied with a 30-billion-parameter one. Three reasons, and only one of them is about the models.

The 304B is storage, not compute. V4-Flash is a sparse mixture of experts that routes each token to 6 of its 256 experts, so a single token activates about 13 billion parameters. Muse Glimmer is dense: every one of its 30 billion parameters participates in every token. Per token, Muse Glimmer is doing roughly 2.3 times more arithmetic than the model that is ten times its size. Measured by what actually runs when a token is generated, the small model here is the bigger one. This is the whole point of sparsity — you buy capacity cheaply, not compute — and it is why "304B versus 30B" is the wrong frame for a task like this.

The test has hit its ceiling. Ten classic algorithm problems — two-sum, binary search, LRU cache, edit distance — are exactly the material every 2026 code model has seen thousands of times. Both scoring 10/10 does not mean they are equal; it means the instrument cannot resolve a difference. Where we have used harder work, the gap appears: V4-Flash managed only 1 of 3 on our CUDA tasks. That is the test that would separate these two, and we have not yet put Muse Glimmer through it.

Muse Glimmer is distilled from a much larger model. It inherits Muse Spark's behaviour on well-trodden problems without needing the parameters that produced it. Distillation is very good at exactly this: transferring competence on common tasks into a small package. It transfers less well on the rare and the strange — which, again, is not what this test measures.

Where the extra parameters should tell is in breadth. Those 256 experts hold 304 billion parameters' worth of capacity against Muse Glimmer's 30 billion — roughly ten times the room for the long tail: rare languages, obscure libraries, niche domains, facts that appear once in a corpus. That is what you are buying with a sparse model, and it is real. (One caveat on the word: experts do not map to human-legible subjects the way the name suggests. Routing is learned, and no single expert is "the one that knows chemistry" — see our MoE explainer. The capacity is real; the tidy division of labour is not.) None of it is what ten classic algorithm problems measure.

And there is one difference the benchmarks miss entirely: context. V4-Flash serves 1,000,000 tokens against Muse Glimmer's 131,072 — roughly eight times the window. On a ten-task set where every prompt is a paragraph, that capability is worth precisely nothing, which is why it appears nowhere in the numbers above. On real agentic work it is often the whole decision: a repository-scale prompt, a long-running session that accumulates its own history, or a document set that simply does not fit in 128K.

Put a number on it. Source code runs around ten tokens per line, so the stock 131,072 tokens is on the order of 12,000 lines — and that is before the system prompt, the tool definitions, the conversation so far, and leaving room to actually reply. A working budget of eight to ten thousand lines is more honest. That is a comfortable single module and nowhere near a large project: on a real codebase you will be doing retrieval whether you planned to or not, and the agent will spend turns re-reading files it has already seen. V4-Flash's million tokens is roughly a hundred thousand lines — not a bigger number so much as a different way of working. This is the sharpest practical limit on Muse Glimmer as a coding model, and no amount of decode speed touches it.

The window is not quite fixed: the model can be rope-scaled to 262,144 tokens, twice the stock figure, which unsloth documents and the community reports corroborate. That roughly doubles the budget to ~25,000 lines and costs about 1.7 GiB more KV cache, which the 5090 has room for. It closes some of the gap and none of the argument — rope-scaled context degrades toward the far end, and 262K is still a quarter of what V4-Flash serves natively. No amount of decode speed compensates for a model that cannot see the input. If your workload runs long, that is the axis to choose on, and it points at V4-Flash regardless of everything else on this page.

The hardware is not the same, and it explains the speed

These numbers come from two very different machines, and the difference accounts for much of the decode gap:

Both machines were speculating. We checked rather than assumed: vLLM exposes Prometheus counters, and over the server's lifetime it had issued 107,754 drafts totalling 538,770 draft tokens, of which 294,915 were accepted. That is exactly 5.0 draft tokens per step at a 54.7% acceptance rate — about 3.74 tokens per verification. DeepSeek's DSpark drafter was working throughout.

That is worth knowing, because it makes the headline comparison a fair one. Muse Glimmer with DFlash against V4-Flash with DSpark, each in the configuration its vendor intends, is 268.3 against 67.8 tokens per second: a four-fold gap between two systems that are both speculating.

Token generation is memory-bandwidth-bound — the limit is how fast you can read the active weights. The 5090 has roughly six times the bandwidth per unit, offset by Muse Glimmer reading about 2.3 times more weight per token because it is dense. Net, the hardware should favour the 5090 substantially, and the drafters then widen the gap a little: DFlash's 16-token blocks extract more per verification than DSpark's 5.

We are not going to claim a cleaner decomposition than we have. We did not measure V4-Flash with speculation disabled, because that means restarting a production server on machines that were not ours to restart. Without that number we can say the four-fold gap is mostly hardware, somewhat amplified by a better drafter — but we cannot put a precise figure on either term, and neither should anyone else quoting these numbers.

What is clean is that the three rows make three different claims:

• Decode as measured compares whole systems — machine, model, quantisation and drafter together. Muse Glimmer wins by 4×.
• Decode with speculation off would compare machines and architecture. We have it for one side only, so it is incomplete.
• Wall-clock compares models doing a task. V4-Flash wins by 22%, because Muse Glimmer spends its speed advantage on thinking.

Only the last describes what you actually experience while waiting — and it points the opposite way to the headline.

The power column deserves a final word. We have not measured the 5090's actual draw under these workloads, so we are not publishing a tokens-per-joule figure. But a 575 W board against a pair of machines drawing roughly 83 W between them is a seven-fold difference in the denominator, and it points the opposite way to the throughput numbers. That comparison is the one we most want to run next.

What this means

Check reasoning_strength before you benchmark anything. It is the highest-leverage setting on this model and it ships on high. On our ten-task set low scored the same 10/10 in a third of the wall-clock, turning a 22% loss against a 304B model into a 2.8× win. Nothing else here — not the drafter, not the hardware — moves the number that far.

Throughput is not latency. Muse Glimmer decodes four times faster than the 304B model and, at its default effort, still makes you wait longer. Any benchmark quoting tokens per second without a wall-clock column is answering a question nobody asked. Time the task, not the tokens.

And state your temperature. Our speculation speedup reads 5.64× at temperature 0 and 3.00× at Meta's recommended sampling — same model, same drafter, same workload. We first took that gap for the vendor underselling their drafter. It was our sampling; their published 3.1× is right.

Speculation, not sparsity, is what makes local latency unpredictable. If you are choosing between a dense model and a sparse one because you want predictable latency, that reasoning does not hold. Both architectures are flat without speculation and spiky with it. It also inverts the usual advice: the small dense model on one card is not the predictable one. Both are equally at the mercy of how well the drafter guesses. The lever is speculation, and it is one you control — turning it off on this model costs you between 47% and 82% of your throughput.

For code and structured output, DFlash is close to free money. We measured 5.64× on code at temperature 0 and 3.00× at Meta's recommended sampling — either way, a large win for one flag. Prose still gains, just less: 1.87× and 1.27× respectively. There is no quality trade at any temperature — the full model only accepts tokens it would have produced itself.

And check the context window before either of these numbers. Muse Glimmer's 131,072 tokens against V4-Flash's 1,000,000 is the one difference no benchmark here measures, because short prompts cannot see it. For repository-scale or long-session work it outranks everything above.

Related reading

• Meta Unveils Muse Spark: First Model From Superintelligence Labs — the larger model this one is distilled from
• Qwen 3.6 27B: a Local Coding Model You Can Actually Run — the closest direct competitor
• DeepSeek-V4-Flash on Two GB10s: 304B Params, 1M Context, 83 Watts — the MoE measurements this article reinterprets
• AI Workstation Comparison: RTX 5090 vs GB10 (HP ZGX) — choosing hardware for local inference
• Mixture of Experts (MoE), Explained — the design Muse Glimmer deliberately rejects
• Will This LLM Fit My GPU? VRAM Requirements for Every Model Size — the arithmetic behind the tables above