DeepSeek Silently Swapped Models: The KV Cache Arithmetic Is the Real Announcement

DeepSeek replaced the model behind its deepseek-flash API endpoint with a new checkpoint, DeepSeek-V4.1-Flash-1017, without any changelog or email notification. Same name, same price, but if you called the same endpoint on Friday and on Saturday, you were talking to two different models. This hit 903 points on Hacker News, but what's really worth looking at isn't the leaderboard numbers—it's the cache arithmetic hidden in the public config.json.

Same Endpoint, Two Checkpoints

DeepSeek^Ad officially calls this update a "minor update," but the benchmark table it published doesn't support that adjective: all 11 benchmarks went up, with Terminal-Bench 4.0 gaining 11.1 points and ProgramBench gaining 8.8 points. These are numbers the vendor ran on its own test harness, and external parties can't reproduce evaluations like DeepSWE.

What can be reproduced is another part: the new weights are on Hugging Face under the MIT license, in 48 safetensors shards totaling 510,296,708,312 bytes, roughly 510.3 GB (475.3 GiB). The model repository was created on 2026-10-17. The -1017 in the checkpoint name is the date, which means the self-hosted path is fully reproducible—the only thing that was quietly moved is the convenience alias called deepseek-flash.

KV cache (Key-Value Cache) is one of the most memory-hungry structures in Transformer inference. During autoregressive generation, each new token requires a weighted sum over the attention Keys and Values of all previous tokens; recomputing them every time makes cost grow quadratically with context length. Caching means storing historical Key/Value pairs for reuse, at the cost of memory that grows linearly with context. In traditional multi-head attention (MHA), every layer and every KV head needs its own copy, so a 1M-token context can easily need hundreds of GB of cache—this is the main source of long-context inference cost. The recurring terms later in this article—"cache bytes per token," "shared KV heads," "sliding window," "KV compression"—all fundamentally answer the same question: how do you compress this cache to a servable size without wrecking quality? Understanding this is what lets you see why a few fields in config.json are more worth reading than benchmark scores.

Three Key Designs in config.json

After pulling the official config, a few fields determine the whole cache story:

num_hidden_layers      40
len(compress_ratios)   43        <- three more than the number of layers
compress_ratios        {0: 5 layers, 2: 18 layers, 1: 20 layers}
num_attention_heads    64
num_key_value_heads    1
head_dim               512
sliding_window         128
max_position_embeddings  1,048,576
kv_source_layer_ids    [2, 8, 14, 20]   <- only four layers provide long-range KV
index_topk             512

Three things are doing the real work: a single shared KV head; a 128-token sliding window, meaning the cache in window layers stops growing after 128 positions no matter how long the context is; and only four source layers supplying long-range KV, each with a compression ratio applied on top. Add to that a sparse index with index_topk: 512, and the model only attends to a selected subset of what it stores.

Multi-head Latent Attention (MLA) is the core technique the DeepSeek model family uses to reduce KV cache. The idea is to project Key/Value into a low-dimensional latent space for storage, then up-project back to the original dimension on demand during inference, saving the same history length with far less memory than MHA. Related techniques include Grouped-Query Attention (GQA) and Multi-Query Attention (MQA): the former lets multiple Query heads share a set of KV heads, while the latter goes to the extreme of keeping only one KV head. The num_key_value_heads: 1 in this config is the MQA-style shared KV head. head_dim: 512 shows that the per-head dimension is far larger than the usual 128—a compensating design to maintain expressiveness when the number of heads is tiny. compress_ratios specifies a compression ratio per layer, and kv_source_layer_ids picks only four layers to supply long-range KV; these are not standard Transformer fields but scheduling strategies custom-built into this architecture for cache compression.

Cache Bytes per Token Is Not a Constant

The widely circulated claim is "890 bytes of cache per token," and the paper is even titled Pushing the Limits of KV Cache Compression. But if you actually compute from the config, you find that the way this number is quoted is itself problematic.

Given explicit assumptions, here are three bounds:

[A] All layers store 512-dim latent KV, bf16:  44,032 bytes/token -> 46.2 GB at 1M tokens
[B] Same-width original MHA:                    880,640 bytes/token -> 923.4 GB
[C] Only 4 source layers, compressed by 2:       2,048 bytes/token -> 2.15 GB
[circulated value] 890 bytes/token:                            -> 0.93 GB

The 890 figure is even lower than the most aggressive bound [C], which means there must be quantization below bf16 plus the sparse index making up the difference. That's reasonable and makes sense. But one point no coverage mentions is: for this architecture, bytes per token is not a constant, and quoting it as one is a category error. A layer with a window of 128 costs 128 positions whether the prompt is 8,000 tokens or a million tokens. Do the amortization:

Effective bytes/token for window layers only:
ctx = 8,192       688.0
ctx = 131,072      43.0
ctx = 1,048,576     5.4

Same model, same code, but "per-token" cache cost differs by two orders of magnitude depending on the context length at which you measure it. The 890 figure came from a measurement at a specific length and a specific layer mix, and both premises were lost as the number spread. That doesn't mean it's wrong—it means it's incomplete, incomplete in the same way benchmark scores are, except that at least it comes with a config file you can check.

Sliding Window Attention means each token only attends to the previous W tokens rather than the entire history, where W is sliding_window. Its key property is that the KV cache used for attention in a window layer is capped at W positions; older tokens beyond W fall out of the window and the cache stops growing. This is exactly why the "effective bytes/token" for window layers in the amortization table drops sharply as context grows—total cache stays roughly constant, so dividing it by an ever-longer context naturally dilutes the per-unit cost. For the same reason, treating "bytes per token" measured at one context length as an inherent constant of the model does not hold for sliding-window architectures. Sparse indexing (index_topk: 512) is another layer of mechanism: rather than doing dense attention over everything stored, the model first selects the top-scoring positions and then computes, further limiting the KV actually involved in computation.

The Price Sheet Is the Other Half of the Paper

DeepSeek's currently published API prices: $0.15 per million tokens for uncached input, $0.60 per million for output, and $0.003 per million for cache reads.

Cached input is 50x cheaper than uncached input

The 50x cache-read discount is essentially the vendor using price to tell you that its cache serving cost really is extremely low. The work of KV compression shows up on the rate card, not in the press release. DeepSeek's own DeepSWE chart shows the new model at just under $0.20 per task at the highest setting, while competitors on the same chart are at $2 to $10—a 10x to 50x gap on the vendor's own chart and the vendor's own harness, so keep that in mind when reading it. But the direction is consistent with the config, and the config is public.

This release also includes Search and Fetch APIs at $0.75 per 1,000 successful requests, free to use in server-side tools for DeepSeek Harness, Claude Code, and Codex until billing starts at 16:00 UTC on October 31. DeepSeek is no longer just selling a model; it's selling the agent's eyes.

What's Really Worth Worrying About Is the Delivery Mechanism

None of the above is the problem. The problem is the delivery mechanism: a silent swap while the model name stays the same. Every evaluation you ran against deepseek-flash last week describes a checkpoint that no longer serves traffic.

DeepSeek did publish the weights and a dated checkpoint name, so the self-hosted path is fully reproducible. The only thing quietly moved is the convenience path: the API alias. If you pin versions for your database and base images but let your model float on a vendor alias, this release is the bill for that strategy: not that the model got worse—by every public measure it's better—just that it's no longer the one you tested.

Pin the checkpoint. Read the config. The arithmetic itself is the announcement.

Model alias refers to an endpoint exposed under a fixed name in an API (such as deepseek-flash), which the vendor can point to any checkpoint behind the scenes without callers noticing. The counterpart is a versioned checkpoint name (such as DeepSeek-V4.1-Flash-1017) or a fixed weight hash, both of which can be reproduced exactly. In engineering practice, this maps to two strategies: one pursues "always use the latest and best model" and accepts behavioral drift; the other pins the model like a base image to guarantee consistency between evaluation, regression, and production behavior. Silent alias switching is the classic scenario where these two strategies collide—it strips the frame of reference from evaluations, A/B experiments, and compliance audits that depend on a fixed endpoint. Common industry mitigations include pinning checkpoint names, recording weight hashes, running snapshot regression tests on model outputs in CI, and requiring vendors to provide changelogs and deprecation windows.

One-line Summary

DeepSeek silently swapped the model behind the Flash endpoint, and the config and price sheet reveal the real arithmetic of cache compression.

Paragraph Summary

Without a changelog or notification, DeepSeek replaced the model behind the deepseek-flash endpoint with DeepSeek-V4.1-Flash-1017—same name, same price, different behavior. The article argues the real story isn't the benchmark scores but the cache design in the public config.json: a single shared KV head, a 128-token sliding window, only four source layers providing long-range KV, plus sparse indexing. From this it derives that cache bytes per token is not a constant and can vary by two orders of magnitude with context length, and that the circulated 890 bytes/token is just a measurement under specific conditions. The 50x cache-read discount writes the cost of compression directly onto the price sheet. The core warning is about delivery: a silent swap behind an alias invalidates every evaluation based on the old checkpoint, and pinning the checkpoint, self-hosting, and reading the config are the reproducible path.