Muse Glimmer: an agentic model designed backwards from a 24 GB budget

Most model releases describe an architecture and then mention, near the end, what hardware it runs on. Muse Glimmer — released by Meta Superintelligence Labs on 2026-08-09 under Apache 2.0 — reads the other way round. Nearly every structural choice in it is answering the same question, which is how do we fit a competent agent, its KV cache at 131K tokens, a vision encoder and a speculative-decoding drafter inside 24 GB at once?

That is a good question to design against, and the interesting thing is that you can check the answer. Every number below comes from config.json, the safetensors index, and the file sizes in the four repositories Meta actually shipped. The 24 GB claim is not a vibe; it is arithmetic, and it closes with 2.4 GB to spare.

The budget, and what makes it work

Start at the end. The card says 4-bit quantization shrinks the language model to "under 20 GB," leaving headroom for the KV cache, the perception encoder and the drafter within a 24 GB envelope. Here are the measured artifact sizes from the GGUF repository, plus a KV cache computed from the config rather than quoted:

The KV arithmetic is simple enough to do in one line. With 2 KV heads at head dimension 128 in bf16, each token costs 2 × 2 × 128 × 2 = 1024 bytes per layer. Thirteen of the fifty-two layers are global and hold the whole context; the other thirty-nine are capped at a 2048-token window. At the full 131,072-token context that is 1.83 GB — and 16.76 + 1.63 + 1.40 + 1.83 = 21.6 GB.

Now take away the sliding-window pattern and make all 52 layers global. The KV cache becomes 6.98 GB, the total becomes 26.8 GB, and it no longer fits on the card the release is named after. That is the sentence worth keeping: the 3-local-1-global stack isn't an efficiency refinement applied to a model that already fit, it is the reason the model fits at all. Take away the 16:1 GQA as well and the KV cache alone is 112 GB.

The attention stack, verified line by line

The card describes the attention as "[Local, Local, Local, Global] repeating" with "RoPE (θ = 500,000), local layers only." Both claims are checkable per layer, because config.json carries two 52-element arrays.

layer_types gives L L L G thirteen times exactly. layer_rope_theta is 500,000 on every local layer and 0 on every global one, with zero mismatches across all 52. So the layers that see the entire context run with no positional encoding at all.

That is worth pausing on, because this site has now covered three independent labs converging on it inside a year: Kimi K3 applies NoPE to its full-attention layers, and Maple-Preview sets nope_on_global_attention: true on the same 3:1 pattern at 24 layers. Muse Glimmer makes it explicit per layer rather than as a flag. The shared argument is length extrapolation: a layer carrying no notion of absolute distance has nothing to be surprised by when the context gets longer than anything it saw in training, and the local layers underneath have already encoded order well enough to reconstruct it.

A few things the config says that the card does not:

• final_logit_softcapping: 20.0 — logits are squashed through a bounded function before the softmax, a Gemma-style stabilizer that the model card never mentions.
• qk_scale_factor: 3.87 — the attention scale is not the textbook $1/\sqrt{d_k}$. At head dimension 128 that would be 0.0884; this multiplies it by 3.87.
• output_multiplier: 0.19611613513818404 — which is exactly $16/\sqrt{6656}$, a residual-stream rescale tied to the hidden size.
• post_norm_eps: 1e-08, separate from rms_norm_eps: 1e-05 — implying a post-norm alongside the pre-norm rather than one or the other.

None of these is exotic on its own. Together they're a reminder that the published table of hyperparameters is a summary, and the config is the document.

It is a distillation, and the blog says so

The model card describes what Muse Glimmer is. The blog post describes where it came from, and this is the part that most changes how you should read the benchmark numbers:

Pre-Training. We trained Muse Glimmer on Muse Spark's outputs using logit distillation, leveraging a similar data mix as the teacher. Mid-Training. We trained the model on longer-context, more agent-heavy data with richer reasoning traces, alongside organic data. Post-Training. We combined supervised fine-tuning with a mix of on-policy distillation and reinforcement learning across general, reasoning, coding, and agentic domains.

Distillation from Muse Spark at both ends — logit distillation during pretraining, on-policy distillation during post-training. Muse Glimmer is not a small model trained well; it is a large model compressed, twice, with RL in between. That framing explains the shape of the results better than "30B punches above its weight" does: what transferred is the teacher's behaviour on agentic trajectories, which is exactly where the model is strongest.

It also sets up the safety argument later on, which leans on Muse Glimmer being "broadly weaker than Muse Spark 1.0" — a claim that is much easier to make about a distilled student than about an independently trained model.

Speculative decoding, and why the same drafter is worth 3.1× or 1.5×

The second optimization is a companion "drafter" based on DFlash that proposes an entire block of 16 tokens in a single forward pass, which the main model then verifies in parallel. The shipped drafter is a 5-layer model at the target's full 6656 width — 2.56B parameters, 5.1 GB in bf16, 1.63 GB quantized. Calling it "lightweight" is fair relative to 30B, but it is 8.6% of the model and it has to be resident.

The headline is 3.1× on an RTX 5090 and 1.5× on an M4 Max, and the gap between those two numbers is the whole mechanism. Single-stream decoding is memory-bandwidth-bound: you read the entire 17 GB of weights to emit one token. Proposing sixteen and verifying them together amortizes that read across all sixteen, so the gain depends on how much spare arithmetic the device has once the weights are already moving. A 5090 has an enormous compute-to-bandwidth ratio and converts nearly the whole block size into speedup; Apple's unified memory narrows that ratio, so verification stops being nearly free.

expand

The chart carries information the card's table drops. Those error bars span seven prompt categories, and on the 5090 the DFlash result runs from roughly 132 to 340 tok/s. So the honest statement is that speculation is worth somewhere between 1.8× and 4.5× depending on what you ask, and 3.1× is the midpoint of a wide distribution rather than a number you should expect on your workload.

The benchmark table Meta loses a third of

expand

Re-tallied against the better of the two rivals in each row:

Muse Glimmer leads 12 of the 22 scored rows. Qwen3.6-27B takes 8, Gemma4-31B takes 2, and the losses are not decorative: OSWorld-Verified by 9.7 points and TerminalBench 2.1 by 9.0, both to a model three billion parameters smaller.

Filter that ledger to agentic and the profile becomes legible. The rows Muse Glimmer wins by a distance — MCP Atlas by 21 points over Gemma, τ³-Banking by 41% relative, DeepSearch QA, Gaia2 — are the ones measuring tool schemas and multi-turn task completion inside a scaffold. The rows it loses are computer-use (OSWorld) and long-horizon terminal work (TerminalBench). For a model distilled specifically on agentic trajectories, that is exactly the shape you would predict, and it is more informative than a uniform win would have been.

Publishing it in that form is the least common thing about this release. A comparison table where your own model is beaten in a third of the rows, by a competitor, in your own launch material, is not the norm.

The table where losing is the point

The chem/bio section inverts the usual reading of a benchmark, and it is worth explaining because the presentation is initially confusing. Meta bolds the most performant model in each row — and Muse Glimmer is deliberately not it in four of six:

The argument is that Muse Glimmer sits "approximately in line with other models in its size class, while showing strictly lower capabilities than larger open-weight models, suggesting that it is unlikely to materially enable new threats upon release." Including Kimi K3 as an uncontested upper bound on every row is doing real work here: it establishes that whatever Muse Glimmer can tell you about wet-lab protocols, an already-open model tells you more.

The same inversion runs through the safety rows of the main table, and there Muse Glimmer genuinely loses. Gemma4-31B has less than half its contextual-integrity violation rate (12.1 vs 26.4) and a lower prompt-injection attack success rate (25.6 vs 28.4). Muse Glimmer's compensation is utility — 94.2 on AgentDojo against Gemma's 90.8 — which is the familiar helpfulness/safety trade stated in numbers instead of prose. Whether 26.4% is an acceptable violation rate for a model explicitly recommended for agents with "deep access to personal context" is a judgment the card leaves to you, and it does at least give you the number to judge with.

What actually shipped

I checked the "Released Artifacts" table against Hugging Face, because promised artifacts and present artifacts are frequently different things. All four exist, in three sibling repositories the card does not link:

The drafter's own config.json confirms the card's spec exactly — 5 layers, block_size: 16, sliding window 2048 on all five, 32 query heads and 8 KV heads. The ExecuTorch repository ships separate .pte files for Apple Metal and NVIDIA sm80, in text-only and text-plus-image variants, which is how the M4/M5 numbers were produced.

One small correction to the card while I'm counting: it states total parameters as "~29.6B" twice. The safetensors index says 29,776,626,688 — 29.78B. A 0.6% understatement, and I mention it only because everything else in that table matched the config to the digit.

The take

The reason this release is worth reading closely is not the benchmark line, which is good but contested by a smaller competitor. It is that Muse Glimmer is a clean worked example of designing an architecture against a deployment constraint and then publishing enough for someone outside the lab to check the constraint was met.

The three decisions that matter — 16:1 GQA, three sliding layers per global one, and 4-bit quantization validated at 1.0% degradation — are not independent optimizations. They are one budget, allocated. Remove any of them and the model stops being the thing the announcement describes. That is a more useful artifact than a leaderboard position, because the budget is the part that generalizes: the next person trying to fit an agent on a laptop has a worked example with all its numbers exposed.

What is missing is the same thing that is always missing on day one. There is no third-party evaluation of any of these numbers, the methodology report is a link rather than a paper, and the quantization degradation figure — 1.0% averaged across 15 benchmarks — is exactly the kind of average that can hide a specific capability falling over. The card says the compression was validated on agentic tasks; it does not show that table.

Sources: the Muse Glimmer announcement (Meta AI Research, 2026-08-10) and the Muse-Glimmer-30B model card, plus config.json, model.safetensors.index.json and the file trees of the -GGUF, -assistant and -ExecuTorch-PTE repositories, all as of 2026-08-10. Benchmark numbers are Meta's own, with no third-party replication. The two figures are Meta's, flattened onto white. The KV-cache arithmetic, the 24 GB budget reconciliation and its counterfactuals, the per-layer verification of the attention and RoPE arrays, and the re-tally of the comparison table are mine and are computed from the published config and file sizes. All four interactives are mine.