DeepSeek V4.1 Flash 量化：每秒 26 个 Token，但存在取舍

据称，DeepSeek V4.1 Flash 量化版在双 RTX 3090 上可达到每秒 26 个 Token，将一个大模型带入了桌面端实验场景。该社区构建版本每个权重使用 2.6127 比特，这一指标衡量为模型参数分配的数值存储空间。其所报速度伴随着显著的内存需求、缓慢的加载过程，以及尚未解决的编程性能疑问。

核心矛盾在于压缩与实际工作效用之间。让模型适配现有硬件固然重要，但开发者最终需要的是在可接受的等待时间内交付正确的改动。持续快速生成文本，并不能证明一个代理能够高效完成编程任务。

这一差异也为该实验提供了一个实用的参照点：Qwen。作者已在日常使用一套基于 Qwen 的本地配置，并将 DeepSeek 描述为一次实验。本文讨论的是一种额外的部署选择，而非既有编程工作流已被替代的证据。

DeepSeek V4.1 Flash 量化版推出可下载的社区构建版本

这一具体进展是一项社区模型发布，同时附带了一份详细的、由作者自行报告的桌面端测试结果。

Reddit 用户 whiteh4cker 表示，他们使用 lxe 的 dsx 引擎创建了 DeepSeek-V4.1-Flash-1017-dsx-2.6bit，用于编程和代理式任务。代理式任务允许模型指挥操作，例如调用工具或编辑文件。这份本地推理报告现称权重已上传。

这一更新之所以重要，是因为最初的简介称上传仍在进行中。可获取的构件让其他用户能够进行检查和复现，但并不能证明公开的性能数据可泛化到作者机器之外的环境。

所链接的量化模型权重也将该版本与底层模型区分开来。DeepSeek 提供原始模型；社区贡献者提供压缩后的衍生版本；dsx 开发者提供执行该模型所用的引擎。

这些角色对应不同类型的证据。模型开发者的能力主张描述其发布版本和评测条件。压缩作者的测量结果描述某次特定转换。引擎的基准测试则描述一种软件与硬件配置。

将这些主张合并为一句关于“DeepSeek 性能”的陈述，会掩盖其中的重要差异。该桌面端结果涉及的是一个通过专用实现运行的特定压缩模型。它不会自动继承与原始版本相关的全部能力或基准分数。

发布时间使编程质量尤其值得关注。DeepSeek 于 2026 年 10 月 17 日宣布了 1017 更新。根据该公司的编码模型更新，此次更新强调项目开发、更快完成任务和更短输出。

这些主张说明了开发者为何会考虑为本地编程测试这一快照，但并不能验证压缩后的衍生版本。社区转换版本必须建立其自身的证据，尤其是在微小数值变化可能影响长链推理或工具决策的领域。

这一差异对于决定是否下载该构建版本的人而言很实际。可用性回答的是能否开始实验；可复现的基准测试回答的是另一台机器是否会有类似表现；编程评估则回答该实验是否值得纳入日常工作。

该报告推进了第一个问题，并为第二个问题提供了线索。第三个问题则基本仍未得到解答。只要结果始终与其配置和局限性相对应，这依然是有价值的进展。

桌面端的关键不止于显卡

显卡最受关注，但整台机器决定了这种部署是否实用。

作者报告称，除双 RTX 3090 外，机器还配备了 192 GB 系统内存。压缩后的权重占用 187.6 GB，而 Engram 表在 SATA 固态硬盘上占用 203 GB。Engram 是一种学习型查找记忆组件，用于补充模型计算。

报告称，从机械硬盘加载需要 90 至 110 分钟。作者在评论中澄清，该磁盘会在推理开始前将权重加载到内存中。推理指执行模型以处理输入并生成输出。

这一澄清避免了一个容易出现的误读。报告并未表示机械硬盘会在生成过程中持续供应全部模型计算。启动行为与稳态生成是不同的测量指标，对开发者工作也有不同含义。

对于始终运行模型服务器的人，启动可能只是偶发的中断；对于频繁重启、切换模型或共享工作站的人，它则可能主导整体体验。因此，同样的生成速度数据会支持对便利性作出截然不同的判断。

压力落在那些用现有硬件评估本地部署的开发者身上。他们必须同时考虑内存容量、存储位置、启动行为和持续响应性。熟悉的显卡名称，并不意味着配套系统也很普通。

报告中的机器也挑战了一个常见的采购捷径：主要根据显存来选择本地模型。系统内存和存储同样属于部署预算的一部分。它们是否可用，决定了哪些模型配置在技术上可行。

这并不能证明每个人都需要作者的精确配置，但足以说明，仅通过显卡名称无法负责任地概括这一结果。可复现的描述需要包含机器其余部分及其软件设置。

使用习惯同样重要。专用工作站可以在任务间保持模型可用；共享桌面则必须容纳相互竞争的应用和工作负载。这两种情况都不会体现在每秒 Token 数的标题里，但都会影响这套配置是否真正有用。

对编程工作流而言，中断也不止发生在启动时。开发者可能需要更改上下文设置、恢复失败进程，或在不同项目之间切换。真正相关的问题是，系统在整个工作会话中的表现如何。

这正是为何该实验对基准报告提出了直接要求，而不是证明它会给托管服务提供商带来广泛压力。本地部署主张需要描述完整机器，否则读者无法判断结果是否匹配自己的资源。

其中有价值的含义，比“替代远程服务”的主张更为有限。这一配置为本地实验提供了一个具体候选方案。它的运行要求仍是结果的一部分，而不是应从标题中删去的背景细节。

Engram 将问题从模型规模转向数据放置

这一技术机会来自将计算与存储的信息视为不同资源。

DeepSeek 的条件记忆研究将 Engram 描述为一种基于短 Token 序列的查找机制。Token 是语言模型处理的文本单位。该研究将条件记忆视为条件计算的补充。

条件计算会针对给定输入激活模型的选定部分。在混合专家架构中，这些部分包括称为专家的专用参数组。其更广泛的理念是，存储容量和每个 Token 所执行的工作不必同步增长。

对于这项桌面端实验，重要的后果是一个放置问题：哪些信息必须留在显卡附近？哪些信息可以存放在其他位置？移动或检索这些信息会带来多少等待时间？

这些问题解释了为什么文件大小本身无法预测响应性。一个大型存储组件的行为可能不同于一个需要反复算术运算的同等大小组件。除容量外，其访问模式同样重要。

这也是压缩与架构相互作用的地方。量化会降低用于存储模型数值的数值精度。Engram 涉及的是设计的另一部分：通过查找提供学习到的信息。两者都会影响部署，但不应被视为可互换的技术。

较低的每权重比特数描述的是压缩构件的一个方面，并不能概括整个系统的内存使用情况。它也无法说明每个模型组件在执行期间是如何表示或访问的。

dsx 推理引擎专为该 DeepSeek 模型设计，采用 Rust 与 CUDA——NVIDIA 的图形计算平台。其文档描述了在显存、系统内存和存储之间进行放置的方式。这是围绕特定架构开展的专用工程。

这种专门化既带来机会，也带来维护责任。引擎可以针对已知模型行为进行优化，用户则必须检查模型更新、文件变动或不同设置是否仍与该实现兼容。

当前文档也使原帖中关于图像的观察变得更复杂。帖子称似乎不支持图像输入，但代码库现已列出与视觉相关的选项，因此这一限制仍应与受测构建版本绑定。

两种观察都不能证明已发布量化版本具备可靠的图像性能。软件选项只能证明某项功能已暴露出来；成功的多模态评估才能证明完整配置是否能正确处理视觉任务。

当代理需要检查截图、图表或界面输出时，这对开发者尤为重要。纯文本编程辅助与可视化应用测试具有不同要求。一项有利的文本结果无法同时解决两者。

其更广泛的意义在于，本地部署所引发的问题发生了变化。读者不应只问模型是否装得下，还必须问其组件如何排列。这一答案连接了容量、响应性、功能支持与维护。

这使该实验在技术上颇具意义，而无需宣称其在架构上取得胜利。它展示了一条具体的部署路径。该路径是否能带来更好的编程成果，仍是一个独立且可测量的问题。

更好的压缩分数仍无法确定编程质量

评估结果支持进一步研究该构建版本，但其编程可靠性仍未得到解决。

作者的对比报告显示，新构建版本的 KL 散度为 0.1972。KL 散度用于衡量概率分布之间的差异，此处是将模型输出与参考结果进行比较。在该评估下，数值更低意味着一致性更高。

同一对比还报告了 82.59% 的首选一致率和 9.3626 的困惑度。首选一致率追踪最高排名 Token 预测是否匹配。困惑度衡量模型对评估文本预测的不确定性；在相同测试中，较低数值通常表示预测效果更好。

这些测量旨在回答压缩是否会改变模型行为。它们并不直接衡量编码代理能否修复缺陷，也无法证明每一处与参考模型的不一致都会造成有意义的失败。

这种区别在两个方向上都成立。变化的 token 可能依然让答案同样有用；而关键决策处的微小变化，则可能让代理走向错误的修改，或发起不必要的工具调用。

因此，编程为压缩提出了严苛的测试要求。模型必须在一连串决策中维持约束。有效的评估应检验最终完成的工作，而不能假定 token 层面的相符会直接转化为项目层面的成功。

讨论串中，dsx 开发者 lxe 提出了一项值得注意的警告：

> “当我制作原始模型时，令人意外的是，这种约 2 bit 的动态量化仅仅因为量化本身，就让模型对自身变得更加不确定；面对高难度任务时，其 CoT 几乎是完整模型的两倍。我已经排除了 API 问题和提示词模板的影响。在你这个 bpw 下，也会遇到这种情况吗？”

CoT 指思维链，即模型生成的中间推理文本。这是该开发者对早期压缩版本的观察，是测试新发布版本的一个有用假设，而非已确认存在于该版本中的缺陷。

发布作者的回应也说明了现有证据的边界：

> “过去几个月里，我一直在工作中通过 API 使用 DeepSeek 开发软件。我让这个 2.6 bpw 模型在网页 UI 中以最高推理强度写一篇关于古代中国的 10 段故事。它的表现与 API 版本相似，没有过度思考。不过，我没有用更难的提示词测试它。”

这段回应描述了一项初步的行为检查，但并未回答引擎开发者提出的更棘手的编程问题。创意写作与软件修复对规划、精确性和工具使用有不同要求。

下一步有价值的评估应在匹配条件下比较已完成的编程任务，并记录正确性、推理长度、重试次数和耗时。生成更多文本的模型，必须通过更好的结果来证明这些文本的价值。

围绕参考模型本身还存在报告问题。读者需要知道比较使用了哪些模型文件、提示词和评估设置；否则，再亮眼的数字也很难脱离作者的环境进行解读。

DeepSeek V4.1 Flash 量化具备合理的质量论据，但目前这一论据仍建立在代理指标和有限的行为反馈上。现有证据支持进行受控试验，却不足以宣称它在高要求编码工作上与原始模型相当。

Qwen 让等待时间的权衡变得具体

实际比较对象是作者现有的工作流，并应通过完整任务耗时来评估。

作者表示，他们每天都在使用一套基于 Qwen 的本地配置。链接中的 双 GPU Qwen 配置 记录了在同类显卡上部署 Qwen3.8-Flash-Next 的方式。因此，尽管公开配置不同，Qwen 仍是一个相关的替代方案。

相同的显卡名称并不能构成受控比较。模型、内存配置、服务软件和测试负载都可能不同。因此，公开的峰值速率应始终与各自的测试条件绑定。

DeepSeek 帖子报告的提示词处理速度为每秒 170 个 token。提示词处理，也称为预填充，是生成前针对输入进行的计算。生成速度则衡量随后输出 token 的产生速度。

这两个阶段造成的等待类型不同。缓慢的输入处理会延迟首次响应；缓慢的生成会在响应开始后拉长等待时间。即便基准测试标题只强调后者，开发者仍会同时感受到两者。

报告的上下文设置为 262,144 个 token。上下文窗口是输入和输出可用的最大 token 预算。选择这一容量，并不能证明计时测量中实际处理了完整窗口。

这一区别对代码仓库工作影响重大。开发者可能提供简短的错误信息，也可能提供大量源文件；同一台服务器面对这些请求时，实际体验可能截然不同。

代理还会增加一层复杂性，因为其任务可能涉及反复交互。它会读取工具结果、修订计划，并请求更多信息。完整延迟取决于这一序列，而非一次连续不中断的输出。

缓存会复用先前计算的结果，因此可能改变输入处理负担。其收益取决于请求之间保留了哪些可复用内容。现实的比较应明确这一行为，而不应假设每一轮都从零开始。

讨论串中关于提示词速度的分歧，反映了这些相互竞争的工作负载。偶尔测试交互式请求的人，可能会与运行无人值守任务的人对同一配置作出不同评价。仅凭生成速度数字无法解决这种分歧。

因此，Qwen 的比较应关注真实任务会发生什么。DeepSeek 是否能以更少的重试生成正确补丁？额外等待是否换来了更好的决策？现有配置是否仍更适合日常工作？

这些问题保留了核心权衡：压缩后的容量与可靠完成任务之间的取舍。它们避免将文章变成缺乏依据的模型家族竞赛。随着工作负载变化，相关的赢家也可能变化。

例如，调查陌生代码仓库的开发者需要对所提供代码进行有用的理解；进行小范围修改的开发者则需要迅速而准确地执行。模型比较应保留这些差异，而不是将其平均化。

现有的日常主力配置为这一实验提供了有价值的基准。作者有一套值得保留的工作流，而不是一个等待填补的空位。DeepSeek 必须提供足够的实际收益，才值得切换。

三项结果将决定这个版本能否成为日常主力

独立复现、编程成果和运行稳定性，将决定这一结果值得获得多少重视。

第一个信号是对已发布产物的独立复现。另一位用户应能够确认准确的文件、引擎版本、硬件和设置。所得测量应区分启动、输入处理和生成。

若结果相近，将增强人们对报告行为能在原始机器之外复现的信心。若结果不同，只要能够隔离原因，仍然具有参考价值。无法解释的波动则会限制这一结论的实用性。

复现还应澄清上下文窗口的说法。读者需要看到实际输入和输出长度，以及配置的最大值。这些信息可区分可用的大窗口与在大规模实际负载下得到验证的性能。

第二个信号是在稳定对比条件下完成编程工作。相同任务应同时运行在压缩版本和适当的基准版本上。评估者应保留提示词、工具访问权限和完成标准。

正确性必须与速度一同呈现。无法通过验收检查的快速回答，并不算完成任务；较慢的回答若能避免反复修正和人工返工，则可能仍然值得。

这项评估还应回应讨论串中提出的推理担忧。更长的输出本身并非天然更好或更差；其意义取决于额外计算是否带来了更可靠的结果。

有利结果将加强接受该版本资源需求的理由。较弱结果则会缩小其适用范围，例如仅用于实验或特定工作负载。无论哪种结果，都会改善当前的证据基础。

第三个信号是在多个工作会话中的可重复运行。除了成功演示之外，还需观察启动、恢复、内存压力和功能兼容性。只要拟议工作流依赖图像支持，就应明确验证该能力。

稳定性会加强全天保留该模型可用的理由；频繁干预则会削弱它对无人值守代理的吸引力。由于维护同样会消耗开发者注意力，这一判断应与基准性能并列考量。

未来几个月中，这些信号提供了一条比追逐每张更高 token 速率截图更清晰的路径。它们将可下载的产物连接到可复现的执行、继而连接到有用的工作，最后连接到持续使用。每一步都回答了不同的采用问题。

当前结果在这一序列中令人鼓舞。它提供了一个具体的压缩模型，以及异常具体的部署说明。其最强的贡献，是让进一步评估成为可能。

目前，应将 DeepSeek V4.1 Flash 量化视为一个候选方案，与您当前的编码工作流进行受控试验。保留配置，并选择拥有明确验收检查的任务。除了模型自身的运行时间，也要记录等待、审阅和修复输出所花的时间。应将失败也纳入比较，尤其是那些起初看似可信却导致不必要重试和错误修改的情况。若该版本支持您所需的功能，并产生可靠结果，那么其内存和加载要求就成为经过充分了解后的权衡；若不能，您仍会为未来实验获得一个有用的边界。在更换日常主力之前，请问这个基准尚未回答的问题：本地模型能否以可接受的监督程度，正确完成您的实际工作？