Laguna S 2.1 GGUF Q4_K_M 从 68GB 增加到 96GB？
摘要
用户注意到 Laguna S 2.1 的 Q4_K_M 量化版本从 68GB 增加到了 96GB，可能是因为使用了更多的 FP16 层，并讨论了量化与上下文循环可能存在的问题。
我偶尔会查看 Laguna S 2.1，看看他们遇到的问题是否有更新或修复。我刚刚注意到他们最近更新了 Q4_K_M，现在体积膨胀到了 96GB，将 8 层提升至 FP16，其余层保持 4 位。有人知道他们为什么这样做吗？我猜测是因为之前的 Q4_K_M 在该量化级别存在问题，但只是想看看是否有人对此有更深入的了解。我尝试使用 Unsloth 的 Q4_K_M，但发现它在较高上下文时开始反复循环。我还没有尝试他们昨天发布的最新更新版本（修复了 YaRN 配置），但我尝试在 llama.cpp 中手动设置这些配置值，即使那样仍然有循环问题，所以我认为结果会相同。不过我会再试一次，以防万一。
相似文章
Unsloth 推出的 Laguna S 2.1 量化版本已发布
Unsloth 发布了 Laguna S 2.1 Mixture-of-Experts 模型的 GGUF 量化版本。该模型是一个拥有 118B 参数（8B 激活参数）的编码模型，具备 1M 上下文窗口和智能体能力。量化版本支持高效的本地部署。
如果你正在运行Laguna S 2.1，感觉它很“笨”或者推理不正常，是否使用了低于Q8的量化？
探讨在Laguna S 2.1中使用低于Q8的量化是否会降低推理能力，导致其显得‘笨’。
Laguna S 2.1 循环修复即将到来
Poolside 发布了 Laguna S 2.1，这是他们最擅长处理长周期任务的模型，同时在 Hugging Face 上提供了多种量化变体（FP8、NVFP4、INT4、DFlash、GGUF）。
DeepSeek-V4-Flash (MXFP4): 仅通过KV缓存量化类型（f16与q8_0）变化，计算缓冲区规模约扩大3倍——还有其他人在 llama.cpp 上看到这种情况吗？
一位用户报告称，在DeepSeek-V4-Flash (MXFP4)中将KV缓存量化类型从f16改为q8_0，导致计算缓冲区规模大约扩大了3倍，询问其他人是否在使用 llama.cpp 时也观察到了这一现象。
poolside/Laguna-S-2.1-GGUF
Poolside发布了Laguna S 2.1 AI模型的GGUF量化版本，包括一个DFlash投机解码草稿模型，支持通过llama.cpp进行高效的本地推理。