273GB 的 GLM-5.3「去审查版」量化，社区整活比官方激进多了
Hugging Face 上这两天有个 GLM-5.3 的量化版本下载量起来了，一个月 1342 次。我盯着配置解析警告看了半天，才搞明白这个 repo 在玩什么花样——它不是官方的，是一个叫 Infatoshi 的用户把「去审查版」GLM-5.3 用 ExLlamaV3 压到 3.0bpw，再挂上来的。
先说这条链路。基础模型是 Z.ai 官方的 zai-org/GLM-5.3，754B 级别的 MoE 架构，256 个路由专家、8 个激活，加上 1 个共享专家。有人基于它做了个权重编辑版本（weight-editing，不是微调），起名 UNCENSORED，改动全记录在 CRACK_SURGERY.json 里，然后这个 repo 又把它量化到 EXL3 3.0bpw。整条链是社区自发的，和 Z.ai、dealignai 都没关系，页面上也写清楚了。
这模型的体量是真的唬人。平均位宽 3.04bpw，但不同模块给得不一样：attention 和共享专家 5bpw，dense MLP 4bpw，路由专家 3bpw，lm_head 6bpw。整体压到 273GiB。本地要跑，作者是用 8 张 A100 40GB 叠出来的，TabbyAPI 配了 MTP 草稿模式和 98K token 的共享缓存。这配置对大多数团队来说就是个参考，不是能随手折腾的。
量化保真度数据倒是挺干净。wikitext-2 测试集上 20 行 × 2048 token，量化版和 FP8 源版的 KL 散度 0.089（反方向 0.097），中位 per-token KL 只有 0.021，perplexity 从 3.302 微涨到 3.440。在 FP8 版 top-1 概率≥0.95 的那 44% token 上，中位 KL 只有 0.0011——高置信度的输出基本没被量化伤到。
真正的坑在 agent 场景。作者跑了 tau2-bench（航空、零售两个域），对比对象是 Z.ai 官方在 OpenRouter 上以 FP8 服务的原版 GLM-5.3。量化版在航空域 0.640，比基线 0.710 低了 0.070；零售域 0.482 对 0.504，低 0.022。作者自己标注了，这个样本量下差异都够不上统计显著，航空域那个点估计最多算「可能的小幅回落」，别当实测结论用。注意对比里混了权重编辑和量化两重因素，不是纯量化损失。
比数字更有意思的是工具调用那个大坑。GLM 写工具参数时用的是原始文本，比如 <arg_value>9523456873</arg_value>。而 TabbyAPI 的 glm4_5 解析器（到 commit be74bf0 为止）会无视工具 schema，把所有值都按 JSON 反序列化——于是订单号、产品 ID、邮编这类本该是字符串的参数，到你的工具里就变成了整数。在 tau2-bench 零售域上，这直接让大约 70% 的工具调用失败。作者是把 schema 类型为 string 的参数保留为原文之后，才跑出上面的分数。如果你真想拿这个模型搭 agent，不改解析器基本跑不通。
这 repo 值得刷一眼，倒不是因为它能吊打官方版——保真度和 agent 分数都说明不了太多——而是因为社区在「权重编辑 + 量化 + agent 适配」这条链上已经走得比厂商激进得多。官方不会给你发 UNCENSORED 版，更不会把 3bpw 的部署细节和工具解析的坑一条条写清楚。这种整活贴才是本地推理圈真实进度的注脚。许可证是 MIT，跟着上游走。
不过话说回来，273GB 的模型、8 卡 A100 的部署门槛、还没修好的工具解析器，这哪是普通用户能用的东西。它更像是一份「社区里已经有人把这一步做到什么程度」的现场记录——至于你要不要照着搭一套，先掂量掂量自己的算力账单再说。