V4 Flash came out in late April. The 0731 checkpoint is the beta DeepSeek shipped on July 31 — same model, newer weights — and the GGUF builds for it landed in the antirez repo the same week. The release also bundles the tooling that makes the model practical on consumer hardware: a speculative-decoding draft model called DSpark, native MXFP4 weights, and GGUF files sized for machines with 96-128 GB of memory.
This is a good model for its size, not a “frontier” model, whatever that word means these days. It’s strong enough to be useful while running on hardware that isn’t a data center.
The 0731 Checkpoint/Release
For the users of the ds4 inference engine, the “0731” is a date-stamped GGUF tag — chat-v2-imatrix-0731 — on the antirez/deepseek-v4-gguf Hugging Face repo. DeepSeek released V4-Flash as a preview in late April, then followed with a beta checkpoint on July 31; the 0731 files in the GGUF repo are that beta, converted for DwarfStar.
V4 Flash is a Mixture-of-Experts model: ~284 billion total parameters, only ~13 billion active per token, MIT-licensed, up to 1 million tokens of context. The 0731 checkpoint is the same model with the updated weights obtained by post training.
The post training allegedly improved benchmark performance, the model card claims great improvements.
If the numbers hold up, it’s a fantastic model for local AI. It won’t beat much larger models on every benchmark, and it doesn’t need to. What matters is the combination: decent capability per parameter, plus a deployment path that doesn’t require a cluster.
Speeding up inference: DSpark
The most interesting part of DeepSeek V4 model family is DSpark, DeepSeek’s draft model for speculative decoding. The idea is simple: most tokens in a sequence are predictable, so there’s no reason to spend expensive compute on all of them.
DSpark reads the hidden states from the main V4 Flash model and proposes up to five future tokens in one step. DS4 checks those candidates against the authoritative Flash model and keeps only the accepted prefix. The main model stays in charge; DSpark is a speed-up, not a quality change.
It buys latency on generation, where token-by-token autoregressive work dominates. Because it rides on the main model’s hidden states rather than running its own forward pass, it adds a fraction of the memory and compute a second model would.
In my own machine running ds4, I sadly see no token generation speed improvements, even though I tried different parameter combinations, so be aware.
Native MXFP4
Quantization is where the “can I run it?” answer comes from. The 0731 release adds an mxfp4 tier at about 156 GB, built from DeepSeek’s released MXFP4 routed-expert weights and preserved as-is instead of re-quantized.
That matters two ways. On Blackwell CUDA, DS4 uses native FP4 matrix instructions with FP4 activations, so the hardware speaks the model’s native format. On other CUDA targets it falls back to Q8 activations. Either way, the weights stay in the format DeepSeek shipped, which avoids the quality loss of a second quantization pass.
The mxfp4 tier joins the existing ladder:
| Tier |
Size |
Best for |
| q2 |
~87 GB |
96-128 GB RAM machines |
| q2-q4 |
~98 GB |
96-128 GB RAM machines (last 6 expert layers at Q4) |
| mxfp4 |
~156 GB |
192+ GB machines, native FP4 |
| q4 |
~165 GB |
192+ GB RAM machines |
The Hugging Face files line up with those tiers: the IQ2XXS build at ~86.7 GB, a Layers37-42Q4KExperts variant at ~97.6 GB that keeps the last six expert layers at higher precision, and a DSpark-support file at ~6 GB for the draft-model path.
A note on those sizes: the repo’s own README quotes lower numbers, calling the q2 tier “81 GB” and the q2-q4 “91 GB”, while the Hugging Face file listing shows 86.7 GB and 97.6 GB. The README numbers are loose GiB-style rounding; trust the file listing if you’re budgeting RAM.
Distributed Prefill
The 0731 release also points at the distributed story if someone is lucky to have multiple of those fairly expensive machines. DS4’s prefill path is pipelined, so splitting transformer layers across machines pays off in a way generation can’t. The measured numbers for two MacBooks doing parallel decoding:
| Prompt size (tokens) |
Prefill speedup |
| 9,421 |
1.38x |
| 28,684 |
1.66x |
| 63,819 |
1.85x |
The speedup grows with prompt length, which is exactly where single-machine prefill hurts most. Generation stays autoregressive and doesn’t parallelize the same way, but for long-context work the prefill win is the win.
One caveat I want to flag: those multipliers come from the README’s two-M5-Max benchmark, and the comparison isn’t perfectly apples-to-apples. The two-machine run used the Q4 GGUF, while the single-machine reference used the smaller Q2 GGUF, so the “single-process” baseline was already running a lighter model. The trend is real — longer prompts parallelize better — but the exact speedups are a bit flattering to the two-machine setup.
Local AI options are steadily improving
The 0731 release makes a solid local option out of what was mostly a spec sheet.
The RAM requirements are reduced. A ~87-98 GB quantized run fits in a 96-128 GB machine — a top-tier MacBook Pro or a DGX Spark-class system. For a model this size, that’s a real step down in what you need to own.
Speculative decoding makes it feel faster. DSpark works on the autoregressive bottleneck, so the model’s quality doesn’t cost you interactive latency. Local reasoning stops feeling like a compromise.
Native formats keep quality. MXFP4 shipped as-is, with Blackwell FP4 instructions, skips the second-quantization tax. You run closer to what DeepSeek released.
The MoE architecture carries inference in unified memory machines like the Mac Studio and DGX Spark: 13 billion active parameters per token means the compute is modest even when the memory is large. That’s what makes a ~284B model feel like a practical local deployment rather than a spec-sheet curiosity.
Hardware Is Super Expensive in 2026
As of August 2026, a 96-128 GB unified-memory machine is not budget equipment — a top-tier MacBook Pro or a DGX Spark-class system can cost between 4000 to 5000 USD. The AI buildout has sucked the memory market dry: TrendForce was warning of 45% price hikes a year ago, and the numbers since have been grim. A 32GB DDR5 kit that went for about $90 on Prime Day last July now lists around $460, and Micron wound up its whole consumer Crucial line to feed the AI data centers. For the average user, the entry point is expensive, no matter how efficient the model or the engine.
The usual tradeoffs apply too. The aggressive 2-bit tier still gives up something on the hardest long-context retrieval and precise numerical reasoning. And the whole stack is tuned to the DS4 engine and DeepSeek’s published GGUF files, so it’s an opinionated path, not a general loader.
None of that makes the release less interesting. It just keeps the “run it locally” story honest: good for its size, runnable on consumer hardware, and the hardware is the gate.
Getting Started
If you want to try it:
git clone https://github.com/antirez/ds4
cd ds4
make # macOS Metal, or: make cuda-generic # Linux CUDA
./download_model.sh ds4f-q2 # ~87 GB tier, or ds4f-q2-q4 / ds4f-mxfp4
# add the DSpark-support GGUF for speculative decoding
./ds4
One correction to the obvious path: the download script’s target for the q2 tier is ds4f-q2, not q2-imatrix — the repo renamed its targets when it added the 0731 builds. The README lists ds4f-q2, ds4f-q2-q4, ds4f-q4, ds4f-mxfp4, and ds4f-dspark.
Start with the q2 tier if you have 96-128 GB. Add DSpark for the latency win. Move to mxfp4 if your machine and budget allow, and watch the two-MacBook prefill numbers if you’ve got a second box lying around.
The hardware is the gate, and in 2026 the gate is fortified. If you’re already sitting on a 96-128 GB machine, this is a genuinely useful model to have locally.
Thoughts on Local AI
I’ve seen media figures such as content producers claiming the local AI crowd is flat out delusional, claiming there is no point in using local AI. The reasoning is that paying a subscription to a frontier AI lab is a far better economic proposition.
It cannot be disputed that for a number of use cases it makes more sense to use vendor APIs. The higher the stakes and the quicker one has to move determines what’s the best option.
If you don’t or can’t have your data leaving your network, and you can work slower, local AI can be quite capable and that is my experience using it as an editor and assistant system.
It’s slower, and the model is less capable than a frontier lab, but good for my personal use case. Sometimes we forget how far this technology evolved in the last couple of years.
Know what you’re optimizing for and your needs. That helps you decide where on the fully local - fully remote frontier you want to be.
Let’s all relax and be happy with our choices :)