Muse Glimmer 30B Would Not Load in Ollama, So I Ran and Measured It on llama.cpp

2026年10月22日

A new model called Muse Glimmer 30B has been published on Hugging Face (a site that distributes AI models). The license is Apache-2.0, and the quantized file is about 16.8GB. It looked like it would fit on an RTX 3090 with 24GB of VRAM, so I actually ran it.

However, loading failed in Ollama, the tool I usually use. The file from the same distributor, with the same Q4_K_M quantization, ran in different software. What changes depending on the software that runs it?

This reflects the state of things as of October 16, 2026.

Purpose: what this article measures

This article checks the following two things.

• Whether it loads: whether the same GGUF file (a model file format for local use) loads in Ollama 0.30.5 and in llama.cpp build 10941
• Speed: in the software that loaded it, how many tokens per second it reads the input (input processing) and writes the answer (generation)

There are also things I did not measure. Japanese quality, accuracy, and behavior when given images are outside the scope of this article. Details are in “Limitations: what I did not measure".

My aim is that after reading, you take away two things: a rough guide to running this model on a 3090, and how to tell why a file will not load.

Background: terms explained

Because several technical terms follow, I will sort them out first.

• Token: the unit an AI uses when processing text. It does not match the character count; a word or a fragment of a word counts as one token
• tok/s (tokens per second): the number of tokens processed per second. Larger is faster, and all speeds in this article use this unit
• Input processing (pp512) and generation (tg128): an AI first reads the question (input processing, also called prefill) and then writes the answer one token at a time (generation). pp512 is the speed of reading 512 tokens, and tg128 is the speed of writing 128 tokens. Both are in tok/s
• VRAM: the dedicated memory on a GPU. If the whole model fits here, it can run on the GPU alone
• Quantization: a method of making a file smaller by making the model’s numbers coarser. Q4_K_M is one format that shrinks to roughly 4 bits
• GGUF: the model file format read by llama.cpp-family software. The file records the name of the model’s design (the architecture name)
• llama.cpp and Ollama: both are software for running AI locally. I understand that Ollama uses llama.cpp-family components internally (unconfirmed), but the list of supported designs differs by version
• Dense model: a design that uses the whole model for every question. It is the counterpart of MoE, which uses only the parts it needs

What Muse Glimmer is: history and design notes

Before the measurements, I will sort out where this model comes from. This section is based on public information on Hugging Face (the model card and config files), and the sources are collected at the end of the article.

Publisher and release timing

The publisher is the organization “meta-models" on Hugging Face. Hugging Face displays the name “Meta Inc." (verified), and the author field of the model card says “Meta Superintelligence Lab". The repository was created on August 9, 2026, and the card says “released August 2026". The creation date of a repository does not necessarily match the release date, but it gives a rough idea of the timing. The license is Apache-2.0.

The same organization also has Muse-Spark-Open-816B-A42B, created on September 15, 2026 (an MoE model that uses 42 billion of its 816 billion total parameters at a time). However, I could not read the relationship between that model and Glimmer from the card.

Name and lineage

The model card describes Muse Glimmer as a model “distilled from Muse Spark". Distillation is a method of training a small model by using the outputs of a large model as the example. The stated goal is autonomous agents (AI that carries out work while calling tools) that run on consumer hardware.

I could not confirm where the names “Muse" and “Glimmer" come from. I also could not confirm when Muse Spark was released or how large it is in this investigation.

Internal design: a 3-to-1 attention pattern

According to the model card and config files, Muse Glimmer is a dense causal transformer (a format that predicts the next word from the previous words) with 52 layers. Its attention repeats a pattern of “3 local layers, 1 global layer". Local layers look only at the most recent 2,048 tokens, and global layers look at the whole text. Of the 52 layers, 39 are local and 13 are global.

The longer the text gets, the more memory (KV cache) global attention needs. In this design only 13 layers look at the whole text. The number of KV heads is also small at 2 (one sixteenth of the 32 on the question side), which reads as a design that keeps memory small even for long text. However, I have not checked that effect with numbers.

The card also says it has a dedicated encoder for reading images (about 1.8B parameters, 50 layers), that it handles text lengths of 131,072 tokens or more, and that its vocabulary is 202,048. The total parameters are about 29.6B on the card and 27.85B in the GGUF metadata. I guess this difference is close to the size of the image encoder, but the card does not say so.

Another distinctive feature is speculative decoding. A small drafter predicts 16 tokens at a time, the main model checks them all at once, and the ones that match are accepted. The card reports that on an RTX 5090, 74.9 tokens per second became 233.4 tokens per second (3.1 times), but this is the developer’s own figure. I did not use the drafter in this measurement.

External evaluation: the Artificial Analysis index

As a third-party evaluation, there is the Intelligence Index from Artificial Analysis (a site that compares AI performance). In the chart in the site’s X post (Intelligence Index v4.3.2), the bar for Muse Glimmer is labeled 17. This is a number published by Artificial Analysis, not a measurement by this blog. Please check the original post for the exact value.

Method: how I measured

I used one machine running Ubuntu. The only GPU was an RTX 3090 (24GB VRAM), and I compared the following two pieces of software.

• Ollama 0.30.5: used to check whether the model loads
• llama.cpp build 10941 (commit 4a8993735, Vulkan build): used to measure speed

The model is Muse-Glimmer-30B-KQuant-17GB-Q4_K_M.gguf from meta-models/Muse-Glimmer-30B-GGUF (15.59GiB, 27.85B dense). I did not use the mmproj file for images or the drafter, and measured with text only.

Item	Details
GPU	RTX 3090 (24GB VRAM)
OS	Ubuntu
Software	llama.cpp build 10941 (Vulkan)
Model	Muse Glimmer 30B (Q4_K_M, 15.59GiB)
Measurement date	October 16, 2026

• I measured with llama-bench using -ngl 99 (put all layers on the GPU), -p 512 (512 tokens for input processing), -n 128 (128 tokens for generation), and -r 5 (repeat 5 times)
• Of the 5 runs, I took the median of the middle 3 points. This drops the two runs at the ends to reduce the effect of variation
• For comparison, I also measured Qwen3.8 27B (UD-Q4_K_M, 16.5GB) with the same llama.cpp b10941 and the same conditions. Because both the model size and the quantization format differ, I list it only as a reference value

Results: load check and speed

It would not load in Ollama, but it loaded in llama.cpp

When I loaded this GGUF in Ollama 0.30.5, it failed with HTTP 500 and the error unknown model architecture: muse-glimmer. Loading the image file also failed.

The file from the same distributor with the same Q4_K_M quantization (shown as 16.8GB on the Ollama side and 15.59GiB on the llama.cpp side) loaded in llama.cpp build 10941. The GGUF card says “llama.cpp b10353 or later is required; b10344 and earlier do not have the architecture name registered and cannot load it". b10941 is a version that meets this condition. On the other hand, I did not look into which point in llama.cpp-family code Ollama 0.30.5 contains.

Speed: RTX 3090, llama.cpp b10941

The Qwen3.8 27B row in the table below is a reference value with the same software and the same conditions. Because the model size and quantization differ, it does not show which is better.

Model (file)	Input processing pp512 [tok/s]	Generation tg128 [tok/s]	VRAM [GB]	Peak temperature [°C]
Muse Glimmer 30B (Q4_K_M, 15.59GiB, 27.85B)	1,339.06 (spread 7.49)	42.29 (spread 0.12)	16.9	72
Qwen3.8 27B (UD-Q4_K_M, 16.5GB) *reference value	1,119.98 (spread 9.19)	36.23 (spread 0.11)	not recorded	not recorded

Muse Glimmer reached 1,339.06 tok/s for input processing and 42.29 tok/s for generation. VRAM usage was 16.9GB, and the peak temperature during measurement was 72°C. About 7GB of the 24GB of VRAM was free.

The Qwen3.8 27B row is a reference value with the same software and the same conditions. Because both the model size and the quantization format differ, the table does not show which is better. Also, when I first measured with 6 runs, outliers of 34 to 38 tok/s mixed into the generation values. The rule of taking the middle 3 points absorbs them, but please keep in mind that values move depending on conditions.

Discussion: the software version decides whether it loads

The biggest finding of this time comes before the speed numbers. Even with the same GGUF file, whether it loaded was decided by whether the version of the software running it knew the model’s architecture name (muse-glimmer). It failed to load in Ollama 0.30.5 and loaded in llama.cpp b10941, which is a concrete example.

Right after a model with a new design comes out, the file may be published while the software on your machine has not caught up. If the error message says “unknown model architecture", checking the software version is the shortcut, before suspecting a corrupted file or a lack of VRAM.

On speed, a generation rate of about 42 tokens per second works out to about 3 seconds for 128 tokens. However, this is the value for running a single question alone, and I did not measure handling several questions at the same time.

Lined up with Qwen3.8 27B under the same conditions, Muse Glimmer’s numbers came out larger. But the file size, quantization format, and design differ, so I cannot narrow down the reason for this gap. The 3-to-1 attention pattern may be related, but I did not check that this time.

Limitations: what I did not measure

• Japanese quality and accuracy: I did not measure the quality of the text, the correct answer rate, or how often it hallucinates. Speed and the quality of answers are separate matters
• Image input: I did not use the mmproj file for images, so I did not measure behavior when reading images
• Speculative decoding: I did not use the drafter, and I did not re-test the card’s speedup figures (such as 3.1 times)
• Ollama numbers: it did not load, so there are no speed numbers. I also have not checked whether newer versions of Ollama can load it
• Long input: only the conditions of 512 tokens for input processing and 128 tokens for generation. I did not measure text of tens of thousands of tokens
• Comparison between models: the Qwen3.8 27B comparison is a reference value, and because size and quantization differ, I cannot judge which is better
• Number of measurements: 5 runs per condition, on a single measurement day, October 16, 2026. On another day or with another build, values may move
• Intelligence Index of 17: a number published by Artificial Analysis, not verified by this blog (I did not measure Japanese quality or accuracy)

Summary: whether it loads depends on the software version

• The same GGUF failed to load in Ollama 0.30.5 with “unknown model architecture: muse-glimmer" but loaded in llama.cpp build 10941
• On an RTX 3090 (24GB VRAM), Muse Glimmer 30B in Q4_K_M (15.59GiB) fit with all layers on the GPU, with 16.9GB of VRAM and a peak temperature of 72°C
• Input processing was 1,339.06 tok/s (pp512) and generation was 42.29 tok/s (tg128)
• As a reference value with the same software and conditions, Qwen3.8 27B (UD-Q4_K_M) was 1,119.98 tok/s for input processing and 36.23 tok/s for generation. Size and quantization differ, so this does not show which is better
• Japanese quality, accuracy, and image input were not measured

When you try a new model, why not check whether your software supports it before looking at the file?

Next, if I can measure aspects other than speed, such as how well it handles conversation in Japanese, I will follow it in this blog’s local LLM articles.

References

• Muse Glimmer 30B model card (README and config.json): https://huggingface.co/meta-models/Muse-Glimmer-30B
• Repository information (creation date and license): https://huggingface.co/api/models/meta-models/Muse-Glimmer-30B
• GGUF version (file list and required llama.cpp version): https://huggingface.co/meta-models/Muse-Glimmer-30B-GGUF
• Organization information: https://huggingface.co/api/organizations/meta-models/overview / List of published models: https://huggingface.co/api/models?author=meta-models
• Qwen3.8-27B quantized file (reference value): https://huggingface.co/unsloth/Qwen3.8-27B-GGUF
• Artificial Analysis X post (Intelligence Index chart): https://x.com/artificialanlys/status/2110760441240752399
• The Hugging Face information above was retrieved on October 16, 2026