Meta has released Muse Glimmer, a multimodal agent model with approximately 30B parameters, supporting 128K context length and capable of running on devices with 24GB VRAM. The model is open-sourced under the Apache 2.0 license, reduces KV cache memory usage through GQA, and employs a hybrid local and global attention architecture to lower computational costs for long contexts. Two quantized versions are provided to suit different VRAM configurations. The visual module features a dedicated ViT Perception Encoder to process screenshots and screen information, and during training, on-policy distillation is introduced to handle long-task state deviations. The DFlash inference acceleration component uses block diffusion for parallel token prediction, achieving approximately 3x faster decoding on RTX 5090. The model performs excellently on agent benchmarks such as MCP Atlas and DeepSearch QA, but still has room for improvement in pure GUI scenarios like OSWorld Verified.

Author and source: Leiphone

Yesterday, Meta released Muse Glimmer, a multimodal agent model with approximately 30 billion parameters, supporting 128K context length, capable of calling tools, executing code, and processing images and screen information.

This model is open-sourced under the Apache 2.0 license and includes two 4-bit quantized versions, a standalone vision encoder, and the DFlash inference acceleration component, with local deployment options available via llama.cpp, MLX, ExecuTorch, and more.

Although a parameter scale of 30B and a context length of 128K may not seem extraordinary today, the issue is that Meta intends for it to do more than ordinary chat—it aims to establish a complete local agent execution paradigm.

Muse Glimmer, designed for long-running local agents, faces stringent engineering constraints: it must process continuously generated screenshots while maintaining task logic spanning dozens of steps, all within a limited 24 GB of GPU memory. After running for dozens of steps, previous tool outputs, code logs, page states, and reasoning processes accumulate in the context.

At this point, many issues that aren't obvious in chat scenarios quickly become magnified: How do you fit 128K context into limited GPU memory? How do you manage historical states as screenshots accumulate? How does the model recover after a tool call fails? And how much does a large volume of reasoning tokens slow down decoding?

The technical design of Muse Glimmer revolves around these very issues. Rather than relying on a single, standout new architecture to solve everything, it makes aggressive trade-offs in Attention, KV Cache, training methods, quantization, and decoding.

If previous local models were about "just getting running," Muse Glimmer aims to be "as usable and continuously reliable as cloud-based models."

Looking at these parts together makes it easier to understand why Meta designed it this way, compared to looking at 30B or 128K individually.

How to fit 128K context into 24GB GPU memory?

Muse Glimmer uses 52 layers of Dense Transformer with a hidden size of 6656, 32 query heads, but only 2 key-value heads.

Not every layer processes the full context; instead, it uses a cyclic pattern of three Local Attention mechanisms followed by one Global Attention mechanism.

Local Attention only processes the nearby 2048 tokens, while Global Attention handles information exchange over longer distances.

Both designs actually increase the cost of long contexts. When the model generates new tokens, it caches the Key and Value of previous tokens, known as the KV Cache. The longer the context, the more memory this portion consumes.

Muse Glimmer has only 2 KV heads per layer, with each head dimension at 128. Roughly calculating in BF16, the KV cache for one token in a single layer occupies approximately 1024 bytes.

If all 52 layers stored a full 128K context, the KV cache would require approximately 6.5 GiB. However, Muse Glimmer actually has 39 Local layers and 13 Global layers. The Local layers only need to maintain a sliding window of about 2048 tokens, while only the Global layers need to preserve the full long context.

Using the same estimation method, the KV cache can be reduced to approximately 1.7 GiB. This is not an officially published runtime memory figure, but rather a theoretical estimate based on publicly available architecture parameters—nevertheless, it already explains why this architecture was designed this way.

If it stored independent KV pairs for all 32 heads, as in traditional MHA, rather than using only 2 KV heads, the KV cache would theoretically increase by approximately 16 times under the same conditions, reaching over 20 GiB.

The standalone KV cache already exceeds a 24GB GPU. Here, two methods are actually used: GQA reduces the number of KV pairs that need to be stored per token, and Local Attention reduces the number of layers that require long-term storage of full KV caches.

After completing this step, weight quantization becomes meaningful. Muse Glimmer’s K Quant 17GB weights are approximately 16.8 GB, the vision module is about 1.4 GB, and DFlash is around 1.6 GB—adding up to nearly 20 GB. This version is designed for devices with 24 GB of VRAM, while another variant, Dynamic K Quant at around 20 GB, is tailored for devices with 32 GB of VRAM.

The two quantization methods differ not only in file size. Among the 15 benchmarks provided by Meta, the average accuracy loss for Dynamic K Quant is approximately 0.2%, while for K Quant 17GB it is approximately 1.0%.

In other words, the 24GB version further reduces VRAM usage and takes up less space, but requires accepting a slightly more noticeable drop in performance. The 32GB version aims to preserve the original model's performance as much as possible.

Muse Glimmer’s 128K context is achieved through this combination: Attention reduces computational load, GQA further reduces the KV cache, and finally, quantization compresses the model weights.

This approach also comes with a cost. The 39 Local layers can only directly access the nearest 2,048 tokens; distant information must be propagated through the Global layer. Therefore, being able to input 128K tokens is not the same as being able to reliably utilize the entire 128K.

Meta's Beam128K results show that this hybrid local and global architecture still demonstrates strong capability in utilizing long-range information, but it addresses long context, not long-term memory. Deciding which information to retain, which has become outdated, and when to update the state still requires handling by the Agent Runtime.

This issue becomes even more apparent with the visual agent.

128K is not unlimited space.

Muse Glimmer also includes a ViT-G 14 Perception Encoder with approximately 1.8 billion parameters, designed to process screenshots, web pages, charts, and documents. A single image can be converted into up to 4,096 visual tokens.

It currently accepts text and image inputs with text output, rather than incorporating all modalities into a single generative model.

Within the Agent workflow, this visual capability is primarily responsible for reading the environment state. The Computer Use Agent first observes the current screen, identifies the positions of pages, buttons, and text, then performs one action. After the page changes, it reads the new screenshot and continues to determine the next step.

As a result, visual inputs continuously enter the context. If all screenshots from a forty-step task are fully retained, even with a 128K context, the context will quickly become saturated with visual tokens. Older screenshots may also conflict with the current state—the page has changed, but previous buttons and windows remain in the context, forcing the model to extra effort to determine which state is the most recent.

Meta also does not retain an unlimited Screenshot History in OSWorld Verified, but only keeps the most recent screenshots. This indicates that Perception Encoder and Context Management are two distinct issues.

The former is responsible for converting the current screen into information the model can understand, while the latter determines which historical states are still valuable and which should be deleted. Therefore, 128K is more like providing the Agent with a larger workspace, rather than eliminating state management.

As the agent continues to interact with the environment, the focus shifts from what the model perceived to what the model just did.

This is where the training for Muse Glimmer begins.

How to proceed after the agent goes off track

Muse Glimmer is distilled from the larger Muse Spark.

Meta divides training into Pre-Training, Mid-Training, and Post-Training. Pre-Training uses Logit Distillation, Mid-Training incorporates additional long-context, reasoning trace, and agent data, and Post-Training adds SFT, On-Policy Distillation, and RL.

Logit Distillation differs slightly from the conventional approach of using a large model's answers to train a small model. When the teacher predicts the next token, it produces a probability distribution over the entire vocabulary. The student learns not only the final selected token but also the teacher’s relative judgments among other candidate tokens.

This is useful for the Agent, as many scenarios do not have a single correct action. When presented with a webpage, the model can continue searching, open a specific result, or switch to another tool. The Teacher’s probability distribution captures its preferences among these actions, not just the final output text.

At Mid Training, the training shifts from single responses to complete task trajectories. After tool execution, the environment changes: searches return new results, code execution failures produce error messages, and incorrect GUI interactions alter the page. In other words, the agent’s output directly alters the next input.

Assume the teacher’s correct trajectory is A to B, then to C, and finally to D. If the student only learns from the teacher’s data, it will repeatedly observe A to B and B to C. However, during actual execution, the student might step directly into a different B state on its first move.

From this point on, the environment has changed, and the B-to-C transitions in the training set cannot directly tell it how to act now. On-Policy Distillation comes into play here: the Student first performs its own rollout to reach states it will genuinely encounter, and then receives supervision from a stronger model on those states.

Therefore, the training data now includes not only the teacher's ideal path but also the erroneous states that the student itself may generate. This connects directly with the failure recovery emphasized by Muse Glimmer.

After entering incorrect parameters, if the model can understand the error and make a revised tool call, the task can still proceed. Similarly, if you take a wrong path on a website, as long as you recognize that the current state is incorrect, you can backtrack or switch routes. The real challenge occurs when the model fails to recognize the error and continues executing based on the incorrect state, allowing the deviation to accumulate.

Therefore, an agent's capability shouldn't be judged solely by whether a single tool call is correct, but also by whether the entire task can ultimately be completed and whether it can recover from errors that occur along the way. This also explains why Muse Glimmer performs better on certain long-process agent benchmarks.

However, completing the task does not mean there are no issues with local execution. If a complex task generates a large number of Reasoning Tokens, the new bottleneck will quickly become the Decode phase.

Two questions, one before and one after

Muse Glimmer supports four levels of Reasoning Strength: low, medium, high, and xhigh. This setting can be understood as the runtime reasoning budget.

Higher tiers typically cause the model to generate more reasoning tokens, which may lead to higher success rates on complex coding and agent tasks, but the trade-off is direct: context grows faster and decode times become longer.

Meta uses high Reasoning Strength in its public benchmark, which leads to DFlash.

The decoder in a Transformer is autoregressive: the second token must wait for the first, the third depends on the second, and so on. While this is acceptable for responses of a few hundred tokens, an agent may generate thousands or even tens of thousands of tokens in a single task.

The approach of speculative decoding involves adding a smaller Drafter model. The Drafter first predicts a sequence of upcoming tokens, which the main model then verifies in one step. If multiple candidate tokens can be sequentially accepted, this reduces the number of decode steps executed by the 30B main model.

The problem with traditional approaches is that the Drafter itself is typically also an autoregressive model; if it needs to draft 16 tokens, it still must generate them one by one.

DFlash replaced this section with Block Diffusion.

The DFlash Block Size of Muse Glimmer is 16, enabling parallel prediction of a set of candidate tokens. However, being faster alone is not enough for Drafter. If the predictions are inaccurate and the main model rejects most of the candidates, the earlier speed advantage will quickly disappear.

Therefore, DFlash also directly reads the Hidden Features from layers 1, 13, 25, 37, and 49 of Muse Glimmer and passes these intermediate representations to Drafter, which has only five layers. This allows Drafter to leverage the internal representations already formed by the 30B main model, without needing to reprocess the full context.

These features are not used only once at the input stage; instead, they are continuously injected into the Key and Value of each layer in the Drafter to prevent them from weakening as the network deepens.

There’s another detail during training: within a 16-token block, earlier tokens are more important than later ones. If the first token is incorrect, even if subsequent tokens are guessed correctly, the consecutive acceptance length will remain very short.

Therefore, DFlash assigns higher loss weights to tokens at the beginning of the block and gradually decreases them toward the end. It optimizes for the longest possible acceptable prefix, rather than simply maximizing average accuracy across 16 positions. In Meta’s K Quant 17GB dataset, the decode speed on an RTX 5090 increased from approximately 74.9 tokens/s to 233.4 tokens/s.

If an Agent Task accumulates 10,000 tokens, solely considering decoding, the former would take approximately 134 seconds, while the latter would take about 43 seconds. Real-world tasks also include prefill, tool execution, and network latency, but for agents with high reasoning strength, this difference already significantly impacts the overall task experience.

High Reasoning Strength increases token generation, and DFlash reduces the time required for this process. Long contexts increase KV Cache, while GQA and Local Attention reduce memory usage. Quantization keeps model weights within the capacity of consumer-grade GPUs.

In addition, Muse Glimmer performs well on Agent benchmarks such as MCP Atlas, DeepSearch QA, and Gaia2, all of which require long execution chains.

MCP Atlas requires the model to select and invoke tools across multiple MCP servers. DeepSearch QA needs to continuously search, open pages, locate information, and proceed based on new results. Gaia2 simulates stateful applications such as email, calendar, and contacts, and the environment itself changes during the task.

These tasks align well with Muse Glimmer’s training approach. However, it does not maintain the same advantage on OSWorld Verified, TerminalBench, and SWE Bench Verified. For example, on OSWorld Verified, Muse Glimmer scores 65.9, while Qwen3.6 27B achieves 75.6. On TerminalBench 2.1, Muse Glimmer scores 51.7, compared to 60.7 for the other model.

Its capability distribution is therefore relatively clear. The Research Agent, tool collaboration, and long-process stateful tasks are stronger, while there is still significant room for improvement in pure GUI, terminal, and some coding agent scenarios. These scores should not be interpreted entirely according to traditional model rankings.

Agent Benchmark results can also be influenced by the System Prompt, Tool Definition, Scaffold, maximum execution steps, sampling parameters, and even the Judge Model. Meta itself acknowledges that the Agent Tools and System Prompts used by third-party models may not be optimally tuned for them.

By the Agent stage, comparing checkpoints in isolation has become increasingly insufficient to capture the full picture. The same issue applies to security.

Running locally does reduce the frequent transmission of files, screenshots, and private context to the cloud, but this only addresses the data pathway. Prompt injection, erroneous tool calls, privilege escalation, and irreversible actions still persist. Meta has also separately evaluated Agentic Risk, Privacy, and Prompt Injection, and recommends continuing to enhance guardrails and incorporate necessary human-in-the-loop controls for real-world deployment.

A clear competency roadmap

The complete technical pathway of Muse Glimmer can ultimately be connected into a clear and coherent chain.

Model size is kept around 30B, with GQA and Local Attention reducing VRAM costs for 128K context; quantization enables deployment on 24GB and 32GB devices; the Perception Encoder processes visual environments; On-Policy Distillation addresses state deviations in long tasks; Reasoning Strength allows developers to control reasoning budgets; DFlash mitigates decode latency caused by large volumes of reasoning tokens.

Muse Glimmer has not proven that a local 30B model can replace cloud-based frontier models, but it has demonstrated that the ultimate potential of a local 30B model lies not in scale alone, but in system-level engineering that holistically addresses various hard constraints. It has integrated the four most challenging constraints in local agents—memory, context, environmental state awareness, and inference speed—into a single cohesive system design.

Although Muse Glimmer cannot yet fully replace cloud-based flagship models, it has paved a path toward industrial-scale implementation of the goal that everyone can have their own private agent.