Meta's Muse Glimmer Lands Day-0 in llama.cpp, vLLM, and ExecuTorch — A 30B Multimodal Agent Model That Fits on One Consumer GPU

Meta shipped Muse Glimmer this morning — a 30B multimodal agent model under Apache 2.0, with full weights landing day-0 in llama.cpp, vLLM, MLX, ExecuTorch, and transformers, plus an Ollama/LM Studio/Unsloth rollout “in the coming days.” It’s Meta Superintelligence Labs’ first open-weight release in over a year, and the first open-weight model to ship with a pre-integrated speculative drafter (DFlash) that gives a measured 3.1× decode speedup on an RTX 5090. The 4-bit K-Quant-17GB build validates on a single RTX 3090 at 23.6 GB VRAM with 256k context. For anyone running agents locally, this is the most consequential open drop of 2026.

What’s actually in the box

Glimmer is a 30B dense multimodal trained for “always-on local agent workflows,” distilled from Meta’s larger Muse Spark. The architecture is two-tower: a ~1.8B parameter Perception Encoder vision side accepting up to 4,096 visual tokens per image, plus a 28B text decoder. Total context is 131,072 tokens, vocabulary 202,048, knowledge cutoff January 4, 2026. Vision and text share an aligned embedding space, so image inputs don’t need a separate cross-attention layer — you can hand it a screenshot of a failing test and ask it to fix the test, and it does so without a tool call.

The release ships BF16 weights (~55 GB), GGUF k-quants, and ExecuTorch builds on the Hugging Face collection. The same transformers snippet runs on NVIDIA (CUDA), AMD (ROCm), and Intel (XPU) without changes. DFlash — a smaller block-speculative drafter model that proposes 16-token blocks for the main model to verify in parallel — is included in the same collection.

Three stacks, day-0

The reason this release lands different from the usual “open weights in three weeks” pattern is Meta pre-shipped the integrations before announcement. The Hugging Face collection carries:

transformers — full PyTorch BF16 + ROCm + XPU compatibility
llama.cpp — GGUF k-quants for CPU and CUDA
vLLM — server-side serving with continuous batching
MLX — Apple Silicon optimized
ExecuTorch — mobile/edge deployment including M-series Macs

Ollama, LM Studio, and Unsloth are flagged as “in the coming days.” If you’re on the K-Quant-17GB build and want to be the first person on your block running it, the llama.cpp and vLLM paths work today. LM Studio users will get the GUI install “in the coming days” once the GGUF shows up in the registry — that registry sync is the gating step, not the conversion.

DFlash: the bit that matters for agents

Agent loops make lots of short model calls — plan, critique, tool result, plan, critique, tool result. The bottleneck is decode throughput per call, not prefill. DFlash attacks that directly: a small drafter proposes 16-token blocks, the main model verifies them in one forward pass. Meta measured the K-Quant-17GB build at batch 1, greedy decoding:

Hardware	Without DFlash	With DFlash	Speedup
RTX 5090 (llama.cpp)	74.9 tok/s	233.4 tok/s	3.1×
Apple M5 Max (ExecuTorch)	26.6 tok/s	50.2 tok/s	1.9×
Apple M4 Max (ExecuTorch)	23.7 tok/s	37.8 tok/s	1.6×

The 3.1× on desktop NVIDIA is the headline number, but the M-series numbers are the more important signal: Apple Silicon users can roughly double decode throughput without changing hardware, because ExecuTorch ships DFlash pre-wired. For an agent loop that generates 200 tokens per step and runs 50 steps per task, that’s the difference between 30 seconds and 15 seconds on an M4 Max.

This is the first open-weight release where a speculative drafter ships pre-integrated, not as a third-party patch. It’s the difference between “you can use a 30B agent model locally if you set up a custom draft pipeline” and “you can use a 30B agent model locally.”

The quantization story

The 30B dense parameter count is the hard number. BF16 weights are ~55 GB and don’t fit on any single consumer GPU. Meta ships three real options:

BF16 (~55 GB) — full precision. Two GPUs or a workstation. Not a consumer story.
K-Quant-Dynamic (~32 GB) — 0.2% benchmark degradation averaged across 15 evals. Targets a 32 GB card (RTX 5090, workstation GPUs).
K-Quant-17GB (~24 GB target, 23.6 GB on a 3090) — 1.0% degradation averaged across 15 evals. The consumer GPU build.

The K-Quant-17GB has been validated by r/LocalLLaMA on a single RTX 3090: 23.6 GB VRAM at 256k context, 1200 tok/s prefill, 54 tok/s generation. That’s a real, measured number, not vendor marketing — it’s what you get if you actually put one of these on a 2020-era GPU.

The HF blog also mentions Unsloth has NVFP4 quantizations tuned for Blackwell GPUs shipping in the same window. NVFP4 is a 4-bit floating-point format that retains more dynamic range than int4 — useful when you want quality closer to K-Quant-Dynamic at the file size of K-Quant-17GB. Worth watching.

Benchmarks: where Glimmer wins and loses

The HF benchmarks table puts Glimmer against Gemma4-31B and Qwen3.6-27B, both in thinking mode. The pattern is clean: Glimmer wins agentic orchestration and research, loses terminal and computer-use.

Wins:

MCP Atlas: 75.5 vs Gemma4’s 54.2, Qwen3.6’s 62.5
DeepSearch QA: 74.6 vs 61.7 / 71.1
SWE-Bench Pro: 51.2 vs 36.9 / 50.2
GAIA2: 43.3 vs 36.4 / 40.0

Losses:

OSWorld-Verified: 65.9 vs Qwen3.6’s 75.6
TerminalBench 2.1: 51.7 vs Qwen3.6’s 60.7

The MCP Atlas gap is the one that matters most for agent builders. The model is tuned for tool-use protocols specifically. The OSWorld loss tells you it’s not the right pick for a GUI-driving agent — Qwen3.6 still owns that niche.

Built-in retry and a reasoning strength knob

Two design choices deserve attention. First, Glimmer was trained to retry tasks it fails on the first attempt — many open-weight models stop cold on a failed tool call. This is the kind of training detail that doesn’t show up on a benchmark but cuts your retry-loop code in half.

Second, there’s a reasoning_strength parameter on the processor — low / medium / high — that controls how much compute Glimmer spends per task. This is novel for an open-weight release. It’s a per-task cost/quality lever: when an agent loop hits a planning step that doesn’t need depth, you drop to low and save tokens; when it hits a synthesis step that does need depth, you raise to high. For agent developers who care about cost per resolved task, this is a real lever that wasn’t there before.

Running it locally: LM Studio and llama.cpp

When the LM Studio rollout lands (in the coming days per the HANDOFF), the path is:

Install LM Studio from lmstudio.ai — current 0.3.x line.
Search “muse-glimmer” in the model browser. Pick the K-Quant-17GB GGUF if you have a 24 GB card; K-Quant-Dynamic if you have a 32 GB card.
In the model config panel, the GPU layer slider controls how many transformer layers stay on the GPU. For a full offload of K-Quant-17GB on a 24 GB card, slide to maximum. For a 12 GB card, you can fit roughly 20 of the 48 layers on the GPU and the rest offloads to system RAM.
Start the local server, point your agent at http://localhost:1234/v1.

If you want it today rather than waiting for the LM Studio registry, the llama.cpp path works now:

# Get a GGUF (K-Quant-17GB is the consumer target)
huggingface-cli download meta-models/Muse-Glimmer-30B-GGUF \
  muse-glimmer-30b.Q4_K_M.gguf --local-dir ./models

# Full offload on a 24 GB card
./llama-cli -m ./models/muse-glimmer-30b.Q4_K_M.gguf \
  -ngl 48 -c 131072 --temp 0.7

# Partial offload on a 16 GB card (most layers to CPU/RAM)
./llama-cli -m ./models/muse-glimmer-30b.Q4_K_M.gguf \
  -ngl 24 -c 131072 --temp 0.7

The -ngl flag is --gpu-layers — number of transformer layers to keep on the GPU. Each 30B layer at 4-bit is roughly 350 MB; with 48 layers, a full offload is ~17 GB of weights, leaving ~7 GB on a 24 GB card for the KV cache at long context.

RAM math: why a partial offload still needs system RAM

A common mistake: assuming partial GPU offload means the rest of the model disappears. It doesn’t. The offloaded layers live in system RAM and get paged in on demand. If you have a 16 GB GPU and want to keep 24 layers on the card, the remaining 24 layers still need to be in RAM — that’s 24 × 350 MB = ~8.4 GB of system RAM just for the offloaded weights, plus KV cache, plus whatever else your OS is doing.

The rule of thumb for K-Quant-17GB:

24 GB GPU: full offload in VRAM. No system RAM needed beyond the OS.
16 GB GPU: ~16 layers on GPU, ~32 layers offloaded. At least 11 GB system RAM for weights + 4–8 GB KV cache at 131k context. Plan for 20 GB free RAM.
12 GB GPU: ~10 layers on GPU, ~38 layers offloaded. At least 13 GB system RAM for weights + KV cache. Plan for 24 GB free RAM.

If you don’t have that RAM headroom, the OS will swap and decode will grind to single-digit tok/s. The K-Quant-17GB build that fits in 24 GB VRAM is the only build that gives you a clean “fits on one card” story.

What this changes

The combination of three factors is what makes Glimmer different from the usual open-weight release. Day-0 in three stacks means the integration work is already done — you’re not waiting for llama.cpp to ship a PR, you’re not patching vLLM to support a new architecture. DFlash pre-integrated means the agent-loop decode-throughput problem is solved at the model level, not the inference-engine level. And the K-Quant-17GB build that fits in 23.6 GB on a 3090 means the deployment target is hardware people already own.

For agent builders who were hedging on Qwen3.6 because of the open-weight gap, the calculus just shifted. Glimmer wins on MCP Atlas and SWE-Bench Pro, ships under Apache 2.0 (not Qwen’s custom license), and runs on the GPU you already have. The one place Qwen still wins is OSWorld / computer-use, so the right pick depends on whether your agents drive GUIs or call tools.

If you’ve been waiting for an open-weight multimodal agent model that you can actually deploy without a 4-GPU workstation, this is it. The K-Quant-17GB GGUF is the file you want today; the LM Studio install path comes with the registry sync.