The ISTA Deep Algorithms and Systems Lab has released three GGUF builds of DeepSeek-V4.1-Flash-1017, a sparse mixture-of-experts model with 763.2 billion parameters, 384 routed experts per layer and 6 active experts per token. The news is not just the scale: the entire architecture can be served on a single NVIDIA GPU with 12 GB of VRAM. The three files use GSQ and RCO quantization and bring the backbone to 1.75, 2.00, and 2.25 bits per weight, with sizes between 120.7 and 155.2 GB. A shared Engram file of 110.6 GB, identical for every build, needs to be downloaded only once.

The most relevant technical point is not compression itself, but the separation between the dense path and the routed experts. GSQ jointly learns grid assignments and group scales, closing most of the gap between scalar and vector quantization at very low bit-widths. RCO assigns a quantization type to every backbone tensor under the target budget, with separate ladders for dense weights (Q5_K–Q8_0) and routed experts (IQ1_S–IQ3_S). The average bit-width is computed over the 551.9 billion backbone parameters: this is what the search controls directly.

The other element is the Engram. The two lookup tables with 196.6 billion parameters remain in IQ4_NL and are read one row per token: they stay memory-mapped on disk, not fully loaded into VRAM. This shifts the constraint. There is no need to keep the entire model in VRAM, but the storage system must sustain relatively frequent accesses. For anyone evaluating self-hosted or on-premise deployment, this changes capacity planning: the GPU remains small, while storage I/O speed and disk latency become part of the inference pipeline.

On benchmarks, at 2.00 bpw the model matches the base version on every evaluated test: AIME25 100.00, GPQA-Diamond 90.91, LiveCodeBench v6 89.71. The IQ1_M build at 1.75 bpw retains 98.7% of the task average, with GPQA-Diamond at 88.38 versus 90.91 and LiveCodeBench at 88.57 versus 89.71. Results for the IQ2_XS build at 2.25 bpw are still to come.

There is an operational constraint: llama.cpp does not support DeepSeek-V4.1 yet, so the files do not run there for now. Anyone who wants to try them today has to use Strata, which serves every build on a single GPU with 12 GB of VRAM through a one-click installer and an OpenAI-compatible endpoint on localhost. This introduces a dependency on a specific runtime, even though the repository publishes the full per-tensor RCO allocation for all 1008 tensors in every build. For teams that need data sovereignty and deployment control, this is relevant: hardware cost drops sharply, but framework compatibility becomes the new critical point. It is not a linear reduction in TCO; it is a shift of cost toward storage, integration, and serving maintenance. Those hoping to use the model on a standard llama.cpp stack will have to wait.