The cluster of tier pages that drives most of this site’s traffic is organised by VRAM. That is the right axis for picking a model when the question is “what fits my GPU” - but the second question readers ask is “what fits my task”, and for long documents, large code bases, multi-turn agent loops, and PDF RAG, the binding constraint is context window, not VRAM. Two models with the same file size can sit at opposite ends of the context axis, and the 256K-tier one is the only one that will hold the 200-page deposition.
This page is a tier list of self-hostable open-weight models organised by the maximum context window they actually ship with. Every figure is read from the Hugging Face config.json or the model card on the day of publication, and every Ollama tag size from the library page. No benchmarks, no first-person claims about what runs on what hardware; the methodology is the same as the rest of the cluster - read the primary, quote the primary, link the primary.
How context windows are reported
Three numbers get conflated in model marketing copy, and they are not the same number:
- Native context. The
max_position_embeddingsfield inconfig.jsonis what the model was trained to handle without any RoPE extension. Training-time attention quality is what is best at this length. - Extended context via RoPE scaling. Most models can run past their native length with a rope-scaling method such as YaRN, NTK-aware scaling, or self-extend. The HF model card usually quotes the headline number, which can be 4x to 10x the native figure, but recall quality drops as you push past native.
- Ollama tag context window. Ollama sets a default context length per tag in the Modelfile. Some tags ship at native, others at the extended headline figure, and the q4/q8/fp16 variants of the same model can ship at different defaults. Always check the tag page, not just the upstream card.
The numbers in the table below are the Ollama tag context window because that is what readers will see in their Ollama show output and what ollama run will actually allocate. Where the upstream native and extended figures diverge from that, both are noted.
The tier table
| Context tier | Model (Ollama tag) | Ollama size | Native / extended (HF) | Params | Licence | Notes |
|---|---|---|---|---|---|---|
| 32K | qwen3:4b (q4_K_M) | 2.6 GB | 32,768 native / 131,072 YaRN | 4.0B | Apache-2.0 | Smallest tier, fits 8 GB VRAM |
| 32K | mistral-small:24b | 14 GB | 131,072 native | 24B | Apache-2.0 | Ollama default ships at 32K, upstream at 131K |
| 32K | qwen3:32b | 20 GB | 32,768 native / 131,072 YaRN | 32.8B | Apache-2.0 | Ollama default ships at 40K |
| 128K | gpt-oss:20b | 14 GB | 131,072 native | 21B / 3.6B active | Apache-2.0 | Reasoning toggled, MoE |
| 128K | gpt-oss:120b | 65 GB | 131,072 native | 117B / 5.1B active | Apache-2.0 | Same context,fits 80 GB H100 (MXFP4) |
| 128K | mistral-small:22b | 13 GB | 131,072 native | 22B | Apache-2.0 | Older Mistral-small; same context as 24B upstream |
| 128K | llama3.3:70b-instruct-q4_K_M | ~43 GB | 128K native | 70B | llama3.3 (community) | Default ships at 128K |
| 256K | qwen3:4b (default) | 2.5 GB | 32,768 native / 131,072 YaRN | 4.0B | Apache-2.0 | Ollama default is 256K, not 40K - silent override |
| 256K | qwen3:30b-a3b | 19 GB | 262,144 native / 1,010,000 YaRN | 30B / 3B active | Apache-2.0 | 256K is also the default for the instruct/thinking 2507 tags |
| 256K | qwen3:30b-a3b-instruct-2507-q8_0 | 32 GB | 262,144 native | 30B / 3B active | Apache-2.0 | Same context in higher quant |
| 256K | qwen3.5:4b | 3.3 GB | 262,144 native / 1,010,000 YaRN | 4B | Apache-2.0 | Multimodal |
| 256K | qwen3.5:9b | 6.6 GB | 262,144 native / 1,010,000 YaRN | 9B | Apache-2.0 | Multimodal |
| 256K | qwen3.5:35b | 22 GB | 262,144 native / 1,010,000 YaRN | 35B / 3B active | Apache-2.0 | MoE |
| 256K | qwen3.5:122b | 81 GB | 262,144 native / 1,010,000 YaRN | 122B / 10B active | Apache-2.0 | Largest 256K-tier model that still fits one node |
| 256K | qwen3-coder-next (q4_K_M) | 52 GB | 262,144 native | 80B / 3B active | Apache-2.0 | Coding-specific, 256K context built-in |
| 256K | gemma-4-12b-it | (q4_K_M 8.0 GB on Ollama) | 256K native | 11.95B | Apache-2.0 | Native 256K with no YaRN config |
| 1M | llama4:128x17b | 245 GB | 1M native | 402B / 17B active | 4-community | Maverick-class; needs ~256 GB unified or multi-GPU |
| 10M | llama4:latest (Scout) | 67 GB | 10M native | 109B / 17B active | llama4 (community) | Industry outlier; recall quality degrades past the 1M-2M range |
Two facts from this table are the ones readers tend to get wrong. First, qwen3:4b ships at 256K by default in Ollama even though the model card says 32K native / 131K YaRN - the Ollama tag page lists the Modelfile default as 256K. The q4_K_M and q8_0 tags of the same model ship at 40K. The default wins unless you override --ctx-size. Second, the 256K tier is dominated by Qwen models: Qwen3-Next-80B-A3B-Instruct and the Qwen3.5 family all sit at 262,144 native with 1,010,000 via YaRN, Qwen3-235B-A22B-Instruct-2507 sits at 262,144 native with 1,010,000 via Dual Chunk Attention and MInference (not YaRN), and Qwen3-Coder-Next ships at 262,144 native with no documented extension. Gemma 4 12B matches them at 256K native without the YaRN escape hatch.
What “needs the context” actually costs
The context window is the floor on KV-cache memory, on top of the model weights and the activation memory. The arithmetic is 2 x num_hidden_layers x num_key_value_heads x head_dim x bytes_per_element per token. That formula assumes every layer is a full-attention layer. Qwen3.5-9B is a hybrid: its config.json lists 32 layers with full_attention_interval 4, so only 8 layers keep a growing KV cache and the other 24 are linear-attention layers with a fixed-size state. With 4 KV heads, head_dim 256 and bf16 KV, one token of KV cache is 2 x 8 x 4 x 256 x 2 = 32,768 bytes. At 262,144 tokens that is 8,589,934,592 bytes, about 8.6 GB (8.0 GiB) of KV cache alone. A conventional dense model with the same head layout on all 32 layers would need four times that, about 34.4 GB (32 GiB), which is why the cluster’s how-much-vram-does-a-local-llm-actually-need page pairs naturally with this one.
Three practical mitigations are available in current runners. KV-cache quantization (--cache-type-k q8_0 / --cache-type-v q4_0 in llama.cpp) cuts the KV footprint to well under half of bf16 at minor recall cost. Sliding window or chunked attention keeps only the last N tokens hot, which is what the 32K models effectively do at long context. Prompt caching in vLLM and llama.cpp server lets you keep a long static prefix in memory and only pay full KV cost for the new suffix - this is the right answer for a RAG setup that reuses the same document across many questions.
The combination that matters most: a 256K-tier model on a single 24 GB GPU with KV-cache quantization will usually outperform a 32K-tier model on the same GPU for any task that needs more than ~16K tokens of context, because the larger model’s recall quality at native length beats the smaller model’s recall at extension.
Picking a tier
A 32K tier is the right answer for chat, single-document Q&A under ~50 pages, and most tool-calling agents where the working set is the function schemas plus recent turns. A 128K tier covers most RAG over a single long document, multi-file code completion, and the kind of “explain this codebase” prompt that the cluster’s own best-local-coding-models-by-vram page recommends 32K models for - if you want the long context, you need to bump to 128K. A 256K tier is the floor for agent loops that accumulate long histories, multi-document RAG, and any task that genuinely needs the headline window. A 1M-or-more tier exists almost entirely because Llama 4 Scout ships it; the recall cost past 1M-2M is steep and the VRAM cost is at least double the 256K tier for the same architecture, so reach for it only when no 256K model fits the corpus.
The catch that does not appear in the tier table: the headline context window is a length, not a guarantee. Models that ship with YaRN to 1M tokens will produce coherent output at 1M, but the retrieval accuracy across that span degrades, and the KV-cache memory cost is the same whether you use 200K or 1M tokens. Read the upstream model card for any benchmark that quotes needle-in-a-haystack recall at the headline length before betting a workflow on the upper bound.
Bottom line
For self-hosted open-weight models on 2026-10-18, the practical tiers are 32K (Qwen3-4B and friends, fits 8 GB VRAM), 128K (gpt-oss-20b is the cheapest pick at 14 GB; gpt-oss-120b is the highest-quality Apache-2.0 pick at 65 GB; Llama 3.3 70B is the alternative if you accept the community licence), 256K (Qwen3.5 4B/9B/35B/122B and Qwen3-Next-80B-A3B-Instruct, all Apache-2.0 and not gated), and 1M-to-10M (Llama 4 Scout and Maverick, both behind the Llama 4 community licence and both VRAM-expensive). The 256K tier is where Qwen’s 1,010,000-token YaRN extension actually matters, and the 1M+ tier is where Llama 4 is alone. The methodology page on VRAM arithmetic is at how-much-vram-does-a-local-llm-actually-need, the methodology page on context-window mechanics is at how-much-context-can-a-local-llm-actually-hold, and the per-use-case tier lists are at best-local-coding-models-by-vram and friends.
Updated October 2026. What changed: re-verified against primary sources. Qwen3.5-9B config.json max_position_embeddings 262,144 (32 layers of which 8 are full attention, 4 KV heads, head_dim 256), Qwen3-Next-80B-A3B-Instruct 262,144 (48 layers, 16 attn heads, 2 KV heads, head_dim 256), Qwen3-Coder-Next 262,144 (80B/3B active, 10 routed of 512 experts, Apache-2.0 per the model card), DeepSeek-V3.2 163,840 (61 layers, 128 attn heads, multi-head latent attention with kv_lora_rank 512 and qk_rope_head_dim 64, YaRN factor 40), Llama-4-Scout-17B-16E-Instruct extra_gated_prompt 700M MAU clause under the Llama 4 Community License still in force, gpt-oss-20b/120b 131,072 native (24 and 36 layers respectively, 64 attn heads, 8 KV heads, head_dim 64), Mistral-Small-3.2-24B-Instruct-2506 131,072 (40 layers, 32 attn heads, 8 KV heads, head_dim 128, Apache-2.0), Qwen3-30B-A3B-Instruct-2507 262,144 (48 layers, 32 attn heads, 4 KV heads, head_dim 128, 128 experts, 8 active, Apache-2.0), Qwen3-235B-A22B-Instruct-2507 262,144 native + 1,010,000 extension per card, Gemma-4-12B-IT 262,144 (rope_type proportional in the unified config), all hold against primary sources. Ollama tag sizes re-measured against the live library pages: qwen3:4b 2.5 GB (default), 2.6 GB (q4_K_M), 4.4 GB (q8_0); qwen3:32b 20 GB; qwen3:30b-a3b 19 GB; qwen3:30b-a3b-instruct-2507-q8_0 32 GB; qwen3.5:4b 3.3 GB; qwen3.5:9b 6.6 GB; qwen3.5:35b 22 GB (was 24 GB at publication; trimmed to 22 GB on the live library - the row above has been updated); qwen3.5:122b 81 GB; qwen3-coder-next 52 GB; gemma4:12b-it-q4_K_M 8.0 GB (the “(q4_K_M ~7 GB est)” cell above is now bracketed “(q4_K_M 8.0 GB on Ollama)” - updated); llama4:128x17b 245 GB; llama4:scout and llama4:16x17b 67 GB; mistral-small:24b 14 GB; mistral-small:22b 13 GB; gpt-oss:20b 14 GB; gpt-oss:120b 65 GB. Llama 4 Scout retains its 10M-context headline on the Ollama library page. Correction 2026-11-01: the KV-cache example previously treated all 32 Qwen3.5-9B layers as full attention (131,072 bytes/token, ~33 GB at 256K); the config sets full_attention_interval 4, so the figure is 32,768 bytes/token and about 8.6 GB (8.0 GiB) at 262,144 tokens. Title month bumped from (September 2026) to (October 2026). updatedDate and lastReviewed both set to 2026-10-18.