DeepSeek released DeepSeek-V4.1-Flash on Hugging Face on September 10 under an MIT license covering the repository and model weights. The model accepts text and images, produces text and supports a context window of up to one million tokens. It is an open-weight deployment option rather than a ready-made hosted application.
The model card describes a mixture-of-experts backbone with 552 billion parameters, plus a separate 196-billion-parameter conditional-memory component. DeepSeek says the architecture activates 8 billion backbone parameters per token during input processing and 16 billion during decoding. Those active counts do not represent the total weights a deployment must store or establish that the model fits on a small local machine.
What the memory changes mean
DeepSeek divides its 40-layer backbone into a 20-layer causal encoder and a 20-layer decoder. The decoder derives its global key-value cache from the encoder’s final hidden states. The company reports a global KV-cache footprint of 890 bytes per token, roughly one-quarter that of DeepSeek-V4-Flash.
That is a specific cache measurement, not the whole serving-memory requirement. Model weights, other runtime state and the implementation also affect deployment resources. The architecture is aimed at reducing the cost of handling long inputs, but the model-card figure alone does not establish end-to-end throughput or a cloud bill.
Integration changes
The release changes tool-call tags from V4, so applications cannot assume that an existing conversation formatter remains compatible. The repository supplies a Python encoder and the deepseek-recipe Rust and Python toolkit instead of a standard Jinja chat template. The format supports image and text content, mid-conversation system messages and configurable reasoning effort.
Reasoning effort accepts values from 1 to 100, with a reference default of 75. DeepSeek’s reported instruct evaluations use the maximum setting, making the setting relevant when interpreting scores or reproducing results rather than treating every run as equivalent.
The included inference implementation is intended as readable reference code. It requires conversion of the downloaded weights into tensor-parallel checkpoints and does not provide a production serving system. Teams remain responsible for hosting, tool execution and HTTP routing. The repository also includes benchmark-reproduction instructions, giving deployers a way to inspect the stated setup before deciding whether to build a production integration.