YOUR MODELS. YOUR MACHINE.
Big models.
Right-sized hardware.
Find out what runs, what fits, and what it costs.
Make room for local AI, without the guesswork.
01 / THE CALCULATOR
Build your local setup
Hardware shortlist
* Bandwidth ceiling, not expected speed. Fits in memory ≠ fast in practice. Prices marked as planning budgets are editable examples. Open any result for its assumptions, sources, and software.
02 / SIDE BY SIDE
A clearer comparison
A little perspective helps.
Use the + buttons in your results to compare machines
with the same model and settings.
03 / NO BLACK BOX
Know what’s
behind the numbers.
Transparent assumptions. Traceable sources.
A useful starting point for your own testing.
How do you calculate memory fit?
Required memory = weights + FP16 key/value cache + runtime workspace. The cache uses each model’s layers, KV heads, and head dimension: 2 × layers × KV heads × head dimension × context × 2 bytes. Workspace is the larger of 1 GiB or 5% of weights.
CPU and unified-memory systems reserve the larger of 4 GiB or 15% of RAM for the OS. Dedicated GPUs reserve the larger of 1 GiB or 5% of VRAM. A comfortable fit leaves at least 10% of usable execution memory free. Shared memory is counted once. The Ryzen preset also respects its documented graphics allocation cap.
Artifact sizes are published, rounded decimal GB values, converted to GiB. If exact sizes are unavailable, the fallback uses parameters × bits ÷ 8 plus 10% quantization overhead. Near a boundary, verify with the actual artifact and runtime.
What does the speed figure mean?
No matching measured benchmarks are bundled in this first catalogue. Every result is explicitly unbenchmarked. For a dense model fully resident in memory, the optional bandwidth ceiling divides documented memory bandwidth by weight size. It is a theoretical bound, not expected tokens/second. Context/cache traffic and compute make actual decoding slower.
MoE and offloaded configurations get no bandwidth ceiling. Prompt processing and time to first token differ from generation speed. Runtime, quantization, context depth, thermals, and concurrent users all matter.
How to measure your own setup ↗Where do the prices and models come from?
Hardware specifications come from manufacturers; model architecture and rounded GGUF sizes come from Qwen’s model repositories. The initial eight models are representative Qwen configurations, not a ranking of today’s best models. Every result links its sources and license.
Prices distinguish historical MSRP, announced MSRP, and illustrative system budgets. Used systems are examples, not listings. Reference configurations may no longer be orderable. USD reference prices are never automatically converted; other currencies need your quotes. No taxes, shipping, electricity, training, or recurring costs are included.
Which software should I use?
LM Studio offers a graphical interface. Ollama manages models and a local API. llama.cpp gives direct control over GGUF models and CPU/GPU offloading. Use platform-specific builds and match the exact quantization/context to the estimate.
Intel MacBook Pro presets use llama.cpp on CPU; integrated graphics and separate Radeon VRAM are excluded until GPU support is verified. Fanless MacBook Air models may throttle during sustained use.
On Apple silicon, MLX-LM is another option; MLX checkpoint sizes differ from GGUF, so these weight estimates do not transfer exactly. DGX Spark needs an ARM64 / Blackwell-compatible stack: follow NVIDIA’s specific recipes.