At one million tokens, DeepSeek reduced context memory from 389 GB to 890 megabytes.
That is the clean result. The model keeps the full context in memory, but usually reads only selected positions when generating a token. The questions around speed, quality, implementation, and attribution are much less tidy.
389 GB Became 890 Megabytes
A small network scores the available positions and selects 512 for each generated token. Eight of the model’s 40 layers make that choice independently.
Finding the best positions among one million scores could become expensive on its own. DeepSelect avoids sorting every value. For one million values, its proof limits the sorting step to about 29,000.
That means fewer than 3% of the values reach the sorting step. Everything else receives one comparison, making selective reading affordable enough to matter.
Most of the memory reduction, however, comes from the model’s architecture. Only four layers maintain a global cache. The other 36 borrow stored keys and values from those layers.
The main cache stores four-bit values. The sliding-window cache stays at eight bits because DeepSeek reported that it was sensitive to rounding.
Storage fell from 3.5,000 bytes per token in Previous Flash to 890 bytes in the new model. DeepSeek also reports that a cache miss costs 50 times more than a cached input token, so cache behavior matters to the economics as well as memory use.
Fast Tokens Did Not Settle Performance
Artificial Analysis measured the model at just over 200 tokens per second externally.
That sounds fast. But the model used nearly twice the median number of output tokens to reach its score. Generating each token quickly does not necessarily mean completing the work with fewer tokens.
Benchmark quality also changed sharply between versions:
- On Terminal Bench 2.1, the model finished ahead of Opus 5 and GPT 5.6.
- On Terminal Bench 4.0, it lost by 20 points.
DeepSeek published the Terminal Bench 4.0 loss in its own report. This is why the evidence supports a clear memory result, but not universal superiority.
Token speed, output length, and benchmark score measure different parts of the work. In this case, the external speed number was strong, yet the model needed many more output tokens and performed very differently across two versions of Terminal Bench.
The Released Kernel Is Narrow and Buggy
The current kernel does not offer broad hardware support. It compiles for two Blackwell targets, while older Ampere and Hopper targets are commented out.
Its Top-K range is limited too. Settings above 4,000 are unsupported, and one bad value aborts the kernel.
An outside contributor reported four bugs and submitted four fixes on the first day. The reported problems included integer overflow and writes that extended beyond the tensor.
Those constraints do not erase the memory result. They do make the implementation story narrower than the headline number. The released code has limited target support, a hard Top-K boundary, and reported correctness problems that received immediate fixes.
DeepSelect deserves credit for more than an idea. The speaker specifically credits its proof, instruction-level implementation, and multi-chip path. But the released kernel still has to move beyond its current limits.
The Credit Dispute Is Narrower Than Code Copying
A paper called Light Top K became publicly available on July 13. Its authors described estimating a threshold, filtering values during the scan, and keeping exact results.
DeepSelect shipped 59 days later. Its design document says DeepSeek created a new top-K algorithm, but it contains no citations.
The two approaches share important ideas. Both establish or estimate a threshold, filter values while scanning, and keep exact results. Their pseudocode also starts with a threshold of minus infinity.
They do not begin identically. The released DeepSelect kernel first processes a 32-kilobyte window, then enters the main scan with a threshold already established. The Light Top K authors also acknowledge that the implementations start differently.
So this is not a simple claim that the code is identical. The narrower question is whether DeepSeek’s design document should acknowledge related prior work.
DeepSeek has a dramatic long-context memory result, backed by a proof and an instruction-level implementation. The next question is whether DeepSelect can fix its reported bugs and attribution dispute while expanding beyond its current Blackwell and Top-K limits.