Meta released Muse Glimmer on 10 August 2026: a dense, multimodal, Apache 2.0 model distilled from Muse Spark and aimed at agents that run on your own hardware. The pitch is genuinely interesting, and — unlike most “runs locally” claims — the deployment story mostly holds up when you check the numbers. Where it needs qualifying is narrower and more specific than the coverage suggests.
This article covers what the model is, what it takes to run, where it wins, and where it loses.
The specs, without rounding
Total parameters | ~29.6B (dense) |
Split | ~28B text decoder + ~1.8–2B vision encoder |
Text decoder | 52 layers, hidden size 6656 |
Attention heads | 32 query / 2 KV (GQA 16:1), head dim 128 |
FFN | SwiGLU, intermediate dimension 19,968 |
Position encoding | RoPE (θ = 500,000), local layers only |
Sliding window | 2,048 tokens |
Vision encoder | ViT-G/14 Perception Encoder, 50 layers, width 1536, patch size 14 |
Vocabulary | 202,048 (200,000 BPE + 2,048 special) |
Max visual tokens per image | 4,096 |
Context | 131,072 |
License | Apache 2.0 |
Knowledge cutoff | 4 January 2026 |
Languages | 100+ |
BF16 checkpoint | 59.58 GB |
Modalities | Interleaved text + image in, text out |
Meta’s model card gives the vision encoder as ~1.8B; Hugging Face’s launch post rounds it to 2B and the decoder to 28B. Same model, different rounding.
Dense, not mixture-of-experts. Every parameter activates on every token, which costs throughput but buys predictable latency and no routing variance across long multi-step runs — a reasonable trade for agentic work, and clearly a deliberate one.
Architecture
Hybrid attention. The decoder alternates three sliding-window layers with a 2,048-token window using rotary position embeddings, then a fourth layer using full attention with no positional embedding at all. That (SWA, SWA, SWA, Full) block repeats 13 times for 52 layers. The RoPE layers preserve local order and distance; the NoPE layers carry global information.
Gated grouped-query attention. 32 query heads to 2 KV heads — each key-value head serves 16 query heads, cutting KV-cache memory 16x relative to full multi-head attention. This, not the sliding window, is the dominant reason the cache stays small (see the arithmetic below).
Q-K normalization with query scaling. RMS norm is applied to every query and key head before attention to keep logits stable, then queries are multiplied by a scale factor that acts like an inverse temperature at the softmax.
Perception encoder. One encoder handles both images and video. It patchifies to 2 frames × 3 channels × 14 × 14, projects through a linear layer, adds interpolated absolute position embeddings from a learned table, and runs 50 layers with GELU MLPs and the same three-window-then-one-full attention pattern, with 2D RoPE inside the attention layers. After the transformer, pixel shuffle concatenates 2×2 groups of neighbouring spatial tokens, cutting image token count 4x without dropping channels, and the merged features are projected into the decoder’s embedding space. A single image tops out at 4,096 visual tokens.
Video goes through the same encoder frame by frame. The processor targets 2 fps, caps the clip at 96 frames sampled evenly, and interleaves timestamped placeholders into the text. Worth noting what Meta says about this in the limitations: the model is not explicitly optimized for video, and the model card lists supported modalities as text + image in, text out. Video works — there’s a documented transformers path for it — but treat it as frames-with-timestamps, not as a first-class modality. Audio is not supported at all.
KV cache: where the savings actually come from
The hybrid attention pattern is what most write-ups foreground, but at 128K it is the smaller of the two levers. With 2 KV heads at head dim 128, each token costs 1 KiB per layer:
13 global layers × 131,072 tokens × 1 KiB ≈ 1.74 GB
39 windowed layers × 2,048 tokens × 1 KiB ≈ 82 MB
Total at full context: ~1.8 GB
Isolate each lever against the same 131,072-token workload:
Hybrid attention + GQA (what ships): ~1.8 GB
GQA but every layer global: ~7 GB — the sliding window buys ~3.8x
Hybrid attention but full multi-head (32 KV heads): ~29 GB — GQA buys 16x
Neither: ~112 GB
Both matter, but GQA is the load-bearing choice, and it is the one that gets a single line in most write-ups while the attention pattern gets a diagram.
The practical upshot: KV cache is not what will blow your memory budget on this model, even at 131,072 tokens. A 4,096-token image adds roughly 50 MB. Image tokens are a context cost, not a memory cost.
The thing that will break your integration first
Muse Glimmer does not emit JSON tool calls, and it does not wrap reasoning in <think> tags.
Every turn is a sequence of channel-scoped messages. Reasoning goes to a self channel, tool calls are written as XML-style ATEM blocks, and the user-facing answer is a separate channel. If you point an existing OpenAI-shaped agent harness at it and expect JSON function calls, you get nothing usable.
On vLLM’s native path this means --tool-call-parser muse_glimmer and --reasoning-parser muse_glimmer, run together. The reasoning parser also forces skip_special_tokens=False; without that the channel markers get stripped before parsing and both channels collapse into content.
This is the detail most write-ups skip, and it is the one that determines whether your agent works. Meta lists OpenClaw and Hermes Agent as known-compatible scaffolds; anything else, budget integration time.
Running it: the honest memory maths
At BF16 the checkpoint is 59.58 GB — roughly 55 GiB of weights. Meta’s own framing is that full precision exceeds any single consumer GPU, and Hugging Face lists a single 80 GB H100 as the practical minimum for BF16 inference. Full precision is workstation, server or unified-memory territory, not a 4090.
The quantized story is where the “runs on your GPU” claim lives, and it needs to be read carefully — Meta’s own builds and the third-party ones answer different questions.
Meta’s own builds
Meta ships two calibrated k-quants at roughly 4-bit. Its published comparison, with full precision as the baseline:
Variant | Target hardware | Measured degradation* |
|---|---|---|
Full precision (BF16) | 64 GB VRAM | — |
K-Quant-Dynamic | 32 GB VRAM | 0.2% |
K-Quant-17GB | 24 GB VRAM | 1.0% |
*Averaged across accuracy metrics on 15 benchmarks.
Meta’s claim is that ~4-bit compression brings the language model under 20 GB, leaving headroom for the KV cache, the perception encoder and the DFlash drafter to run simultaneously inside a 24 GB or 32 GB envelope. Given that the KV cache at full 128K context is only ~1.8 GB, and that Meta ships quantized drafter builds specifically to keep that overhead small, this claim is credible rather than marketing. Unsloth, which worked on the llama.cpp implementation, reports the model running on 18 GB of RAM or VRAM.
So a 24 GB card is a real target rather than a marketing line. It is still tight: 17 GB of weights leaves about 7 GB for the vision encoder, a quantized drafter, the cache and compute buffers, and Meta does not publish per-component sizes for the projector or the quantized drafter. Verify your own context budget before committing.
The wider checkpoint landscape
Several other quantized builds are circulating. Two of the most-cited are not Meta artifacts, and they answer a different question — throughput on Blackwell, not fit on a 24 GB card:
Variant | Publisher | Size | Notes |
|---|---|---|---|
BF16 reference | Meta | 59.58 GB | Fine-tuning and research |
FP8 block-scaled | RedHatAI | 32.78 GB | Dynamic activations; vision tower and embeddings stay BF16 |
NVFP4 (W4A4) | Inferact | 25.42 GB | ModelOpt, group size 16, Blackwell-only kernels |
GGUF k-quants | Meta / Unsloth | 17 GB and up | Meta publishes no file size for the Dynamic build; add a separate |
DFlash drafter | Meta | 5.11 GB (unquantized) | Optional; quantized versions shipped |
The NVFP4 build is instructive but often misread. It quantizes weights and activations to 4 bits across 364 language-model projections (52 layers × 7), while leaving embeddings, lm_head and the entire vision tower unquantized — which is why it lands at 25.42 GB rather than the ~15 GB a uniform 4-bit quant would imply. That does not fit a 24 GB card. But it was never meant to: the vLLM recipe lists DGX Spark as the target and notes FP4 weights might also run on a 5090, which has 32 GB. It is a 32 GB Blackwell path where W4A4 kernels buy throughput — not Meta’s answer to the 24 GB question.
Likewise, the 5.11 GB drafter figure comes from the vLLM recipe and refers to the base repo, not the quantized builds Meta ships alongside it. On a local machine you would pair a k-quant target with a quantized drafter, which is exactly what Meta’s own speed measurements do.
llama.cpp — the actual easy path
For a single local machine this is the shortest route, not vLLM. You need llama.cpp build b10353 or newer:
curl -LsSf https://llama.app/install.sh | sh
llama serve -hf meta-models/Muse-Glimmer-30B-GGUF
That gives you a WebUI on localhost:8080 and an OpenAI-compatible endpoint. Meta ships calibrated quants in the GGUF repo; Unsloth publishes dynamic ones. Add the drafter with --spec-type draft-dflash --spec-draft-n-max 15.
transformers
from transformers import AutoProcessor, AutoModelForMultimodalLM
MODEL_ID = "meta-models/Muse-Glimmer-30B"
processor = AutoProcessor.from_pretrained(MODEL_ID)
model = AutoModelForMultimodalLM.from_pretrained(
MODEL_ID, dtype="auto", device_map="auto"
)
This snippet — not the vLLM command — is what runs unchanged on NVIDIA (CUDA), AMD (ROCm) and Intel (XPU); device_map="auto" picks whatever accelerator is present. Reasoning effort is set with a reasoning_strength argument in apply_chat_template. Speculative decoding uses MuseGlimmerAssistantModel plus speculation_type="dflash" on generate().
vLLM
Day-0 support ships through the transformers backend:
vllm serve meta-models/Muse-Glimmer-30B \
--model-impl transformers --tensor-parallel-size 4
The native path — the one with working tool calls — looks like this on multi-GPU:
vllm serve /model \
--served-model-name muse-glimmer \
--tensor-parallel-size 4 \
--gpu-memory-utilization 0.92 \
--max-model-len 131072 \
--max-num-seqs 64 \
--enable-auto-tool-choice \
--tool-call-parser muse_glimmer \
--reasoning-parser muse_glimmer \
--generation-config auto
On a DGX Spark the recipe drops to --tensor-parallel-size 1 — GB10 is a single GPU, so there is no tensor parallelism to configure — and describes the command as otherwise unchanged. Note the required image is vllm/vllm-openai:muse-glimmer, and as of the recipe’s publication the code was still pending release. ROCm currently needs an unmerged PR plus a nightly image. Cross-vendor support is real but not yet frictionless.
Sampling
Use temperature 1.0, top_p 0.95, top_k 64. Do not run it greedy — it is a reasoning model, and in practice greedy is not reproducible on this stack either: identical requests at temperature 0 with a fixed seed returned 70, 80 and 86 completion tokens across runs. (That is a batching and kernel artifact rather than a property of the weights, but it is what you will observe.)
Reasoning effort is set with a Reasoning strength: low|medium|high|xhigh line in the system prompt; use high or xhigh for coding and agentic tasks.
Speculative decoding
DFlash is a block-diffusion draft head rather than a conventional small drafter. It predicts a whole block in a single forward pass with the slots attending to each other bidirectionally, and the target model verifies them in parallel. Output quality is unchanged; only speed improves.
It is 5 layers, reads the target’s residual stream at layers 1, 13, 25, 37 and 49, uses sliding-window attention throughout with 32 query / 8 KV heads, and ties its embedding and output projection to the target — so it stores neither and is useless on its own. It must be paired with the specific target it was distilled against.
Block size is 16, with slot 0 re-presenting the last accepted token, leaving 15 to predict. num_speculative_tokens: 15 is fixed, not a tuning knob; llama.cpp clamps anything above 15. Hugging Face found it particularly effective on structured output like code.
Meta’s measured throughput, using the K-Quant-17GB build with the quantized drafter, batch size 1, greedy decoding:
Hardware | Baseline | With DFlash | Speedup |
|---|---|---|---|
RTX 5090 (llama.cpp) | 74.9 tok/s | 233.4 tok/s | 3.1x |
Apple M4 Max (ExecuTorch) | 23.7 tok/s | 37.8 tok/s | 1.5x |
Apple M5 Max (ExecuTorch) | 26.6 tok/s | 50.2 tok/s | 1.8x |
The 3.1x on a 5090 is the number that makes the local-agent story practical rather than aspirational. Two caveats. The CUDA path benefits far more than Metal. And these were measured under greedy decoding — the setting Meta elsewhere tells you not to use — so acceptance rates, and therefore speedups, may differ at the recommended temperature of 1.0.
Benchmarks: where it wins and where it doesn’t
Meta’s published comparison against Gemma4-31B and Qwen3.6-27B — Glimmer at High Reasoning, the other two in thinking mode:
Muse Glimmer leads clearly (margin over the better rival in brackets): MCP Atlas 75.5 vs 54.2 / 62.5 (+13.0), τ³-Banking 23.5 (+6.8), AA-LCR 80.0 (+6.7), WildClawBench 47.6 (+4.4), DeepSearch QA 74.6 (+3.5), GAIA2 43.3 (+3.3), Beam 128K 65.1 (+2.1).
Leads narrowly or ties: IFBench 77.0 (+1.0), SWE-Bench Pro 51.2 (+1.0), AIME 2026 94.7 (+0.6), Charxiv Reasoning 78.8 (+0.4), SciCode 43.6 (+0.2). Treat the last three as ties.
Qwen3.6-27B leads: OSWorld-Verified (75.6 vs 65.9), TerminalBench 2.1 (60.7 vs 51.7), GDPval-AA (1141 vs 953), SkillsBench (46.6 vs 44.3), SWE-Bench Verified (77.2 vs 76.0), ScreenSpot Pro (76.1 vs 75.4), OmniDocBench v1.5 (77.8 vs 75.8), MMMU Pro (75 vs 74).
Gemma4-31B leads: GPQA Diamond (85.7 vs 83.5), Humanity’s Last Exam (23.6 vs 22.0), and both of the safety metrics where lower is better.
Read the shape of that. Glimmer is strongest on tool orchestration, multi-step search, long-context retrieval and maths — and the margins there run from about 3 points to 13, comfortably outside noise. It is weakest precisely on computer-use and terminal work, where OSWorld and TerminalBench show gaps of roughly ten points in the other direction. The multimodal losses to Qwen are all within about two points and shouldn’t drive a decision on their own.
If your use case is a screenshot-driven desktop agent, this is not automatically the best 30B choice, and these are Meta’s own numbers, not a critic’s.
Safety, since it’s always-on
Muse Glimmer was evaluated across content safety, agentic risk, privacy under contextual-integrity theory, and preparedness. Meta notes it does not meet the “Frontier AI” definition in its Advanced AI Scaling Framework, being generally less capable than Muse Spark. Preparedness assessed it at moderate-or-lower risk for chem/bio, with cyber and loss of control inferred to be moderate-or-lower on the grounds that Glimmer is broadly weaker than Muse Spark 1.0. On the chem/bio suite it trails Gemma4-31B on four of six benchmarks (leading on WMDP Bio and Lab Bench ProtocolQA) and sits below the larger Kimi K3 on all six.
Two numbers matter for anyone giving it filesystem or browser access, and both are worth reading against the full field rather than the leader:
Muse Glimmer | Gemma4-31B | Qwen3.6-27B | |
|---|---|---|---|
Siren AgentDojo — attack success (↓) | 28.4 | 25.6 | 40.3 |
Siren AgentDojo — utility | 94.2 | 90.8 | 92.7 |
CI Memories — violation rate (↓) | 26.4 | 12.1 | 53.4 |
CI Memories — coverage | 64.8 | 53.0 | 66.9 |
Glimmer sits second of three on injection resistance and comfortably ahead of Qwen — it is not the outlier its headline gap to Gemma might suggest. But Gemma is better than both, by a lot on CI Memories. A model that reads your screen and calls tools all day is exactly the deployment where injection resistance is load-bearing. Sandbox it and gate irreversible actions; Meta’s own model card recommends human-in-the-loop confirmation for anything irreversible.
Fine-tuning: what it actually costs
Hugging Face’s measured minimums on 80 GB Hopper GPUs:
Inference/eval, BF16: 1× H100
LoRA SFT, BF16: 1× H100, microbatch 1 with checkpointing
Full SFT, BF16: 8× H100 with FSDP/ZeRO-3
LoRA GRPO with transformers rollouts: 1× H100, but slow and tight
LoRA GRPO with separate vLLM rollout server: 8× H100 (4 rollout, 4 training)
Full-finetune GRPO: 8 GPUs usually insufficient
“Open weights so you can fine-tune it” is true. “Fine-tune it on your desktop” means QLoRA and nothing more.
What it’s genuinely good for
The intended pattern is continuous rather than conversational — persistent state across restarts and self-managed memory across hours-long sessions. Worth being precise about that claim: the persistence comes from the agent harness, not from the model. What the model contributes is the ability to stay coherent across it.
Tool-heavy orchestration. Its strongest benchmark category by a wide margin. Multi-step workflows hitting many APIs are the sweet spot.
Coding agents. SWE-Bench Pro leadership is real but thin (one point over Qwen), and Qwen takes Verified and TerminalBench. Benchmark on your own repos.
Document and research work. Long-context retrieval scores are strong — AA-LCR is one of its biggest wins — and the perception encoder handles PDFs and scientific figures.
Privacy-constrained deployments. Apache 2.0 plus fully local operation is the whole argument for data-residency cases.
Meta’s launch demo had it discover a Home Assistant instance on the local network, query device APIs, write an HTML/CSS/JS dashboard from scratch and deploy a local server to verify its own work. That is a fair illustration of what tool-use plus failure-recovery tuning buys you.
License
Apache 2.0, hosted under meta-models on Hugging Face. Commercial use, modification and redistribution under standard terms, with no model-specific agreement layered on top. All released artifacts — BF16 weights, both 4-bit quants, the DFlash drafter and the perception encoder — are covered.
Note that if you access it through a third party — NVIDIA’s NIM endpoints, for example — that provider’s own terms govern the service even though the base model stays Apache 2.0. Meta also states the model is not intended for use by individuals under 18, and puts responsibility for that on deployers.
People Also Ask
Can it run on a single consumer GPU? Yes, with quantization. Meta’s K-Quant-17GB build targets 24 GB VRAM with about 1% measured degradation, and K-Quant-Dynamic targets 32 GB at 0.2%. The KV cache at full 128K context is only ~1.8 GB, which is what makes Meta’s claim that vision and a quantized drafter fit alongside it plausible — though it is tight and worth verifying on your own workload. BF16 needs ~55 GiB and does not. The NVFP4 build at 25.42 GB is a 32 GB Blackwell target — DGX Spark, possibly a 5090 — not a 24 GB one.
Does it support text and image input? Yes — image-text-to-text, with a dedicated perception encoder fused into the text stream, up to 4,096 visual tokens per image. Video works at 2 fps up to 96 frames but is processed as individual frames and is not something Meta optimized for. No audio.
Which hardware vendors work? The transformers snippet runs unchanged on CUDA, ROCm and XPU. ExecuTorch .pte builds target Metal for on-device Apple inference. vLLM on ROCm currently needs a nightly build.
Is it better than Qwen3.6-27B? Depends entirely on the task. Clearly better at tool orchestration, search and long-context retrieval; clearly worse at computer-use and terminal work; a wash on multimodal and on most coding benchmarks. Test on your own workload.
Bottom line
Muse Glimmer is a well-designed local-agent package: permissive licence, a coherent architecture aimed at long sessions, day-0 support across llama.cpp, transformers and vLLM, and builds for desktop, edge and Apple hardware. The “runs on a 24 GB consumer GPU” framing holds up better than most such claims — Meta published the degradation numbers, the KV cache genuinely is small, and the 3.1x speculative-decoding speedup on a 5090 makes it fast enough to use rather than merely to load.
What it is not is the smartest 30B in every dimension. It loses computer-use and terminal work to Qwen by around ten points, trails Gemma on injection resistance, and several of its multimodal “wins” are within noise. Treat the ATEM output format as an integration requirement rather than a footnote, sandbox it before you hand it real permissions, and benchmark it against Qwen on your actual tasks rather than on the launch table.
Do that, and it earns its place on the shortlist on merit instead of on marketing.
Sources: Meta model card for Muse-Glimmer-30B on Hugging Face; Hugging Face launch blog (10 Aug 2026); vLLM Recipes model page; Muse Glimmer GGUF repository; Unsloth documentation; research.meta.ai launch post; VentureBeat launch coverage.