Muse Glimmer 30B VRAM Requirements: 24GB vs 32GB

Short answer: Meta’s official Muse Glimmer 30B GGUF repository targets 24GB hardware for its 16.8GB Q4_K_M text model and 32GB hardware for its 19.7GB dynamic Q4_K_XL build. Image input adds a 1.4GB perception encoder; speculative decoding adds a 1.6GB DFlash drafter. Meta describes the complete 17GB route as roughly 20GB with vision and drafter, and the dynamic route as roughly 23GB. That makes 24GB the supported starting tier and 32GB the higher-quality/headroom tier. A 16GB card is below the official target even though the text file alone is close.

Muse Glimmer memory at a glance

Path	Published files	Meta’s rough working memory	Planning tier
17GB Q4 text only	16.8GB	~17GB	24GB GPU or unified-memory candidate
17GB Q4 + vision	16.8GB + 1.4GB	~19GB	24GB target
17GB Q4 + vision + drafter	16.8GB + 1.4GB + 1.6GB	~20GB	24GB target with limited remaining headroom
Dynamic Q4 text only	19.7GB	~20GB	32GB target
Dynamic Q4 + vision	19.7GB + 1.4GB	~22GB	32GB target
Dynamic Q4 + vision + drafter	19.7GB + 1.4GB + 1.6GB	~23GB	32GB target with more cache headroom
BF16	Official safetensors checkpoint	Not a GGUF path	Meta targets 64GB VRAM

The published “rough total memory” values include weights plus a working context, but they do not define your prompt length, concurrency, operating-system use or maximum safe allocation. Treat them as official starting envelopes, not guaranteed peaks.

What files does Muse Glimmer need?

Official file	Published size	Purpose
`Muse-Glimmer-30B-KQuant-17GB-Q4_K_M.gguf`	16.8GB	Recommended 24GB text model
`Muse-Glimmer-30B-KQuant-Dynamic-Q4_K_XL.gguf`	19.7GB	Higher-quality 32GB text model
`mmproj-Muse-Glimmer-30B-Q4_K_M.gguf`	1.4GB	Perception encoder required for image input
`dflash-Muse-Glimmer-30B-Q4_K_M.gguf`	1.6GB	Optional speculative-decoding drafter

The text model does not become multimodal merely because the base architecture supports images. The perception encoder is a separate companion file. The drafter is optional and changes the serving configuration; it is not part of the text model’s base file size.

Can Muse Glimmer run in 16GB?

Do not treat 16GB as an official full-GPU target. The smaller official text file is 16.8GB before KV cache, runtime allocations, vision or speculative-decoding companions. CPU or system-memory offload can make a mixed-memory experiment possible, but that is different from fitting the supported 24GB envelope entirely in device memory. Measure latency and memory pressure instead of labeling the offloaded result as a 16GB fit.

Is 24GB enough for Muse Glimmer?

Yes, for the official 17GB Q4 path under Meta’s stated target. Meta reports about 17GB working memory for text only, 19GB with vision and 20GB with both vision and the drafter. On a nominal 24GB device, those figures leave approximately 7GB, 5GB or 4GB respectively before any difference between decimal file sizes, binary capacity reporting, driver reservation, display use or your actual cache allocation.

That is enough to justify 24GB as a supported starting tier—not enough to promise the full 131,072-token native context, high concurrency or every desktop configuration. Start at a shorter context and one slot, then record peak allocation.

Why choose 32GB?

The 32GB tier is the official target for the 19.7GB dynamic Q4_K_XL build. Meta reports roughly 20GB for text, 22GB with vision and 23GB with vision plus drafter. The larger envelope supports the higher-quality build and leaves materially more room for cache and runtime state, but it does not establish a speed ranking. GPU generation, bandwidth, kernels, driver, context and host platform still matter.

What about 48GB or 64GB?

A 48GB device gives the quantized paths substantially more nominal headroom for longer context or concurrency, subject to runtime support. Meta’s model card targets 64GB VRAM for full precision. The official GGUF repository explicitly says it does not publish a BF16 GGUF; use the base meta-models/Muse-Glimmer-30B safetensors checkpoint with a supported runtime such as vLLM for that path.

Context length can consume the margin

Muse Glimmer supports a native context of 131,072 tokens, but Meta’s llama.cpp recipe also uses one slot because context is divided across concurrent slots. The maximum context is not a recommendation for every 24GB machine. Start below the ceiling, keep concurrency at one, and increase one variable at a time while watching peak device and system memory.

Runtime compatibility checklist

Use llama.cpp build b10353 or newer; older builds do not recognize the Muse Glimmer architecture.
Pin the exact GGUF text file, and add the matching perception encoder only when testing image input.
Add the DFlash drafter as a separate, disclosed configuration.
Use the model’s chat template and do not stop on <|eom|>.
Record context, slots, GPU layers, backend, driver and any CPU/system-memory offload.
Measure peak memory, latency, output rate, failures and correctness separately.

Start the official 24GB GGUF path

llama serve -hf meta-models/Muse-Glimmer-30B-GGUF \
  --hf-file Muse-Glimmer-30B-KQuant-17GB-Q4_K_M.gguf \
  -a muse-glimmer \
  -ngl 99 -np 1 \
  --host 127.0.0.1 --port 8080

This orientation command follows Meta’s official llama.cpp path but intentionally leaves context at the runtime’s chosen value rather than forcing 131,072 tokens onto every 24GB system. Use the complete current Meta recipe for chat-template, authentication, vision and drafter flags.

Choose and verify the hardware

Primary sources

Method and boundary: file sizes, working-memory envelopes, hardware targets, context and runtime minimums come from Meta’s official repositories and deployment documentation checked October 25, 2026. Nominal remainder calculations subtract the published rough working-memory figure from the marketed capacity; they are planning arithmetic, not measured peak memory or performance.