各位六千系列用户，欢呼吧！

我们的“GLM”已经就位了
https://t.co/pAUQf4WPpe

0xSero/glm-5.2-sm120

来源：https://github.com/0xSero/glm-5.2-sm120

GLM-5.2-NVFP4-REAP-469B — 基于 vLLM 的服务（4× RTX PRO 6000 Blackwell）

一套开箱即用的 Docker 配置，用于在 4× NVIDIA RTX PRO 6000 Blackwell（SM120，单卡 96 GB） 上运行 0xSero/GLM-5.2-NVFP4-REAP-469B (https://huggingface.co/0xSero/GLM-5.2-NVFP4-REAP-469B)（经 REAP 剪枝、NVFP4 量化、DeepSeek 稀疏注意力）模型，并使用 voipmonitor 的 b12x vLLM 镜像。

模型： huggingface.co/0xSero/GLM-5.2-NVFP4-REAP-469B (https://huggingface.co/0xSero/GLM-5.2-NVFP4-REAP-469B) · 磁盘占用约 313 GB（NVFP4）· 经 REAP 剪枝的 469B MoE · DeepSeek 稀疏注意力 + MTP。

已验证配置：DCP=4 · 250k 上下文 · 约 3 倍并发 · 约 60 tok/s 解码 · fp8 KV 缓存 · MTP 推测解码 · 工具调用 · 默认关闭思考功能（可开启）。

硬件目标

前提条件

• Docker + NVIDIA Container Toolkit。
• 拥有 b12x 镜像的访问权限（voipmonitor/vllm:black-benediction-...）。该镜像是唯一集成了 GlmMoeDsaForCausalLM + Glm4MoeMTPModel + SM120 稀疏 MLA 内核 (B12X_MLA_SPARSE) + ModelOpt NVFP4 MoE 加载器的镜像。
• 模型权重需存放在本地路径（默认为 /mnt/llm_models/GLM-5.2-NVFP4-REAP-469B）。

快速开始 — 一条命令

# 1. 下载权重（约 313 GB NVFP4）—— 需要安装 hf CLI：pip install -U huggingface_hub
hf download 0xSero/GLM-5.2-NVFP4-REAP-469B --local-dir /mnt/llm_models/GLM-5.2-NVFP4-REAP-469B

# 2. （可选）修改权重路径 / 端口
cp .env.example .env        # 默认已指向 /mnt/llm_models/...，端口 8000

# 3. 启动。该命令会启动服务器，等待就绪，并进行快速测试。
./launch.sh

launch.sh 会阻塞直到服务器真正响应，然后输出：

  ✅ 就绪 — GLM-5.2 正在服务，并已响应：READY
  端点 : http://localhost:8000/v1   （模型：GLM-5.2-NVFP4-REAP-469B）
  尝试使用 : ./chat.sh "写一首关于GPU的俳句"

（首次启动会编译内核并捕获 CUDA graphs，约需 6 分钟 — launch.sh 会等待完成，若失败则显示日志。）之后即可与其对话：

./chat.sh "用三点解释快速排序"
# 或直接调用 OpenAI 兼容 API：
curl -s http://localhost:8000/v1/chat/completions -H 'Content-Type: application/json' \
  -d '{"model":"GLM-5.2-NVFP4-REAP-469B","messages":[{"role":"user","content":"hello"}]}'

docker compose up -d 同样可用（配置相同，默认关闭思考功能）。

推理（思考）— 默认关闭，开箱即用

GLM-5.2 是一个推理模型。思考功能默认是关闭的，因此即使 max_tokens 较小，普通请求也会在 message.content 中直接返回答案。

为什么重要：开启思考的推理模型会先消耗 token 预算用于“思考”。如果 max_tokens 设置得短，回答前的思考过程就会耗尽预算，导致 content 返回为空（finish_reason: "length"）。默认关闭思考功能可以完全避免这种情况 — 端点行为与普通聊天模型一致。

想要思维链（在困难的数学/代码/逻辑问题上表现更佳）？开启它：

ENABLE_THINKING=1 ./launch.sh          # 重新启动并启用推理
./chat.sh --think "证明 sqrt(2) 是无理数"

当 ENABLE_THINKING=1 时，服务器会添加 --reasoning-parser glm45，因此思维链会流式进入 message.reasoning，答案进入 message.content。请为思考请求设置充足的 max_tokens（≥ 2000）。

工具调用（--tool-call-parser glm47）在两种模式下均可正常工作 — 按惯例解析 message.tool_calls。

已验证配置

为何 index_topk_pattern 对连贯性至关重要

GLM-5.2 使用 DeepSeek 稀疏注意力。vLLM 读取的是 index_topk_pattern，而非检查点中的 indexer_types 数组。没有此模式时，全部 78 层都会构建完整的 indexer，其中的 57 个“共享/跳过”(S) 层会破坏长上下文注意力 → 产生垃圾输出。78 字符的 F/S 字符串（21 个 F，57 个 S）源自模型的 indexer_types，并通过 --hf-overrides 注入。启动时您应看到 57 行日志：Using index_topk_pattern/index_topk_freq to skip sparse MLA indexer ...。

为何使用 DCP_SIZE=4

当 DCP=1 时，MLA KV 缓存会在每个 TP rank 上复制，因此单个 250k 请求需要约 14.5 GB，但每 GPU 仅有约 10.3 GB 空闲 → 显存不足（最大约 177k）。decode-context-parallel-size=4 将 KV 沿着序列维度分片到 4 张 GPU 上，得到 710,593 token 的池。

DCP=4 是最佳方案 — 250k 上下文，约 3 倍并发

DCP=4 是默认配置，也是经过验证的旗舰方案：250k 上下文 · 约 3 倍并发（710,593 token KV 池）· 约 60 tok/s 解码（热启动，启用 MTP）。将 MLA KV 沿着序列维度分片到 4 张 GPU 上，是实现 250k 上下文的关键。

测量条件：温度 0，b12x，MTP=3，fp8 KV。解码为稳态，且与 MTP 接受率相关（短上下文热启动约 60 tok/s）。冷启动 TTFT 受编译主导 — 对于新提示长度的首次请求会即时编译该长度桶（耗时数十秒），之后热启动 / 前缀缓存命中则快速。首次请求响应慢是内核缓存预热的表现，并非死机。

如果您仅需要较小、更快且上下文 ≤128k 的配置，可在 .env 中设置 DCP_SIZE=1 + MAX_MODEL_LEN=131072（约 81 tok/s，但上限约 131k，失去 250k / 约 3 倍并发的余量）。

为何需要 NCCL_P2P_DISABLE=1

这些 RTX PRO 6000 基于 PCIe（无 NVLink）；b12x 的 PCIe allreduce 路径若不禁用 P2P，会在 NCCL 初始化时死锁。

性能（实测，热启动）

首次接触全新长前缀会进行一次该长度桶的单次编译（例如，全新的 99.5k 提示约需 195 秒）。后续相同长度的预填充和前缀缓存命中则快速。

测试

python3 test/coherence_test.py core         # 逻辑、数学、代码、哲学、ASCII、多轮对话
python3 test/coherence_test.py long         # 64k 大海捞针召回测试
python3 test/longctx_multiturn_test.py      # 约 100k token，6 轮推理测试

所有测试均以无 max_tokens 方式流式输出，并报告 TTFT、预填充 tok/s 和解码 tok/s。推理模型会在 reasoning 字段中输出思维链，最终答案在 content 中。

SM120 上的 fp8 / fp4 KV 缓存

• fp8 KV (fp8_ds_mla) 可用，且是实际的底线。检查点未提供 k/v_scale，因此 fp8 以 scale 1.0 运行（启动时会有单行警告）。
• fp4 KV 在 SM120 上被硬件阻止：DSA fp4 索引器缓存断言要求 SM100（数据中心级 Blackwell，B200/GB200）。RTX PRO 6000 不可用。

故障排除