Wink Pings

Running DeepSeek-V4.1-Flash-1017 on 64GB of RAM: a 233GB package, hold off on believing it

Unsloth has released Dynamic V3.1 GGUF for DeepSeek-V4.1-Flash-1017, with a 233GB minimum; it uses an Engram table stored on SSD to bring memory requirements down to the 64GB class. Between 'it runs' and 'it works well,' there is still a 128GB RAM threshold.

Unsloth has released the GGUF for DeepSeek-V4.1-Flash-1017, Dynamic V3.1. The most eye-catching claim in the marketing is 64GB+ RAM.

DeepSeek-V4.1-Flash-1017 GGUF released by Unsloth

Let's lay out the facts first. DeepSeek officially defines 1017 as a minor version update to V4.1-Flash, but the benchmark gains are not minor: Terminal-Bench 4.0 goes from 31.2 to 42.3, DeepSWE v1.1 from 74.2 to 77.0, and HLE without tools from 36.8 to 42.6. The model card lists 763B parameters, a 1M context, and an MIT license.

DeepSeek officially releases V4.1-Flash-1017

Official benchmark comparison

Unsloth's GGUF page lists 748B parameters, with the documentation breaking this down as a 552B backbone plus 196B Engram. Engram is conditional memory, an n-gram lookup table of up to four tokens, and the table does not need to reside on the GPU. This design is the fulcrum of the 64GB claim.

But file size hasn't disappeared. The smallest 1-bit UD-IQ1_S is 233GB, 2-bit starts at 300GB, 4-bit UD-Q4_K_XL is 500.7GB, and 8-bit is 508.4GB. Unsloth's documentation itself lists memory requirements: 128 to 145GB for 1-bit, 256 to 290GB for 3-bit. The 64GB+ RAM in the tweet corresponds to putting the 110.6GB Engram table on an SSD, using mmap and lazy-mode to read on demand, and keeping only hot rows, context, and runtime in memory. It can run in 64GB, slowly. A commenter directly said that the 233GB minimum quantization makes 64GB sound very optimistic. That skepticism is half valid: between being able to start and being usable as an everyday agent, there is a gap in memory bandwidth and cache hit rate.

The install command reveals the key parameters: --load-mode mmap, --lazy-mode on, --override-tensor 'per_layer_token_embd.weight=CPU'. Put the seven shards in the same directory and point to the first one. The Engram table can be switched to different precisions: MXFP8 202.8GB, Q6_K 161.3GB, Q5_K 135.2GB, IQ4_NL 110.6GB. If you want to save memory, switch to a smaller table, at the cost of KLD and top-1 agreement.

On quantization results, Unsloth Dynamic V3.1's selling point is low loss at low bit widths. UD-Q2_K_XL is 334.8GB, with a six-benchmark average of 87.49 versus the Q8 reference of 87.68, a difference of 0.19 points; UD-IQ2_XXS gets 44.38 on Aider pass@1. IQ1_S at 233GB averages 83.53, a noticeable drop. Unsloth also publicly questions ISTA-DASLab's GSQ-RCO quantization: the other side says all quantizations score 100% on AIME25, while Unsloth ran 30 problems times 16 and says only 94.64% of the baseline is retained on average, so it cannot reproduce the result. Take this controversy with a grain of salt; choosing a quantization still depends on your task and memory.

Unsloth Dynamic V3.1 six-benchmark average

Unsloth explains the KLD part quite plainly: the goal of quantization is to make next-token prediction close to the original model, and KLD reaching 0 means fully reconstructing the logits. They tested on multiple held-out sets to rebut the claim that KLD is being gamed. You don't have to trust vendor self-testing, but at least the table gives size, KLD, and top-1 agreement, so you can work out the trade-offs yourself.

KLD comparison

The official post also demos end-to-end project generation, from games to 3D modeling.

The path to running it: Unsloth Desktop or the llama.cpp PR they maintain. Recommended settings are temperature 1.0, top_p 1.0, with top-k and min-p disabled, a context of 1,048,576 tokens, and at least 256K left for output. DSpark speculative decoding with an 8GB Q8_0 drafter is said in the docs to speed up decoding by 1.3x to 1.5x. Unsloth also claims it is 3x faster than other CPU/VRAM/ngram repositories; that number depends on hardware and offload configuration, so don't treat it as a universal constant.

Who should tinker with this now? A Mac Studio with 128GB of unified memory, a DGX Spark, or a 256GB RAM machine can seriously try 1-bit to 3-bit. A 64GB laptop can run it, but it is better for validating workflows than for running a long-context agent continuously. Ordinary users are better off using the API: the official search and fetch endpoints cost $0.75 per 1,000 calls, and server-side tool calls in DeepSeek Harness, Claude Code, and Codex are free until October 31, 2026, 16:00 UTC. Compare that price with local electricity, storage, and tinkering time and do your own math.

The real change in this update, as I see it, is that it moves the barrier for local large models from buying more memory to managing storage tiers. A 233GB file sits on the SSD, with only hot data kept in memory—sounds like something the operating system should be doing, but now the model inference stack does it itself. 64GB is the marketing line; 128GB is the comfortable line. If you want to try it, download the 1-bit version; if you want to get work done, look at 3-bit or higher and 256GB of RAM. Don't treat 64GB+ as a free lunch, and don't be scared off by 233GB—first see whether your task can tolerate the quantization loss and SSD latency.

Sources: Unsloth tweet, DeepSeek model card, Unsloth documentation.

发布时间: 2026-10-31 00:39