在一个残酷的周末调试马拉松进行到一半时，我崩溃了。我已经连续跑了三个小时的长期自主编程 Agent，以让 CFO 都会落泪的速度疯狂消耗着闭源前沿模型的 API 额度。任务是复杂的系统工程——重构一个分布式消息队列——但模型总是丢失上下文，或者犯一些粗心的错误，进而导致更多的 API 调用。我需要一个既能处理长线、深思熟虑的规划，又不用大把烧钱的方案。就在这时，我决定好好研究一下 GLM-5。
GLM-5 是 Z.ai 最新的开放权重推理模型，它发布时的跑分相当亮眼：SWE-bench Verified 得分 77.8%，Terminal-Bench 2.0 得分 56.2，BrowseComp 更是达到了惊人的 62.0%。但根据我踩坑的经验，跑分数据和实际工作流中的好用程度完全是两码事。下面是我实际试用后的真实情况。
硬件现实考量
咱们先解决房间里的大象（最棘手的问题）。GLM-5 是一个拥有 744B 参数的混合专家（MoE）模型，其中活跃参数为 40B。完整模型需要 1.65TB 的磁盘空间。我刚看到这个数字时，差点直接关掉网页。
但 MoE 架构的好处在于：你不需要把所有 744B 参数一次性全加载到显存里。对于任何给定的 token，只有那 40B 的活跃参数在起作用。这就为量化提供了可能，如果是同等能力的稠密模型，这种量化方案根本想都不敢想。
我选用了 Unsloth 的动态 2-bit 量化（UD-IQ2_XXS），这能把模型体积压缩到 241GB。刚好可以塞进一台 256GB 统一内存的 Mac 里，而这正好是我的设备。如果你的硬件配置低一些，1-bit 动态量化版本只有 176GB，可以在 180GB 内存的主机上运行，同时利用 MoE 卸载技术，将部分计算分派给一块仅有 24GB 显存的 GPU。如果你硬件够硬且追求极致质量，还有个 805GB 的 8-bit 量化版本可选。
Unsloth Dynamic 2.0 量化的核心思路是：即使在 1-bit 版本中，重要的层也会被向上转换为 8-bit 或 16-bit。这不是那种会毁掉模型质量的简单粗暴的均匀量化。我一开始还半信半疑，但结果证明它确实行得通。
我的设备配置：一台 192GB 统一内存的 M2 Ultra，外加一台装了 1 张 24GB RTX 4090 和 256GB 系统内存的 Linux 主机。在跑 2-bit 量化时，我用了那台 Linux 主机配合 MoE 卸载。
跑起 llama.cpp
首先，拉取最新的 llama.cpp。这很关键——GLM-5 的支持是最近才加上的，老版本会静默失败或者直接崩溃。
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j$(nproc)
如果你用的是 Mac，把 -DGGML_CUDA=ON 换成 -DGGML_METAL=ON。
从 HuggingFace 下载量化模型。我用的是 Unsloth UD-IQ2_XXS 版本：
huggingface-cli download unsloth/glm-5-UD-IQ2_XXS-GGUF \
glm-5-UD-IQ2_XXS.gguf \
--local-dir ./models
这个下载量有 241GB。去泡杯咖啡吧，可能还得泡好几杯。
接下来是实际的运行命令。针对我开启了 MoE 卸载的 Linux 环境配置：
./build/bin/llama-server \
-m ./models/glm-5-UD-IQ2_XXS.gguf \
-ngl 12 \
--host 0.0.0.0 \
--port 8080 \
-c 202752 \
--temp 1.0 \
--top-p 0.95 \
--min-p 0.01 \
--repeat-penalty 1.0 \
-np 131072
-ngl 12 参数表示将 12 层卸载到 GPU 上。剩下的都在系统内存中运行。这肯定比全显存运行要慢，但起码能跑。而在我的 Mac 上，我完全可以跳过卸载步骤，直接在统一内存里跑所有东西。
我刚开始踩过一个坑：我把 min-p 保留在了 llama.cpp 默认的 0.05。这导致模型在生成有创造性的内容时被截断得太狠。按照建议改成 0.01 后，在开放式编程任务上的效果有了肉眼可见的提升。
真正重要的参数设置
GLM-5 有两套推荐的参数配置，用错的话会严重影响效果。
默认设置（适用于大多数任务）：
- temperature: 1.0
- top_p: 0.95
- max new tokens: 131072
- repeat penalty: 1.0（禁用）
- min_p: 0.01
SWE-bench / 专注编码设置：
- temperature: 0.7
- top_p: 1.0
- max new tokens: 16384
- repeat penalty: 1.0（禁用）
- min_p: 0.01
temperature 的差异至关重要。我曾花了一整个下午对 GLM-5 生成的混乱代码修改抓狂，后来才意识到我在专注修 bug 的任务中用了 1.0 的默认 temperature。降到 0.7 后，单问题补丁的连贯性立刻就上来了。反过来说，当我在做架构规划时用 0.7，输出又变得太保守，错失了有创造力的解决方案。
它的最大上下文窗口是 202,752 个 token。这相当夸张。我塞了一个 150K 的大代码库上下文进去测试，它自始至终都保持了逻辑连贯。这正是 GLM-5 真正闪光的地方——长上下文推理不会退化成车轱辘话或幻觉。
GLM-5 适用的场景（以及不适用的场景）
经过两周的日常使用，这是我的真实评价。
非常适用：长时间运行的自主会话。 对于预算比延迟更重要的数小时编程会话，GLM-5 的经济优势非常明显。本地运行意味着没有按 token 计费的成本，而 200K 的上下文窗口意味着你可以加载整个代码库，无需分块。
非常适用：复杂系统工程。 这个模型比它的前任规划得更周密。在重构一个分布式消息队列的分区分配逻辑时，GLM-5 给出了一份连贯的多文件修改计划，连我没想到的边缘情况都考虑进去了。
不太适用：交互式结对编程。 推理速度明显比 Opus 4.6 的快速模式慢。如果你需要快速来回互动，它就不是你的菜。延迟会打断心流状态。
不太适用：快速的一次性任务。 拿一个 744B 的 MoE 模型去写个简单的正则，简直是用大锤砸图钉。把这种活儿交给更小、更快的模型吧。
一个惊喜：GLM-5 在 BrowseComp 上 62.0% 的得分可不仅仅是跑分好看。配合工具使用时，它的网页浏览能力在研究任务中真的很好用。我让它去调查一个特定版本 Redis 里的冷门内存泄漏问题，它浏览 GitHub issues 和文档的效率比我预期的要高得多。
对于多轮 Agent 任务（特别是 τ²-Bench 和 Terminal Bench 2），你需要开启 Preserved Thinking 模式。我一开始没意识到这点，还纳闷为什么模型在长会话中总是跑偏。打开这个模式后，问题彻底解决了。
实用建议
如果没有硬件，先用 API。 Z.ai 提供包含 GLM-5 访问权限的 Pro 订阅。不过有用户反馈 API 存在稳定性问题，所以在将其纳入核心工作流之前，先在非关键任务上测试一下。
根据硬件选择合适的量化版本。 别试图把 8-bit 量化版硬塞进配置不够的机器里，然后反过来怪模型输出质量差。2-bit 动态量化对大多数本地部署来说才是甜区。
合理分配任务。 GLM-5.2 引入了路由概念：简单、高频的任务走 "High"（更快、更便宜），复杂任务走 "Max"。在本地部署时也适用同样的原则——让 GLM-5 做它擅长的事，剩下的交给小模型。
留意你的 SSD。 如果你因为内存和显存不够而卸载到存储空间，推理速度会很慢。NVMe SSD 勉强能顶住；SATA SSD 和机械硬盘就会非常痛苦了。
实话实说的局限性
推理速度是最大的实际局限。即使用了 MoE 卸载，你也别指望能得到亚秒级的响应。如果你的工作流依赖快速迭代，你得调整预期，或者干脆用 API。
量化的取舍是真实存在的。2-bit 动态量化保留了模型的大部分能力，但在高度微妙的推理任务上，跟全精度模型相比，我确实感觉到了轻微的性能下降。对于 95% 的编程任务，这无所谓。但对于剩下的那 5%，可能就有影响了。
最后，开源模型生态的收敛速度非常快。在编程跑分上，GLM-5、Kimi K2.5 和 DeepSeek V3.2 距离闭源前沿模型都只有个位数的差距了。剩下的差距主要在强化学习（RL）基础设施上，而不是预训练算力。这意味着今天的 GLM-5 在几个月内就会被下一代开源模型超越。别在单个模型的特性上投入过多沉没成本。
GLM-5 不是在所有方面都是最好的。但对于那些需要大上下文和深思熟虑的规划、注重预算的长线编程 Agent 工作流来说，它是你技术栈中值得拥有的一件利器。只要确保你有足够的内存就行。