Muse Glimmer 30B for VPS: RAM, Disk and CPU Cost

Muse Glimmer dey need wetin for VPS

Muse Glimmer dey run for ordinary Linux VPS wey no get GPU, and the tag wey you pull go decide whether e fit inside memory. Meta Superintelligence Labs publish the model on 10 August 2026 under Apache 2.0: e get 30 billion parameters, 128K context window, and dedicated 1.8B parameter perception encoder wey make am fit read images together with text. Meta design am mainly for always-on local agents, no be ordinary chat, and you fit set the reasoning strength for each request.

The Ollama tags wey dem publish, as dem read am on 16 August 2026, dey range from 17 GB reach 59 GB. Na this range dey determine the whole sizing problem. Dem list the default tag as about 18 GB, so the smallest sensible box clearly need more than 18 GB free RAM. The download disk space and memory for the context window go still add on top.

Which muse-glimmer tag you suppose 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 list 11 tags for this model wey no be Apple builds. Dem get the same 30 billion weights, but dem store am with different numeric precision. The size wey you see na wetin you go download, and e still roughly be the memory wey you need hold before you add any context.

The two 4-bit builds na the small ones: 30b-nvfp4 at 17 GB and 30b-q4_K_M at 18 GB. The default 30b tag dey listed with the same size as the q4_K_M build. The 8-bit builds, 30b-q8_0 and 30b-mxfp8, dey near 31 GB. 30b-bf16 na the unquantised 16-bit release at 57 GB. This one need more RAM than most rented servers fit offer at a price wey person go pay for side project.

The -dflash tags na the same builds with DFlash support, and each one dey listed bigger than the plain twin. Ollama describe DFlash as speed feature and show how e work on Apple Silicon and desktop GPUs. For CPU-only VPS, you go use that extra size for real memory to run feature wey dem measure on different hardware. So start with the plain tag and change one thing at a time.

Start with 4-bit unless you get specific reason not to. When you move from 4-bit to 8-bit, the CPU go roughly read double the bytes for every token e generate. Throughput go drop while memory use go rise. That trade-off na the subject of wetin q4, q8 and fp16 quantisation really cost you. For CPU box, the short answer be say the 4-bit build na the only one wey make sense to start with.

Why MLX tags no dey do anything for Linux server

MLX na Apple array framework, and Ollama MLX engine na the backend for Apple Silicon. Any tag wey get mlx for the name, na that engine and hardware dem build am for. For x86 Linux VPS, na tens of gigabytes of download wey you no fit run, and e go just dey occupy disk space without doing anything. The speed figures for the announcement come from tests wey dem run on Mac, so dem no describe your server too. When you read tag list for the model page, first remove every mlx name, then choose size from wetin remain.

E get how much RAM and disk?

Two things dey use memory, and na only one of dem be tag size. The weights dey fixed by the tag wey you pull. KV cache, wey be the state per token wey model dey keep for the conversation, dey grow as the context length wey you configure dey increase. Ollama documentation talk say serving parallel requests dey multiply the context by the number of requests wey dey in flight, so one box wey dey answer two agents at once need more memory than the same box wey dey answer one.

No use RAM figure from any guide, including this one. Pull the tag, send am one prompt, and while model still dey resident run these two commands.

ollama ps
free -h

ollama ps dey show wetin load right now and how the work split between CPU and GPU. free -h dey show wetin remain. Those two outputs for your own box better pass any published table, because dem don already include your context setting, your quantisation, and everything else wey server dey run.

Disk na the easier part. Ollama dey store models under /usr/share/ollama/.ollama/models for Linux, and for most VPS images e dey inside root filesystem. 40GB root volume no go hold the bf16 build wey be 57 GB, and e no go hold two 8-bit tags side by side either. Move the store go 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

ollama user must own that directory, because service dey run as ollama and e dey write the blobs there as that user. If pull fail because of permissions, journalctl -u ollama -n 50 na where the reason go appear.

Swap need one plain statement: swap no let you run bigger tag. Generation dey touch the weights for every token wey e produce, so weights wey dey inside swap dey read back from disk again and again, vmstat 1 dey show the si and so columns busy, and output dey slow down to seconds per token. Keep small swap file as insurance against the out of memory killer. Size the RAM for the tag wey you really want.

Install Ollama and pin a named tag

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

The install script go set up a systemd service, so the server go come back after reboot. If you no want run am as root-managed system service, run Ollama rootless under Podman explain that approach. Then pull one explicit tag.

ollama pull muse-glimmer:30b
ollama list

Read the size column for ollama list by yourself and compare am with the current tag list for the model page. Dem dey add, rename, and remove published tags, and size wey guide show na snapshot from one particular day.

Never write ollama pull muse-glimmer for server wey you depend on. Bare model name dey resolve to latest tag, and latest na pointer wey publisher fit move to another build. Normal pull fit then replace the model under your agent, with different memory needs and different behaviour, and nothing for your logs go announce am. Write the tag for your scripts, unit files, and agent config. Self-host LLM with Ollama on a VPS cover the remaining server setup.

You fit run Muse Glimmer without GPU?

Yes, but make we talk plainly about the limit. To generate one token, system must read model weights from memory. So speed depend more on memory bandwidth than on how many vCPUs the plan advertise. After a few cores, extra cores no dey add much. For shared VPS, every other tenant for the host dey share that bandwidth. So 30B model for 4-bit fit produce only small number of tokens per second.

No accept anybody number for this matter, including my own. Measure tokens per second for your own box and decide based on wetin you see.

The result na clear difference for wetin the model good for. Interactive chat dey painful, because you dey read faster than the server dey write, and every reply start with long pause. Background agent work dey okay, because task wey run unattended for ten minutes no care say e slow. That second workload na exactly wetin Meta describe for this model.

If you need interactive speed, the two honest answers na GPU or hosted API. Calculate the break-even point between GPU VPS and API tokens before you rent anything, and wetin GPU VPS actually give you explain wetin you dey buy. For the wider question of wetin one box fit hold, start with which models you fit self-host, and running similar-sized Qwen model for VPS na the closest comparison for this size class.

Why e dey forget things long before 128K tokens?

Because Ollama default context window na 4096 tokens, no matter wetin the model support. Ollama own FAQ still list this default as of August 2026. The tag dey advertise 128K, but server dey give the model 4096 until you tell am otherwise. So, long agent transcript go lose the early turns, and the model go look like say e get amnesia.

Raise am for the server for every request:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

Inside interactive session, /set parameter num_ctx 32768 go change am for that session only. For API, send num_ctx inside the request options.

Every extra context token dey use memory on top of the weights. If you request the full 128K for a box wey get memory only for the weights, loading go fail or e go fall back to something slower. Raise am step by step, then run ollama ps after each step. How num_ctx and context length work inside Ollama explain the arithmetic.

Reasoning strength: low, medium, high and xhigh

Meta document four reasoning strength for Muse Glimmer, from low reach xhigh, and e recommend the higher two for complex coding and agent tasks. For Ollama, na the think parameter dey control am. Use --think= for command line, or send think inside the API body.

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

Inside interactive session, /set think and /set nothink dey toggle am. Ollama documentation talk say most models accept either boolean or level like low, medium or high, and some accept max for the highest level wey dey available. The exact strings wey this model accept dey for the model page, so read am instead of guessing, and test one manually before you connect am to agent.

For CPU-only box, this setting dey matter well. Higher strength mean say e go generate more thinking tokens before the first word of the answer show, and one thinking token dey use the same wall-clock time as one answer token. Leave routine work for low setting.

Keep the model dey loaded for agent wey always dey on

Ollama dey unload model wey idle after five minutes by default. For agent wey dey run every ten minutes, this mean say e go load full 18 GB from disk again for every run, and if na VPS with network attached storage, this loading no dey quick. Keep am for memory instead.

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

Negative value go keep the model resident until something unload am, while keep_alive for API request go override server default for that one call. The cost dey clear: RAM go remain occupied even when nothing dey happen, so use this setting only for box wey na the agent dey use. How to keep Ollama model loaded explain the different options.

Point coding agent go am

Ollama dey serve OpenAI compatible API for http://127.0.0.1:11434/v1, so most agent tools fit connect with base URL and any API key wey no empty. Ollama Muse Glimmer page still document launch shortcut wey connect supported agent to local model with one command, and you suppose pin the tag there too.

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

Agents dey send big prompts. File contents, tool output, and transcript wey dey grow all dey enter as input tokens. For CPU box, prompt processing na the part wey dey slow everything before generation even start. Keep context setting as small as the task allow. Pointing coding agent go Ollama cover the client side, running coding agent for VPS cover the box wey e dey run on, and controlling agent costs for VPS cover wetin happen when e dey run all day.

Image input dey work the same way. Ollama API dey take images for images field of a message, so client wey only support text no go ever send image, no matter how capable the perception encoder be.

No open port 11434

Ollama API no get authentication. If you set OLLAMA_HOST=0.0.0.0:11434 so you fit reach am from your laptop, you go put model runner wey no get authentication for public internet. Anybody wey discover am fit load models enter your disk and read anything wey your agent send through am. Leave am bound to localhost, then use tunnel instead.

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

How to secure Ollama API endpoint cover the correct options, including reverse proxy wey dey ask for credentials.

Wetin fit break, and wetin you go see

The pull stop halfway. Disk space. Run df -h against the model directory. A 57 GB bf16 build no fit for 40GB root volume, and two 8-bit tags side by side no fit too.

The model load, then the process die. Memory don finish. dmesg -T record the kernel out of memory killer as e choose one process, and journalctl -u ollama -n 100 show the service side of the same event. The fix na smaller tag or smaller num_ctx. More swap no be the fix.

E run at seconds per token. Run vmstat 1 and monitor the si and so columns. If swap activity dey continue, e mean say the weights no fit for RAM and the machine dey read dem back from disk while e dey work.

A tag wey work last week don disappear. Tag lists dey change. Read the model page again, pin the current one, and write the tag name for place wey you go check again.

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

FAQ

How much RAM Muse Glimmer need for VPS?

Start with the tag size, then add the context window. The default tag dey listed as about 18 GB for 16 August 2026, so 16GB box no fit hold am at all, while 24GB box go hold am with small space remain for context. Take this as starting point, no be final answer. Pull the tag, load am one time, then run ollama ps and free -h for your own box and read your own numbers. Longer context and parallel requests go add more memory on top of the weights.

I fit run Muse Glimmer without GPU?

Yes. E fit load and answer for CPU-only VPS. Generation speed depend more on memory bandwidth than core count. For shared host, other users dey share that bandwidth too, so expect small number of tokens per second for 4-bit. E dey okay for background agent work wey run unattended, but e go slow and frustrating for interactive chat. Run ollama ps during request and read the processor column to confirm where the work dey run.

MLX tags get any use for Linux VPS?

No. Every tag wey get mlx for the name na for Ollama's MLX engine, wey be the Apple Silicon backend. For x86 Linux server, those tags na large download wey you no fit run. Use the plain 30b tag, or another non-MLX tag, and ignore the Apple hardware benchmarks wey come with the MLX builds.

Why model dey forget things long before 128K tokens?

Ollama's default context window na 4096 tokens, no matter wetin the model support, so server go truncate long conversations before model ever see dem. Set OLLAMA_CONTEXT_LENGTH for the server, or /set parameter num_ctx for one session, or send num_ctx inside the API request options. Memory use go increase with am, so raise am step by step and check ollama ps every time.

I suppose pin the tag, or make I just use latest?

Pin am. muse-glimmer without tag dey resolve to latest. Na pointer wey publisher fit move to another build anytime, so ordinary pull fit change the model wey your agent dey run. Write muse-glimmer:30b inside scripts, unit files, and agent config. Check the tag list for the model page before you pin am, because published tags dey change.