What a node costs

Four notes, and then the tables below are just these numbers with their working shown. A relay costs more than an exit because it handles every byte twice, once arriving and once leaving. Small files, not bytes, size a storage node — the same gigabyte costs six times more CPU as 25 000 small files than as one large one. RAM does not grow with the size of the vault: one file and twenty-five thousand both land in the same band. And the RAM column is two numbers because there are two questions. The floor is what the node needs to not die — it clears the ~250 MB the daemon briefly wants while starting, which is why a relay says 256 MB and not the 70 MB it settles at. The second is what to buy: the sustained figure with 1.5× headroom, rounded to a size somebody sells. The calculator answers the second one, and will say the first if you set headroom to 1.2×.

Two warnings about that conversion, and they point opposite ways. Clock is not performance across architectures: these numbers came off a Skylake-generation core, and a current AMD Genoa core does appreciably more per cycle at the same clock while an Ampere core does somewhat less, so the same 2 GHz can be worth ±30 %. And a shared vCPU is not a core — it is a slice of one, so on a burstable plan the sustained figure is lower than any clock suggests. Size for the class of machine, not the decimal. Separately: a processor without SHA extensions (most Raspberry Pi class hardware) hashes far slower than clock predicts, and hashing is what caps a storage node there.

The window we set is not the window the weights allow, and the difference is deliberate: the cache is allocated for the whole window at load, so asking for everything a model can address turns the card it was bought for into the next one up. Qwen3.8 27B addresses 262 144 tokens and we ask for 65 536. Each cell is the largest context that model holds entirely on that card, leaving 1 GB for the desktop and the compute buffers; a dash means the weights alone do not fit, and llama.cpp would spill to system memory, which works and is slow.

The table is drawn from the same constants the calculator below uses, so the two cannot drift apart: 2 × layers × kv_heads × head_dim of cache per token from each model's config.json, quantised, plus the weights. Pick a card and a model down there for the memory figure that goes with a window.

* Qwen3 8B is measured on an RTX 2080 Ti, not computed: 7 932 MiB at its full 40 960 window. The other rows are arithmetic from each model's published architecture, and the same arithmetic came within one per cent of that card, so they can be trusted. The quantised cache is what makes a full window fit at all — the same model with a plain f16 cache wanted 2.3 GiB more.

No card at all is also an answer. Every model here runs on a CPU given enough RAM — the same weights and the same cache, in system memory instead: about 9 GB for the 8B, about 26 GB for the 32B, at single-digit tokens per second. Unusable for chat, and perfectly fine for an overnight batch job.

Three things worth reading off that table. Open weights and runnable are different words: the highest-scoring open models — Kimi, GLM, DeepSeek — are hundreds of billions of parameters and want a rack, so they are competitors to the hosted APIs rather than to your machine. One consumer card gets within about ten points of the frontier, which it did not a year ago. And which model you run matters far more than how much card you buy: the gap between Qwen3.8 27B and the 2025-vintage Qwen3 32B is larger than the gap between that 27B and Claude, on cards of the same size.

The catalog is what a node can download and run without you finding weights yourself, so it holds the single-card, permissively-licensed, GGUF-published end of that list. Gemma 4 is Apache-2.0 and Google publishes its own quantization-aware GGUFs — trained knowing they would end up at 4 bits — which is why those two are here rather than a third-party conversion. Anything else with a GGUF still runs; point llama.cpp at it yourself.