, 6 min read, by

Running Muse Glimmer Locally with Ollama: Meta's 30B Model on Consumer Hardware

Run Meta's Muse Glimmer 30B locally with Ollama ≥ 0.32.8: pull the model, call the REST API, send multimodal prompts. Up and running in 15 minutes.

On August 10, 2026, Meta Superintelligence Labs released Muse Glimmer, a multimodal 30B model under the Apache 2.0 license and the open-weight counterpart to the closed Muse Spark model. It is designed for agent-based tasks: multi-step reasoning, tool use, and code generation. In its 4-bit quantized form it requires 18 GB of VRAM, making it suitable for consumer GPUs such as an RTX 4090 or a Mac with an M4 chip.

This post shows the shortest path from a blank machine to a running Muse Glimmer service with a REST interface. The setup is based on an Ollama installation via Docker on Linux; on a Mac with Apple Silicon, use the native Ollama app instead. If you already have Ollama running, you can skip directly to "Pull the model."

Updated 7 October 2026: Corrected the Apple Silicon instructions: the MLX variant runs with the native Ollama app, not in a Docker container, because Docker Desktop on macOS does not pass the GPU through to Linux containers. The Compose file now also uses the Docker tag 0.32.9, because there is no image tagged 0.32.8, and the note on AMD GPUs is more precise.

What Sets Muse Glimmer Apart from Other Open-Weight Models

The most noticeable difference from models like Llama 3.x or Mistral is the embedded vision encoder: the model consists of a language core with approximately 27.8 billion parameters and a separate 1.8-billion-parameter perception module that processes images, screenshots, and diagrams. A 128K-token context window accommodates long documents and multi-step agent interactions within a single conversation.

Muse Glimmer makes sense wherever privacy requirements rule out a cloud service, wherever multimodal inputs (such as screenshots of user interfaces or photos of forms) need to be processed, or wherever a coding agent needs to run on your own hardware. For high parallel throughput in production a dedicated serving stack like vLLM remains the more robust choice; how to set that up is covered in the Hermes and vLLM section of Ollama: self-hosting an LLM locally.

Prerequisites

  • Ollama ≥ 0.32.8: mandatory; version 0.32.7 includes the model in its manifest but lacks NVIDIA/AMD backend support, causing the download to fail with HTTP 412
  • 18 GB VRAM (NVIDIA/AMD) for the standard variant (Q4_K_M) or 21 GB unified memory for Apple Silicon using the MLX variant
  • On Linux with an NVIDIA or AMD GPU: Docker and Docker Compose (recommended) or a native Ollama installation; on a Mac with Apple Silicon: the native Ollama app

Starting Ollama with Docker

The following stack is meant for Linux, with an NVIDIA GPU or CPU only. For an AMD GPU, the Ollama Docker docs use the image with the -rocm tag suffix and additionally pass the devices /dev/kfd and /dev/dri through to the container. On a Mac with Apple Silicon, install the native Ollama app instead: Docker Desktop does not pass the GPU through to Linux containers on macOS, so Ollama would run there without GPU acceleration.

services:
  ollama:
    image: ollama/ollama:0.32.9  # first Docker tag at or above the 0.32.8 minimum (see pitfall 1)
    ports:
      - "127.0.0.1:11434:11434"
    volumes:
      - ollama_models:/root/.ollama
    restart: unless-stopped
    # NVIDIA GPU (NVIDIA Container Toolkit required):
    # deploy:
    #   resources:
    #     reservations:
    #       devices:
    #         - driver: nvidia
    #           count: all
    #           capabilities: [gpu]

volumes:
  ollama_models:
docker compose up -d
curl -s http://localhost:11434/api/version

The ollama_models volume prevents the several-gigabyte model weights from being downloaded again after every container restart. Binding to 127.0.0.1 blocks external access; Ollama has no built-in authentication. For a native installation or a deeper look at configuration options, see the post Ollama: self-host an LLM (quickstart).

Pull and Test the Model

# Linux (Docker), NVIDIA or CPU, Q4_K_M, approx. 18 GB download:
docker compose exec ollama ollama pull muse-glimmer

# Apple Silicon, native Ollama app (not in a container) - MLX engine, approx. 19 GB:
ollama pull muse-glimmer:30b-mlx

# Verify loaded models (on a Mac: ollama list):
docker compose exec ollama ollama list

# Quick interactive test in the terminal (on a Mac: ollama run muse-glimmer:30b-mlx):
docker compose exec -it ollama ollama run muse-glimmer

Calling the REST API

Muse Glimmer uses the same HTTP interface as any other Ollama model: no additional SDK, no new port. The native app on a Mac also listens on port 11434; there, use muse-glimmer:30b-mlx as the model in the following examples. By default Ollama streams the response as a sequence of JSON objects (one per line); "stream": false collects everything into a single response, which is more convenient for scripts and batch processing.

For a plain text request:

curl -s http://localhost:11434/api/chat -d '{
  "model": "muse-glimmer",
  "messages": [
    { "role": "user", "content": "Write a Python function that parses ISO 8601 date strings." }
  ],
  "stream": false
}'

The response text is in message.content. For multimodal prompts, attach the image as a Base64 string in the images array:

# Linux: -w 0 suppresses line breaks; macOS: base64 without -w
IMG=$(base64 -w 0 screenshot.png)

curl -s http://localhost:11434/api/chat -d '{
  "model": "muse-glimmer",
  "messages": [
    {
      "role": "user",
      "content": "Describe what is shown in this screenshot.",
      "images": ["'"$IMG"'"]
    }
  ],
  "stream": false
}'

Requests and responses at a glance:

                +--------------------+                      
  Text -------> |                    | ---> JSON            
                |  ollama serve      |      message.content 
  Image ------> |  Port 11434        |      eval_count      
                +--------------------+                      

Existing applications that use the OpenAI Python SDK can be redirected to Muse Glimmer without code changes by setting base_url="http://localhost:11434/v1/", since the /v1/chat/completions endpoint is fully compatible.

Three Common Pitfalls

1. Ignoring the minimum version requirement. Version 0.32.7 includes Muse Glimmer in its manifest but lacks NVIDIA/AMD backend support; the pull fails with HTTP 412. Check first with ollama --version. There is no Docker image tagged 0.32.8 on Docker Hub (only 0.32.8-rocm); the first matching tag is 0.32.9, as used in the Compose file above.

2. Wrong tag on Apple Silicon. The default tag muse-glimmer is GGUF-based. For the MLX engine on Apple Silicon, the Ollama library explicitly names muse-glimmer:30b-mlx; for significantly higher token rates on M4 and M5 chips, pull this tag, and do so with the native Ollama app rather than in a Docker container. According to the release notes, since version 0.40.0 Ollama on Apple Silicon automatically runs model architectures supported by the MLX runtime on MLX; for Muse Glimmer, however, the library still recommends the explicit MLX tag. The two tags occupy separate storage areas in the Ollama directory; mixing them up means downloading data twice.

3. Underestimating the VRAM budget. The 18 GB for the Q4_K_M variant breaks down into roughly 17 GB of model weights and roughly 1 GB for the vision encoder. Add another 1 to 2 GB for the KV cache during inference. On a card with exactly 18 GB of VRAM the setup runs at its limit, while 24 GB allows for noticeably more comfortable operation.

What to Do Next

With this in place, Muse Glimmer runs locally and is reachable via REST. A natural next step is a RAG pipeline: vectorize documents via POST /api/embed with an embedding model like nomic-embed-text and store them in a local vector database. How to set that up with Qdrant is explained in the post Self-hosting Qdrant for RAG.

Further reading: Ollama blog on Muse Glimmer, Meta research blog, Ollama API reference, Ollama library: muse-glimmer.

Note: The articles on this blog are produced with the help of AI and are editorially reviewed before publication. Editorial responsibility lies with Emre Yurtbay (see the legal notice).

Let's talk

In a free initial consultation, you describe your situation to me. I will give you an initial assessment of how I can support you.

Request a free initial consultation