On a 32 GB GPU, 2 catalog models run fully on the GPU at an 8,192-token context. The most capable is Qwen3-Coder-30B-A3B-Instruct at Q4_K_M (needs ~20.3 GiB). Pick a smaller model or a lower quant for more headroom.
Figures assume a 32 GB GPU paired with 32 GB of system RAM (a typical desktop), judged at an 8,192-token context. Speed depends on the specific card — this page ranks by fit, not speed.
TL;DR
32 GB runs the catalog's code specialists with the thing coding actually consumes: headroom. The specialist class fits here with real slack — near-lossless quants become realistic, and there's room for the long contexts that repository work demands. It's a short, focused list by design; the full 32 GB list shows everything the card runs, code-tagged or not.
The specialist class doesn't grow much between 24 and 32 GB — what grows is your slack, and there are two good ways to spend it. Step the quant up: near-lossless quants track the original model's behavior more closely, which is worth having in code, where small mistakes compound. Or keep the sweet-spot quant and pour everything into context, which is what agent sessions over real repositories actually burn. The calculator will show the trade for your exact window.
Qwen3-Coder-30B-A3B-Instruct at Q4_K_M · 30.5B params · needs ~20.3 GiB
One command to run it (llama.cpp):
llama-server -m Qwen3-Coder-30B-A3B-Instruct-Q4_K_M.gguf -c 8192 -ngl 999| Model | Sweet-spot quant | Fits in |
|---|---|---|
| Qwen3-Coder-30B-A3B-Instruct Qwen | Q4_K_M Runs fully on GPU | ~20.3 GiB |
| Devstral-Small-2-24B-Instruct-2512 mistralai | Q8_0 Runs fully on GPU | ~27.5 GiB |
Derived live from the fit engine + catalog at an 8,192-token context. "Fits in" is the modelled VRAM the sweet-spot quant needs (weights + KV cache + overhead). Speed depends on your specific card — check a GPU page or the calculator.
Because it only lists models the catalog tags as code specialists that also run fully on a 32 GB GPU. Plenty of general instruct models are competent at code — the general 32 GB page shows the full menu, and it's worth testing a strong general model against a specialist on your own tasks.
Mostly slack on the same class of specialists: room to step up to near-lossless quants, and much more space for context — which is where coding workloads actually spend memory. If your sessions involve big files, long agent transcripts, or both, the extra headroom shows up as fewer compromises, not new model names.
If it fits with your target context, yes — near-lossless quants stay closer to the original model's output, and code is less forgiving of small degradations than prose. If you need maximum context instead, the standard 4-bit sweet spot with a longer window is the other good answer. At 32 GB you can genuinely pick either.
Mixture-of-experts code models generate faster per token, which matters in interactive editing and agent loops that make many calls; dense specialists can be stronger per gigabyte on hard problems, and at this tier they fit at high quants. If your workflow is interactive, speed usually wins — test both on your own codebase.
Yes. Run the model with llama.cpp's server (the command on this page) or a desktop runtime like LM Studio or Ollama, and point any editor plugin or coding agent that accepts a custom OpenAI-compatible endpoint at it. At this tier you can also afford the context those tools like to use.
selected to compare · pick at least 2