在本地跑 GLM 5.2（2026）：2-bit 塞进 256GB Mac，或一台 4090 主机

智谱把 GLM 5.2 权重以 MIT 许可放上了 HuggingFace，于是问题不再是「能不能下到一个前沿级 coding 模型」，而变成了「它能不能在我手头这台机器上跑起来」。对一台 Mac Studio，或一台单 GPU 加大内存的台式机来说，答案是「有条件的能」。条件就是量化档。

本地能跑什么（以及跑不了什么）

这篇讲的是在你自己的一台机器上跑 GLM 5.2，用量化后的 GGUF 权重配 llama.cpp、LM Studio 或 Unsloth Studio。这跟在一柜 H200 上给团队提供服务是两码事——那条路由 GLM 5.2 自托管硬件与成本指南负责讲；也跟调托管 API 又是另一码事——那条由 GLM 5.2 接入指南负责讲。

GLM 5.2 是个 753B 参数、1M token 上下文的模型，以 MIT 许可发布。在完整 BF16 精度下权重约 1.5 TB，塞不进任何一台台式机。本地推理就意味着量化：用一点质量换一个能塞进你内存的体积。下面是「什么档位塞进什么机器」的 30 秒版本。

说句实在的结论：一台 256 GB 的 Mac Studio 跑 2-bit 量化，才是现实里「GLM 5.2 摆在我桌上」的配置。4-bit 是质量甜区，但它要一台 512 GB 的机器或者重度 offload。小于 256 GB 的，就是托管 API 的活，不是本地的活。

决策框架：什么时候本地跑 GLM 5.2 值得（什么时候不值）

为对的理由在本地跑量化版。错的理由是省钱——因为对几乎所有人来说，托管套餐更便宜。

该本地跑的场景

• 离线或物理隔离的工作。 不允许任何对 api.z.ai 的出站流量，那模型就只能活在你自己的硬件上。
• 单机隔离的隐私需求。 你的 prompt 和代码永不离开这台机器，一台 Mac Studio 就是整个边界。
• 硬件你本来就有。 一台为视频或 ML 工作买的 256 GB 或 512 GB Mac Studio 夜里闲着，跑个本地量化版不花你额外的钱。
• 折腾和学习。 你想亲手感受一个 753B MoE 是什么脾气、试各种采样设置，或者对着一个没有速率限制的本地 OpenAI 兼容 endpoint 做开发。

不该本地跑的场景

• 你想又便宜又快。 Z.ai Coding Plan 约 $30/月，全速运行。本地 2-bit 量化 3-9 tok/s，光电费就拼不过它的性价比。读一读接入指南。
• 你要服务不止一个人。 一台 Mac Studio 是单会话机器。两个开发者同时拿它狠跑，两边都会觉得慢成蜗牛。那是数据中心那条路。
• 你的机器不到 256 GB。 没有任何量化档能把 GLM 5.2 以值得用的质量塞进 128 GB 的主机。别搭上一个周末白折腾。
• 你需要完整的 1M 上下文。 长上下文的 KV cache 在消费级硬件上装不下。本地实际上限大约在 16K-64K。

退出规则

如果你没有至少 256 GB 的统一内存或系统内存，到此为止，用托管套餐。再怎么量化也改不了这条底线。

系统要求

flowchart TD
  A[内存有多少？] -->|512 GB Mac| B[4-bit UD-Q4_K_XL<br/>本地最佳质量]
  A -->|256 GB Mac 或 DDR5| C[2-bit UD-IQ2_M<br/>最常见配置]
  A -->|不到 256 GB| D[改用托管套餐<br/>不是本地的活]
  B --> E[llama.cpp / LM Studio / Unsloth Studio]
  C --> E

在你下 240 GB 权重之前，先确认你有：

• 内存。 最低 256 GB（Apple silicon 上的统一内存，或 CUDA 主机的系统 DDR5）。2-bit 量化约 240 GB，所以在一台 256 GB 的机器上余量是真的紧：关掉其他应用、给 macOS 留够它那份统一内存，否则你会撞上 swap。要舒服地跑 4-bit 得 512 GB。
• 磁盘。 量化档加上余量：2-bit 约 240 GB 空闲，4-bit 约 376-475 GB。用 SSD，别用机械盘，否则加载时间会让人难受。
• 一个 runner。 从近期 commit 构建的 llama.cpp、LM Studio，或 Unsloth Studio。架构（GLM MoE DSA）新到一个老的 llama.cpp 构建会加载不出 tensor。
• 对的仓库。 社区 GGUF 量化在 huggingface.co/unsloth/GLM-5.2-GGUF。官方的 zai-org/GLM-5.2 仓库只有 BF16，不是你本地推理想要的。

分步操作：在本地跑 GLM 5.2

第 1 步：拉一个 GGUF 量化档

只下你需要的那个量化档，别下整个仓库。--include 过滤器能让你不去抓那 750 GB 你用不上的分片。

# 256 GB 机器用的 2-bit（磁盘约 240 GB）
hf download unsloth/GLM-5.2-GGUF \
  --local-dir ~/models/glm-5.2-gguf \
  --include "*UD-IQ2_M*"

最后你应该在 ~/models/glm-5.2-gguf 里得到一组 GLM-5.2-UD-IQ2_M-0000X-of-0000Y.gguf 分片。如果你在 512 GB 机器上，把过滤器换成 *UD-Q4_K_XL*。具体的分片名以 HuggingFace 上实时的「Files and versions」标签页为准，因为 Unsloth 会随着动态量化的改进修订量化档标签。

第 2 步：用 llama.cpp 跑起来

这是命令行那条路，也是控制力最强的一条。先构建一个近期版本的 llama.cpp（Mac 上 Metal 自动编译；Nvidia 主机加 -DGGML_CUDA=ON）。

# 构建一次
cmake -B build && cmake --build build --config Release -j

# 在 8080 端口起一个 OpenAI 兼容 endpoint
./build/bin/llama-server \
  --model ~/models/glm-5.2-gguf/GLM-5.2-UD-IQ2_M-00001-of-00006.gguf \
  --ctx-size 32768 \
  --n-gpu-layers 999 \
  --temp 1.0 --top-p 0.95 --min-p 0.01 \
  --host 0.0.0.0 --port 8080

每个 flag 都有它的道理：

• --ctx-size 32768 设一个 32K 窗口。在 256 GB 机器上往上调会很快吃内存；从这里起步，只在某个请求真需要时才加大。
• --n-gpu-layers 999 把能 offload 的每一层都 offload 到 GPU。在 Mac 上统一内存让这几乎是免费的；在 4090 上它只 offload 24 GB 装得下的那部分，其余留在 CPU 上。
• --temp 1.0 --top-p 0.95 --min-p 0.01 是智谱推荐的采样默认值。把这几个配错，是「本地模型比托管的笨」最常见的原因。

加载完之后，llama-server 会打出层数，然后输出 server listening on http://0.0.0.0:8080。从 SSD 首次加载要一两分钟。

第 3 步：或者用图形界面（LM Studio / Unsloth Studio）

如果你不想碰构建工具链，有两个图形界面应用能加载同样的 GGUF 量化档。

LM Studio 在桌面应用里跑同样的 GGUF 量化档。在应用内的模型浏览器里搜 unsloth/GLM-5.2-GGUF，挑 2-bit 或 4-bit 量化档，它会处理下载和服务，对外暴露同样的本地端口 OpenAI 兼容 endpoint。

Unsloth Studio 是个带自动内存 offload 的 web 界面，一行命令装好。

curl -fsSL https://unsloth.ai/install.sh | sh
unsloth studio -H 0.0.0.0 -p 8888

如果你想换量化档和设置时不用每次重敲一长串 llama.cpp 命令，这两个都是更好的选择。

第 4 步：冒烟测试

把任意 OpenAI 客户端指向这个本地端口，确认它能应答。

curl -s http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.2",
    "messages": [{"role":"user","content":"Reply with only the string OK."}],
    "max_tokens": 16
  }' | jq -r '.choices[0].message.content'

停顿一小会儿后你应该拿回 OK。如果回复乱码或者反复打转，是你的采样参数不对，对照 huggingface.co/zai-org/GLM-5.2/generation_config.json 里的值，重新核对 --temp 1.0 --top-p 0.95 --min-p 0.01。

真实 tokens/秒：各档位的预期

本地硬件上的生成速度受限于内存带宽，而不是裸算力，所以一台 800 GB/s 统一内存的 Mac Studio 会赢过 RAM 跑在 80-100 GB/s 附近的 DDR5 台式机。下面是该照着规划的数字。

规律是：本地 GLM 5.2 是个单流、单开发者的工具。这速度跑一个想着把任务捋清楚的 coding agent 没问题。它跑不动一个共享 endpoint，没有哪个消费级量化档能改变这点。如果你要给团队上吞吐，自托管硬件指南走了数据中心 GPU 上的 vLLM 和 SGLang 那条路。

本地配置时的常见报错（及修复）

团队 / 多开发者：一台 Mac 不够用时

一台本地机器服务一个人。第二个开发者把 agent 指向同一个 llama-server 的那一刻，两个会话都会慢成蜗牛，因为消费级硬件没有多余带宽去分。没有哪个聪明 flag 能修这事。

本地撑不住扩展时，有两个真实的选项：

1. 上数据中心 GPU。 一个 8x H200 节点跑 FP8 能扛许多并发流，每条几十 tokens 每秒。那是另一套成本和运维的故事，自托管 vLLM 与成本指南里完整走了一遍，包括对托管套餐的盈亏平衡测算。
2. 用一个托管 endpoint，别再伺候裸机。 对多数团队来说，除了数据驻留这一条，托管在每个维度都赢。

本地量化版是给一个想把模型放在自己机器上的开发者的对的工具。给共享服务用，它就是错的工具。

进阶：长上下文与思考模式

基本配置跑通后，有两个旋钮值得了解。

KV cache 量化。 1M 上下文在架构里是真的，但在一台 256 GB 的机器上够不着，因为光 KV cache 就要几百 GB。把它量化能买回点空间：

./build/bin/llama-server \
  --model ~/models/glm-5.2-gguf/GLM-5.2-UD-IQ2_M-00001-of-00006.gguf \
  --ctx-size 65536 \
  --cache-type-k q4_1 --cache-type-v q4_1 \
  --n-gpu-layers 999 --port 8080

这大致把 KV cache 内存砍半，让你在同样的硬件上把上下文往更长推，代价是超长输入上的小幅质量损失。

思考模式。 GLM 5.2 有个推理模式，答题前会花 token 思考。对快速改动和短 prompt，它加的延迟你可能不想要。用 --chat-template-kwargs '{"enable_thinking":false}' 按请求关掉它，在那些额外推理对得起开销的高难度多步问题上再留着它。

当本地是错的答案：托管与 ofox 替代方案

如果 256 GB 这条底线，或者单会话的速度把本地这条路排除掉了，你完全不必因此放弃 GLM 5.2。同一个模型就在 ofox 目录上，model ID 是 z-ai/glm-5.2，定价 $1.40/M 输入、$4.40/M 输出，所以你只改 base URL 和 model ID 就能全速托管跑它，不用买、也不用伺候任何机器。你对着本地的 llama-server 做原型，然后把同一个客户端指向托管模型：

export OPENAI_BASE_URL="https://api.ofox.ai/v1"
export OPENAI_API_KEY="ofox-..."
export OPENAI_MODEL="z-ai/glm-5.2"   # 一模一样的模型，现在托管跑

托管接入指南也讲了走 Z.ai Coding Plan 接同一个模型的路子。如果你想在那一个 OpenAI 兼容 endpoint 后面再放几个开源权重 coding 模型，ofox 这几个也是 day-one 就上了：

在你押注本地裸机或托管订阅之前，想看看 GLM 对一个闭源模型的价格与质量对照，见 GLM 5.2 vs GPT-5.5 成本对比。

本次更新核对过的信息源

• HuggingFace 官方 model card，zai-org/GLM-5.2（753B 参数，MIT 许可，1M 上下文），2026-06-23 核对：https://huggingface.co/zai-org/GLM-5.2
• Unsloth GGUF 社区量化及各档内存表，2026-06-23 核对：https://huggingface.co/unsloth/GLM-5.2-GGUF
• Unsloth GLM 5.2 运行指南（量化档大小、采样默认值、KV-cache flag、Unsloth Studio 安装）：https://unsloth.ai/docs/models/glm-5.2
• llama.cpp 项目：https://github.com/ggml-org/llama.cpp
• LM Studio：https://lmstudio.ai
• 配套 ofox 指南：自托管硬件与成本、托管接入、GLM 5.2 vs GPT-5.5 成本

真正有意思的转变，不是一个前沿模型能在本地跑，而是搞清楚它能不能跑，现在成本这么低。一台你本来就有的 256 GB Mac Studio，加一个下午的下载，就是整个实验的全部。下一个值得盯的是 FP4 和更紧的动态量化：哪天一个好用的 4-bit 跌破 200 GB，本地底线就从一台 256 GB Mac 下移到一台 128 GB 的，能上桌的桌子就一下多了不少。