DeepSeek launching v4.1 flash cheaper and more capable than v4 pro

can't you edit it?

Nah, we're long past the point where that would make a difference - if they could have done so effectively, they would have before K3 and GLM 5.3 were nipping at their heels...

Anti distillation is just American nationalistic marketing, the amount of data they have "distilled" makes no difference. Deepseek "distilled" like 10000 messages? That's clearly not enough. You gain a lot more doing RL in house.

IQ3_XXS (~3.2 BPW). For me this is an option because my Mac studio is only used for serving LLMs, so I can afford to dedicate most of its RAM to this. I can run with 256k context and only uses ~117G, with the remaining (up to 125G which I can allocate to VRAM) being used for prompt caching and context checkpoints.

I'm making my own quants, though the Vision-Exp version is outdated and won't work on llama.cpp master branch (I built it before llama added support):

- https://huggingface.co/tarruda/DeepSeek-V4-Flash-0731-GGUF

- https://huggingface.co/tarruda/DeepSeek-V4-Flash-Vision-Exp-...

For the Vision-exp version, I also ran perplexity + KLD against the original MXFP4. Seems quite OK: https://huggingface.co/tarruda/DeepSeek-V4-Flash-Vision-Exp-...

I must be doing something wrong. I gave v4 pro a try a couple of days ago, gave it a simple prompt like "clean up functions x and y in file z" and it would always start off promising, just to quickly get sidetracked, start hallucinating problems in the code, and just get stuck for hours until I interrupt it:

— hmm — 0x2D696370 — little-endian bytes: 70 63 69 2D = 'p','c','i','-' — hmm — WAIT — WAIT — !!!!! — *WAIT — WAIT — WAIT — WAIT — WAIT — WAIT — *HOLD ON — HOLD ON — HOLD ON — WAIT — WAIT — WAIT — WAIT — WAIT — WAIT — WAIT — !!!!!!!! — *WAIT — WAIT — WAIT — WAIT — WAIT — WAIT — WAIT — WAIT — *OK — WAIT — I THINK I FINALLY SEE THE WHOLE PICTURE — I NEVER READ IT — AND — THE LAYOUT — hmm — !!!!! — *WAIT — WAIT — WAIT — WAIT — WAIT — WAIT — WAIT — WAIT — WAIT — HOLD ON — HOLD ON — HOLD ON — HOLD ON

Then gave the same to Sonnet 5 and it was done 15 - 30 minutes later. I tried v4 pro both in claude code and codewhale with similar results. Haven't tried the new deepseek harness.

The new meta model is fast and very cheap as well, and when used through OpenCode you get quite a lot of free tokens. But meta is also THE surveillance company, so probably also not a good choice in your case.

Even you think both cheat, you can't possibly think they both cheat the same amount.

The Chinese labs have released interesting papers to accompany their releases too, especially DeepSeek and Kimi. This improves their standing among a few of us, who really like to see and read the papers with details about what they have changed and how their models work.

the US is also a surveillance state except about 80% of the surveillance is private companies (that are closely tied to the state)

translation

I make vaporware that doesnt do shit reliably and this chinese crap spouts plausible demos and spam calls more cheaply than the competition saaar

Which versions of flash and at what thinking levels? Which chinese flash models and at what thinking levels? What tasks? What completion rates? How was quality evaluated?

The only positive side is that it is harder for students to feed university exercises to the agent in cybersecurity and expect it to make them all.

GLM 5.3 Flash was the killer for me. It really feels like we have Claude-approaching models at home.

I just wish they kept parameter count down in order to fit entirely within commonly used RAM sizes

This never happens on the deepseek api. It’s always a different provider using lower quants.

All of these flash models have this. You have to build your harness so that it deals with it. Infinite loops are solved by having an error message that says what to do differently on failure, invalid tool calls are solved by making the tool schema less strict and detect things in the runtime etc.

Hallucinations you can't fix. Gemini is a bit worse there than DeepSeek, but there's not much research on how to fix that. The only one is the CaMeL paper by Google, where you tag every prompt and result and then for every assistant response or tool call you first check where it got that data and error if you notice fabrication. This one is really annoying to implement.

With larger models the fabrication starts when the context grows or if you have too many tools, for flash models it's much earlier. We use the flash models for repetitive agentic tasks, where the prompt defines clearly what to do and how. The whole run is about 4-5 steps typically, and context size stays in the comfort zone.

I have used the flash model for over 3b tokens and ofc. I saw some hallucinations and premature termination (I also get this on Astra - way more often than with deepseek v4 flash), but I never had a infinite loop (using the copilot as harness).

I used a lot V4 flash to implement plans built by other models, and it was honestly top notch. The thing was a workhorse, and I got none of the isuses you describe.

I was mostly using DeepSeek on Pi, connecting to their API directly (not some third party provider).

I honestly have more issues steering Sonnet properly.

That may be an issue with the harness you are using, i've never, and never heard of, someone having this problem specifically with this model.

disagree; been using flash as my exclusive model to build a complicated software project, a web engine. See https://github.com/gterzian/formal-web, which as you can see comes with very specific guidance explaining how to implement features according to web standards, as well as various pi extensions that need to be used as part of that work, and it all works not just fine but great with flash. Switching to 4.1 today...

You see this on Reddit where the bot accounts will just comment in German, French or Italian randomly (and other bot accounts responding to it won't even bat an eye, responding in English as if it's the most natural thing in the world)

Very odd. I've used DeepSeek heavily for some weeks, and haven't seen a single Chinese character either in its replies or its thinking. Are you using a quantified model or a different provider by any chance?

Deepseek already has 2x peak pricing. This is just going to be cheaper across the board.

Take a look at the answer below, please. :)

A month ago new V4 Flash 0731 checkpoint was better than existing V4 Pro. They've kept serving Pro, it was updated 13 days later (0813 checkpoint).

Now, 4 weeks later new Flash checkpoint (0910?) is again better than existing Pro. Same situation, but Pro is taken offline this time.

They could raise prices, if capacity is problem

Absolutely nobody commenting that has done that, it's just roleplay. Flash-0731 and Pro-0813 replaced previous models too, and the V4-preview models replaced V3.2 before that. You have your official API from a tiny cutting edge research lab that can only realistically host one model at a time, which you know from every model they released before, but they fully openly provide every model so if you want that infinite stability you can easily host it yourself for eternity. So those commenters want to pretend they require RHEL-like stability for their prompts with enterprise budgets, but somehow can't host those models, yet at the same time offload their entire RHEL-stability requirements to the research lab. Even Google and OpenAI retire models that were still relevant a year ago, but open models actually last forever.

4.1 releases tomorrow, right now you're supposed to be served by same old model

Nope, strong disagree. The model is one small part of the process harness; behaviors are usually routable with expected propensities. Unexpected model changes avoiding change management messes with monitoring and observability thresholds. Stochastic controls are a real thing when you have your distributions defined; your workflows on a new model will throw that expected prior out the window.

They’re nondeterministic at a fine level, but can be “deterministic” at a more general level: e.g. you might know that one model will always return properly formatted json when asked. That might not be true of the replacement, even if it is in general “better” and cheaper.

Just the risk of such a thing means regression testing every time you update the model, and you want to be able to run that testing on your schedule rather than having it forced on you.

Models are not deterministic, but they do have a flavor. When that flavor changes it can change the nature of output in a way that is undesirable.

Sort of like shooting a rifle - where the bullets hit is (to some order of magnitude, no philosophizing please) non-deterministic, but different very similar rifles will group differently and need to be appropriately adjusted to hit anything.

That's a narrow take. Non-deterministic doesn't mean random; workflows can be reasonably validated and consistent to some known degree.

I work for an education department that serves a chatbot for students, and model changes go through painstaking content safety reviews. I initially assumed it's just a bunch of bureaucratic paranoia. But every other model upgrade has a measurably different adherence to the existing system prompts about not talking to the kids about sex and drugs and mental health issues.

A dice roll is non-deterministic.

Replacing a six-sided die for an eight-sided die also keeps rolls non-deterministic.

That doesn't mean it's fine to just replace the dice mid-game.

Crossing the street and Russian roulette both have non-deterministic risks of injury. And yet I would be bothered to find out that that on my way to work, I was playing Russian roulette by surprise.

    > those things are not deterministic

Determinism was an explicit goal of DeepSeek-V4. From their paper: https://arxiv.org/html/2606.19348v1#S3.SS3

    > we implement end-to-end, bitwise batch-invariant, and deterministic kernels with minimal performance overhead

Of course, providers may not implement deterministic inference for various reasons, but it is possible.

The user cares about the distribution of outputs. That distribution is structurally determined by the distribution of inputs (i.e. prompts), the weights of the model, and (these days) the dynamics of the harness guiding successive generations.

The only way to characterize whether a choice is 'right' is to characterize the output distribution (i.e. evals)! Changing the underlying weights necessarily invalidates whatever characterization may have been done. One may assert that one's harness regularizes outputs back toward the desirable distribution, or one may hope the different weights induce a sufficiently similar output distribution.

But no, one should not be completely agnostic to the choice of weights just because there's some nondeterminism.

These models have specific behavioral characteristics trained into them from reinforcement learning and prompts optimized for one aren't guaranteed to transfer to the new generation. Think if the difference between gpt 5.4 and 5.5 and then 5.5 to 5.6 for example. 5.5 was "better" than 5.4 for struggled more across compaction boundaries and needed much more precise instructions before 5.6 sol recovered some of 5.4's ergonomics. All from the same lab but each model was trained with specific behavioral patterns that were basically product decisions. I would be quite annoyed to find that a model provider was routing a promt optimized for one model to a different one, especially for a dumber/cheaper non frontier model that's not going to be as good at just figuring out what you meant

It’s like being told one day that one of your teammates will be replaced tomorrow by another teammate who’s more capable (has a higher test score), regardless of how long you’ve already worked together and gotten used to each other.

In deterministic scenarios, this kind of switch can sometimes actually be safe, because we’ve used various engineering techniques to converge from non-deterministic behavior to deterministic decisions. On the other hand, in scenarios that are inherently non-deterministic, the impact of such a change is much harder to predict, so we need comprehensive evaluations to assess the extent of its impact.

Yes you can and you should. Providers have SLAs for when models roll off support and this has been the case for APIs long before LLMs. For example https://platform.claude.com/docs/en/about-claude/model-depre... and https://developers.openai.com/api/docs/deprecations

Yes exactly. Automatic model downgrade seems horrible for a lot of production workloads, even if you are deterministically constraining the behavior of your agents.

Strict determinism is a different, but related, issue.

E.g. if I've written a role playing character using a specific model I may want to pin the character to that model until I've been able to test the model being "better" doesn't affect the feel of the character before switching. That doesn't mean I need the character's responses to be completely deterministic, but that doesn't imply I'm fine with the character having a different quality or feel of response just because the new model is out.

It'd be nice if there was a more explicit way to signal in the request "I want what you think is best per dollar for this class of answer" vs "I want this model to answer".

Because we care about the distribution of the outputs and how that impacts a specific use case.

It'd be very expensive to get a setup that can run non-flash well.

If they were still at original price I'd get a couple of DGX Sparks myself to run Flash models at a decent quant/context combo.

> I'm not sure that anyone is running production workloads against an API that bills twice as much for a chunk of the day.

I'm not sure that anyone will mind running production workloads against an API that bills half as much for a chunk of the day.