This Tiny Local AI Model Has 1 Million Tokens of Context. But How?

summarized

TLDR

Sparkx 2.5 achieves a 1M token context window in a 4B parameter model by using 27 local attention layers (512 token window) and 9 global layers, reducing KV cache memory to about a quarter of full attention. The practical memory cost at full context is still ~39 GB at 16-bit precision, making smaller windows like 32K tokens (1.3 GB cache) more realistic for local hardware. The architecture is a genuine advance for local coding assistants, but the full million-token claim is more about architectural possibility than everyday usability.

Key points

Sparkx 2.5 uses 27 local and 9 global attention layers across 36 total layers.

The KV cache for a 1M token conversation at 16-bit is estimated at ~39 GB.

At 32K tokens the KV cache drops to about 1.3 GB, making it more practical.

The model scores 44.4 on SWE-bench Pro but 41.6 on SWE-bench Verified.

Local runtime support now includes native llama.cpp and LM Studio versions.

Tools mentioned

Techniques

  • Local attention with 512 token window
  • Global attention layers for long-range dependencies
  • Grouped query attention (16 query heads, 4 KV heads)
  • KV cache management with sliding windows
  • Long context training with sequences up to 1M tokens
Transcript (captions)

0:00 Sparkx 2.5 puts a million token window in a 4B model. Can your local coding assistant afford to use it? The model is small. The memory it builds while reading your project can be much bigger.

0:11 That matters when a useful coding session grows into source files, documentation, error logs, and a long trail of tool results. Spark cuts that cost by giving most of its attention

0:22 layers a short local view while keeping a few that can look across the whole conversation. Those global layers are what make the million token claim interesting. They're also why the full

0:31 window still needs serious memory. So, the useful question is how much context this design makes practical, and what you're trading away when you squeeze it onto your machine. Start with the two

0:41 numbers on the model card. 4 billion describes the model's learned parameters, the settings stored in its weights. A million describes the space available for the conversation. Tokens

0:50 are pieces of text, so that isn't a million words or a fixed number of source files. The configured limit is just over a million tokens and 4B describes the whole model unlike a

1:01 larger mixture of experts that activates only a small part at a time. Loading the weights is only the first memory bill. As the model reads your prompt, attention creates representations of

1:11 earlier text that later tokens can consult. These stored keys and values are the KV cache working notes for this particular conversation. Picture a code example. An early project rule says

1:22 every retry needs a delay. Much later, a function retries a failed request immediately. A useful assistant needs to connect the function to that rule, even with pages of logs between them. This

1:33 illustrates the dependency. It isn't a recorded Spark answer. In a full attention layer, the current token can attend to earlier positions across the available context. A local attention

1:43 layer limits that direct view to recent positions. Spark's local window is 512 tokens. Once the old rule falls outside it, that layer can't directly look back at the rule's original position. But

1:55 that doesn't mean the entire model forgets everything after 512 tokens. Information can move through the layers, and Spark includes full attention layers, too. We're describing which

2:05 earlier positions a particular layer can access directly. The configuration repeats three local layers, then one global layer through 36 layers. That's 27 local layers and nine global ones.

2:16 The recent retry code stays inside the local view while global layers retain a path to the old instruction. That makes the connection possible without guaranteeing a correct answer. So,

2:27 here's where the memory saving happens. A runtime that manages the sliding windows properly can keep their caches bounded as the conversation grows. The nine global layers still keep a growing

2:37 history. Most layers stop accumulating a full conversation's worth of notes, while the global ones preserve the longer reach. Spark also has 16 query heads, but only four sets of keys and

2:48 values. Several query heads share the stored notes. This is grouped query attention. Different queries without a separate copy of the key and value history for every query head. The window

2:58 also involves training. Sparks team describes a dedicated long context stage with sequences reaching a million tokens. That's what supports its native context claim. The length was part of

3:08 training beyond just changing a setting. it still doesn't establish reliable recall everywhere inside that window. So what does the architecture cost in actual publish configuration gives

3:19 enough information for a useful estimate? Take one conversation, keep the keys and values at 16 bit precision and assume the local caches stay bounded. Each stored token needs about

3:30 4.1 kilobytes per attention layer, counting both the key and the value at the full configured window. The nine global caches account for almost all the storage. Include the small local caches

3:41 and the total is roughly 39 GB. That's cache alone before loading the model weights, temporary processing buffers or the software running them. These are calculated storage requirements, not a

3:52 measurement from a laptop. To see the saving, imagine the same dimensions with all 36 layers keeping full history. That hypothetical cache would be about 155 GB. Spark brings it down to about a

4:04 quarter. A large reduction can still leave a large object. The working notes have become the largest thing on the desk. The practical improvement appears when you choose a smaller window. At

4:13 32,768 tokens, the same 16- bit cache estimate is about 1.3 GB. At 131,000 tokens, it's about 4.9. The local part barely changes once its window is full. The global part

4:28 grows with the conversation. Set the context for your task, leaving room for the answer and tool results. Runtime allocation strategies vary and simultaneous conversations need more

4:38 memory. This calculation is a starting budget, not a promise that a particular graphics card will fit the complete workload. Weight compression is a separate choice. The official full

4:48 precision GGUF download is about 8.2 GB. The same repository now offers an 8bit file around 4.4 GB and a 4-bit file around 2.6. Those are file sizes. Choosing the smaller download doesn't

5:02 automatically shrink a 16- bit conversation cache. A runtime may also support cache compression, which can reduce that second bill, but its format support and quality trade-offs need

5:12 their own checks. There's also the time needed to read a large prompt before answering. Reducing the number of global layers doesn't eliminate their longrange attention work, so fitting a million

5:23 tokens wouldn't by itself establish that processing them feels interactive. What can this small model do? Sparks developer reports strong results in coding, tool use, browsing, and

5:33 mathematics. These are its published evaluations in thinking mode with some competitor scores taken from other cards or papers. They aren't independently reproduced results for every compressed

5:43 download. For example, the card reports 44.4 on Swebench Pro compared with 29.4 for Quen 3.54B. That's a reason to investigate a compact coding model. But on SWEBench verified,

5:57 Spark scores 41.6. 6 while Quen's 9B scores 53.1. Even the coding category doesn't produce one universal winner. The other headlines are 40.9 on browse comp, 54.6 on MCP Atlas, and 90.7 on AM

6:13 2026. Those cover different jobs from browsing and tool-based tasks to competition mathematics. Each is a reason to investigate a particular capability rather than evidence that

6:23 this model wins at everything. The less flattering rows matter, too. On the GPQA knowledge benchmark, Spark scores 67.4 behind Quen's 9B at 77.2. Instruction following is more nuanced.

6:37 Spark leads the listed Quen models on IAL and ifbench, but Gemma 412B beats it on. The sensible conclusion depends on both the task and the comparison model. For a useful trial, choose a repository

6:50 whose expected behavior you know. Put a relevant instruction earlier in the material. Request a change that depends on it. Then inspect the patch and run the tests. Repeat at a few context links

7:00 while recording memory and time to the first answer. For agents, validate the tool arguments, too. This is a proposed evaluation, not a result claimed here. Local runtime support has been moving

7:11 quickly. Older advice points to custom builds. Spark's current card now lists native support versions and llama.cpp is release notes confirm the addition of Spark support. The old claim that every

7:23 local setup requires XH tokens fork is no longer accurate. The card also names minimum versions for Alama and LM Studio. Spark has an Alama model page, but the exact Alama release linked by

7:35 the card wasn't available during research. Check that your installed runtime supports Spark before treating the advertised command as a tested setup. The download options are already

7:44 broader than one full precision file. Alongside the official GGUF files, there's an official INT8 checkpoint, community GGUF quantizations, 4bit and 8bit MLX conversions, and an ONNX

7:57 export. These are different packages for different execution paths. The file name tells you how the weights are stored, not whether your chosen app understands the architecture. The MLX conversion

8:07 cards point to Spark's dedicated runtime rather than the standard library. That project also documents loading the original checkpoints on Apple silicon or Linux using the supported processor or

8:17 graphics hardware. So, the conversion and original checkpoint routes are both documented options, but their installation instructions aren't interchangeable.

8:26 The runtime's own guidance is particularly useful for agents. It recommends 8bit or full precision weights for tool calling and warns that four-bit weights can reduce the accuracy

8:36 of structured arguments. That's the maintainer's advice, not a quality test of every conversion. If a smaller model fits only by breaking the tool arguments your workflow needs, the saved memory

8:46 hasn't bought you a working agent. Spark advertises more than 200 languages, and its license file is Apache 2.0. Broad language coverage doesn't mean equal quality in every language. Include your

8:57 own repository comments or support documents in the trial if an English benchmark doesn't represent that work. Spark is worth a trial for local coding and tool workflows because the

9:07 architecture reduces the cost of keeping history and its published strengths fit those jobs. Choose a supported runtime, a context budget that matches the task and enough weight precision to preserve

9:18 the behavior you need. If you regularly need a whole archive, compare full context processing with selecting the relevant files first. A larger window can remove some packing work, but it

9:28 doesn't remove the need to check that the model used the right evidence. Our earlier video on quantized Quen downloads follows that next question. How two similarly sized files can

9:38 preserve different amounts of useful ability. A 4B model reaches a million tokens through local attention. A smaller set of global layers, shared key value storage, and long context

9:49 training. That gives you more room for a chosen memory budget. Whether the full million helps your work depends on the runtime and results you can verify.

Frontier News · by Hyperjump Technology