1-bit 跑分赢了，文件还有 250GB：Unsloth 这轮基准先看体积和 baseline

Unsloth 放出 DeepSeek-V4.1-Flash-1017 的 GGUF 量化，先给了三个数：DeepSWE 68.1，Terminal-Bench 72.2，AutomationBench 52.7。1-bit 版本，512K 上下文，Unsloth 说整体比其它量化高 10% 以上。

这几个数容易让人兴奋。1-bit 听起来像把模型压到只剩开关，居然还能在 Terminal-Bench 上跑到 72.2。评论区有人直接调侃，每个权重像一盏电灯。Unsloth 的结论更直接：这轮 GGUF 在所有基准里排名最高。

但先别把 1-bit 当成免费午餐。同一批发布里，Dynamic V3.1 在 GPQA Diamond、AIME25、LiveCodeBench v6、MMLU-Pro、Aider 等基准上领先，官方写 Run on 64GB+ RAM。评论区第一波问题就卡在内存和文件体积上。

有网友说，最小量化 233GB，64GB 听起来乐观。另有人估算 1-bit 文件约 250GB。官方原话是 64GB+ RAM，素材没有解释这个数字对应哪一档量化、什么上下文、是否包含 offload。对本地部署的人来说，这比跑分更关键。模型能不能跑，先看文件放不放得下，再看长上下文时内存怎么涨。

GGUF 和量化本身不复杂。GGUF 是给本地推理用的模型文件格式，量化是把权重用更低位数表示，换更小的体积和更低的内存占用。位宽越低，通常越省资源，也越容易掉精度。Unsloth 这次说 1-bit 不掉那么多，所以值得看。但 1-bit 赢了要拆成两个问题：赢的是哪个任务，赢了多少，和谁比。

DeepSeek 自己的发布说明写得很清楚：V4.1-Flash-1017 有更强的基准表现、更快的任务完成、更短的输出，性能与成本是 Pareto improvement，已经在网站、App 和 API 上线，并针对 DeepSeekHarness 和腾讯 CodeBuddy 做了优化。这是原模型发布信息。Unsloth 做的是把这套模型转成不同位宽的 GGUF，再跑基准。

对比 baseline 时，评论区出现了一条更冷静的补充。DeepSeek 官方卡上的 DeepSWE 是 77.0，Automation-Bench 是 60.5，Terminal-Bench 用的是 v4.0，42.3，Claude Code harness。Unsloth 这里的 Terminal-Bench 72.2 是 TB 2.1，通过 mini-swe-agent 跑。两个数不能直接放一起。按 DeepSWE 粗算，68.1/77.0 约等于保留了 88%。这个读法比 72.2 很高更有信息量。

还有一条曲线问题。有网友指出，1-bit 这档不是单调的：DeepSWE IQ1_M 是 68.1，文件约 250GB；IQ2_XXS 是 63.7，文件约 300GB。低比特反而高。误差条覆盖的是随机种子还是任务，也没说清。对做部署的人来说，这类细节决定该选哪个文件，不该只看标题里的 1-bit。

所以这轮发布最值得拿走的，不是 1-bit 全面替代 8-bit 这种结论。素材里的数据只支持更窄的判断：Unsloth 的 Dynamic V3.1 量化在若干基准上缩小了低比特和更高比特的差距，1-bit 在特定任务上表现突出。要判断它能不能进生产，还得补三件事：512K 上下文下内存占用是多少，长工具历史先坏的是精确标识符召回还是指令跟随，本地写代码的体感是能接复杂任务还是只能切小段。

Unsloth 的 GGUF 文件在 Hugging Face 上，博客也给了各量化说明。想本地试，先看自己的内存和显存，再看任务，不要只看一张总分图。跑分是入口，不是结论。

链接：GGUF https://huggingface.co/unsloth/DeepSeek-V4.1-Flash-1017-GGUF ，Blog https://unsloth.ai/docs/models/deepseek-v4.1-flash ，原始发布 https://x.com/UnslothAI/status/2117266365929365525 。