September 10, 2026 · 8 min read

Can You Run DeepSeek V4.1 Flash Locally? The Honest Hardware Math

Short answer: not today, and the reason is not your graphics card. There are two walls. The smallest quantised build on the Hub right now is 168.9 GB, and no released runtime can execute any of these files yet. The llama.cpp work is a draft pull request that opened on the same day as the weights.

That is the honest version. The rest of this page is the arithmetic behind it, checked against the actual files and the actual pull request rather than the announcement.

What landed, and when

DeepSeek published the weights for DeepSeek-V4.1-Flash on Hugging Face on 10 September 2026 at 02:17 UTC, under the MIT licence, with no gate and no access form. That matters more than it sounds: MIT means commercial use, modification and redistribution without asking anyone.

The checkpoint is 48 safetensors shards totalling 510.3 GB. It is not a plain FP8 dump either. The routed experts are stored at FP4 inside an otherwise FP8 checkpoint, which is why the file size does not divide neatly by the parameter count.

DeepSeek V4.1 Flash
Backbone parameters552 billion
Active per token8 billion in prefill, 16 billion in decode
Experts1 shared, 384 routed, 6 routed active
Context window1,048,576 tokens
Original weights510.3 GB across 48 files
LicenceMIT
Reads imagesYes, natively

The number that fools people

Eight billion active parameters during prefill, sixteen billion during decode. Those figures are real and they are the point of the architecture, but they describe compute per token, not memory. Every one of the 552 billion backbone parameters has to be somewhere the model can reach, because the router picks a different six experts for the next token than it picked for this one.

There is a second store on top of that. DeepSeek calls it Engram, a conditional memory of 196 billion parameters that is looked up sparsely by token. It is part of the checkpoint and it is not small.

So the rule from every other mixture of experts release holds here too: active parameters decide how fast it runs, resident weights decide whether it starts at all.

What the quants actually weigh

Community quantisation started within hours of the drop. These are measured file sizes from the Hub, added up per build, on the evening of 10 September 2026.

BuildSizeNotes
Original, FP8 with FP4 experts510.3 GB48 shards, DeepSeek's own
MLX, 2 bit with MTP238.8 GBfor Apple silicon
GGUF Q2_K191.8 GB7 shards
GGUF mixed, IQ2_XXS gate and up, Q2_K down168.9 GBsmallest published so far

The smallest of them averages 2.25 bits per weight across the routed experts. That is aggressive, and the author of that build says openly that it was quantised without an importance matrix, on a constant unit importance vector, as a memory bounded choice rather than a calibrated one. Two bit weights without calibration cost quality in ways that are hard to predict from the file size.

The wall nobody puts in the headline

You can download 168.9 GB. You cannot run it.

Support for this architecture lives in llama.cpp pull request 28696, titled "convert : add DeepSeek V4.1 (DeepseekV41ForCausalLM)". It opened on 10 September 2026 at 10:23 UTC, about eight hours after the weights, and at the time of writing it is still marked draft and not merged. Read the title carefully: it is a convert pull request. It teaches the converter how to turn the checkpoint into a GGUF. Being able to write the file and being able to execute it are two different pieces of work.

The person who published the mixed two bit build says the same thing in plainer words on the model card: it is a weights artifact, and no runtime has yet been shown to execute it end to end. That sentence is doing a lot of work, and it is the most useful sentence written about this model so far.

This is normal for day one. GLM-5.3-Flash sat behind an unmerged pull request for the same reason two weeks ago. It usually resolves in days or weeks. It has not resolved yet.

One trap if you convert it yourself

DeepSeek V4.1 stores its FP8 block scales in 32 by 32 blocks. DeepSeek V4 used 128 by 128. If a converter carries the old value across, every weight in the model is silently rescaled. You do not get an error. You get a file that loads, runs, and produces confident nonsense, which is the worst failure mode there is because it looks like a model problem rather than a conversion problem.

If you see token soup out of a self converted build, check the block size before you blame the quant.

What machine would hold it, when the runtime lands

Take the 168.9 GB build as the floor. Weights are not the whole bill: you also need room for the context and for the runtime itself, so a machine with exactly 192 GB of unified memory is going to be uncomfortable and a 256 GB machine is the first honest fit. The 191.8 GB Q2_K build needs 256 GB outright. At four bit, which is where quality usually stops hurting, you are looking at something over 300 GB and there is no such build published yet.

The context is the one piece of good news, and it is a big one. The whole architecture exists to shrink the KV cache, and DeepSeek puts the global cache at 890 bytes per token. A full million token context is therefore about 930 MB of cache. On most large models the context is what kills the machine. Here it is a rounding error next to the weights.

What to run locally instead, today

If the goal is a capable model on hardware you own, these three actually run, and we have measured hardware pages for each:

Locally Uncensored runs all three on Windows and Linux with nothing sent anywhere: the models sit on your disk, the chat stays in your machine, and there is no account in the way.

And if you want this model in particular

Then it is a hosted model for now, the same way Qwen 3.8 was until its open checkpoint hit HuggingFace on 12 August. LU Labs Cloud carries DeepSeek V4.1 Flash from 10 September, on every plan and on a credit pack with no subscription, alongside the rest of the chat catalogue. The Think switch stays on for this one, because we measured it and the off signal does not save anything: the model keeps reasoning and the monologue moves into the answer instead.

When the runtime lands, this page gets the numbers that matter: real tokens per second on real machines, not a table of file sizes.

Questions people are actually asking

Can I run DeepSeek V4.1 Flash on a 24 GB graphics card?

No. The smallest published build is 168.9 GB and every routed expert has to be reachable, so a single consumer card is not the unit of measurement here. Offloading to system RAM does not fix it either at this size.

Does it work in llama.cpp or Ollama?

Not yet. The convert support is llama.cpp pull request 28696, opened 10 September 2026 and still a draft. Ollama follows llama.cpp, so it is downstream of that work. Check the pull request before you rebuild anything, since this moves quickly.

Is DeepSeek V4.1 Flash open source?

The weights are MIT licensed, which is as permissive as these releases get: commercial use, modification and redistribution are all allowed. The training data and the training code are not published, so it is open weights rather than open source in the strict sense.

Is there an uncensored version?

Abliterated repositories appeared within hours of the drop, as they do for every notable release. They sit behind exactly the same wall as the official checkpoint: nothing can execute them yet. Judge them when there is a runtime and someone has actually measured refusal behaviour, not from a repository name.

How much context can it really hold?

One million tokens, and unusually for a model this size the context is not what stops you. The global KV cache is 890 bytes per token, so a full million token window is roughly 930 MB. The weights are the problem, not the window.

Run the models that actually fit your machine, privately and uncensored.

Get Started on GitHub