Meta's 30B Agent Weights Fit a 24GB GPU • The Weighted Average

Meta’s Muse Glimmer turns local agent inference into a hardware decision: its 4-bit weights are under 20 GB and target 24 GB or 32 GB machines, while the full-precision model requires more than 55 GB. Using 55 GB and 20 GB as conservative bounds, the compressed footprint is at least 63.6% smaller—but the model’s own benchmark card still trails Qwen3.6-27B on several coding and tool-use tests. The right move this quarter is a parallel pilot for privacy-sensitive and offline workflows, not a wholesale replacement for a cloud frontier model.

A local agent becomes a procurement decision

Meta is not merely adding another endpoint to the model menu. Its Muse Glimmer announcement describes a 30-billion-parameter open-weight model designed for local agents, function calling, coding, multimodal input, and long-running workflows. The weights are available under the Apache 2.0 license, and Meta points developers to Hugging Face and its own documentation rather than requiring a hosted API.

That changes the first question a team should ask. It is no longer only “which model produces the best answer?” It is “which workloads should keep their context, credentials, and latency inside the device boundary?” Local execution can be attractive for source code, private documents, disconnected environments, and judge models that do not need frontier-scale generality. It can also move the burden from a vendor’s service-level agreement to a team’s GPU memory, runtime, patching, observability, and safety work.

The model card puts the artifact’s shape in sharper terms: approximately 29.6 billion parameters, a dedicated perception encoder of roughly 1.8 billion parameters, text-and-image input, and a 131,072-plus-token context length. Those specifications come from the Muse Glimmer model card, not from a third-party reverse-engineering exercise. The large context window is useful only if the local runtime can keep retrieval, memory, and tool state coherent; it is not a guarantee that a 24 GB machine can sustain every advertised context at useful latency.

Availability is part of the decision. Meta says the weights are downloadable now, while optimized integrations for llama.cpp, MLX, and ExecuTorch are arriving in the coming days. The developer guide describes the model as a local multimodal transformer with a 128K-token default context and lists supported launch partners. That is a promising starting line, not a production support contract. Teams should pin the exact weight revision, runtime, quantization, and prompt template in the pilot record.

The archive’s Muse Code analysis reached a related conclusion from the orchestration side: parallel local work becomes valuable only when the operator sets a stop-loss and verifies the merged result. Glimmer makes the same argument at the model boundary. Owning the weights is useful; owning a reproducible evaluation is indispensable. Today’s JetBrains spend-control brief makes the same argument from the budget side: model choice can remain plural only when requests are attributable and bounded. The Intel financing brief makes it from the infrastructure side: a larger capacity budget is not yet qualified output.

The memory budget is the product

The local case lives or dies in the space between the weights and the rest of the agent. Meta says a full-precision 30B model needs more than 55 GB, while its roughly 4-bit compression shrinks the language model to under 20 GB. The model card independently records the under-20-GB K-Quant-17GB variant and a 24 GB target, with a 32 GB option for the less compressed configuration. Taking the conservative endpoints gives a minimum footprint reduction of 1 − 20 ÷ 55 = 63.6%. The true reduction is larger because both source figures are bounds.

That remaining memory is not spare capacity in the colloquial sense. It must accommodate the KV cache, the perception encoder, the speculative-decoding drafter, the operating system, and the serving runtime. At the strict 20-GB upper bound, a 24-GB envelope leaves roughly 4 GB, or 16.7%, before any other application competes for memory. A long context, image-heavy prompt, or multiple concurrent requests can consume that margin quickly. A pilot should therefore record peak resident memory, context length at peak, concurrency, and whether the system silently spills to slower memory.

Speed is similarly hardware-specific. The model card reports DFlash speculative decoding at 3.1× on an RTX 5090, 1.8× on an M5 Max, and 1.5× on an M4 Max. The underlying measurements move from 74.9 to 233.4 tokens per second on the RTX 5090, 26.6 to 50.2 on the M5 Max, and 23.7 to 37.8 on the M4 Max. Meta’s methodology page says those experiments use batch size one and average across a diverse prompt set; they are not a universal service-rate guarantee.

Muse Glimmer's speedup depends on the host

K-Quant-17GB decode speedup with DFlash, batch size 1

Meta Muse Glimmer model card · Aug 2026

The comparison is the point: the drafter is not a magical 3.1× coupon that follows the model to every machine. It rewards a particular hardware and runtime combination. The DFlash paper describes block-diffusion speculative decoding, in which a smaller network proposes blocks of tokens and the main model verifies them. That architecture can reduce serial waiting without changing accepted output, but its benefit depends on memory headroom, kernel quality, prompt shape, and the host’s ability to run both networks without contention.

The open-weight license removes one category of lock-in; it does not remove operations. A team still needs a reproducible build, a model download policy, a runtime security review, telemetry that does not leak prompts, and a plan for weight updates. The llama.cpp project and MLX project are useful evidence that local serving ecosystems exist, while ExecuTorch supplies a mobile and edge-oriented path. None of those repositories promises that Meta’s first integration will behave identically across them.

Benchmarks leave the cloud door open

Glimmer is credible enough to test, but the benchmark table does not justify a model switch by itself. Meta reports 51.2 on SWE-Bench Pro, ahead of Gemma4-31B’s 36.9 and just above Qwen3.6-27B’s 50.2. On SWE-Bench Verified it reports 76.0, behind Qwen’s 77.2; on TerminalBench 2.1 it reports 51.7, behind Qwen’s 60.7. The public benchmark page exposes the same comparison across agentic, coding, multimodal, safety, and reasoning tasks.

That pattern is more useful than a single win. Glimmer may be a strong local coding baseline while still losing on the exact tasks where a team needs terminal reliability, computer use, or long-horizon tool execution. It means the evaluation matrix should contain the organization’s own repositories and tool policies, not just the vendor’s leaderboard. A local model that is 20% cheaper in infrastructure terms but sends twice as many tasks to human repair is not cheaper in production.

Safety numbers reinforce the need for a system-level test. Meta’s model card reports a 28.4% attack-success rate on its Siren AgentDojo evaluation, with 94.2 utility. Gemma4-31B is reported at 25.6% attack success and 90.8 utility, while Qwen3.6-27B is at 40.3% and 92.7. The lower attack-success figure is better, but these are model-and-harness measurements, not a license to attach unrestricted tools. Meta explicitly recommends additional guardrails and human confirmation for irreversible actions.

The methodology deserves equal prominence with the scores. Meta says it uses the most favorable self-reported result or an internal reproduction for non-Muse models when available. It also says third-party results come from a best-effort common framework that may not be tuned to proprietary models’ strengths. That does not make the table useless; it makes it a hypothesis generator. Independent runs should preserve the same task set, prompts, tool permissions, stopping rules, quantization, and judge version before anyone interprets a score delta as a product advantage.

The Claude math result in today’s Second Front offers a useful contrast. There, the interesting claim is not merely that a model produced a high-level answer, but that a research workflow produced artifacts for experts and a formal checker to interrogate. Glimmer pilots should use the same discipline: save traces, retain failed runs, and distinguish model competence from scaffold competence.

Pilot the edge, keep the escape hatch

Who should switch first? Teams with a clear local-first requirement, a 24- or 32-GB hardware envelope, non-sensitive pilot repositories, and reversible tool actions should run Glimmer beside their incumbent. Offline coding, private document triage, local evaluation, and low-latency classification are sensible candidates. Teams that need the best available performance on high-stakes autonomous actions should keep a cloud fallback until independent evidence closes the benchmark and safety gaps.

The pilot should price the whole system rather than the download. Record hardware acquisition or allocation, electricity, model-serving engineering, storage, update labor, context failures, tool-call retries, review time, and escalation to a cloud model. The public release does not provide a universal cost-per-task number; that absence is itself a reason to measure locally rather than repeat Meta’s headline. The llama.cpp DeepSeek analysis showed why a runtime optimization can be valuable while remaining workload-specific.

A serious pilot should split the local promise into three ledgers. The first is data locality: verify where prompts, tool results, model traces, crash dumps, and telemetry land, because “runs on your device” does not automatically mean every artifact stays there. The second is availability: a local model removes a network dependency but makes the team responsible for model files, drivers, runtime upgrades, and recovery when a GPU or host fails. The third is performance: measure p50 and p95 time to first token, total task time, peak memory, and human repair, not only decode speed on a clean prompt.

Those ledgers also make escalation rational. A local agent can handle a private, reversible task, then hand an ambiguous or high-risk request to a cloud model or a human reviewer. That hybrid route may be more expensive per response than an all-local slogan, but it can be cheaper than overprovisioning every workstation for the hardest context. Keep the routing rule explicit and log the reason for each escalation. Otherwise the organization will discover only after deployment that the “fallback” is a second unmeasured system with its own data, latency, and budget risks.

The operator checklist is short:

Platform teams should pilot on reversible repositories and pin weights, runtime, quantization, context, and concurrency before comparing quality.
Security teams should require scoped credentials, human confirmation for irreversible actions, local log redaction, and a kill switch; open weights do not provide those controls.
Finance teams should count hardware, power, integration, maintenance, review, and cloud fallback rather than treating zero license fee as zero cost.
Procurement should keep an escape hatch until third-party coding, tool-use, privacy, and adversarial evaluations reproduce the result on representative work.
Change the verdict if independent runs show lower cost per validated task without a material increase in repair, leakage, or unsafe tool-action rates.

Muse Glimmer is therefore neither a toy nor a frontier replacement. It is a credible new point on the local-agent frontier: small enough to fit a consumer memory envelope, capable enough to earn a controlled bake-off, and unfinished enough that the bake-off—not the model card—should decide.