27B 压到 11.8GB 还能任务无损：Qwen3.8-27B 这个 GSQ-RCO 量化有点东西
在本地跑模型的人大概都清楚，27B 这个量级的模型一直是张纠结的牌：显存稍微紧一点就放不下，放得下又往往得在量化上做很多妥协。DASLab 这次给 Qwen3.8-27B 出的这套 GSQ-RCO GGUF 量化，算是把「又小又能打」往前推了一步，而且它跟平时用的那种全局统一量化不是一回事。
过去下载的 GGUF 大多都是 uniform quantization，整个模型用同一种量化类型压到底，简单粗暴，但精度损失没得挑。这套 GSQ-RCO 反着来，给每个 tensor 单独分配一种量化类型——用 GSQ 做低比特的逐张量量化，再用 RCO 在固定体积预算下给每一层挑合适的量化档位，最后拼成一个标准的 GGUF 文件。拼完依然是标准格式，llama.cpp、Ollama、LM Studio 拿过去直接就能跑，不用改任何东西，这点对想省事的人挺重要。
材料里给出的四个档位是 IQ2_XS（2.50 bpw，8.4GB）、IQ2_S（2.75 bpw，9.3GB）、IQ3_XXS（3.00 bpw，10.1GB）和 IQ3_S（3.50 bpw，11.8GB），另外还有一个 0.9GB 的 mmproj 视觉投影，让这个模型能跑多模态。几个档位里 IQ3_S 更值得单独说，它被标成 task-lossless：AIME25 上跟基座模型完全一样（100.00），LiveCodeBench v6 也一样（85.71），GPQA-Diamond 只落后 0.51 分，而体积只有 BF16 的五分之一多一点。
拿基座模型来比，这个压缩的含金量更明显。BF16 版本要 53.8GB，IQ3_S 只要 11.8GB，相当于 4.6 倍的缩水；跟同样用来做对比的 Unsloth Dynamic 量化那套 UD-IQ3_S 相比，AIME25 领先 3.33 分、LiveCodeBench 领先 1.71 分，还小了 0.2GB。再往下看，IQ2_XS 在 2.50 bpw 这个更极限的位置，跟同体积的 UD-IQ2_S 相比，AIME25 领先 10 分、GPQA-Diamond 领先 8.59 分、LiveCodeBench 领先 4.57 分。同等体积下，这套按敏感度分配精度的做法普遍比统一压法更能保住推理和代码能力。
每个量化档位还都有个 -mtp 版本，构建比不带的多约 0.35GB，里面装了模型的 Multi-Token Prediction 头，用于在 llama.cpp 里做 speculative decoding。权重本身跟不带 MTP 的完全一样，质量不变，只是多一个加速选项。对靠自回归一次次吐 token、又被显存卡死的本地部署场景，这个加速头多少能缓解一点等待感，而且因为是标准 GGUF，直接替换就行。
当然，Benchmark 只能说明一部分问题，这一点材料里其实自己也交代得挺克制——他们跑的是 perplexity 加五个 zero-shot 任务，再加 AIME25、GPQA-Diamond 和 LiveCodeBench 三块推理和代码的硬指标，并统一拿 BF16 基座和 Unsloth 那套作为参照。任务无损是好事，但它说明的是在评测集合上的表现，实际业务里的长上下文、工具调用、生成稳定性这些，还是得过一遍自己的场景才算数。另外这些量化权重继承的是 Qwen3.8-27B 的 license，GSQ-RCO 那套工具本身才是 Apache-2.0，动手改造前要看清用的是哪部分。
整套东西放在 Ollama 上也就是一行 ollama run hf.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF 的事，LM Studio 里搜仓库名也能挑文件。材料里每个文件还附了 tensor-allocation 的分配表，以及量化时用的 imatrix，方便审计每一层到底用了什么精度——这种把过程摊开给人看的态度，对做部署的人来说挺舒服的。现在这个仓库每月下载量已经冲到 160 多万，说明想跑大模型又不想上云的人确实不少。至于要不要为了省几 GB 去选 IQ2_XS 那个极限档，我的看法是别贪心，条件允许还是上 IQ3_S，推理质量稳很多。