DeepInfer 之外：DeepSeek-V4.1-Flash 跑在 12 GB 显卡上
新的 2-bit GGUF、MIT 许可的本地运行时，加上刚合并的 llama.cpp 支持，让 V4.1-Flash 的本地路线在这周变了。12 GB 是真的；但账单的其余部分是 46–64 GB 内存、240–275 GB 磁盘，以及十来个 tokens/s。
2026 年 10 月 23 日，奥地利 ISTA-DASLab 发布了 DeepSeek-V4.1-Flash-1017 的三个 GGUF 版本。模型卡称，配合 Strata 运行时，它们可以跑在一张 12 GB 显卡上。两天后，llama.cpp 合并了 V4.1-Flash 架构支持。对一个由 DeepInfer 在 SM100 集群上服务的模型来说，这听起来像矛盾。其实不是。这是另一种产品，有另一张账单，也有另一份工作。
这是一篇基于公开资料的发布笔记。我们读了模型卡、运行时的文档、release notes 和 llama.cpp 的 PR。我们没有下载那 250 GB 文件，没有跑模型，也没有做基准测试。下文所有性能和质量数字都标明了是项目自测，不是独立结果。DeepInfer 的核心事实仍以本站 2026-10-20 的快照为准；本地运行时的事实核查于 2026 年 10 月 26 日。本站是独立、粉丝制作的站点；方法见关于页。我们与 ISTA-DASLab、Strata 维护者或 DeepSeek 没有关联。
先给结论
如果你想在一台台式机上试 V4.1-Flash，这是一条不从那 64+64 卡集群开始的公开路径。预算按 12 GB 显存、46–64 GB 系统内存、至少 275 GB 的 NVMe 可用空间来算；在项目测过的显卡上，生成速度大约是 4–11 tokens/s。
如果你要对外服务，这里没有任何东西能替代 DeepInfer。DeepInfer 仍是 DeepSeek 面向 SM100 和 Ascend 950 的离线集群引擎，仍只支持一个模型，仍缺 KV cache 系统、prefill/decode 分离和跨副本负载均衡。一台单请求 5 tokens/s 的台式机，不是 64+64 卡部署的缩小版，而是另一种产品。
如果你想用 llama.cpp 生态，架构支持已经进了上游，但这不等于“这个特定的 GGUF 包能在 mainline llama.cpp 里加载”。这个包把 Engram 表放在独立的 110.6 GB 文件里；上游转换器则把 Engram 写进模型 GGUF。先确认文件布局，再决定要不要下 250 GB。
记住一句话：763B 参数的模型没有缩到 12 GB。 它是把 backbone 压到每权重 1.75–2.25 bit，其余部分由运行时从内存和 SSD 流式读取。12 GB 是显卡下限，不是总内存预算。
这周发布了什么
本地路线不是一次发布完成的。它由一串发布、在四天里拼起来。
| 日期（UTC） | 发布 | 新增了什么 |
|---|---|---|
| 10-23 | ISTA-DASLab GSQ-RCO GGUF | V4.1-Flash-1017 的三个量化版本：1.75、2.00、2.25 bits per weight。GSQ 和 RCO 参考代码是 Apache-2.0；量化权重继承基座模型的 MIT 许可。 |
| 10-24 | Strata 0.2.4 | MIT 许可的第三方运行时，先在 Terminal 路径里加入 V4.1-Flash。此时桌面 app 还没跟上。 |
| 10-25 | Strata 0.2.5 / 0.2.6 | 0.2.5 把 V4.1-Flash 放进桌面 app；0.2.6 跟进压力测试修复，并让内存足够大的机器把 CPU 侧专家全部装入内存，跑得更快。 |
| 10-25 | llama.cpp PR #31086 | 合并 deepseek41 架构：转换器、DSpark draft、视觉投影器和 DSV4 KV cache。跟进 PR #31137 在 10-26 合并，带上 review 修复。 |
日期取自 Hugging Face 和 GitHub API。项目 release notes 可能使用本地日期。
这个顺序很重要。量化让模型小到值得一试；运行时让它不用自己搭编译链就能用；llama.cpp 让它进入最大的本地推理生态之一。三块都必要，但没有一块单独够用。
GSQ-RCO 改变了什么
GSQ-RCO 不是新模型，而是一套套在已发布 V4.1-Flash-1017 checkpoint 上的量化方法。GSQ 负责每个 tensor 的低比特标量量化；RCO 在总大小预算下，为每个 tensor 分配一种量化类型。产物是标准 GGUF，不是只有某个运行时能读的私有格式。
关键词是“逐 tensor”。均匀 2-bit 会给所有地方用同一种类型；这次是在类型之间搜索：dense 张量（attention、shared experts、embedding、output head）在 Q5_K、Q6_K、Q8_0 里选，routed experts 在 IQ1_S 到 IQ3_S 里选。routed experts 占参数大头，所以搜索的大部分自由度都花在它们身上。
| 版本 | backbone 平均 bpw | Backbone | 共享 Engram | 合计（ISTA） | Strata 下载 |
|---|---|---|---|---|---|
IQ1_M | 1.75 | 120.72 GB | 110.60 GB | 231.32 GB | 239 GB |
IQ2_XXS | 2.00 | 138.24 GB | 110.60 GB | 248.84 GB | 257 GB |
IQ2_XS | 2.25 | 155.23 GB | 110.60 GB | 265.83 GB | 274 GB |
Strata 的数字更高，是因为它额外带了约 8 GB 的 DSpark drafter。Engram 文件由三个版本共用，只需下一次。
Engram 表是最容易被忽略的部分。它有 196.6B 参数，按 IQ4_NL（4.50 bits per weight）存放，共 110.60 GB 查找表。它不是矩阵乘权重，而是每个 token 稀疏读一行，所以可以 mmap 在磁盘上，不必占显存或内存。这正是“12 GB 显卡”能成立的原因，也是为什么 NVMe 是硬要求而不是可选项。
基座是稀疏 MoE：763.2B 参数，每层 384 个 routed experts，每个 token 激活 6 个，上下文 1M。量化卡把发布权重描述为 FP8 dense、FP4 routed。2-bit 版本是另一个小得多的运行点，不是无损副本。
拆开 12 GB 这个说法
“能跑在 12 GB 显卡上”在技术上准确，但在实践上不完整。模型卡说 backbone 不必装进显存：配合 Strata，模型其余部分放在系统内存里。运行时把热专家留在内存，其余从 SSD 流式读取；Engram 表则留在磁盘。显卡只是内存层级的一环，不是全部。
| 要求 | 资料怎么说 | 为什么重要 |
|---|---|---|
| 显卡 | 12 GB 显存；Windows/Linux 上的 NVIDIA RTX 30/40/50 系列；Linux 上的 AMD Radeon AI PRO R9700 | 这是下限，不是总内存预算。这个版本的 DeepSeek 引擎不支持 macOS。 |
| 系统内存 | 项目报告测试过的最低配置约 46 GB；64 GB 是测试过的舒适值；低于约 40 GB 未测试且很慢 | 装不进显存的专家放在内存里。内存越少，SSD 换页越多。 |
| 磁盘 | 单个版本 239 / 257 / 274 GB；三个全下 533 GB；建议 NVMe | Engram 表从磁盘读。慢盘会拖慢每一个生成的 token。 |
| 上下文 | Strata 固定 8K；--context 可以要求更大 | 模型支持到 1M token，但本地运行时核查过的配置短得多。 |
| 并发 | 同时只处理一个请求；--parallel 会被忽略并给出警告 | 这是单用户运行时，不是多租户服务器。 |
| 速度 | RTX 5070 12 GB + 64 GB 内存约 4–6 tok/s；RTX 3060 12 GB + 46 GB 内存约 9–11 tok/s；单张 R9700 约 21–25 tok/s；四张 R9700 约 74–77 tok/s | 项目自测，不是独立基准。Prompt 处理是另一项数字，通常快得多。 |
这张表才是真正的购买指南。如果你有一张 12 GB 游戏卡和 16 GB 内存，这条路不适合你。如果你有一张 12 GB 卡、64 GB 内存和一块快的 2 TB NVMe，你就在项目实际测过的配置里。这两台机器之间的差距，比三个量化版本之间的差距大得多。
还有一个版本细节值得钉住：速度数字来自 Strata 自己的 release notes 和模型表，不是 ISTA-DASLab。Strata 0.2.6 说，如果机器能把所有 CPU 侧专家装进内存并留出 8 GiB 余量，现在会在加载时全部拷入，跳过按需存储。这提升了大内存机器的速度，但没有改变 46 GB 这个下限。
还有一个设置会改变比较：Strata 0.2.5 加入了 Faster 模式，每个 token 只用模型 6 个专家中的 5 个，并且在显存 16 GB 或以下的显卡上默认开启。公开的质量数字没有说明是否开启了 Faster 模式。如果你在 12 GB 显卡上用默认设置，和基准对比前先确认这一点。
两套质量数字，说的不是同一件事
ISTA-DASLab 给了一个很干净的结果：2.00-bit 版本在三项基准上都追平基座，任务平均恢复率 100.0%。这是个强标题，但它比看起来窄。
| 版本 | bpw | AIME25 | GPQA-Diamond | LiveCodeBench v6 | 任务平均 | 恢复率 |
|---|---|---|---|---|---|---|
| 基座（FP8 / FP4） | — | 100.00 | 90.91 | 89.71 | 93.54 | 100.0% |
| IQ1_M | 1.75 | 100.00 | 88.38 | 88.57 | 92.32 | 98.7% |
| IQ2_XXS | 2.00 | 100.00 | 90.91 | 89.71 | 93.54 | 100.0% |
| IQ2_XS | 2.25 | 100.00 | 90.40 | 89.71 | 93.37 | 99.8% |
ISTA-DASLab 在 reasoning effort 50 下测得。作者自测，没有独立复现。AIME25 每一行都是 100.00，已经饱和，无法区分版本。
看列，不要只看平均。AIME25 在基座和每个量化版本上都是 100.00，说明它在这个难度上已经没有区分度。真正的信号在 GPQA-Diamond（IQ1_M 88.38，基座 90.91）和 LiveCodeBench v6（88.57 对 89.71）。2.00-bit 两项都追平；1.75-bit 掉了约 1.2 个任务平均分；2.25-bit 掉了约 0.2 分。放在三项平均里，这些都是小差异，也是那种在你自己负载上可能消失、也可能放大的差异。
Strata 讲的是另一个故事。它在一组固定的 4,995 个位置上测困惑度：2.00-bit 比原模型高 15.5%，2.25 高 7.3%，1.75 高 21%。它还报告了代码和 agent 文本的退化：2.00 是 8.6% 和 5.3%，2.25 是 3.2% 和 2.2%，1.75 是 8.9% 和 10.2%。1.75 在普通英文散文上尤其弱（困惑度 +53%），文档类 +24%。
两套数字可以同时为真。三项基准的平均值很粗，而且会饱和；困惑度和 KL 散度能看到基准平均掩盖掉的分布偏移。“100.0% 恢复”的意思是：2.00-bit 在那个 reasoning effort 下、那三项任务上追平了基座。它不意味着量化模型在任何文本上都和原模型不可区分。如果你的工作是长文写作、多语言内容或特殊的工具调用轨迹，任务平均不够当证据。
“100% 质量”不是量化版本的一种属性。它是在特定基准集、特定 reasoning effort、特定基座 checkpoint 上的一次结果。诚实的写法是两句一起说：“在 reasoning effort 50 的 AIME25、GPQA-Diamond 和 LiveCodeBench v6 上，2.00-bit 版本追平了基座的任务平均；在另一组 4,995 个位置上，困惑度高 15.5%。”
llama.cpp 支持合并了，不等于这个包能跑
10 月 25 日，llama.cpp 合并了 PR #31086“model: DSV4.1 flash”。这个 PR 加入 deepseek41 架构、转换器、DSpark draft 模型、视觉投影器和 DSV4 KV cache 扩展。跟进 PR #31137 在 10 月 26 日合并，带上 review 修复。这是实打实的上游支持，也是 V4.1-Flash 进入上游 llama.cpp 的时刻。
但“llama.cpp 支持 V4.1-Flash”和“ISTA-DASLab 的 GGUF 能在 mainline llama.cpp 里加载”是两个不同的勾选项。ISTA 这个包把 Engram 表作为独立的 110.60 GB 文件发布；上游转换器把 Engram 表写进模型 GGUF，作为一个 per-layer token embedding tensor，运行时从模型里加载。这是两种布局。
截至 10 月 26 日核查，模型卡仍写着：“As of October 23, 2026, llama.cpp does not support DeepSeek-V4.1, so these GGUFs do not run in llama.cpp yet. They are supported in Strata.” 它的 llama.cpp 命令写的是“等 llama.cpp 支持之后”的未来步骤。这句话可能很快过时——架构支持已经合并——但这个包本身还没有记录一个能加载其独立 Engram 文件的 mainline llama.cpp 构建。
所以实用建议很无聊但很重要：如果你想用 llama.cpp，从一个把 Engram 表嵌进 GGUF 的版本开始，或者用合并后的转换器从 HF checkpoint 自己转。如果你想用 ISTA 的 2-bit 版本，先用 Strata，等模型卡记录上游路径。不要因为“支持合并了”就默认“这个包能跑”，然后下 250 GB。
还有一个 caveat：合并的 PR 加了两条 attention 路径，默认是优化过的 sparse gather，dense 参考路径在 LLAMA_DSV41_SPARSE=0 后面。dense 路径是正确性参考，不是速度建议。上游支持也只有几天，后续修复还在进。把它当新代码，不要当已经稳定的运行时。集群引擎与本地运行时的范围对比，见DeepInfer 对比 llama.cpp。
DeepInfer 仍赢在哪里
DeepInfer 是离线推理引擎，不是托管 API，也不是模型；它支持 NVIDIA SM100 和华为 Ascend 950，只服务 DeepSeek-V4.1-Flash 一个模型。它也没有包含 KV cache 系统、VE/prefill/decode 分离，以及跨数据并行副本的负载均衡。这些不是小缺口，而是引擎和服务之间的差别。
| 维度 | DeepInfer | GSQ-RCO + Strata | llama.cpp |
|---|---|---|---|
| 工作 | 面向单一模型的集群推理 | 单用户本地推理 | GGUF 模型的本地/边缘运行时 |
| 硬件 | NVIDIA SM100；华为 Ascend 950 | 12 GB+ RTX 30/40/50；Radeon AI PRO R9700；46–64 GB 内存 | 广泛的 CPU/GPU 矩阵，取决于构建和模型支持 |
| 模型格式 | HF checkpoint | GGUF，backbone 1.75–2.25 bpw | GGUF，多种量化类型 |
| 上下文 | 模型支持到 1M；由部署配置决定 | Strata 核查为 8K | 取决于构建和内存 |
| 并发 | 集群调度、Wide-EP、EPLB | 一次一个请求 | 本地 server；不是多租户集群 |
| 服务层 | 不含：KV cache、PD 分离、副本负载均衡 | 本地 OpenAI 兼容端点 | 本地 OpenAI 兼容 server |
| 质量证据 | DeepSeek 的图表；没有第三方复现 | 作者自测基准；项目自测困惑度 | 取决于 GGUF 和构建 |
DeepSeek 说，最小高效生产单元是 64 张 prefill 卡加 64 张 decode 卡。这个数字最清楚地说明了 DeepInfer 是干什么的。一台 5 tokens/s 的台式机，可以用来做私有草稿、prompt 实验或工具调用原型；它接不住有延迟 SLO 的多用户负载，也没法把 110 GB 的 Engram 表摊到几百个并发序列上。
它也不是一个公平的速度对比。DeepInfer 公布的 decode 图用的是 64 张 SM100、EP64DP64、131,072 token 上下文，以及 75% 的 draft 接受率假设。单张 RTX 5070、8K 上下文是另一个实验。两者没有公开的同条件实测，这篇也不会编一个。
有用的切法是按负载分。瓶颈在“能不能用上”时，用本地栈：模型在你控制的机器上，没有按 token 计费，能接受长回答等几分钟。瓶颈在吞吐时，用 DeepInfer：多用户、缓存复用、长上下文，以及一套你准备围绕缺失组件自己补的服务层。瓶颈在可移植性时，用 llama.cpp：你想要一个运行时跑遍笔记本、台式机和小服务器，也愿意跟着快速变化的上游走。
怎么自己验证
这次的 release notes 异常详细，所以是可以验的。如果你准备花一天下 250 GB，先花十分钟钉住下面几项。
| # | 钉住这个 | 为什么 |
|---|---|---|
| 1 | Checkpoint 和量化版本 | “V4.1-Flash”不够。钉住 V4.1-Flash-1017 和具体版本（IQ2_XXS、IQ2_XS 或 IQ1_M）。 |
| 2 | 运行时和文件布局 | Strata、mainline llama.cpp，还是某个 fork？Engram 是独立文件还是内嵌？答案决定这个下载能不能用。 |
| 3 | Reasoning effort 和上下文 | ISTA 的基准用 reasoning effort 50；Strata 核查的上下文是 8K。你的默认值可能不同。 |
| 4 | 内存和磁盘，不只是显存 | 12 GB 显存是标题。46–64 GB 内存和 239–274 GB 磁盘才是实际门槛。 |
| 5 | 你自己的任务组合 | 跑散文、代码、工具调用和多语言样本。饱和的 AIME 分数不会告诉你模型怎么写合同条款。 |
| 6 | 你上下文长度下的 decode 速度 | 8K 下的 tokens/s 不等于 2K 下的。Prompt 处理是另一项数字，不要混在一起。 |
| 7 | 对比基线 | 和 API 或集群在同一任务、同一 SLO 下比。本地 tok/s 和集群图表不是同一种工作单位。 |
如果只做一件事，做第 2 项。这个发布里最贵的错误，是为正确的模型下了错误的运行时。
常见问题
DeepSeek-V4.1-Flash 真的能跑在 12 GB 显卡上吗？
按 ISTA-DASLab 和 Strata 的说法，可以，但 12 GB 只是显存下限。记录的配置还需要约 46–64 GB 系统内存、单个版本 239–274 GB 磁盘，以及一块 NVMe 盘。模型是从内存和 SSD 流式读取的，不是整个塞进显存。项目报告在测试过的 12 GB 显卡上约为 4–11 tokens/s。
GSQ-RCO 是新模型吗？
不是。它是对已发布 DeepSeek-V4.1-Flash-1017 checkpoint 做的非均匀 GGUF 量化。量化权重继承基座模型的 MIT 许可；GSQ 和 RCO 参考代码是 Apache-2.0。发布包含三个版本：IQ1_M 1.75 bits per weight、IQ2_XXS 2.00、IQ2_XS 2.25。
llama.cpp 现在支持这些 GGUF 了吗？
llama.cpp 在 2026 年 10 月 25 日合并了 V4.1-Flash 架构支持，10 月 26 日又合并了跟进修复。这不会自动让 ISTA-DASLab 这个包在 mainline llama.cpp 里加载：这个包把 Engram 表作为独立的 110.6 GB 文件发布，而上游转换器把 Engram 写进模型 GGUF。下载前先确认文件布局和模型卡的运行时说明。
它能替代 DeepInfer 吗？
不能。DeepInfer 是面向 SM100 和 Ascend 950 的离线集群引擎；这是单用户本地运行时。DeepInfer 仍缺 KV cache 系统、prefill/decode 分离和副本负载均衡，DeepSeek 说最小高效生产单元是 64 张 prefill 加 64 张 decode 卡。本地栈适合访问和实验，不适合服务一群人。
我该选哪个版本？
ISTA-DASLab 推荐 IQ2_XXS 2.00 bits per weight：它在三项报告基准上追平基座，比 IQ2_XS 小约 17 GB。如果你有磁盘、又想要最低的实测困惑度增幅，选 IQ2_XS。只有在磁盘或内存紧张、并且能接受可测退化（尤其是散文和文档）时，才选 IQ1_M。
它到底有多快？
Strata 报告：RTX 5070 12 GB + 64 GB 内存约 4–6 tokens/s；RTX 3060 12 GB + 46 GB 内存约 9–11；单张 Radeon AI PRO R9700 约 21–25；四张 R9700 约 74–77。这些是项目自测，不是独立基准，并且取决于版本、上下文和存储。Prompt 处理比生成快得多，应该分开测。
资料来源
- ISTA-DASLab《DeepSeek-V4.1-Flash-1017 · GSQ-RCO GGUFs》：版本、大小、基准、量化流程、运行时说明。核查于 2026-10-26。
- IST-DASLab/GSQ 与 IST-DASLab/RCO：参考代码，Apache-2.0。
- Strata 及其 DeepSeek V4.1 文档：MIT 许可、要求、速度和质量测量。
- Strata releases：v0.2.4（10-24）、v0.2.5 与 v0.2.6（10-25）。
- llama.cpp PR #31086 与 PR #31137：架构支持与跟进修复。
- llama.cpp
conversion/deepseek41.py：上游转换器对 Engram 的处理。 - DeepInfer 仓库与部署问答：范围、硬件、缺失组件、64+64 卡单元。
- DeepSeek-V4.1-Flash-1017 模型卡：763.2B 参数、384 experts、1M 上下文、MIT 权重。
所有资料来源访问日期：2026-10-26。厂商与项目数字在正文中单独标注。我们未找到这些版本的独立基准。