DeepSeek V4.1 Flash Shrinks the Cache, Not the Migration Work

DeepSeek’s API migration position on September 14 has an immediate operational consequence: an accepted model name no longer necessarily identifies the model originally behind it. The current documentation says legacy Flash names now route to DeepSeek V4.1 Flash, while V4 Pro will remain available beyond September 14 with its billing method unchanged. Meanwhile, DeepSeek attributes substantially smaller attention caches to V4.1 Flash’s architecture. Those are different kinds of continuity: the service can keep accepting requests while the implementation and conversation contract underneath them change. DeepSeek API notice V4.1 Flash model card

That split is where cache engineering meets migration risk. DeepSeek says V4.1 Flash reduces global KV cache storage to 890 bytes per token and uses bounded replay to reduce persistent cache requirements further. Neither claim removes the need to verify model routing, prompt encoding, reasoning history, tool parsing, or serving support. This is architecture and integration analysis, with no local deployment test or independent resource measurement. September 14 is this article’s publication date and the date addressed by the current Pro continuity notice; the V4.1 Flash repository was created on September 10, according to its metadata. The available evidence does not establish a new September 14 model launch. Model card Repository metadata

The old Flash name now authorizes a different backend

DeepSeek’s first-call documentation recommends deepseek-flash. It also says deepseek-v4-flash and deepseek-v4-flash-vision-exp remain accepted, although their corresponding models have been retired. Requests using those names are served by V4.1 Flash and billed at the Flash price. That is an explicit compatibility mapping, not evidence that the older models remain selectable. For an application whose configuration still names an earlier Flash model, a successful response establishes endpoint availability but does not establish model continuity. API model-name notice

The distinction matters for incident investigation and change control. A configuration diff may show no model change even though the provider has changed the backend. An internal record that treats the requested model string as the complete identity of an inference run would therefore miss this migration. The practical response is to record the configured name alongside the provider’s documented mapping and the date that mapping was checked. Such records cannot create a version pin where none is documented, but they can prevent an alias from being mistaken for one.

Pro follows a separate path. DeepSeek says it decided, in response to user demand, to continue V4 Pro API services after September 14, 2026, with further notice if anything changes. Its pricing page lists the Pro version as DeepSeek-V4-Pro-0813 and the Flash version as DeepSeek-V4.1-Flash. The notice supplies neither a replacement shutdown date nor a permanent availability promise. It does establish that teams should not treat September 14 as a compulsory Pro cutover deadline. Models and pricing

The dates also require restraint. Hugging Face records the V4.1 Flash repository’s creation as September 10 and its last modification as September 10. Those timestamps describe the repository, whereas the API pages reviewed for this article have no publication-date metadata. Reading them together supports a current migration analysis anchored to September 14, not a claim that every document or service change originated that day. The difference is consequential: the news is how current routing and availability affect integration decisions, rather than a newly discovered launch timestamp. Repository metadata

Causal encoding changes where the decoder gets its memory

DeepSeek describes V4.1 Flash as a multimodal mixture-of-experts model that accepts images and text and generates text autoregressively. Its causal encoder-decoder architecture organizes a 40-layer Transformer into a 20-layer causal encoder followed by a 20-layer decoder. The central change is the source of the decoder’s global keys and values: they are projected from the final encoder hidden states, instead of being derived separately from each decoder layer’s own hidden states. Architecture description

A KV cache stores attention information from previously processed tokens so subsequent generation can reuse it. Hugging Face’s cache documentation explains the general purpose: autoregressive prediction repeatedly depends on preceding tokens, and retaining their keys and values avoids recomputing that information for every new prediction. V4.1 Flash’s architectural intervention concerns how that reusable information is produced and shared. It is more specific than selecting a smaller cache implementation around an otherwise unchanged model. Transformers cache strategies

The word “causal” is essential to interpreting the encoder-decoder label. The encoder remains constrained by token order; the architecture does not imply access to future generated text. Nor does “encoder” mean only an image-processing front end. DeepSeek separately describes a vision encoder and projector that turn images into embeddings. The causal encoder belongs to the language backbone through which the combined input is processed. Conflating these components would obscure the actual cache change, which concerns the decoder’s global attention state.

Prefill and decode then become materially different phases. Prefill processes an available input sequence and establishes the state needed for generation. Decode produces the continuation autoregressively. DeepSeek reports 8B activated parameters per token during prefill and 16B during decode, linking the split to improved cost efficiency for input-heavy agent workloads. The architectural explanation makes that claim intelligible: the decoder’s global memory can be obtained from encoder outputs without constructing it through each decoder layer’s separate history. These are DeepSeek’s resource claims, not measured latency or throughput results from this analysis. CED and activated-parameter claims

For workload planning, the implication is conditional. A task that supplies extensive existing material and requests a short answer has a different phase balance from one that generates a long continuation. Activated-parameter counts help explain why DeepSeek targets the former, but they cannot determine end-to-end response time. Scheduling, memory movement, prompt reuse, and output length still sit between the architecture and the user’s experience.

Global cache and persistent cache answer different questions

DeepSeek attributes the global cache reduction to several cooperating mechanisms. Compressed Sparse Attention 2 assigns attention layers static Full, Reindex, or Reuse modes to share main KV data and indexer keys across layers and reuse sparse-attention selections. A hierarchical sparse indexer in the decoder confines later indexing layers to candidates established by the first Full Mode layer. DeepSeek says this bounds deeper indexer cost independently of context length; it does not say that every operation in the model becomes independent of context length. CSA2 description

The card also specifies FP4 main KV caching in E2M1 format, with one E4M3 scale per 16 channels. DeepSeek reports that these designs together bring global KV storage to 890 bytes per token, roughly one quarter of DeepSeek-V4-Flash’s global cache footprint. This is a claim about a named component of inference state. It should not be relabeled as total device memory per token, total process memory, or the storage requirement for deploying the model. The wording “global” limits what the figure establishes.

Persistent cache reduction involves another mechanism. Sliding-window attention retains local context, and DeepSeek’s SWA Bounded Replay reconstructs missing sliding-window KV states by replaying only the most recent window of tokens. According to the card, this avoids persisting those sliding-window states to SSD and reduces the persistent KV footprint to roughly one eighth of DeepSeek-V4-Flash’s. The global-cache and persistent-cache ratios therefore describe different storage boundaries. They should not be multiplied together or treated as interchangeable measures of the same allocation. Bounded replay and cache claims

flowchart TD
    A["Ordered text and image embeddings"] --> B["Causal encoder"]
    B --> C["Final encoder hidden states"]
    C --> D["Projected decoder global KV"]
    D --> E["CSA2 sharing and FP4 main KV"]
    E --> F["Global cache footprint"]
    G["Recent token window"] --> H["SWA bounded replay"]
    H --> I["Reconstructed local KV"]
    I --> J["SWA state need not persist to SSD"]
    F --> K["Separate cache accounting boundaries"]
    J --> K

The operational question changes with the boundary. Global cache size helps characterize retained attention state as context grows. Persistent cache size concerns what must survive outside the immediate active state under the described replay design. Replay substitutes reconstruction work for storing some local state; the model card does not quantify the resulting resume latency for a particular service. An operator considering this mechanism would need to observe suspension, restoration, and continued generation together, rather than assess saved storage alone.

Hugging Face’s general cache guide reinforces why lower memory should not automatically be translated into faster inference. It describes tradeoffs among dynamic allocation, static allocation, offloading, and quantization, including cases where quantization harms latency for short contexts. That guidance is contextual evidence, not independent validation of DeepSeek’s implementation. V4.1 Flash’s specific savings remain vendor claims, and generic Transformers cache options do not establish support for its specialized sharing and replay behavior. Cache tradeoffs

Sparse activation leaves a large weight estate

The headline activation figures can conceal another deployment distinction. DeepSeek lists 552B backbone parameters, while reporting the smaller per-token activated counts for prefill and decode. It also describes Engram conditional memory with 196B parameters, accessed sparsely through token-based lookup. Within each MoE layer, the card specifies one shared expert and 384 routed experts, with six routed experts activated per token. These quantities describe different aspects of the system and should retain their labels. Parameter and expert architecture

Sparse activation means a token does not exercise every stored parameter. It does not mean the deployment only needs to accommodate the parameters selected for that particular token. Different tokens can select different experts, and the serving system must make the required weights available. Consequently, the 8B prefill figure is not a download-size estimate, a resident-memory guarantee, or evidence that the complete model fits the hardware associated with a much smaller dense model.

The repository metadata makes the distinction visible without requiring a speculative hardware calculation. It lists checkpoint tensors across several data types and a checkpoint divided into multiple safetensors files. The inference instructions then describe converting those weights into one checkpoint file per tensor-parallel rank, with the example selecting FP4 experts. Those are concrete signs that checkpoint representation, parallel placement, and runtime access remain deployment work even when token-level computation is sparse. No device-count recommendation can responsibly be derived from the activated count alone. Checkpoint metadata Weight conversion instructions

There is also a separation between weight precision and cache precision. The card’s FP4 main KV description concerns attention state, while the conversion command’s expert setting concerns weights used by MoE computation. Both may affect resource use, but changing one does not establish that the other is implemented or enabled. A deployment inventory would need to identify the checkpoint format, runtime weight format, and cache format independently.

The architecture therefore offers a plausible route to cheaper processing of large inputs while leaving substantial fixed machinery in place. That is not a contradiction. Cache compression targets state that grows with conversation length, whereas sparse routing targets work performed for each token. Weight storage remains a separate burden. Treating all three as a single “model size” would erase the distinction that makes the design worth examining.

The reference runner cannot certify a production engine

DeepSeek’s inference README sets a clear scope: the supplied implementation is readable reference code rather than a production serving engine. It covers the vision encoder and aligner, sliding-window and compressed sparse attention, the two-level indexer, Engram lookups, MoE, Hyper-Connections, and the DSpark forward path. It also states that generation itself uses plain autoregressive sampling. That final qualification matters because an implemented forward path is not the same thing as an operational generation strategy. Minimal inference documentation

The card describes DSpark as speculative decoding with semi-autoregressive draft generation and confidence-scheduled verification. Reading the card together with the inference README shows why a user should not assume that running the reference generator exercises that full acceleration scheme. The architecture includes the component, but the documented generation loop has a narrower purpose. Any performance expectation tied to speculative decoding needs evidence about the engine actually executing drafts and verification. DSpark description

The same restraint applies to the self-test. DeepSeek says it builds a small model using default arguments and exercises actual dense-FP8 and MoE-FP4 kernels through prefill and decode. However, its weights are uninitialized, so it checks shapes and kernel plumbing rather than numerics. Passing that check would be useful evidence that certain computational paths run; it would not validate converted checkpoint correctness, answer quality, or sustained serving reliability. This analysis has not run it. Reference self-test scope

A hypothetical self-hosting migration illustrates the distinction. An infrastructure team could first convert a pinned checkpoint using the documented conversion path, then compare the supplied equivalent text and JSON image examples for matching encoded inputs. It could use the reference implementation to investigate discrepancies before testing its selected serving engine with full model weights. This is a hypothetical workflow, not a reported deployment. Its acceptance evidence would concern separate questions: conversion correctness, image preprocessing, generation behavior, and engine support for the intended cache mechanisms.

Only after those questions are resolved would resource measurements become interpretable. Otherwise, an apparently disappointing cache result could reflect an engine that does not implement the advertised sharing scheme, while an apparently successful startup could conceal an untested output parser. The reference code makes the design inspectable; production evidence must show which parts survive in the deployed execution path.

Prompt syntax is now part of the migration contract

The model card states that this release includes no Jinja-format chat template. Instead, DeepSeek supplies a standalone Python encoding reference, with examples and tests for conversations, tool calling, thinking, numeric effort, system messages inserted during conversations, and interleaved images. An integration that assumes every model can be installed by swapping a tokenizer’s existing chat template therefore has a specific gap to address. Prompt encoding statement

The encoding README identifies three changes from V4. DSML tool markup now uses a leading space in its tag names, including calls, invoke, and parameter; the former V4 wrapper used tool_calls without that space. Reasoning effort becomes a numeric budget. System messages are also supported in the middle of a conversation through a dedicated system token. These are serialization changes, not merely alternative human-readable descriptions of the same prompt. Exact V4.1 encoding changes

For a custom gateway, that syntax has consequences on both sides of inference. The encoder must express tool definitions and conversation boundaries in the model’s expected form, and the parser must recover tool calls from generated output. The reference parser explicitly handles well-formatted output only and does not attempt recovery from malformed generations. Production error handling is therefore outside its guarantee. A parser accepting the happy path should not be assumed to handle partial, invalid, or otherwise unexpected completions safely.

Image handling introduces an ordering contract as well. The encoding reference preserves image records in the same order as their placeholders in the prompt, while pixel loading and expansion into model image tokens belong to the image processor. DeepSeek’s vision architecture uses an encoder and a two-layer projector to produce visual embeddings. Keeping images attached to their surrounding text is thus essential to preserving the question presented to the model; successful loading alone does not verify that association. Image encoding and ordering Vision architecture

Consider a hypothetical document-review gateway that sends alternating text instructions and page images, then asks a namespaced extraction tool to process a selected result. Its migration would compare image order, the encoded system message, the qualified tool name, and the parsed tool arguments against expected structures before relying on generated answers. This hypothetical workflow follows specific documented contracts. It would also test malformed output handling separately, because the reference parser’s documented scope does not supply that recovery behavior.

Reasoning history makes tool presence a structural decision

The hosted thinking-mode guide gives the migration a particularly sharp failure condition. When a request carries the tools parameter, all previous turns’ reasoning_content must be passed back, including turns in which the model did not call a tool. DeepSeek says failure to preserve that content correctly causes a 400 error. When the request does not carry tools, prior reasoning need not be returned and is ignored even if supplied. The branch depends on the request carrying tools, not on whether a particular response happens to invoke one. Thinking-mode context rules

That difference makes conversation storage part of API compatibility. A message layer that retains only visible assistant text can appear adequate during ordinary chat and fail when the same application enables tools. Likewise, code that preserves reasoning only for messages containing tool calls misses the explicit rule covering other turns. The stored representation must support the conversation mode the application will use subsequently, rather than merely reproduce what appeared in the user interface.

The local encoding reference has a related rule: its drop_thinking option normally strips earlier reasoning in conversations without tools, while tool use automatically disables that dropping. This aligns with the need to preserve context through tool interactions, but developers should still follow the appropriate contract for their integration surface. A local encoder’s handling of the final assistant turn is not a reason to override the hosted API’s stated rule about prior reasoning. Reference reasoning retention

A hypothetical coding assistant migration could expose this problem without a long workload. Suppose its persistence layer stores assistant content and tool calls but discards reasoning_content. The assistant receives an answer on a tool-enabled request that happens not to invoke a tool, then sends the saved conversation with another tool-enabled request. Under DeepSeek’s documented contract, the omitted reasoning is still a compatibility defect. A hypothetical acceptance check would preserve the complete assistant message, continue through both tool and non-tool responses, and verify that history reconstruction retains the required fields.

This is where architectural efficiency and integration requirements intersect most directly. Smaller cache state can reduce the provider’s burden of retaining a long sequence, while tool-enabled applications must still carry the correct reasoning history into that sequence. Compression does not authorize the client to discard semantically required conversation fields. Nor does the hosted cache-hit price tell a client which fields it can omit.

Effort controls and protocol adapters have different limits

At the encoding layer, DeepSeek documents integer reasoning effort from 1 through 100, with low mapping to 50, high to 75, and max to 100. The default is high, and the prefix is rendered only in thinking mode at the start of the conversation. That last condition is important for applications that try to alter behavior midway through an existing encoded prompt: changing a setting in application state does not establish that a new prefix has reached the model. Numeric effort encoding

The hosted API documents a different public control surface based on effort aliases. It maps medium and xhigh to high, while ultra maps to max. These aliases can preserve request compatibility while collapsing distinctions that a client interface presents to users. The model card’s numeric capability should therefore not be read as proof that every hosted protocol accepts arbitrary numeric settings. Integration decisions need to follow the documentation for the actual endpoint. Hosted effort mapping

Sampling parameters add another silent compatibility issue. DeepSeek’s thinking-mode guide says temperature, presence_penalty, and frequency_penalty have no effect in thinking mode, although supplying them does not raise an error. It says top_p is raised to a lower bound of 0.95 in thinking mode and fixed at 1.0 in non-thinking mode. Thus, an accepted request cannot verify that a control is operative. A migrated interface that still promises adjustable temperature during thinking would misdescribe the documented behavior. Parameter behavior

DeepSeek offers deepseek-recipe to handle protocol conversion, prompt rendering, and output parsing across Messages, Chat Completions, and Responses formats. Its Rust libraries and Python bindings support text, images, thinking, client tool calls, and streamed or complete responses. But the repository explicitly leaves inference, tool execution, and HTTP transport to the caller. It also lists unsupported features, including JSON Schema constraints, enforcement of strict tool settings, Responses conversation retrieval through previous_response_id, and encrypted thinking content. Recipe scope and limitations

Those limits define ownership. An application requiring stored Responses conversations must provide that state elsewhere or change its workflow; conversion support alone does not supply it. An application relying on schema enforcement needs a separate validation mechanism. The toolkit reduces duplicated protocol work, but its example servers use mock inference. Their existence demonstrates how components connect, not that a complete V4.1 production service has been delivered.

Anthropic compatibility can change routing as well as semantics

DeepSeek’s Anthropic-format endpoint adds another model-name translation. Names beginning with claude-opus map to deepseek-v4-pro, while names beginning with claude-haiku or claude-sonnet map to deepseek-flash. Unsupported model names map automatically to Flash. The Pro mapping uses Pro pricing. Consequently, a client displaying an upstream model label can conceal both a different backend and a different billing category after its endpoint is changed. Anthropic model mapping

A hypothetical gateway migration should therefore test routing deliberately, including what happens when configuration supplies an unexpected model name. If the application expects an invalid name to fail, the documented fallback to Flash violates that expectation without necessarily producing a transport error. The gateway could validate its allowed names before forwarding requests and record the intended DeepSeek route. This hypothetical measure addresses a documented ambiguity; it does not assume that any particular production application has already encountered it.

The compatibility matrix also says thinking budget_tokens is ignored, cache_control is ignored, and disable_parallel_tool_use is ignored. Document content is unsupported even though image content is supported. These distinctions matter because a protocol-shaped request can carry several assumptions beyond the text itself: how reasoning is budgeted, whether tools may be parallelized, how caching is requested, and what media types are accepted. Each assumption needs an explicit destination-side interpretation. Anthropic compatibility details

There is a documentation tension worth retaining rather than smoothing away. The Anthropic matrix lists temperature as fully supported, while the thinking-mode guide states that temperature has no effect in thinking mode. The narrower mode-specific statement should inform migration expectations, and an integration requiring precise sampling control would need confirmation of behavior on its chosen route. These documents do not justify a universal claim that temperature behaves identically across modes.

The pricing page further separates service economics from architectural accounting: it lists cache-hit input, cache-miss input, and output billing categories, alongside peak and off-peak schedules. Those commercial categories do not disclose the internal hit rate or replay cost of a particular workload. A smaller global KV footprint is not a customer invoice formula. Cost planning must follow the documented route and actual usage categories rather than convert cache compression ratios into assumed bill reductions. Pricing categories

The evidence needed now is a preserved conversation through the real stack

DeepSeek’s evaluation implementation documentation offers a useful lesson even without discussing scores. Its reference patch addresses container runtime constraints, test-runner concurrency, IPv6 loopback, additive mounts, and trajectory collection. Those details show that observable agent behavior depends on the execution environment around the model. A migration check that stops after receiving fluent text would leave tool execution, environment assumptions, and trace preservation unexamined. Evaluation implementation notes

The Harness quickstart makes the application boundary equally concrete. A configured model route becomes usable after saving its settings, but a workspace must also be selected before a session can begin. The agent can read and edit files, run commands, delegate work, and maintain a plan, with approvals governed by the active permission policy. Endpoint configuration therefore establishes only one component of an operational agent. Workspace selection and permission behavior belong to the deployed workflow and need to survive its migration as well. Harness quickstart

For API users, the immediate acceptance artifact should be a complete conversation that crosses the boundaries most likely to fail: the intended route, a tool-enabled response without a tool call, an actual tool invocation, preserved reasoning history, and a correctly reconstructed follow-up. For multimodal users, image ordering belongs in that same trace. For self-hosters, the corresponding evidence must also identify checkpoint conversion and which cache and generation mechanisms the serving engine actually implements.

The current notice gives Pro users continued service beyond September 14, while legacy Flash callers already face remapped execution. DeepSeek’s architecture explains how retaining long contexts could become less expensive internally, but it does not establish that an existing client preserves the model’s required conversation. The next decisive evidence is a successful end-to-end trace through the chosen production stack, accompanied by separately measured global cache, persistent state, and resume behavior. Until those boundaries are verified, a surviving model name proves routing compatibility, not a completed migration.