DeepSeek V4.1 Flash: Low-Cost Inference Meets Mixed Results in Practical Tests

DeepSeek V4.1 Flash is here, and its combination of low price, speed and reported benchmark results caught my attention. I see a recurring pattern: frontier models advance, then open-weight models approach earlier generations, potentially becoming easier to deploy later. But my own small set of tests did not always match the promise of the benchmark chart.

DeepSeek compares V4.1 Flash with Kimi K3, GLM 5.3, Claude Opus 5 and GPT 5.6 Sol. Its chart reports 30.0 on Terminal-Bench 3.0, 74.2 on DeepSWE v1.1 and 88.1 on CyberGym. On the chart both Opus 5 and GPT 5.6 Sol score higher on Terminal-Bench; performance depends on the benchmark and its testing conditions.

The model has 552 billion total parameters. I find the efficiency more interesting than the overall size: a mixture-of-experts model routes work through selected parts of its weights instead of activating all of them for every token. This can reduce the computation needed for inference, although it does not mean the unused weights disappear from deployment requirements.

DeepSeek describes a causal encoder–decoder architecture with 8 billion active parameters for input and 16 billion for output. It attributes the reported performance to this architecture, new pretraining methods and larger-scale reinforcement learning post-training. In my use, the model feels very fast, and I will demonstrate that shortly.

The benchmark results are uneven across categories. DeepSeek’s CyberGym score leads the models in the displayed comparison, while its ExploitGym score is below several competitors in the table. These are specific reported evaluations, not evidence that one model is better at every task.

The next claim concerns the KV cache, which stores intermediate attention information used during generation. DeepSeek says V4.1 Flash’s cache requires one-quarter of the high-bandwidth memory and one-eighth of the SSD storage of the previous generation’s cache. That is a cache comparison, not a claim that the complete model requires one-quarter as much memory.

I look at charts showing how memory prices have risen and connect that pressure to growing AI demand and constrained supply. High-bandwidth memory is an important cost for serving models, so reducing cache requirements can matter. The charts are illustrative; individual product prices and their causes vary.

DeepSeek’s chart shows a substantial decline in global KV cache bytes per token across its model generations: from V1 to V3.2, then V4 Flash, and finally V4.1 Flash. The newest step is roughly a fourfold reduction relative to V4 Flash. Less cache storage can support higher throughput and lower serving costs, depending on the workload.

The release-time API prices vary by peak and off-peak hours. For one million uncached input tokens, DeepSeek listed $0.15 off-peak and $0.30 peak; output was $0.60 and $1.20 respectively. Cached input was $0.003 and $0.006 per million tokens. Those are the rates shown in September 2026, not a promise of current prices.

The weights are available to download, so deployment is not limited to sending data to DeepSeek’s hosted service. A third-party cloud or a local setup may be an option, subject to the hardware, implementation and any quantization available. Open weights do not by themselves guarantee that a 552-billion-parameter model fits on an ordinary computer.

DeepSeek has become known for efficiency. I think the market increasingly has a distinction between the most expensive frontier models and faster, cheaper models that are good enough for many tasks. I speculate that routine work such as making a website or a PDF often does not need the most expensive model, though the right choice depends on quality requirements and the particular job.

DeepSeek also released a technical report describing its architecture and techniques. That makes the work more useful to other researchers and developers, who can study the methods and build on the available material. The availability of weights and a report should still be considered alongside the applicable license and practical deployment constraints.

For a speed demonstration, I ask for a thousand-word essay about DeepSeek. The response appears very quickly; I estimate roughly 200 tokens per second and around six seconds, but this is a visual estimate, not a controlled measurement. Fast generation is impressive, but speed alone does not establish correctness.

My first Rubik’s Cube simulation finishes in about 12 seconds and initially looks plausible. When I scramble it, the behavior breaks: pieces move incorrectly, and the solve action snaps the cube back to its original state. I also cannot manipulate individual sides as expected, which makes the result disappointing for this test.

I run the same prompt using DeepSeek V4.1 Flash through a Codex harness. The second interface looks different and has more controls, but its squares appear disconnected and colors change incorrectly during scrambling and solving. The harness and execution environment differ from the first test, so these examples should not be treated as a controlled comparison.

The second app’s solve function replays recorded moves backwards. That can undo a known scramble, but it is not a general solver for an arbitrary cube state; the displayed app also identifies this limitation. I see an unsuccessful result after repeated scrambling and conclude that this particular implementation falls short of my expectations.

For another point of comparison, my colleague Alex has been asking models to paint a reference portrait in Microsoft Paint. I show an Astra example with layered brush strokes, then ask DeepSeek through Codex to use a browser-based Paint-like application. The environments are not identical: my test uses a different portrait and a web replica.

The DeepSeek result is stylized and recognizable as an attempt, but it lacks the detail I admired in the other example. It does not reproduce the same layered-brush technique. This is an informal visual judgment on one attempt rather than a standardized head-to-head evaluation.

Finally, I ask for a ray-traced 3D simulation of a projectile passing through water. The generated application provides controls for muzzle speed, caliber, mass, spin and other parameters, but the actual simulation leaves something to be desired in my view. I come away seeing a fast, inexpensive workhorse, while remaining unsure how it compares overall with GLM 5.3.