How to Run Qwen3-Coder in Ollama & When to Use the API

Qwen3-Coder ships in the official Ollama library in two very different sizes: a 30B model that runs on a good workstation, and a 480B model that needs a small server rack. This guide shows the exact ollama pull / ollama run commands, every published size and quantization tag with its on-disk footprint, the memory you actually need for each, and — honestly — the point at which a hosted, OpenAI-compatible API is simply cheaper and faster than keeping GPUs warm. If you only ever wanted the default, it is one command: ollama run qwen3-coder.

Run Qwen3-Coder in Ollama in one command

Install Ollama, then run ollama run qwen3-coder — that single command pulls and starts the default model. Qwen3-Coder is published in the official Ollama library at ollama.com/library/qwen3-coder, described by Alibaba as performant long-context models for agentic and coding tasks. The default tag is the 30B variant, about 19GB on disk:

# pull + start an interactive session (default = 30B)
ollama run qwen3-coder

# or just download the weights without chatting
ollama pull qwen3-coder

# pick a specific size explicitly
ollama run qwen3-coder:30b
ollama run qwen3-coder:480b

The default qwen3-coder (equivalently qwen3-coder:latest and qwen3-coder:30b) resolves to the 30B model at roughly 19GB using the Q4_K_M quantization. That is the one almost everyone wants; the 480B tag is a different class of machine entirely, covered below. If this is your first local model, our guide to running LLMs locally in 2026 walks through the whole setup.

The two Qwen3-Coder sizes and their tags

There are two model sizes — a 30B you can run on a workstation and a 480B that needs a server — plus a cloud tag for the big one. Both are mixture-of-experts (MoE) models, so only a fraction of the parameters activate per token, but the full weights still have to fit in memory. The specifics come straight from the Ollama library and the matching Hugging Face model cards:

The 30B card (Qwen3-Coder-30B-A3B-Instruct) reports 30.5B total and 3.3B activated parameters across 128 experts with 8 activated per token, 48 layers, and GQA with 32 query and 4 KV heads. The 480B card (Qwen3-Coder-480B-A35B-Instruct) reports 480B total and 35B active across 160 experts, 62 layers, 96 query and 8 KV heads, released in BF16. The qwen3-coder:480b-cloud tag runs that 480B model on Ollama's cloud rather than on your machine — useful, but at that point you are no longer fully self-hosting.

Quantization tags and what each costs on disk

Each size ships in three quantizations — Q4_K_M, Q8_0, and fp16 — and the tag name encodes both the size and the quant. Lower quantization means smaller files and less memory at some quality cost; the default everyone gets is Q4_K_M. The quantization-suffixed tags below come from the Ollama tags page (re-verify the exact strings before scripting against them, as tag naming can shift):

The plain qwen3-coder:30b tag is the same 19GB Q4_K_M build; the -a3b- and -a35b- fragments simply spell out the active-parameter count (3B and 35B). Unless you have a specific quality or memory reason, start with the Q4_K_M default and only move up to Q8_0 or fp16 if you have the memory to spare and measure a difference on your own tasks.

The hardware you actually need

The 30B fits comfortably on a single 24GB GPU; the 480B needs roughly 250GB of memory, which is a server, not a desktop. On-disk size is a floor — you also need headroom for the KV cache, which grows with context length. A realistic reading of the numbers:

• 30B, Q4_K_M (~19GB): fits a single 24GB card (e.g. a 4090-class GPU) with room for a modest context. This is the sweet spot for local Qwen3-Coder.
• 30B, Q8_0 (~32GB) / fp16 (~61GB): needs a larger card, two GPUs, or generous system RAM with CPU offload (slower). Diminishing returns for most coding work.
• 480B, Q4_K_M (~290GB): Ollama's own guidance is roughly 250GB+ of memory to run locally. That is a multi-GPU server or a very large unified-memory machine — not a workstation.
• 480B, Q8_0 (~510GB) / fp16 (~960GB): multi-node, data-center territory.

If you are budgeting a machine for large open-weights models generally, our GPT-OSS 120B hardware requirements breakdown covers the VRAM-vs-RAM-vs-offload tradeoffs in more detail — the same physics applies here.

Context length, KV cache, and the 256K catch

Both sizes have a native 262,144-token (256K) context extendable to ~1M via Yarn — but long context eats memory fast, and Ollama defaults to a much smaller window. The 256K figure is the model's capability, not what you get out of the box. Two practical caveats:

• Ollama's default context is small. Unless you raise the context window (in the model parameters / your request options), you are running far below 256K regardless of the model's ceiling. Ollama option names have changed over releases, so check the current docs — as of mid-2026 this is the num_ctx parameter.
• KV cache scales with context. Every extra token of context adds to the KV cache, which sits on top of the weight size. A large context on the 30B can add many gigabytes; the full 256K (let alone the ~1M Yarn extension) is only realistic with substantial memory. Budget for it or you will hit out-of-memory errors that the weight-size table alone does not predict.

When the hosted API is cheaper and faster (honestly)

Self-hosting wins on privacy and at full-time saturation; a per-token API wins on almost everything else — and it is the only sane way to touch the 480B. This is the trade-off the size tables hide. Here is the honest decision:

Self-host vs API, in one line: if you can keep a 24GB GPU busy nearly all the time and need data to stay on-prem, local 30B Qwen3-Coder is a genuine win. For anything bursty, any need to scale quickly, and any use of the 480B, the per-token economics of a hosted, OpenAI-compatible API almost always come out cheaper and always start faster — you never pay for idle silicon, and there is no 290GB download. The general math is in our cheapest LLM API guide, and if your driver is coding-agent spend specifically, cutting token costs for coding agents has the levers. It is also worth checking whether a different model wins per-task: sticker price and parameter count do not predict correctness or per-task cost — see how we rank coding LLMs in 2026.

Note on benchmarks: any "beats model X" claim you see for Qwen3-Coder should be read as vendor-reported unless it comes from an independent, reproducible harness. Sizes and parameter counts above are from official Ollama and Hugging Face sources; performance is task-dependent — test on your own workload.

One key across local Qwen3-Coder and a hosted fallback

Ollama and any OpenAI-compatible gateway speak the same API shape, so you can develop against local Qwen3-Coder and swap to a hosted endpoint by changing only the base URL and key. Ollama exposes an OpenAI-compatible endpoint locally; a gateway like DataLLM Lab exposes the same interface for hundreds of hosted models. Because the request format matches, the same client points at either — this is standard OpenAI-compatible configuration, not a special integration:

from openai import OpenAI

# local Qwen3-Coder via Ollama
local = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

# hosted fallback via an OpenAI-compatible gateway — same code shape
hosted = OpenAI(
    base_url="https://www.datallmlab.com/v1",
    api_key="YOUR_KEY",
)

resp = local.chat.completions.create(
    model="qwen3-coder",
    messages=[{"role": "user", "content": "Refactor this function..."}],
)

That symmetry is the point: prototype offline on the 30B, and when you need the 480B, more throughput, or elastic scale, repoint base_url at a hosted endpoint instead of buying a 250GB server. Any tool that accepts a custom base URL and API key works the same way — see what OpenAI-compatible means and, if you route across providers, routing and failover.

FAQ