---

license: mit

license_link: LICENSE

base_model: deepseek-ai/DeepSeek-V4.1-Flash-1017

base_model_relation: quantized

tags:

- gguf

- deepseek

- deepseek-v4.1

- metal

- ixv

language:

- ja

- en

---

DeepSeek-V4.1-Flash-1017-ELVEZ-Q2 (GGUF)

DeepSeek-V4.1-Flash-1017-IQ2_XXS-Q2_K-imatrix.gguf — a 2-bit-expert quantization of

deepseek-ai/DeepSeek-V4.1-Flash-1017, made by ELVEZ

from the official weights, with an 8,192-token activation imatrix. DeepSeek-V4.1-Flash-1017-Vision.gguf is the

matching vision encoder, and DeepSeek-V4.1-Flash-1017-DSpark.gguf the matching DSpark draft head for speculative

decoding (added 2026-10-19).

DeepSeek released the 1017 weights on 2026-10-17 as a minor update of DeepSeek-V4.1-Flash. The architecture,

tokenizer and prompt encoding are unchanged, but the language and vision weights changed, so earlier V4.1 Flash

GGUFs cannot be reused for 1017.

This is the DeepSeek V4.1 Flash model that IXV — ELVEZ's AI development distribution for software

development in Japan — runs on a Mac Studio. It is published here so that anyone can check how it was made and what

we measured.

This card records what we measured and what we have not. Everything here is as of 2026-10-18, except the DSpark

file and its section, added on 2026-10-19.

> Runtime. We have run these files only on IXV's engine (ixv-server), with Metal on an M3 Ultra. The GGUF

> stores the Engram tables in a layout of its own (see below), so it is not a general-purpose GGUF. The llama.cpp,

> Ollama and other snippets in the "Use this model" menu are generated by Hugging Face for every GGUF; we have not

> tested any of them, and we do not expect them to work. See Compatibility.

日本語の概要は末尾にあります。

Files

| File | Size | SHA-256 |

|---|---:|---|

| DeepSeek-V4.1-Flash-1017-IQ2_XXS-Q2_K-imatrix.gguf | 365,713,686,528 bytes | e782308bdf255cf96c36438d7e6e88f2f7e5aeac2be391a786ac714728b8edad |

| DeepSeek-V4.1-Flash-1017-Vision.gguf | 970,555,552 bytes | 68b4f292441dac422e9f904f3a120ee955d0e303ebf3455a39d8606f60cb8602 |

| DeepSeek-V4.1-Flash-1017-DSpark.gguf | 7,935,279,104 bytes | 4f85722c85591bfc022933947cc19673345aea1a202ace11e96db9f99072813b |

What is in the file

| Tensors | Type |

|---|---|

| Routed experts, gate and up | IQ2_XXS (imatrix-weighted) |

| Routed experts, down | Q2_K (imatrix-weighted) |

| Attention projections, shared experts, output head | Q8_0 |

| Norms, router and other small tensors | F16 / F32 as in the recipe |

| Engram tables | the official FP8 values and scales, unchanged, packed at the end of the file (188.8 GiB) |

• 1,046 tensors. The main weights that stay in memory are about 151.8 GiB; the engine reads only the Engram rows it

needs from disk.

• The MTP (speculative) layers of the official checkpoint are not in this file; they are the separate DSpark file

below.

• The vision encoder keeps all 266 tensors in BF16, byte for byte from the official checkpoint.
• The recipe is the same as the upstream V4.1 Flash Q2 recipe (antirez/ds4 gguf-tools), which IXV imported.

DSpark draft head

DeepSeek-V4.1-Flash-1017-DSpark.gguf holds the official checkpoint's DSpark draft head: the three mtp.* stages

in shards 44-46 (5 draft tokens, for layers 37-39). It is used together with the main GGUF above, which provides the

shared token embedding and output head, and is not a model on its own.

| Tensors | Type |

|---|---|

| Attention, shared expert, main_proj, Markov head | Q8_0 (as the main GGUF uses for the same roles) |

| Routed experts (FP4 + E8M0 per 32) | MXFP4, a lossless repack of the official values |

| hc_*_fn, Markov embedding | F16 |

| Norms, router, biases, confidence head and other small tensors | F32 (exact) |

• 81 tensors. Made with IXV tools/gguf/deepseek41_dspark.py, a tool ELVEZ wrote for IXV, from the official

shards 44-46 at revision 1bae0e10… (recorded in the GGUF with the SHA-256 of the three shards).

• Checked with deepseek41_dspark.py --validate --verify-payload against the official shards: MXFP4 and F32

payloads equal the source, F16 equals the source rounded to nearest, and Q8_0 equals a fresh encode with the same

quantizer, for all 81 tensors.

• The output does not change. IXV accepts a drafted token only when it is the token the full model picks, so

the answers with and without DSpark are byte-identical. We checked this on IXV's golden sets (7 CLI, 11 server and

15 image cases).

Speed on the M3 Ultra with IXV (runtime 0420c8d8, server arguments as in production, one round of 3 runs each,

temperature 0, thinking off):

| Prompt | Without DSpark | With DSpark | Draft acceptance |

|---|---:|---:|---:|

| Short (27 tokens) | 35.96 tok/s | 47.14 tok/s (1.31×) | 68% |

| ~6.3k tokens | 35.77 tok/s | 42.27 tok/s (1.18×) | 64% |

| ~38.8k tokens | 34.06 tok/s | 36.94 tok/s (1.08×) | 61% |

The gain is smaller for long prompts and with thinking on (about 1.1× in IXV's DSpark measurement), because fewer

drafts are accepted. We have not yet measured it at temperature 1.0, DeepSeek's recommended setting, where we expect

a smaller gain for the same reason. Prompt processing is not affected.

Provenance

| | |

|---|---|

| Base model | deepseek-ai/DeepSeek-V4.1-Flash-1017, revision 1bae0e1088993b9b82de08f59de5be5a34e42170 (recorded in the GGUF's general.source.revision), MIT license |

| Converter | IXV tools/gguf/deepseek41_quantize.py and deepseek41_vision.py, imported from antirez/ds4 gguf-tools (commit 9139e2ae58a41503968a500f36f75895c1ba63fc, MIT) with only names changed; deepseek41_dspark.py (DSpark file), written for IXV |

| imatrix | 8,192 tokens, collected on a first (non-imatrix) conversion of the same weights; 14,931 of 15,360 routed experts observed (97.21%) |

How it was made

deepseek41_quantize.py --hf DeepSeek-V4.1-Flash-1017 --source-revision 1bae0e10… --out <bootstrap>.gguf
<engine> -m <bootstrap>.gguf --imatrix-dataset <prompts> --imatrix-out imatrix.dat --imatrix-max-tokens 8192
deepseek41_quantize.py --hf DeepSeek-V4.1-Flash-1017 --source-revision 1bae0e10… --imatrix imatrix.dat --out DeepSeek-V4.1-Flash-1017-IQ2_XXS-Q2_K-imatrix.gguf
deepseek41_vision.py --hf DeepSeek-V4.1-Flash-1017 --out DeepSeek-V4.1-Flash-1017-Vision.gguf
deepseek41_dspark.py --hf DeepSeek-V4.1-Flash-1017 --source-revision 1bae0e10… --out DeepSeek-V4.1-Flash-1017-DSpark.gguf

• The final file was made from the official safetensors, not by requantizing the first file.
• Calibration prompts: a subset of the upstream calibration set (code, tool calls, reasoning, multilingual prose,

translation; both thinking and non-thinking), chosen round-robin by category with a fixed seed. Reading the first

prompts in order covered only 89.40% of the experts; spreading the subset across categories and languages raised

it to 97.21%. The upstream V4.1 Flash Q2 reports 97.15% with the same token budget.

• Experts that the imatrix never observed (1,288 expert slots in total) keep the non-imatrix quantization.
• Both files were checked against the official weights with the validators (deepseek41_validate_gguf.py --payload

and deepseek41_vision.py --verify-payload): all 1,046 tensor layouts and payloads, and all 266 vision tensors

byte for byte.

• Conversion took 69 minutes on the M3 Ultra (24 threads).
• On the day it was imported, IXV's converter produced byte-identical plans and tensor encodings to the upstream tool

for this checkpoint.

Compatibility

Tested:

• IXV's engine (ixv-server, runtime 912a7860), Metal backend, Mac Studio M3 Ultra 512 GB, macOS 27,

--ctx 65536 --batched-session 1, with the vision encoder (--vision).

• With the DSpark file (--dspark): IXV runtime 0420c8d8 and later, same machine, --ctx 131072.

Not tested:

• Upstream antirez/ds4.
• llama.cpp or other GGUF runtimes. The architecture is deepseek41, and the Engram tables use a layout of our own.
• CUDA / ROCm, SSD streaming, tensor parallelism, other Apple Silicon generations.

Evaluation

One machine (Mac Studio M3 Ultra 512 GB), IXV runtime 5e30513c for quality and 912a7860 for the speed below,

2026-10-18. We did not compare against another quantization of the 1017 weights on the same machine; the

"reference" column is an earlier V4.1 Flash (not 1017) measurement on a different machine and engine, for orientation

only.

Speed (decode, 3 runs each, no prompt cache)

| Prompt | This file |

|---|---:|

| Short Japanese prompt (27 tokens, 300 generated) | 36.1 tok/s |

| ~6.3k-token prompt | 35.9 tok/s (prefill about 18.5 s) |

Quality

| Test | This file | Reference (V4.1 Flash, not 1017) |

|---|---:|---:|

| Japanese knowledge QA, 48 questions (thinking off) | 46/48 | 43/48 (upstream Q2, other machine and engine) |

| HumanEval, 164 problems (chat, thinking on, max 16,384 tokens) | 152/164 (92.7%) | 98.2% (upstream Q4) |

| Japanese long-form writing, 6 prompts, max 4,096 tokens, judged by Claude, /20 | 13.0 (19.5 over the 4 answered) | — |

| Number test, 20 questions (sums, powers, readings in 万・億, values read from files; tools on) | 20/20 | — |

| Image cases, 15 (charts, diagrams, a photo, Japanese UI text, screenshots, two images, image in a tool result) | 15/15 correct | — |

Notes on the quality results:

• The model sometimes thinks until the token limit and never answers. This is the main weakness we saw.

9 of the 164 HumanEval problems ended with no code (all 16,384 tokens spent on thinking), and 2 of the 6 long-form

prompts gave no text at 4,096 tokens. At 16,384 tokens one of the two then gave an essay (scored 18/20) and the

other still gave no text. Excluding the 9 problems, HumanEval was 152/155.

• HumanEval formatting. The raw score was 0.6%: chat answers start the function body without indentation. As in

our standard procedure we re-indented only the problems that failed raw. The earlier V4.1 Flash Q4 measurement

behaved the same way.

• Long-form. The four answered prompts scored 20, 19, 19 and 20 (the email is template-like with many ○○

placeholders).

• Images. In one image-plus-tools request the model called the right tool but wrote its one-line preamble in

English.

• The Japanese QA and long-form prompts and the number test are ELVEZ's internal evaluation sets and are not published.

Limitations

• One machine, one evaluation session. Small test sets (48 QA questions, 6 long-form prompts, 20 number questions,

15 image cases).

• No same-machine comparison with another quantization of the 1017 weights.
• The tendency to think until the limit depends on the request and on the thinking settings; we have not yet

measured how lower reasoning effort changes it.

• This is not a release by DeepSeek or antirez. Please report problems with these files to us, not to them.

License

MIT, following the base model deepseek-ai/DeepSeek-V4.1-Flash-1017.

Credits

• DeepSeek — DeepSeek-V4.1-Flash-1017.
• antirez — ds4 and its gguf-tools (the V4.1 Flash conversion recipe and the quantizers), which IXV imported.
• ELVEZ Inc. / 株式会社エルブズ — conversion, imatrix calibration and evaluation.

The conversion, evaluation and this card were prepared with Claude Code (Anthropic) and reviewed by ELVEZ.

日本語の概要

• エルブズの AI開発ディストリビューション IXV が、Mac Studio で使う DeepSeek V4.1 Flash のモデルです。作り方と測ったことを誰でも確かめられるよう、ここで公開しています。
• DeepSeek が 2026-10-17 に公開した DeepSeek-V4.1-Flash-1017 の公式の重みから、エルブズが量子化しました（専門家は IQ2_XXS・Q2_K、8,192 トークンの imatrix、専門家の 97.21% を観測）。画像を読む部品（DeepSeek-V4.1-Flash-1017-Vision.gguf）も 1017 から作りました。1017 では画像の重みも変わっているため、以前の V4.1 Flash 用の GGUF は使えません。
• Mac Studio（M3 Ultra、512 GB）の IXV で、生成は約 36 tok/s でした。
• 日本語知識 QA 46/48、HumanEval 152/164、数字の試験 20/20、画像 15/15 でした。一方で、考え続けて上限に達し、答えを書かずに終わることがあります（HumanEval 9/164、長文 6題中2題）。
• 先読み（DSpark）の部品 DeepSeek-V4.1-Flash-1017-DSpark.gguf も、公式の重みの shard 44〜46 から IXV のツールで作りました（10/19 追加）。本体と一緒に使います。答えは先読みなしとバイト単位で同じで、生成は温度0で約 1.1〜1.3 倍（入力が長いほど小さい）、思考ありでは約 1.1 倍でした。温度1.0ではまだ測っていません。
• 動作を確かめたのは IXV のエンジン（Metal、M3 Ultra）だけです。Engram の表を独自の並びで持つため、llama.cpp などの一般の GGUF の実行環境では動かない見込みです。「Use this model」に出る手順は、Hugging Face がすべての GGUF に自動で表示するもので、当社では試していません。
• 変換のツールは、antirez さんの ds4 の gguf-tools を IXV に取り込んだものです。
• ライセンスは元のモデルに合わせて MIT です。