GLM-5.2 - 压缩纪实

一个由极客组成的社区，如何仅用15,000美元预算，以近乎无损的质量运行GLM-5.2。本文基于RTX Pro 6000 Discord服务器中分析的上万条信息整理而成。

内存昂贵 $$

GLM-5.2 是一个大型混合专家模型。精确来说，753B参数量，在BF16精度下占用1.56TB，这还不包括KV缓存和优化所需空间。运行它需要约2TB的高带宽内存。

你至少需要16块DGX Sparks，最低投入约70,000美元。

0xSero@0xSero·6月20日我想要2131388.1K

FP8 和 NVFP4 能稍微降低这一需求。将每个权重从16位量化到8位，可以节省约50%的成本；降到4位，权重内存需求仅为原来的25%。

大约一年来，这已是下限。将模型压到4比特以下一直效果不佳，甚至根本不可行，尤其是在最佳推理引擎上。建议阅读此篇了解更多关于SGlang和VLLM的内容。

Ahmad@TheAhmadOsman·5月21日文章LLM与本地AI硬件的推理引擎（2026版）选择推理引擎不是第一步。你先得确定硬件策略、工作负载形态和部署模型，引擎随后跟上。 这才是思考LLM推理引擎最实用的方式。402571.6K997K

REAP剪枝：突破4比特下限

Cerebras研究团队发表了这篇关于MoE专家剪枝的精彩论文：https://arxiv.org/abs/2510.13999 他们发现，剪枝可以进一步缩小模型体积，同时保留剩余部分的4比特精度。

这种剪枝可以精准操作：你运行“观察“，基于校准数据集收集专家激活值和显著性分数，然后决定保留或剪枝哪些部分。

这使得我们在保持稳定编码代理体验的同时，实现了约82%的权重压缩。REAP必然有所牺牲——无论是世界知识、推理质量，还是模型置信度——而此方法一度就是你能达到的最低压缩水平。

GLM-5.2 登场

ZAI发布其最新旗舰模型后，任何拥有硬件的人都立刻开始着手尽可能压缩这个漂亮的模型。

Discord里每个人都在谋划和实验如何减小模型体积，以便让它能在4块RTX Pro 6000（50,000美元）或3块DGX Sparks（15,000美元）上运行。

GGUF：用速度换显存

Llama.cpp 长久以来就能把大多数模型塞进消费级硬件，甚至压到2比特，这样权重所需内存仅为BF16的12.5%。

Unsloth 在如此低比特压缩下保持模型智能方面也一直无出其右。如果你的硬件允许，一定要试试，在LMStudio上很容易上手。

Unsloth AI@UnslothAI·6月18日GLM-5.2 现在可以在本地运行了！

2比特模型保留约82%准确率，我们从1.51TB压缩到238GB（减少84%）。

可在256GB Mac或RAM/VRAM配置上运行。

GLM-5.2 是迄今为止最强的开源模型。

指南：https://unsloth.ai/docs/models/glm-5.2… GGUF：https://huggingface.co/unsloth/GLM-5.2-GGUF…Z.ai引用Z.ai@Zai_org·6月17日介绍 GLM-5.2：前沿智能，开放权重

• 编码和代理任务显著提升
• 支持1M上下文窗口，长程能力强大
• 两种推理努力程度：GLM-5.2（极限）突破上限，而GLM-5.2（高）在性能与效率之间取得良好平衡2731.1K7.3K1.8M

GGUF与Llama.cpp速度慢

虽说开箱即用，但牺牲了大量速度：预填充在Llama.cpp上明显更差，并发支持也不理想。

如今每个工作流都会生成子代理，我们经常同时运行2-8个后台代理。Codex和Claude Code真正革新了自动化工作。

要在本地实现这一点，不仅需要惊人的智能，吞吐量往往更为重要。因此Llama.cpp不是选项。

我想说的是，我对llama.cpp及其与世界分享的所有创新只有敬意。它是一个很好的起点，也是目前最好用的“开箱即用“引擎。

先试试REAP

第一批兼容VLLM的压缩版本是我制作的一系列GLM-5.2 REAP。我使用混合数据集（编码、代理、哲学、宗教经典、科学知识）进行校准，剪掉了34%的专家。

这些REAP在一个月内累计下载35,000次，约占原始16位模型下载量的8%。剪枝后，我将其量化到NVFP4、GGUF和Intel的W4A16。

REAP 取得了惊人成绩：

• terminal-bench-2.1 上 70.8%
• aider-polyglot 上 91%
• GPQA Diamond 上 86%

但MMLU Pro 掉了约30分，并且在未保留的话题上容易循环。在一段时间内，这成了社区采用的标准。

它让我们能够使用NVFP4，这保留了大部分智能，并为Blackwell卡带来适度的速度提升。这里可以看到它如何构建一个Minecraft克隆。

0xSero@0xSero·6月22日GLM-5.2-REAP-NVFP4

这个实验中，我用30,000+个我的代理会话样本、推文、写作和代码库来校准模型。

非常迷人，每个数据集都产生了不同的东西。20936522K

0xSero@0xSero·6月18日GLM-5.2 一次生成 - REAP + NVFP4

这是我在本地见过的最好的单次生成Minecraft克隆。

• 昼夜系统
• 完整的物品系统
• 动物
• 无限环境
• 漂亮方块
• 角色移动
• 流畅控制

–– 1个bug

我无法点击挖掘/合成261319814K

下一次创新：混合精度推理

我们之前讨论了量化如何缩小模型并适配消费硬件。2026年4月，Deepseek发布了DS4-Flash，一款FP8/FP4混合精度模型，性能出色——当然这并非新事物。

动态GGUF（如Unsloth发布的）一直是兼顾体积最小化和智能保留最大化的热门方案：根据比特重要性对模型不同部分进行不同程度的量化。

于是诞生了这个美丽的混合压缩标准。 https://huggingface.co/madeby561/GLM-5.2-MXFP8-NVFP4-NF3-Hybrid

madeby561 将GLM的模型权重中的192个专家压缩到NF3，保留64个高显著性专家为NVFP4，并将模型其余部分（门控、注意力等）量化为MXFP8。

我们立即看到了显著改进。这一切都需要自定义内核，以及Discord上数百人日以继夜的合作。

权重只是冰山一角

一旦能将模型权重装入内存，下一个挑战就是KV缓存。我们成功将权重从1.51TB降至300GB，压缩了80%，同时保留了模型大部分智能。

没有进行剪枝——这是最关键的一点。这立即消除了一整类bug和挑战。

0xSero@0xSero·7月8日4块6000上的GLM-5.2，运行在ZCode

/目标 用C++编写一个任天堂DS模拟器，不要使用现成模拟器。不停下来，直到能运行Mario 64 DS rom。241632339K

KV缓存也必须削减

在VLLM中，默认每个GPU上必须容纳一份KV缓存副本，这加速了推理（减少PCIe数据传输），但消耗大量显存。对于采用的混合模型，我们最多只能获得约200k令牌，虽然够用，但并非理想。

通过选择将KV缓存跨GPU分摊，我们在FP8下攀升到约370,000令牌的KV缓存。https://docs.vllm.ai/en/latest/serving/context_parallel_deployment/#decode-context-parallel

压缩空间仍然巨大。就像我们能将权重压缩到NVFP4甚至NF3一样，KV缓存同样可以压缩：https://github.com/vllm-project/vllm/issues/32220

社区运行了各种评估和基准测试，在384GB内存中实现了740k令牌上下文，这允许更高的并发、更长的会话，甚至更快的推理。

ExllamaV3、TR3与KL散度

KL散度是一种衡量模型质量的工具。将相同的固定token分别输入BF16教师模型和压缩后的版本，然后比较它们对下一个token分配的概率分布。

我使用并发现EXL3量化和ExllamaV3是服务4比特以下模型且保持最高质量的可靠推理引擎。https://github.com/turboderp-org/exllamav3

网格编码量化

通常，你对每个权重单独进行舍入，并希望误差不会累积得太糟。网格编码则一次性查看一整块权重，从中挑选最优的压缩路径。这样可以将误差分散开来，而不是毁掉某个重要的权重或方向。

因此，使用TR3我们可以将不太重要的专家压到大约3比特，而无需像REAP那样删除它们。它们仍然存在，只是以更巧妙的压缩形式存储。

QTIP 是这种压缩风格背后的研究方法：网格与不相关性处理的量化。

它首先对权重空间进行轻微打乱，这样就没有哪个敏感方向会承受所有量化损伤。然后利用网格编码将整组权重一起压缩，而不是逐个舍入。

EXL3 是该思想的一个实用、更快速的版本。TR3 利用它将尾部专家保持在约3比特，而不是删除它们。

https://huggingface.co/brandonmusic/GLM-5.2-NVFP4-TR3-Hybrid

GLM-5.2 在2比特下运行？Moet

vLLM-Moet 将巨大的专家矩阵存储为符号对称的2比特权重，然后为热门专家使用一个FP4的“增量“缓存。如果路由器不确定，它可以用更高精度的专家权重重新处理该token。

所以正常路径是廉价的W2；救援路径是FP4。

它还有一个狂野的部分：当连W2也放不进显存时，专家可以驻留在固定RAM或NVMe中，而GPU持有所需的热数据。缓存未命中时，获取所需的专家，然后重新处理token。这正是它声称能在两块96GB显卡上运行GLM-5.2的原理。

我们在一张RTX Pro 6000上以100 tok/s的速度测试了Deepseek-v4-flash在GPQA Diamond上的表现，得分与NVFP4几乎相同，只有1个问题在moet方法上失败。

Moet 不需要静态量化或剪枝，它直接运行原始模型权重，只是在需要时才存储轻量级缓存。这个方法更新颖，建议你了解一下。

你如今也能拥有前沿模型

50,000美元是一大笔钱，但12,000-15,000美元更可行，因此会有越来越多人转向本地部署。Sparks 能以最高30 tok/s的速度运行这个模型，足够完成实际工作。

我们都清楚自己对这些工具的依赖日益加深。我想告诉你的是，相比起点，我们已经进步了太多。

似乎距离我们都能拥有自己的模型并不遥远了。