@tolak_eth: 我想分享一下我们是如何避免每年花费约16万美元来托管拥有完整1M上下文的GLM-5.2。当GLM-5.2推出时……
摘要
Phala通过将MoE专家量化至4位并保留关键部分为FP8/BF16，在单个8×H200节点上实现了与FP8基线相同的基准测试结果，从而避免了每年16万美元的GLM-5.2完整1M上下文托管成本，并在Hugging Face上发布了优化后的模型GLM-5.2-W4AFP8。
查看缓存全文
缓存时间: 2026/07/03 18:40
我想分享一下我们如何避免每年花费大约16万美元来托管完整1M上下文的GLM-5.2。
当GLM-5.2发布时，Phala是http://Z.ai的发布合作伙伴之一。我们尝试立即在现有的8×H200配置上运行它。这个模型令人兴奋，但部署现实并不那么美好：我们无法在该节点上完全打开1M上下文窗口。明显的路径是迁移到更昂贵的配置，很可能是Blackwell级别的硬件。这是一个不小的成本决策。
这正是开源的力量所在。团队没有将模型视为固定的工件，而是开始考虑是否能让内存预算奏效。他们将路由MoE专家量化为4-bit，将重要部分保留为FP8/BF16，并仔细验证了结果。结果是GLM-5.2-W4AFP8：在单个8×H200节点上实现完整1M上下文，基准测试结果与FP8基线一致。
截至今天，Hugging Face上的GLM-5.2-W4AFP8已有接近2万次下载。我认为这很能说明问题。开发者不仅想要更大的上下文窗口，他们还希望模型在运行时实用，而不必让每次部署都变成硬件采购问题。
这让我想起了《黑客与画家》：开源的美妙之处在于用户不必停留在“这就是发布的内容”。他们可以重塑工具，直到它适应现实世界。
下载：https://huggingface.co/PhalaCloud/GLM-5.2-W4AFP8…
相似文章
@0xSero：我们找到了一种在 vLLM 中以完整上下文运行 GLM-5.2 且无需剪枝的方法。 - 前 32 个专家使用 NVFP4 - 其余使用 fp3 - intel auto…
一位社区研究员通过混合量化（NVFP4、NF3、MXFP8），在无需剪枝的情况下，在 vLLM 中运行了 GLM-5.2（753B 参数，全部 256 个专家），可在 4×96GB GPU 上运行，拥有约 307k KV 缓存，精度接近 FP8。
@Tech2Wild: 在家运行完整的GLM-5.2，744B参数，全部256个专家，未剪枝，跨4×NVIDIA DGX Spark (GB10)。200K上下文 · MTP …
一份详细的指南，介绍如何跨4个NVIDIA DGX Spark节点运行未剪枝的GLM-5.2模型（744B参数，256个专家），支持200K上下文，总吞吐量高达60.5 tok/s。包含性能基准测试、致谢和补丁。
@0x_kaize: https://x.com/0x_kaize/status/2068775813785506091
关于在使用 GLM 5.2 模型时避免速率限制和降低成本的指南，涵盖提示批处理、缓存、免费模型替代方案、努力水平、上下文窗口管理和自托管。
在4台GB10上运行GLM 5.2，配备100G交换机，330k上下文，~25 tok/s解码，~650 tok/s预填充
本文详细介绍了在4台GB10的配置上，使用100G交换机运行GLM 5.2，在330k上下文下实现约25 tok/s解码和约650 tok/s预填充。内容包括硬件成本、使用Depth Prefill的性能基准测试，以及关于为更长上下文进行模型剪枝的说明。
@HuggingPapers: NVIDIA 刚刚在 Hugging Face 上发布了优化版的 GLM-5.2，这是一个拥有 753B 参数和 1M 上下文的 MoE 模型，针对 Blackwell GPU 量化至 NVFP4……
NVIDIA 在 Hugging Face 上发布了优化版 GLM-5.2 MoE 模型，拥有 753B 参数和 1M 上下文，针对 Blackwell GPU 量化至 NVFP4，精度几乎与 FP8 持平。