Run Meta Muse Glimmer 30B on a VPS

What Muse Glimmer needs on a VPS

Muse Glimmer runs on an ordinary Linux VPS with no GPU, and the tag you pull decides whether it fits in memory. Meta Superintelligence Labs published the model on 10 August 2026 under Apache 2.0: 30 billion parameters, a 128K context window, and a dedicated 1.8B parameter perception encoder so it can read images alongside text. Meta pitches it at always on local agents rather than at chat, with a reasoning strength you set per request.

The published Ollama tags, read on 16 August 2026, run from 17 GB to 59 GB. That range is the entire sizing problem. The default tag is listed at about 18 GB, so the smallest sensible box has clearly more than 18 GB of free RAM. Disk for the download and memory for the context window come on top of that.

Which muse-glimmer tag should you pull?

[
  {
    "label": "30b-nvfp4",
    "size_gb": 17
  },
  {
    "label": "30b (default)",
    "size_gb": 18
  },
  {
    "label": "30b-q4_K_M",
    "size_gb": 18
  },
  {
    "label": "30b-q4_K_M-dflash",
    "size_gb": 20
  },
  {
    "label": "30b-nvfp4-dflash",
    "size_gb": 21
  },
  {
    "label": "30b-q8_0",
    "size_gb": 31
  },
  {
    "label": "30b-mxfp8",
    "size_gb": 33
  },
  {
    "label": "30b-q8_0-dflash",
    "size_gb": 33
  },
  {
    "label": "30b-mxfp8-dflash",
    "size_gb": 35
  },
  {
    "label": "30b-bf16",
    "size_gb": 57
  },
  {
    "label": "30b-bf16-dflash",
    "size_gb": 59
  }
]

Ollama listed 11 tags for this model that are not Apple builds. They hold the same 30 billion weights stored at different numeric precisions. The size you see is what you download, and it is also roughly what you must hold in memory before any context is added.

The two 4-bit builds are the small ones: 30b-nvfp4 at 17 GB and 30b-q4_K_M at 18 GB. The default 30b tag is listed at the same size as the q4_K_M build. The 8-bit builds, 30b-q8_0 and 30b-mxfp8, sit near 31 GB. 30b-bf16 is the unquantised 16-bit release at 57 GB, which is more RAM than most rented servers offer at a price anyone would pay for a side project.

The -dflash tags are the same builds with DFlash support, and each one is listed larger than its plain twin. Ollama describes DFlash as a speed feature and demonstrates it on Apple Silicon and on desktop GPUs. On a CPU only VPS you would be paying that extra size in real memory for a feature measured on other hardware, so start with the plain tag and change one thing at a time.

Start at 4-bit unless you have a specific reason not to. Moving from 4-bit to 8-bit roughly doubles the bytes the CPU has to read for every token it generates, so throughput drops while memory use rises. That trade is the subject of what q4, q8 and fp16 quantisation actually cost you, and on a CPU box the short answer is that the 4-bit build is the only one worth starting from.

Why the MLX tags do nothing on a Linux server

MLX is Apple's array framework, and Ollama's MLX engine is its Apple Silicon backend. Any tag with mlx in the name is built for that engine and that hardware. On an x86 Linux VPS it is tens of gigabytes of download you cannot run, and it will sit on your disk doing nothing. The speed figures in the announcement that were measured on a Mac belong to those tags, so they do not describe your server either. When you read the tag list on the model page, filter out every mlx name first, then size from what is left.

How much RAM and disk does it really need?

Two things claim memory, and only one of them is the tag size. The weights are fixed by the tag you pull. The KV cache, the per token state the model keeps for the conversation, grows with the context length you configure. Ollama's own documentation notes that serving parallel requests multiplies the context by the number of requests in flight, so a box answering two agents at once needs more memory than the same box answering one.

Do not take a RAM figure from any guide, including this one. Pull the tag, send it one prompt, and while the model is still resident run these two commands.

ollama ps
free -h

ollama ps shows what is loaded right now and how the work is split between CPU and GPU. free -h shows what is left over. Those two outputs on your own box beat any published table, because they already include your context setting, your quantisation and everything else the server is running.

Disk is the easier half. Ollama stores models under /usr/share/ollama/.ollama/models on Linux, which sits on the root filesystem on most VPS images. A 40GB root volume will not hold the bf16 build at 57 GB, and it will not hold two 8-bit tags side by side either. Move the store to a mounted volume before you pull anything.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_MODELS=/mnt/models"

sudo mkdir -p /mnt/models
sudo chown -R ollama:ollama /mnt/models
sudo systemctl daemon-reload
sudo systemctl restart ollama

The ollama user must own that directory, because the service runs as ollama and writes its blobs there as itself. If a pull fails on permissions, journalctl -u ollama -n 50 is where the reason appears.

Swap needs one plain statement: swap does not let you run a bigger tag. Generation touches the weights for every token it produces, so weights that live in swap are read back from disk over and over, vmstat 1 shows the si and so columns busy, and output slows to seconds per token. Keep a small swap file as insurance against the out of memory killer. Size the RAM for the tag you actually want.

Install Ollama and pin a named tag

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
systemctl status ollama

The install script sets up a systemd service, so the server comes back after a reboot. If you would rather not run it as a root managed system service, running Ollama rootless under Podman covers that path. Then pull an explicit tag.

ollama pull muse-glimmer:30b
ollama list

Read the size column in ollama list yourself and compare it against the current tag list on the model page. Published tags get added, renamed and removed, and a size in a guide is a snapshot of one day.

Never write ollama pull muse-glimmer on a server you depend on. A bare model name resolves to the latest tag, and latest is a pointer the publisher can move to a different build. A routine pull then swaps the model underneath your agent, with different memory needs and different behaviour, and nothing in your logs announces it. Write the tag in your scripts, in your unit files and in your agent config. Self-hosting an LLM with Ollama on a VPS covers the rest of the server setup.

Can you run Muse Glimmer without a GPU?

Yes, and it is worth being blunt about the ceiling. Generating one token means reading the model weights out of memory, so speed is set by memory bandwidth rather than by how many vCPUs the plan advertises. Past a handful of cores, more cores buy you very little. On a shared VPS that bandwidth is shared with every other tenant on the host, so a 30B model at 4-bit produces a small number of tokens per second.

Do not accept anyone's number for that, mine included. Measure tokens per second on your own box and decide from what you see.

The result is a real split in what the model is good for. Interactive chat is painful, because you read faster than the server writes and every reply starts with a long pause. Background agent work is fine, because a task that runs unattended for ten minutes does not care that it is slow. That second workload is exactly what Meta describes for this model.

If you need interactive speed, the two honest answers are a GPU or a hosted API. Work out the break even point between a GPU VPS and API tokens before you rent anything, and what a GPU VPS actually gives you describes what you are buying. For the wider question of what a given box can hold, start at which models you can self-host, and running a similar sized Qwen model on a VPS is the closest comparison in this size class.

Why does it forget things long before 128K tokens?

Because Ollama's default context window is 4096 tokens, whatever the model supports. That default is in Ollama's own FAQ as of August 2026. The tag advertises 128K, and the server hands the model 4096 until you say otherwise, so a long agent transcript loses its early turns and the model looks like it has amnesia.

Raise it on the server for every request:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

Inside an interactive session, /set parameter num_ctx 32768 changes it for that session only. Over the API, send num_ctx in the request options.

Every extra token of context costs memory on top of the weights. Ask for the full 128K on a box sized for the weights alone and the load will fail or fall back to something slower. Raise it in steps and run ollama ps after each step. How num_ctx and context length work in Ollama goes through the arithmetic.

Reasoning strength: low, medium, high and xhigh

Meta documents four reasoning strengths for Muse Glimmer, low through xhigh, and recommends the higher two for complex coding and agent tasks. In Ollama this rides on the think parameter. Use --think= on the command line, or send think in the API body.

ollama run muse-glimmer:30b --think=high "Summarise the changes in /tmp/patch.diff"

Inside an interactive session, /set think and /set nothink toggle it. Ollama's documentation says most models accept either a boolean or a level such as low, medium or high, and that some accept max for the highest available. Which exact strings this model accepts belongs on its model page, so read that rather than guessing, and try one by hand before you wire it into an agent.

On a CPU only box this dial has teeth. A higher strength means more thinking tokens generated before the first word of the answer appears, and a thinking token costs the same wall clock time as an answer token. Leave routine work at the low setting.

Keep the model loaded for an always on agent

Ollama unloads an idle model after five minutes by default. For an agent that fires every ten minutes, that means paying a full 18 GB load from disk on every single run, and on a VPS with network attached storage that load is not quick. Pin it in memory instead.

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

A negative value keeps the model resident until something unloads it, and keep_alive in an API request overrides the server default for that one call. The cost is honest: the RAM stays occupied while nothing is happening, so this is a setting for a box dedicated to the agent. Keeping an Ollama model loaded covers the variations.

Point a coding agent at it

Ollama serves an OpenAI compatible API at http://127.0.0.1:11434/v1, so most agent tools connect with a base URL and any non empty API key. Ollama's Muse Glimmer page also documents a launch shortcut that wires a supported agent to a local model in one command, and you should pin the tag there too.

ollama launch claude --model muse-glimmer:30b

Agents send big prompts. File contents, tool output and a growing transcript all arrive as input tokens, and on a CPU box prompt processing is the part that hurts before generation has even started. Keep the context setting as small as the task allows. Pointing a coding agent at Ollama covers the client side, running a coding agent on a VPS covers the box it lives on, and controlling agent costs on a VPS covers what happens when it runs all day.

Image input works the same way. The Ollama API takes images on the images field of a message, so a text only client will never send one, however capable the perception encoder is.

Do not open port 11434

The Ollama API has no authentication. Setting OLLAMA_HOST=0.0.0.0:11434 so you can reach it from your laptop puts an unauthenticated model runner on the public internet, where anyone who finds it can load models onto your disk and read whatever your agent sends through it. Leave it bound to localhost and tunnel instead.

ssh -N -L 11434:127.0.0.1:11434 user@your-vps

Securing the Ollama API endpoint covers the proper options, including a reverse proxy that asks for credentials.

What breaks, and what you will see

The pull stops partway. Disk. Run df -h against the model directory. A 57 GB bf16 build does not fit on a 40GB root volume, and neither do two 8-bit tags side by side.

The model loads and then the process dies. Out of memory. dmesg -T records the kernel out of memory killer choosing a process, and journalctl -u ollama -n 100 shows the service side of the same event. The fix is a smaller tag or a smaller num_ctx. It is not more swap.

It runs at seconds per token. Run vmstat 1 and watch the si and so columns. Steady swap activity means the weights do not fit in RAM and the box is reading them back from disk while it works.

A tag that worked last week is gone. Tag lists change. Re-read the model page, pin whatever is current, and record the tag name somewhere you will look again.

ollama pull muse-glimmer:30b
ollama list
sudo du -sh /usr/share/ollama/.ollama/models

FAQ

How much RAM does Muse Glimmer need on a VPS?

Start from the tag size and add the context window. The default tag is listed at about 18 GB on 16 August 2026, so a 16GB box cannot hold it at all and a 24GB box holds it with little room left for context. Treat that as a starting point, not an answer. Pull the tag, load it once, then run ollama ps and free -h on your own box and read your own numbers. Longer context and parallel requests both add memory on top of the weights.

Can I run Muse Glimmer without a GPU?

Yes. It loads and answers on a CPU only VPS. Generation speed is limited by memory bandwidth rather than by core count, and on a shared host that bandwidth is shared, so expect a small number of tokens per second at 4-bit. That is usable for background agent work that runs unattended, and painful for interactive chat. Run ollama ps during a request and read the processor column to confirm where the work is running.

Are the MLX tags any use on a Linux VPS?

No. Every tag with mlx in the name is built for Ollama's MLX engine, which is its Apple Silicon backend. On an x86 Linux server those tags are a large download you cannot run. Use the plain 30b tag, or one of the other non MLX tags, and ignore the Apple hardware benchmarks that go with the MLX builds.

Why does the model forget things long before 128K tokens?

Because Ollama's default context window is 4096 tokens no matter what the model supports, so the server truncates long conversations before the model ever sees them. Set OLLAMA_CONTEXT_LENGTH on the server, or /set parameter num_ctx for one session, or send num_ctx in the API request options. Memory use rises with it, so raise it in steps and check ollama ps each time.

Should I pin the tag or just use latest?

Pin it. muse-glimmer with no tag resolves to latest, which is a pointer the publisher can move to a different build at any time, so a routine pull can change the model your agent runs on. Write muse-glimmer:30b in scripts, unit files and agent config. Check the tag list on the model page before you pin, because published tags change.