DeepSeek swapped its Flash model overnight. I pulled the new config and did the cache math.

Description and use

DeepSeek silently swapped the model behind the same API name, causing users to unknowingly use a different checkpoint. By downloading the new config, calculating cache sizes, and pinning the checkpoint, reproducibility can be restored.

Problem

A silent model swap under the same API name caused users to unknowingly interact with a different checkpoint, breaking reproducibility and evaluation consistency.

Outcome

The new checkpoint is larger (≈510 GB) and offers better benchmarks, but its per‑token cache cost varies with context length; the advertised 890 bytes/token is a lower bound. The silent swap highlights the risk of relying on vendor aliases without version pinning.

Workflow

• 1. Download the new config.json from Hugging Face. 2. Extract key parameters (num_hidden_layers, compress_ratios, kv_source_layer_ids, etc.). 3. Sum the safetensor shard sizes to compute total model size. 4. Perform cache‑size calculations using the provided formulas. 5. Compare calculated per‑token cache bytes to the 890 bytes figure. 6. Review DeepSeek’s pricing to understand cache read cost. 7. Pin the checkpoint name (DeepSeek‑V4.1‑Flash‑1017) in deployments to avoid silent swaps.

Evidence

On October 17, DeepSeek replaced the model behind its deepseek‑flash API endpoint.

Source

The new checkpoint is DeepSeek‑V4.1‑Flash‑1017, on Hugging Face under MIT, and it was the top story on Hacker News this morning (903 points when I checked).

Source

The circulating 890 figure sits below even my most aggressive bound, which means quantization below bf16 and the sparse index (index_topk: 512) are doing the rest.

Source