在本地运行 GLM-4.7：优化 Z.ai 的思考模型
- Aisha Washington
- 6月6日
- 讀畢需時 4 分鐘
Z.ai 发布的 GLM-4.7 为开放权重“思考模型”树立了新标杆，在 SWE-bench（73.8%）和 Terminal Bench 2.0（41.0%）上均达到最先进水平。然而，该基础模型体型庞大——拥有 3550 亿参数，需要 400GB 磁盘空间。对大多数人而言，这难以企及。
但情况已发生变化。借助 Unsloth 的 Dynamic 2.0 量化，现在你可以run GLM-4.7 locally 将其压缩至约 135GB，且推理能力损失极小。通过在 llama.cpp 中利用特定的 Mixture-of-Experts (MoE) 卸载策略，该模型现可在高端工作站和特定 GPU+RAM 配置上运行。
本指南详细说明了驯服该模型所需的精确标志、正则命令和硬件设置。
现场笔记：硬件现实与 Unsloth 解决方案
要run GLM-4.7 locally，你必须了解其架构。它是一个 MoE（Mixture of Experts）模型。与密集模型不同，它不会对每个 token 使用所有参数。这种架构允许激进优化，前提是你知道如何在 GPU（VRAM）和 CPU（系统 RAM）之间分配负载。
已验证硬件层级
1. “黄金”消费级设置（2 位动态）
硬件： 1x 24GB GPU（RTX 3090/4090）+ 128GB DDR4/DDR5 RAM。
模型： Unsloth Dynamic 2-bit (UD-Q2_K_XL)。
性能： 可用。你必须使用 MoE 卸载（下文详述）将“专家”层移至系统 RAM，同时保持活动处理在 GPU 上。
2. 高保真设置（4 位）
硬件： 1x 40GB+ GPU（A6000/Mac Studio）+ 205GB+ 系统 RAM。
模型： Q4_K_XL 或 Q4_K_M。
性能： 如果你拥有 205GB 统一内存或组合 VRAM+RAM，预计约 5 tokens per second (t/s)。低于 205GB，由于交换会导致显著减速。
3. Mac Silicon 层级
要求： 192GB 统一内存是获得良好性能的现实下限。理想情况下，205GB+ 可让 4 位量化版本发挥最佳性能。
llama.cpp 的关键配置
在执行任何命令之前，有两个不可或缺的设置必须遵守。忽略这些将导致垃圾输出或聊天循环中断。
1. --jinja 标志
标准 llama.cpp 构建可能难以处理 GLM 的特定聊天模板。你must在启动命令中附加 --jinja 标志。这会强制引擎使用模型中嵌入的 Jinja2 模板，确保正确解析对话历史和“thinking”标签。
2. 温度敏感性
GLM-4.7 是一个“思考”模型，其行为因任务而异。
默认 / Agent / 多轮： 将 Temperature 设置为 1.0，Top_p 设置为 0.95。这是通用推理的最佳点。
基准测试 / 严格编码： 将 Temperature 设置为 0.7，Top_p 设置为 1.0。用于 SWE-bench 类任务，精度优先于创造力。
秘诀：MoE 卸载策略
这是本指南最重要的部分。如果要在 24GB 显卡上运行，不能简单地将所有层加载到 GPU（-ngl 99）。需要选择性地将 MoE“专家”层卸载到系统 RAM。
llama.cpp 通过 -ot（override tensor）标志使用正则表达式实现此功能。
策略 A：最大卸载（最低 VRAM）将所有 MoE 层移至 CPU RAM。这是 24GB 显卡的最安全选择。
codeBash
-ot ".ffn_.*_exps.=CPU"策略 B：平衡卸载（中等 VRAM）如果有更多 VRAM 余量，可以仅卸载 Up/Down 投影层：
codeBash
-ot ".ffn_(up|down)_exps.=CPU"策略 C：混合卸载（自定义）甚至可以从特定深度开始卸载层（例如，从第 6 层开始），将早期层保留在 GPU 上以提高速度：
codeBash
-ot "\.(6|7|8|9|[0-9][0-9])\.ffn_(gate|up|down)_exps.=CPU"运行 GLM-4.7 的分步指南
我们推荐使用 llama.cpp 以获得对内存拆分的最佳控制。
1. 安装依赖项
为大型下载准备传输工具。
codeBash
pip install huggingface_hub hf_transfer2. 下载模型
我们推荐UD-Q2_K_XL版本。它在大小（135GB）和 Unsloth 的“Dynamic 2.0”准确性之间取得平衡，后者在 MMLU 上保持 SOTA 性能。
codePython
import os
from huggingface_hub import snapshot_download
os.environ["HF_HUB_ENABLE_HF_TRANSFER"] = "0" # Set to 0 to avoid rate limits
snapshot_download(
repo_id = "unsloth/GLM-4.7-GGUF",
local_dir = "unsloth/GLM-4.7-GGUF",
allow_patterns = ["*UD-Q2_K_XL*"]
)3. 启动命令
以下是 Linux/WSL 环境（假设 24GB GPU + 128GB RAM 设置）的稳健命令。
codeBash
./llama-cli \
--model unsloth/GLM-4.7-GGUF/UD-Q2_K_XL/GLM-4.7-UD-Q2_K_XL-00001-of-00003.gguf \
--n-gpu-layers 99 \
--jinja \
--threads 32 \
--ctx-size 16384 \
--flash-attn \
--temp 1.0 \
--top-p 0.95 \
-ot ".ffn_.*_exps.=CPU"注意：即使我们设置了 --n-gpu-layers 99，-ot 标志也会覆盖专家层的设置，将其强制到 CPU，同时将注意力头保留在 GPU 上。
高级调优：长上下文与 Ollama 设置
压缩上下文（KV Cache 量化）
GLM-4.7 支持 128k 上下文窗口，但这会大量消耗 RAM。要适应更长文档，应量化 K 和 V 缓存。添加 --cache-type-k q4_1 和 --cache-type-v q4_1 可显著减少内存开销，且准确性损失可忽略。
注意： 必须使用 -DGGML_CUDA_FA_ALL_QUANTS=ON 编译 llama.cpp，才能在量化 V-cache 上使用 Flash Attention。
在 Ollama 中运行
Unsloth 已针对 Ollama 优化了特定量化版本。
1 位原生版本： UD-TQ1 量化可原生运行。
codeBash
OLLAMA_MODELS=unsloth ollama run hf.co/unsloth/GLM-4.7-GGUF:TQ1_0
2 位变通方案： 要在 Ollama 中运行更大的 2 位量化版本，首先需要使用 llama-gguf-split 合并 GGUF 分块，然后通过 Modelfile 或路径将 Ollama 指向单个文件。
FAQ：GLM-4.7 故障排除
问：我收到关于“chat template”或生成不正确的错误。
答： 你忘记了 --jinja 标志。GLM-4.7 requires this specific flag in llama.cpp 来正确处理其系统提示和轮次切换。
问：我的生成速度极慢（低于 1 t/s）。
答： 你可能正在交换到硬盘（SSD/NVMe）。请确保组合 VRAM + 物理 RAM 超过模型大小（2 位版本为 135GB）。如果依赖磁盘交换，性能会大幅下降。
问：我可以在 Mac Studio 上使用 4 位版本吗？
答： 可以，但前提是你拥有 192GB 内存配置（M2/M3 Ultra）。如果只有 128GB，必须坚持使用 Dynamic 2-bit (UD-Q2_K_XL) 版本。
问：保存最多 VRAM 的正则表达式是什么？
答： 使用 -ot ".ffn_.*_exps.=CPU"。这会将all 专家层移至 CPU，仅将模型的“主干”保留在 GPU 上。
问：2 位量化会让模型变笨吗？
答： 使用 Unsloth 的 Dynamic 2.0 方法不会。他们优先保持“智能”层处于更高精度。基准测试显示，2 位版本在编码和逻辑任务上的表现与全精度模型几乎相同，不同于旧的静态量化方法。
