ISTA-DASLab/DeepSeek-V4.1-Flash-1017-GSQ-RCO-GGUF · Hugging Face

来源：https://huggingface.co/ISTA-DASLab/DeepSeek-V4.1-Flash-1017-GSQ-RCO-GGUF

基准模型与 GSQ-RCO 量化在 AIME25、GPQA-Diamond 和 LiveCodeBench v6 上的对比（https://huggingface.co/ISTA-DASLab/DeepSeek-V4.1-Flash-1017-GSQ-RCO-GGUF/blob/main/assets/plots/DeepSeek-V4.1-Flash-1017-benchmarks_bars.png）

**更新，2026 年 10 月 27 日。**这些文件现在使用 llama.cpp 自带的 DeepSeek-V4.1 布局，可在 llama.cpp b11870 或更新版本中加载，包括图像。

• **已经下载过旧文件？**无需重新下载模型。在你的模型目录下运行 convert_ds41_upstream.py：它会在本地把文件重写为当前版本，且仅下载约 80 KB。参见更新已下载的文件。

• **首次下载？**共享的 Engram 文件是每个构建的第 6 个分片，因此对你使用的每个构建（IQ1_M、IQ2_XXS 或 IQ2_XS，见llama.cpp）只需链接一次：

  ln -s DeepSeek-V4.1-Flash-Engram-IQ4_NL.gguf DeepSeek-V4.1-Flash-1017-GSQ-RCO--00006-of-00006.gguf
  

概览

本仓库提供 DeepSeek-V4.1-Flash-1017 的 GGUF 量化版本，共三种规格：IQ1_M（每权重 1.75 比特）、IQ2_XXS（2.00）和 IQ2_XS（2.25）。

与对所有权重张量统一使用同一种量化类型的均匀量化不同，这里的每个模型都为每个张量单独指定一种量化类型。该分配通过基于梯度的搜索获得：在总大小预算约束下，依据每张量的敏感度分配精度。生成的文件是标准 GGUF。

DeepSeek-V4.1-Flash-1017 是一个稀疏专家混合模型，拥有 7632 亿参数：每层 384 个路由专家，每个 token 激活 6 个，上下文窗口为 100 万 token。路由专家在参数量中占绝对主导，因此也主导了大小预算，搜索的大部分自由度都花在这里——量化类型按层分配（而非按专家分配，GGUF 无法表达后者）。借助 Strata，所有构建都能在一块显存 12 GB 的 GPU 上运行。参见使用方法。

**方法概述。**GSQ 在给定量化类型下对每个张量进行精确的低比特标量量化；RCO 在大小预算下为每个张量分配量化类型。两者结合，在目标大小下得到一个非均匀的 GGUF。

两种方法均由奥地利科学技术研究所（ISTA）的高级算法与系统实验室（DASLab）开发。

可用文件

每个构建都是由五个分片组成的核心 GGUF，以量化标识符命名：DeepSeek-V4.1-Flash-1017-GSQ-RCO--0000i-of-00006.gguf，i 从 1 到 5。第 1 个分片仅包含元数据，第 2 到 5 个分片包含 transformer 权重，共 5519 亿参数。bpw 是这些分片的平均比特宽度，也就是搜索所控制的量。

Engram 文件 DeepSeek-V4.1-Flash-Engram-IQ4_NL.gguf 以 IQ4_NL（4.50 bpw）保存模型的两张 Engram 查找表（1966 亿参数）。该文件在所有构建中完全相同，因此只存储一次，即便尝试多个构建也只需下载一次。llama.cpp 将其作为构建的第 6 个分片加载，因此每个构建都需要一个名为 ...-00006-of-00006.gguf 的链接指向它（一条命令即可，见llama.cpp）。这些表是查找表而非矩阵乘法权重，因此在每个构建中都以固定类型保存，并被排除在搜索之外。它们在被评测的模型中同样是量化的，而不只是在发布的文件中。

所有三个构建都能借助 Strata 在一块显存 12 GB 的 GPU 上运行。表中 Engram 一列在每一行都是同一个共享文件。视觉投影层 mmproj-DeepSeek-V4.1-Flash-1017-BF16.gguf（0.97 GB）同样服务于所有构建。GB 按 10⁹ 字节计算。

IQ2_XXS 是更强的工作点：它在所有三项基准上都与基准模型持平，达到其任务平均分的 100.0%（93.54）。IQ1_M 构建则以损失 1.2 分任务平均分换取少 17.5 GB 的体积。

内存需求

只有核心分片持有 transformer 权重。Engram 表以稀疏方式读取，每个 token 读取一行，因此可以保持在磁盘上的内存映射状态，无需占用显存或内存。借助 Strata，核心分片也不需要装入显存：所有构建都在一块 12 GB GPU 上运行，模型其余部分保存在系统内存中。请将 Engram 文件放在 SSD 上，以保持分页开销较低。

结果

所有模型都以基准模型 deepseek-ai/DeepSeek-V4.1-Flash-1017 的发布版本（FP8 稠密权重、FP4 路由专家）为对照进行评测。我们报告三项推理与生成基准：AIME25、GPQA-Diamond 和 LiveCodeBench v6。任务平均分为三者均值；恢复率是任务平均分相对于基准模型的比例。本卡片中所有数字均在推理强度 50 下测得。

IQ2_XXS（2.00 bpw）保留了基准模型任务平均分的 100.0%：它在 AIME25（100.00）、GPQA-Diamond（90.91）和 LiveCodeBench v6（89.71）上均与基准模型持平。IQ2_XS（2.25 bpw）在 AIME25 和 LiveCodeBench v6 上与之持平，GPQA-Diamond 得分为 90.40，整体为 99.8%。最小的构建 IQ1_M（1.75 bpw）在 AIME25 上同样取得 100.00，整体保留 98.7%。

使用方法

**运行时支持。**llama.cpp 从 b11870 版本（2026 年 10 月 25 日）起支持 DeepSeek-V4.1，包括图像；本仓库的文件自 2026 年 10 月 27 日起采用该布局。该日期之前的下载可在本地转换，参见更新已下载的文件。这些 GGUF 也支持在 Strata 中使用。

Strata 引擎

Strata 可在一块显存 12 GB 的 NVIDIA GPU 上运行这些 GGUF，提供一键安装器和 localhost 上的 OpenAI 兼容端点。这些构建是与 Strata 一起针对本地推理协同优化的。

llama.cpp

需要 llama.cpp b11870 或更新版本。

# 下载一个构建以及共享的 Engram 文件（需要：pip install -U "huggingface_hub[cli]"）
hf download ISTA-DASLab/DeepSeek-V4.1-Flash-1017-GSQ-RCO-GGUF \
  --include "*IQ2_XXS*" "*Engram*" --local-dir .

# Engram 文件是每个构建的第 6 个分片
ln -s DeepSeek-V4.1-Flash-Engram-IQ4_NL.gguf DeepSeek-V4.1-Flash-1017-GSQ-RCO-IQ2_XXS-00006-of-00006.gguf

llama-cli -m DeepSeek-V4.1-Flash-1017-GSQ-RCO-IQ2_XXS-00001-of-00006.gguf \
  -p "Explain mixed-precision quantization." -ngl 99

-m 接受第一个分片；llama.cpp 会从同一目录打开第 2 到第 6 个分片。若要试用其他构建，只需下载其分片（--include "*IQ1_M*"）并添加对应链接。在 Windows 上，mklink /H DeepSeek-V4.1-Flash-Engram-IQ4_NL.gguf 可创建硬链接；在该目录下运行 convert_ds41_upstream.py 也会创建缺失的链接。

Engram 表保持在磁盘上的内存映射状态，每个 token 读取一行（llama.cpp 默认的 --lazy-mode auto 对超过 4 GiB 的张量即如此处理），因此既不需要显存也不需要内存。参见内存需求。

图像

下载视觉投影层并通过 --mmproj 传入：

hf download ISTA-DASLab/DeepSeek-V4.1-Flash-1017-GSQ-RCO-GGUF \
  --include "mmproj-*" --local-dir .

llama-server -m DeepSeek-V4.1-Flash-1017-GSQ-RCO-IQ2_XXS-00001-of-00006.gguf \
  --mmproj mmproj-DeepSeek-V4.1-Flash-1017-BF16.gguf -ngl 99

使用 llama-mtmd-cli 时，请同时传入 --jinja，以便使用 GGUF 中内嵌的聊天模板。

聊天模板与推理强度

基准仓库不附带 Jinja 聊天模板；其提示词格式由 DeepSeek 的编码器 encoding/encoding.py 定义。这些 GGUF 内嵌了一套改编自 Unsloth 的 DeepSeek-V4.1 发布版的模板，并针对该编码器校验了文本对话、工具调用和图像格式化。

推理强度接受 1 到 100 的整数（也接受数字字符串），或 low、high、max（分别对应 50、75、100）。默认强度为 DeepSeek 的 high（75），且仅在思考模式下生效。结构化图像块（包括工具结果中的图像）会保留其图像占位符。图像推理需要视觉投影层，参见图像。

llama-server -m DeepSeek-V4.1-Flash-1017-GSQ-RCO-IQ2_XXS-00001-of-00006.gguf -ngl 99 \
  --reasoning on --reasoning-effort 50

强度 50 是本卡片所有结果的测量设置。按请求级别设置时，在 chat completion 请求体中写 "reasoning_effort": "50"（字符串形式，数字也要用字符串）。--reasoning off 可关闭思考模式。

更新已下载的文件

2026 年 10 月 27 日之前下载的文件（每个构建四个分片，外加一个单独的 DeepSeek-V4.1-Flash-Engram-IQ4_NL.gguf）是为更早的 llama.cpp 分支写的，无法在当前的 llama.cpp 中加载。convert_ds41_upstream.py 可将其逐字节转换为本仓库的当前文件，无需重新下载模型。它需要 Python 3.8+，不依赖额外的包，仅从本仓库获取两个小文件（chat_template.jinja 和 exp_probs_b_vl.f32，共 80 KB）。

cd /path/to/downloaded/model-folder
hf download ISTA-DASLab/DeepSeek-V4.1-Flash-1017-GSQ-RCO-GGUF convert_ds41_upstream.py --local-dir .
python3 convert_ds41_upstream.py .

它会转换目录中的每个构建以及 mmproj，把新的核心分片写在旧分片旁边；每个写入的张量都会被读回并与源文件比对。Engram 文件是原地转换的：只有头部会改变，其 110 GB 的表保持不变，脚本还会补上第 6 分片的链接。所需的可用空间是新分片的大小（每个构建 121 至 155 GB）。加上 --delete-old 后，一个构建的新分片一经校验就会删除其旧分片，因此只需一个构建的空间即可。新的第一个分片从 chat_template.jinja 获取聊天模板，因此不再需要 patch_chat_template.py。

量化流程

1. **逐张量数据库。**用 GSQ 将每个权重张量在每一种候选 GGUF 量化类型下进行量化，得到一个可检索的量化张量变体数据库。
2. **RCO 搜索。**带预算约束的黎曼搜索为每个张量分配一种量化类型，使核心分片的平均比特宽度达到目标值。
3. **装配。**所选的逐张量变体被拼接为一个标准 GGUF 文件。

稠密张量（注意力、共享专家、嵌入、输出头）与路由专家矩阵使用不同的量化阶梯，因为在任意给定预算下，路由专家所处的比特宽度远低于稠密通路：稠密张量从 Q5_K、Q6_K 和 Q8_0 中选择，路由专家则从 IQ1_S 到 IQ3_S 的类型中选择。搜索的教师模型是发布版检查点本身（路由专家保持原生 FP4），校准数据由模型自身生成。

参考实现：GSQ 位于 IST-DASLab/GSQ，RCO 位于 IST-DASLab/RCO。

可复现性材料

每个发布的构建都附带审计其构建过程所需的文件：

引用

如果你使用这些模型或方法，请同时引用两篇论文：

@article{gsq2026,
  title = {GSQ: Highly-Accurate Low-Precision Scalar Quantization for LLMs via Gumbel-Softmax Sampling},
  author = {Dadgarnia, Alireza and Tabesh, Soroush and Nikdan, Mahdi and Helcig, Michael and Kurtic, Eldar and Kleinegger, Maximilian and Alistarh, Dan},
  journal = {arXiv preprint arXiv:2604.18556},
  year = {2026}
}
@article{rco2026,
  title = {Riemannian Constrained Optimization for Budgeted Quantization Type Allocation},
  author = {DASLab},
  journal = {arXiv preprint arXiv:2605.00649},
  year = {2026}
}