@0xSero：我们找到了一种在 vLLM 中以完整上下文运行 GLM-5.2 且无需剪枝的方法。 - 前 32 个专家使用 NVFP4 - 其余使用 fp3 - intel auto…

X AI KOLs Following 模型
glm-5.2 vllm quantization mixed-precision nf3-kernel hugging-face open-source

摘要

一位社区研究员通过混合量化（NVFP4、NF3、MXFP8），在无需剪枝的情况下，在 vLLM 中运行了 GLM-5.2（753B 参数，全部 256 个专家），可在 4×96GB GPU 上运行，拥有约 307k KV 缓存，精度接近 FP8。

我们找到了一种在 vLLM 中以完整上下文运行 GLM-5.2 且无需剪枝的方法。 - 前 32 个专家使用 NVFP4 - 其余使用 fp3 - intel autoround 校准 - MXP8 注意力机制 - bf16 路由器和嵌入式 sees 在 3 个 DGX spark / 四块 RTX pro 6000 上运行 感谢社区 https://t.co/QF5SQ0Tc6v
查看原文
查看缓存全文

缓存时间: 2026/07/07 10:18

我们找到了一种方法，可以在不剪枝的情况下，在 vLLM 中运行完整上下文的 GLM-5.2。

  • 前 32 个专家使用 NVFP4
  • 其余使用 FP3
  • Intel AutoRound 校准
  • MXP8 注意力机制
  • BF16 路由器和嵌入式 sees

在 3 台 DGX Spark / Quad RTX pro 6000 上运行

感谢社区

https://t.co/QF5SQ0Tc6v

madeby561/GLM-5.2-MXFP8-NVFP4-NF3-Hybrid · Hugging Face

来源：https://huggingface.co/madeby561/GLM-5.2-MXFP8-NVFP4-NF3-Hybrid

https://huggingface.co/madeby561/GLM-5.2-MXFP8-NVFP4-NF3-Hybrid#glm-52-mxfp8-nvfp4-nf3-hybridGLM-5.2-MXFP8-NVFP4-NF3-Hybrid

⚠️**可用——请阅读注意事项。**只能通过下方自定义服务镜像加载（内部 NF3 3 位内核——官方 vLLM/推理堆栈均不支持）。在 4× 96GB sm120 GPU 上运行，DCP4 下提供约 307k token 的 KV 缓存（是之前 FP8 层级构建的 2.44 倍）——可运行约 118k 上下文并留出并发余量，或单流最高约 240k。非官方模型的 1M，也未获得官方支持。

**完整的 GLM-5.2——753B，每层 256 个专家——在 4× 96GB GPU 上运行。无剪枝。**高流量专家使用来自 lukealonso/GLM-5.2-NVFP4（https://huggingface.co/lukealonso/GLM-5.2-NVFP4）的字节级精确 NVFP4（感谢 Luke 提供了同类最佳的低 KLD 4 位层级）；长尾部分使用 NF3——我们内部开发的 3 位专家格式，并配有匹配的自定义 sm120 内核。非专家层（注意力/密集层/共享层）使用 MXFP8（OCP 微缩放 FP8，从 BF16 原始数据构建）——原生服务，加载时不反量化，这正是大 KV 缓存的来源。总计约 327 GB——唯一能在 4 张卡上容纳 GLM-5.2 并提供约 307k token KV 池（DCP4 下）的配置。

https://huggingface.co/madeby561/GLM-5.2-MXFP8-NVFP4-NF3-Hybrid#accuracy精度

与参考卡相同的协议（温度 1.0，top_p 0.95，最大推理努力）。GPQA-Diamond 是在此确切检查点上测量的；其余指标尚未运行。

精度GPQA DiamondSciCodeIFEvalBBH A-LCRτ2-Bench Telecom
基线（FP8）89.5249.8574.9569.3897.9
NVFP4（完整）89.3949.0475.8170.1398.25
此模型（326 GB，4× 96GB）88.38待定待定待定待定
REAP-594B（剪枝版，作为对比）86.8747.77———

解读：在 GPQA-Diamond 上，混合模型得分为 88.38（175/198）——与全精度 FP8/NVFP4 相差约 1 分（2 题），即在此样本量下统计上持平——同时比 REAP-594B 剪枝版高出约 1.5 分。这正是此构建的意义所在：保留全部 256 个专家并以混合精度运行，能在剪枝专家明显损失准确度的地方保持持平。基线：nvidia/GLM-5.2-NVFP4 卡。

https://huggingface.co/madeby561/GLM-5.2-MXFP8-NVFP4-NF3-Hybrid#output-drift-vs-fp8-kld相对于 FP8 的输出漂移（KLD）

此模型的下一个 token 分布与官方 FP8 分布的差异程度——这是一种相似度度量，非质量排名（两个同样好的模型仍然会有差异）。数值越低表示越接近 FP8。Prefill KL，1.05M 位置，top-8192 支持。

模型大小相对于 FP8 的漂移（KL ↓）适配 4× 96GB？
官方 FP8753 GB— （参考）❌ 需要 8+ GPU
Luke NVFP4 （约等于 FP8 级质量）435 GB0.100❌ 太大
此模型 （rev 3，mxfp8）327 GB0.177✅ 118k–240k ctx
此模型 （rev 2，fp8 层级）326 GB0.172✅
此模型 （rev 1，RTN 源）326 GB0.198✅

**注意参考基准。**此表是相对于 FP8 的漂移。并非 rtx6kpro wiki（https://github.com/local-inference-lab/rtx6kpro/blob/master/models/glm5.2_v12.md）使用的相对于 BF16 的漂移框架（其中 FP8 本身约为 0.079，Luke 约为 0.068）——不同的基线，请不要交叉比较两个表格。

简单解读：我们的输出相对于 FP8 的漂移比最佳 4 位量化的漂移稍大，而我们是唯一能启动在四卡上的型号。实际上，模型在约 99.98% 的情况下会与 FP8 将下一个 token 排成相同顺序（JS 0.035）；漂移存在于接近平局时的置信度上。Rev 3 保留了 rev 2 的字节级相同专家，仅将约 8 位的非专家层级从 fp8 替换为 mxfp8；其漂移测得为 0.177，而 rev 2 为 0.172——+0.005 仅为 mxfp8 层级与 FP8 的 fp8 格式间的微小偏差（相对于 FP8 的伪影，非质量变化：GPQA 保持不变，88.38）。

https://huggingface.co/madeby561/GLM-5.2-MXFP8-NVFP4-NF3-Hybrid#serving服务

即用镜像——已内置 NF3 内核、混合加载器、原生 mxfp8 层级以及高并发索引器修复（基于 2026-07-04 eldritch 基础构建）：madeby561/vllm-glm52-nvfp4-nf3-hybrid:v2（https://hub.docker.com/r/madeby561/vllm-glm52-nvfp4-nf3-hybrid）。此仓库中的 docker-compose.yml 正是服务配置：

hf download madeby561/GLM-5.2-MXFP8-NVFP4-NF3-Hybrid --local-dir ./glm52-mxfp8 MODEL_DIR=./glm52-mxfp8 docker compose up

需要 4× 96GB sm120 GPU + 约 64GB 内存。提供 MTP-5 / DCP4 服务，并配有约 301k token 的 KV 池（原生 mxfp8 层级）。compose 文件中已设置 --max-model-len 240000，以便实际使用长上下文——一次约 240k 的请求会填满池；对于更短的请求，可降低该值以获得更高并发。启动时间约 3 分钟（fastsafetensors）。单流解码约 60-90 t/s（取决于内容）；在 8-48 并发时，聚合速率约 250-600 t/s。

由 madeby561 构建——旨在回答一个问题：四卡机器能否运行完整模型而不进行“脑叶切除”？在 GPQA-Diamond 上，答案是肯定的。

相似文章