Muse Glimmer 30B: 4× Faster Than a 304B Model, and 22% Slower to Finish

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.

That is the most useful thing we learned, and it is the reason to distrust any benchmark table quoting tokens per second without a wall-clock column beside it. 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 a 5.6× speedup 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. (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, temperature: 0. 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.

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:

Meta undersells its own drafter. The published figure is 3.1× (74.9 → 233.4). We measured 5.64× on code. Their 233.4 sits right next to our structured result of 258.85, which suggests their headline reflects a structured or mixed workload. On the workload people actually buy a local coding model for, it does better than advertised.

Speculation never loses. The worst case, prose, is still 1.87×. The trade is not speed against risk — it is how much you win.

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. 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.

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.

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.

This is the practical lesson of the whole exercise. Throughput is not latency. A reasoning model that generates four times faster while generating six times more tokens has not made you more productive, and any benchmark table quoting 268 against 68 without the wall-clock column is telling you something true and useless.

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 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. 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

Throughput is not latency. If you take one thing from this, take that. Muse Glimmer decodes four times faster than the 304B model and still makes you wait longer, because it spends the difference thinking. Any benchmark table quoting tokens per second without a wall-clock column is measuring something real and answering a question nobody asked. When you evaluate a reasoning model, time the task, not the tokens.

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. Meta's published 3.1× understates what you will see; we measured 5.64× on code. If your workload is prose you still gain, just less. There is no quality trade either way — 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.

If you are publishing benchmarks for this model over the next few weeks, check GET /slots first.

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