Capture DeepSeek’s 4x KV cache savings without the lock-in

If your team is deciding how much to bet on one model vendor’s cost curve, the risk is lock-in: a price advantage you cannot reproduce, built on a serving stack you cannot see. The DeepSeek efficiency moat is cache, kernel and serving gains that compound across releases. This article shows which parts you can buy, run privately or copy, and which parts only the vendor keeps.

Key takeaways

• What: DeepSeek’s V4.1-Flash keeps 890 bytes of global KV cache per token, 4x less than V4-Flash and 437x less than DeepSeek-V1, according to its V4.1-Flash report.

• Why it matters: those savings reach you as low API prices and MIT-licensed weights, but they protect cost, not capability: DeepSeek’s V4 report puts it 3 to 6 months behind closed frontier models.

• How: compressed attention, cache sharing across layers, a fused MoE kernel and load-aware speculative decoding were designed together, and rivals copy the ideas within months but not the integration.

• What to do: price your workload on the deepseek-flash API, then pilot the open weights privately, knowing your team must rebuild the KV cache, disaggregation and load-balancing layers DeepSeek did not release.

Background you need

Three concepts carry the rest of the article:

• KV cache: the keys and values stored for every past token so decoding does not recompute them. It grows with context length and layer count.

• Mixture of experts (MoE): each token runs through a few experts out of hundreds, so the cost moves from arithmetic to routing and communication.

• Speculative decoding: a cheap drafter proposes several tokens and the large model verifies them in one forward pass.

The bottleneck: memory, not arithmetic, sets the price of long context

DeepSeek’s framing is that prefill compute, KV cache capacity and storage bandwidth are now the main barriers to cheaper deployment, once sparse attention has made the arithmetic cheap. The cache is the clearest place to see it, because it is a simple product of bytes per token and tokens:

Eq. 1: KV cache size.

where:

• M is the global KV cache one sequence holds in GPU memory

• b is the bytes of global KV cache per token, summed over all layers

• s is the sequence length in tokens

At 890 bytes per token and a 1M-token sequence, V4.1-Flash needs about 890 MB of global KV per sequence (Eq. 1). Applying the reported ratios, V4-Flash needs about 3.6 GB (4 times more) and DeepSeek-V1 about 389 GB (437 times more). A grouped-query baseline of 8 KV heads with head dimension 128 in BF16 stores 4,096 bytes per token per layer, and the V4 report says V4 reaches roughly 2% of that baseline at 1M tokens.

Whatever fixes this has to attack bytes per token directly, and it must not make the model worse. That is a design problem across architecture, numerics and kernels, not a single paper.

Is the record one trick or compounding gains?

It is compounding. No single trick produces 890 bytes per token, and the savings span three layers of the stack: architecture, training and infrastructure. Table 1 lays the lineage out chronologically, and Fig 1 groups it by layer. The V4.1 report closes by pairing continued cost reduction with capability scaling, and its title is about KV cache compression rather than a benchmark.

Table 1: DeepSeek’s efficiency lineage, reported savings only.

Fig 1: Efficiency lineage by stack layer. Read each column top to bottom for release order. Savings arrive in all three layers across the release cycles, which is what lets them multiply instead of merely add.

The multiplication can be written down. If each generation cuts the cache by a factor, the cumulative reduction is the product:

Eq. 2: Cumulative cache reduction.

where:

• R is the cumulative reduction in KV cache per token

• rᵢ is the reduction factor contributed by generation i

V4-Flash holds 7% of V3.2’s cache at 1M tokens, a factor of 1/0.07, about 14.3. V4.1-Flash then cuts global KV another 4 times. Eq. 2 gives 14.3 x 4, about 57 times since V3.2. The two factors use different accounting (the V4 number is accumulated cache at 1M tokens, the V4.1 number is global KV only), so read 57 as an order of magnitude, not a measurement.

Builds on: KV cache compression from MLA onward.

Intuition: each release removes the cost the previous one exposed, so the savings stack instead of overlapping.

The remaining question is how the architecture itself got there, and why each step created the next problem.

How did the architecture cut KV cache 437x?

It did so in four steps, each fixing what the last one left. Multi-head latent attention (MLA) in V2 compressed keys and values into a latent vector, cutting the cache 93.3% against DeepSeek 67B. DeepSeek Sparse Attention (DSA) in V3.2 added a lightning indexer that picks which entries each query reads, which lowers attention compute while the stored cache stays large.

V4 attacked the stored size. Compressed sparse attention (CSA) compresses the KV cache along the sequence and then runs DSA over the compressed entries. Heavily compressed attention (HCA) compresses harder and keeps dense attention. The configurations show how aggressive this is: CSA uses a compression rate of 4 and HCA 128, with a 128-token sliding-window branch for recent text. KV entries are stored as BF16 for the rotary dimensions and FP8 for the rest, nearly halving the cache against pure BF16, and the indexer runs in FP4.

V4.1-Flash went further along a new axis, depth. Even a compressed cache is multiplied by layer count, so CSA2 lets neighboring layers share it. Each layer runs in one of three statically assigned modes: Full builds the global KV and picks its own top-k entries, Reindex reuses the KV but rescores to pick fresh entries, and Reuse takes both the KV and the selected indices from an earlier layer. HCA is gone, and the global branch is pure CSA2.

Fig 2: Causal encoder-decoder layout of V4.1-Flash. The 20-layer encoder carries the long prompt. The decoder derives its global KV from the encoder’s final hidden states, so prefill sends the full prompt through only half the network, plus a 128-token replay.

The second axis (Fig 2) is how much of the network a prompt must traverse. In the causal encoder-decoder (CED), decoder global KV is projected from the encoder’s final hidden states, so prefill activates 8B parameters while decode activates 16B out of 552B backbone parameters. A sliding-window cache that used to be persisted is now rebuilt by replaying only the last 128 tokens (SWA Bounded Replay), which DeepSeek says costs negligible quality and brings persistent storage to about 1/8 of V4-Flash. Extending context from 4K to 1M raises single-token decode FLOPs by only about a quarter.

Two smaller extensions follow the same logic of moving cost out of the hot path. Single-pass mHC halves residual-stream memory traffic against the original multi-kernel version. Engram adds 196B parameters as hashed n-gram lookup tables rather than dense compute, with deterministic addressing that allows prefetch from host memory.

Builds on: MLA, then DSA, then CSA and HCA, then CSA2 with CED.

Intuition: store less per token, then share what remains across layers, then skip the half of the network that prefill does not need.

None of this is free. Every one of these mechanisms needs a custom attention path, and the cost moves to the next component in the block.

Why is it hard to copy? Kernels and co-design

The harder-to-copy part sits below the architecture diagrams. Once attention is cheaper, the MoE layer becomes the bottleneck, because tokens must be dispatched to expert GPUs, computed, and combined back. In V4, DeepSeek splits experts into waves so one wave computes while the next receives tokens and a finished wave sends results, then fuses the whole pipeline into one GPU program. It reports 1.50x to 1.73x speedups for general inference against non-fused baselines and up to 1.96x for latency-sensitive cases such as RL rollouts, validated on both NVIDIA GPUs and Huawei Ascend NPUs. The report open-sourced only the CUDA implementation, as Mega MoE in DeepGEMM, which requires SM90 or SM100 NVIDIA GPUs. An Ascend port, DeepGEMM-Ascend, had its initial release on September 30, 2026 and lists MegaMoE for Ascend 950 NPUs under the MIT license.

The report also states a hardware design rule that explains why bandwidth alone is not the goal. Communication is fully hidden when the ratio of peak compute to interconnect bandwidth stays below the ratio of compute to communication in one token-expert pair:

Eq. 3: Compute-to-bandwidth rule.

where:

• C is peak compute throughput and B is the interconnect bandwidth

• h is the hidden size and d is the expert intermediate dimension

• 6hd is the FLOPs of the gate, up and down projections per token-expert pair, and 3h is the bytes moved (FP8 dispatch plus BF16 combine)

For V4-Pro, d = 3,072, so 2d = 6,144 FLOPs per byte: each GB/s of bandwidth hides 6.1 TFLOP/s of compute, and extra bandwidth beyond that gives diminishing returns. As an illustration, an accelerator with 2,000 TFLOP/s would need about 330 GB/s of effective dispatch bandwidth to hide communication (Eq. 3). DeepSeek also asks vendors for power headroom, lower-latency cross-GPU signaling and a cheaper activation function than SwiGLU.

Three other pieces show the pattern. DeepSeek writes fused kernels in TileLang, a kernel language, because the architecture would otherwise need hundreds of fine-grained PyTorch operators. It builds batch-invariant kernels (output independent of what else is in the batch) with a dual-kernel attention design whose multi-SM path keeps the same accumulation order as the single-SM path, and reports negligible overhead.

An outside commentator makes the same point about attention design:

“it is simply just not enough to come up with a clever attention pattern. You also need the kernels and the surrounding optimization set up to use that pattern.”

The Insane Infrastructure Design of DeepSeek V4

Builds on: FlashMLA, DeepEP, DeepGEMM and DualPipe from Open Source Week.

Intuition: an idea only becomes a cost cut after someone writes the kernel, the cache manager and the numerics that make it fast on real chips.

Even a perfect inference stack leaves the other half of the loop: training and reinforcement learning.

Does efficiency extend to training and post-training?

Yes, and the evidence runs from V3 to V4.1. The V3 report validated FP8 mixed-precision training at very large scale and reported 2.788M H800 GPU hours, or $5.576M at an assumed $2 per hour. That figure covers only the official run and excludes research and ablations, so it is a floor for what a rival must spend, not a total.

V4 pushed the same discipline. The Muon optimizer runs most modules, with a hybrid ZeRO bucket assignment that keeps each matrix whole because Muon needs full gradient matrices. FP4 quantization-aware training covers the MoE experts and the indexer, and the FP4-to-FP8 dequantization is lossless because FP8 has the larger dynamic range. Agentic RL runs on DSec, a sandbox platform with four execution substrates managing hundreds of thousands of concurrent instances.

V4.1 is candid about where the effort goes. DeepSeek writes that its post-training “introduces no algorithmic innovation” and that all substantive changes lie in the data pipeline, with on-policy distillation from over 40 teacher models. It also reports that V4.1-Flash-Base matches V4-Pro-Base using one third of the total parameters and one quarter of the active ones.

Builds on: GRPO from DeepSeekMath, then specialist training plus on-policy distillation in V4.

Intuition: once the algorithm is settled, efficiency moves into data, environments and recovery from failures.

Training is a one-time cost. Serving is paid per request, which is where the next mechanism sits.

How does DSpark turn serving load into a scheduling problem?

DSpark treats speculative decoding as a policy that depends on load, not as a fixed draft length. A parallel backbone drafts a block of tokens in one pass, a small sequential head (a Markov head, which conditions each token on the previous one) restores local coherence, and a confidence head estimates how likely each position is to survive verification. A hardware-aware scheduler then verifies only as much of the block as current engine throughput justifies, as the DSpark paper describes. bycloud sums up the key idea as “treating speculative decoding as a dynamic serving policy”.

Offline, DSpark improves accepted length over the autoregressive Eagle3 by 30.9%, 26.7% and 30.0% on Qwen3-4B, 8B and 14B, and over the parallel DFlash by 16.3%, 18.4% and 18.3%. In production, it replaced the MTP-1 drafter two weeks after the V4 preview, and the paper reports 51% higher aggregate throughput on V4-Flash at 80 tok/s per user and 52% on V4-Pro at 35 tok/s per user. At stricter service levels the nominal gains are 661% (Flash, 120 tok/s) and 406% (Pro, 50 tok/s), and the authors caution against reading those as speedups:

“We therefore interpret this high-SLA point primarily as evidence that DSpark extends the feasible interactivity frontier, rather than as a representative multiplicative speedup over a well-utilized baseline.”

DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation

The released DeepSpec repository (MIT) trains Eagle3, DFlash and DSpark drafters, with 12 checkpoints on Qwen3 and Gemma-4 targets. DSpark is also built into V4.1-Flash’s design. Serving economics follow from these gains. The pricing page lists deepseek-flash at $0.003 per 1M cache-hit input tokens and $0.15 per 1M cache-miss tokens off-peak, with peak rates double. Cache hits depend on the on-disk KV cache that the compressed layout makes affordable. DeepSeek’s own February 2025 accounting showed a 545% cost-profit margin, but only on a theoretical basis that assumed all tokens were billed at R1 prices.

Builds on: multi-token prediction in V3, then Eagle3 and DFlash.

Intuition: an extra draft token is cheap on an idle server and expensive on a full one, so the verify budget should follow load.

By the numbers

Table 2: Reported efficiency metrics, V4 family and V4.1-Flash.

All values are reported by DeepSeek. The V4-Flash figure of about 3,560 bytes is 890 x 4.

Can rivals copy the DeepSeek efficiency moat from the papers?

Partly. Ideas spread fast, and kernels and co-design spread slowly. Z.ai’s GLM-5 report says the model adopts DSA to cut training and inference costs, which came about 4.5 months after V3.2-Exp shipped on September 29, 2025. A published algorithm is therefore copyable inside a model generation.

Table 3: Which layers of the stack can be copied, and what stops a rival.

Fig 3: The co-design loop behind the moat. Architecture choices fix what kernels must do, and kernels and the serving engine determine real cost. The release covers papers, weights, kernels and an offline engine; the production cache, disaggregation and load balancing stay in-house.

The co-design row is the argument (Fig 3). DSpark’s gains were measured inside DeepSeek’s production engine, where verification length depends on live throughput profiles. Batch-invariant kernels and the rollout log are tuned to the same engine. A rival can download CSA2, the weights and an offline engine, but the release leaves out the cache system and scheduling that make 890 bytes per token a usable number in production. bycloud’s reading is that DeepSeek “isn’t chasing the benchmark state-of-the-art status and is instead optimizing the heck out of actually running LLMs”.

What’s the catch?

The strategy has five exposures, and the reports state most of them.

1. Frontier gap. DeepSeek estimates that V4 trails the leading closed models by 3 to 6 months. V4.1-Flash scores 90.6 on Terminal-Bench 2.1 against 89.1 for Opus-5, but 30.0 against 43.3 on Terminal-Bench 3.0 and 31.2 against 51.8 on 4.0, all at maximum effort. DeepSeek warns that “this parity does not imply that the model matches the frontier capabilities of leading closed-source systems”.

2. Complexity. The V4 report concedes that its architecture is relatively complex and promises to “distill the architecture down to its most essential designs”. V4.1 started that, dropping HCA.

3. Untested edges. The V4.1 report says CSA2 selection errors and approximate SWA state reconstruction may degrade capability in untested boundary cases. V4 also reports two stability fixes, Anticipatory Routing and SwiGLU Clamping, whose principles are not well understood.

4. Hardware coupling. Public kernels target SM90 and SM100 NVIDIA parts or Ascend 950 NPUs, and the DeepInfer engine lists only SM100 GPUs and Ascend 950.

5. Self-reported baselines. DSpark is compared with DeepSeek’s previous drafter on DeepSeek’s own traffic.

Caveat: DeepSeek’s own reports and repositories supply every efficiency number in this article. Those sources include no independent measurement of 890 bytes per token or of the DSpark throughput figures.

Under the hood: what the persistent cache actually stores

V4 writes the compressed CSA and HCA entries to disk so a repeated prefix is reloaded instead of recomputed, and only the tail of an incomplete compression block is recomputed. The uncompressed sliding-window (SWA) entries are the awkward part: they exist in every layer and are about 8 times larger than the compressed entries. The V4 report offers three policies for them, full caching, periodic checkpointing and zero caching, and deployments pick one.

The V4.1 report adds production evidence. In V4 deployments SWA KV took nearly half of persistent cache capacity, yet it is reused only within a minute-scale window of an active session, and exact recomputation (zero caching) proved prohibitive in production. V4.1 therefore keeps SWA KV in a short-lived pool carved from 10% of host DRAM, keeps global KV on SSD for at least 72 hours, and relies on bounded replay of the last 128 tokens to make the occasional miss cheap.

Limitations and open questions

The reports leave several things open:

• No independent measurement of V4.1-Flash cache size or serving throughput on third-party engines

• No total training cost for V4 or V4.1, so the $5.576M V3 figure has no recent equivalent

• No public KV cache system, prefill/decode disaggregation or load balancing for DeepInfer, so DeepSeek’s full serving path is not reproducible

• Whether CSA2 holds up on retrieval-heavy workloads beyond the benchmarks DeepSeek chose

Where is the DeepSeek efficiency strategy heading?

The target of efficiency has moved each year. V2 and V3 attacked training cost and per-token compute, V3.2 attacked attention compute, V4 attacked KV memory, and V4.1 attacks prefill and persistent storage. The V4 report’s stated next steps were sparse embedding modules, lower-latency architectures, multimodality and better data synthesis. V4.1 delivered two of those: Engram and native multimodality, with a 3x3 pixel-unshuffle that cuts vision tokens 9x.

Three directions follow. First, harness-aware design: the V4.1 report says DeepSeek will integrate model-harness co-design, so the agent loop and the model are optimized together. Second, simpler architecture, since both reports commit to pruning. Third, hardware: the V4 report’s requests to chip vendors on power, signaling and activation functions suggest DeepSeek wants silicon shaped for fused, fully concurrent MoE kernels. Pricing is moving too: peak and off-peak pricing took effect on August 16, 2026, and V4.1 launched with reduced prices.

What this means for your organization

Teams with heavy long-context or agent workloads should care most, along with teams that must keep data in their own VPC, because DeepSeek’s cost lever is memory and serving efficiency and it can be bought, self-hosted or partly rebuilt.

Choosing between the API and open weights

The cost advantage reaches API users through pricing. The pricing page serves V4.1-Flash as deepseek-flash with a 1M-token context and up to 384K output tokens.

curl https://api.deepseek.com/chat/completions \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-flash", "messages": [{"role": "user", "content": "Hello"}]}'

curl https://api.deepseek.com/chat/completions \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-flash", "messages": [{"role": "user", "content": "Hello"}]}'

curl https://api.deepseek.com/chat/completions \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "deepseek-flash", "messages": [{"role": "user", "content": "Hello"}]}'

The legacy name deepseek-v4-flash is still accepted: that model is retired, and requests are served by DeepSeek-V4.1-Flash-1017 at the Flash price. Structure agent prompts so shared prefixes repeat, because cache hits cost 50 times less than misses off-peak ($0.003 against $0.15 per 1M tokens).

The weights are MIT-licensed on Hugging Face, so the API is a choice, not a requirement. The API ties your costs to a price list that already changed in 2026, while the weights move that risk to your own capacity planning.

Running it privately: forward-deployed inference

Start with memory. At 890 bytes per token, Eq. 1 gives about 0.9 GB of global KV per 1M-token sequence, so 100 concurrent sequences hold about 89 GB across your cluster, before weights. That figure excludes sliding-window state: the V4.1 report keeps it in a pool carved from 10% of host DRAM and keeps global KV on SSD for at least 72 hours. Neither the V4.1-Flash nor the V4-Pro card gives a GPU or memory requirement.

Several pieces are public:

• Weights and reference code: the V4.1-Flash card points to an inference folder for weight conversion and local inference, and the Hugging Face page lists vLLM, SGLang, Docker Model Runner and Transformers launch snippets.

• Kernels: DeepGEMM’s Mega MoE needs SM90 or SM100 GPUs and is MIT-licensed, and DeepGEMM-Ascend lists MegaMoE for Ascend 950 NPUs.

• Drafters: DeepSpec (MIT) trains DSpark, DFlash and Eagle3 drafters, with 12 checkpoints on Qwen3 and Gemma-4 targets rather than DeepSeek’s own models.

• Engine: DeepInfer (Apache 2.0) calls itself the framework that powers DeepSeek’s production services. This release does offline inference for V4.1-Flash on NVIDIA SM100 GPUs and Ascend 950 NPUs, on Linux with Python 3.12 and CUDA 13 or CANN 9.2, and includes DSpark verification and SWA bounded replay. Its benchmarks used 4 SM100 GPUs for prefill and 64 for decode.

The README then lists what a complete service still needs and the release does not include: a KV cache system, prefill/decode disaggregation, and load balancing across data-parallel replicas. The card’s own production tooling, deepseek-recipe, stops short of serving: “Model inference, tool execution, and HTTP transport are left to the caller.” So a forward-deployed team gets the model and the kernels but rebuilds the serving integration. That is where the moat shows up for an organization, because the API’s cache-hit price depends on DeepSeek’s persistent cache, and a KV cache system is on the missing list.

No source reports V4.1-Flash throughput on third-party hardware, so a cost case for private deployment needs your own measurement. The case the evidence supports directly is data control and portability.

Hedging vendor concentration

GLM-5 adopted DSA about 4.5 months after V3.2-Exp shipped, so efficiency ideas spread within a model generation and a rival may match DeepSeek’s cost curve. Keep the model name in configuration, since a retired name now routes to a different model. Keep an evaluation suite that can swap in another engine, and keep the serving layer on engines such as vLLM and SGLang.

Next steps for your team

1. Price your workload on the DeepSeek pricing page, splitting input into cache-hit and cache-miss tokens and peak against off-peak.

2. Launch the DeepSeek-V4.1-Flash weights with the vLLM or SGLang snippets, then measure cache size and throughput on your hardware.

3. Build DeepInfer on SM100 or Ascend 950 hardware and scope the missing KV cache system, disaggregation and load balancing.

4. Benchmark Mega MoE from DeepGEMM on Hopper or Blackwell GPUs, or from DeepGEMM-Ascend on Ascend 950.

5. Train a drafter for your own target with DeepSpec, after checking its default Qwen3-4B target cache of about 38 TB and 8-GPU node.

My take: The thesis mostly holds, with one correction. The compounding asset is not the efficiency ideas, which GLM-5 absorbed within five months, but DeepSeek’s ability to change model, kernels and serving engine in one release cycle and publish the papers, weights and kernels while the full serving integration stays private. That makes the moat real but narrow: it protects cost, not capability, so it fails if the quality gap widens beyond a tolerable 3 to 6 months or a rival matches the whole stack. I would update if an independent engine reproduced 890 bytes per token at comparable quality.

What to watch next

Three checks would sharpen the verdict:

1. Independent replications of V4.1-Flash cache size and throughput on vLLM or SGLang, which would test DeepSeek’s own figures.

2. A Pro-scale model using CSA2 and CED, since the pricing page still lists V4-Pro-0813.

3. Whether DeepSeek releases the KV cache system, disaggregation and load balancing that DeepInfer’s README lists as missing, which would show how much of the co-design can be reproduced outside DeepSeek.

FAQ

Short answers to common questions about DeepSeek’s cost advantage.

What is DeepSeek’s moat?

DeepSeek’s moat is compounding efficiency across architecture, training and infrastructure, backed by kernels and a serving engine built with the models. The ideas themselves are public and copyable, as GLM-5’s adoption of DSA shows.

Is DeepSeek-V4.1-Flash open source?

Its weights are MIT-licensed on Hugging Face, and key kernels are MIT-licensed in DeepGEMM and DeepGEMM-Ascend. DeepInfer, the offline engine, is Apache 2.0, but its release omits the KV cache system, prefill/decode disaggregation and load balancing a full service needs.

Can you run DeepSeek-V4.1-Flash on your own infrastructure?

Yes, with work. The weights are MIT-licensed, the Hugging Face page lists vLLM and SGLang launch snippets, and DeepInfer runs the model offline on NVIDIA SM100 GPUs or Ascend 950 NPUs. Your team must still build the serving layer around it, and neither model card states GPU requirements.

What is DSpark?

DSpark is DeepSeek’s speculative decoding method that pairs a parallel drafter with a small sequential head and verifies only as many tokens as server load justifies.

How much did DeepSeek-V3 cost to train?

DeepSeek reported 2.788M H800 GPU hours, or $5.576M at $2 per GPU hour, for the official run only.

Sources

• DeepSeek-V4.1-Flash: Pushing the Limits of KV Cache Compression

• DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence

• DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation

• DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model

• DeepSeek-V3 Technical Report

• GLM-5: from Vibe Coding to Agentic Engineering

• DeepGEMM

• DeepInfer

• Models & Pricing

• The Insane Infrastructure Design of DeepSeek V4

• DSpark: DeepSeek-V4’s Insane Compute Optimization Explained

• DeepSeek-V4.1 Flash: The Most Insane Optimization So Far