Mellum2.1's Q4 Build Is 8.07 GB. I Checked the Numbers Before Downloading.

A reality check on the 12B coding model everyone is posting about: real GGUF file sizes, JetBrains' own benchmark table, and the hardware most of us actually have.

Every post about JetBrains Mellum2.1 says a version of the same sentence: a 12B model that runs like a 2.5B one. That is a real property of mixture-of-experts — 12B total weights, about 2.5B active per token — and it is why the model fits on cards that a dense 12B would not.

What none of those posts give you is the download size. So before pulling anything, I asked Hugging Face directly for the file list of JetBrains/Mellum2.1-12B-A2.5B-Thinking-GGUF instead of trusting a summary. This is what came back (API read on October 13, 2026):

File sizes from the Hugging Face API file list, read 2026-10-13.

The repository was created on 2026-10-07 and, as of that read, showed 27,140 downloads and 78 likes. Apache 2.0, so commercial use is fine.

The 16 GB floor is real, and the context window is the trap

The Q4_K_M file is 8.07 GB. Adding KV cache and runtime overhead, a 16 GB machine is the practical floor for the recommended build at short-to-moderate context. The GGUF card's own example command sets --ctx-size 131072, the model's full 131,072-token window — if you copy that line on a 16 GB laptop, you will hit memory pressure long before you hit a token limit. Start at 8k–16k and raise it only if you need it.

This is the part the "runs on a laptop" framing hides: the model fits, the context may not.

Two things that will trip you up

1. There is no official Ollama library tag. ollama.com/library/mellum2.1 and ollama.com/library/mellum2 both return 404 (checked today). The ollama run hf.co/JetBrains/... lines you see in posts work by pulling the GGUF straight from Hugging Face — not by resolving a local library name. If you expect ollama run mellum2.1 to work, it does not.
2. MXFP4_MOE is not in older llama.cpp builds. The smallest quantization (7.03 GB) needs a recent build; if your toolchain is months old, plan on Q4_K_M or an upgrade.

What JetBrains' own numbers actually say

These are JetBrains' self-reported evaluations, not independent reproductions. They compare Mellum2.1 Thinking against a dense 9B model from a different lab:

Read that table twice, because it does not say what the launch posts say. The 12B MoE wins on single-shot code generation (LiveCodeBench, HumanEval+). It loses on the multi-step agentic benchmarks (SWE-bench Pro, Terminal-Bench) to a 9B dense model that a fraction of the RAM can hold. JetBrains also reports 7,969 tokens/s versus 4,347 tokens/s for Qwen3.5-9B on a single H200 — again, their test.

If you buy this model for throughput — high-volume generation, lint-level edits, a fast worker behind a slower planner — the numbers back you up. If you buy it expecting it to close hard repository-level issues on its own, a smaller dense model is scoring higher in the vendor's own table.

Why there are no throughput numbers from me

My test box is 2 vCPU with 7 GB of RAM (about 4 GB available) and no GPU. The smallest published build is 7.03 GB. The model does not fit on the machine I have, so I did not run it, and I am not going to quote a tokens-per-second figure I never measured. What I did measure is above: file sizes, repository dates, and the two 404s.

Before you download

• Check RAM against 8.07 GB plus KV cache, not against "12B params".
• Use Q4_K_M unless you are on 24 GB or more.
• Cut context on first run; the card's example is the maximum, not the default.
• Test it on a bug you have already fixed before pointing it at a repo you care about.
• Treat every speed and score comparison as vendor-reported until someone publishes an independent run.

The interesting question for the next month is not whether a 12B MoE can code. It is whether the open model that ships fastest ends up being the one your agent actually uses, when the slower one solves more of the tasks.

Sources: GGUF repository, model card, Hugging Face API metadata.