ciprianveg/gb10-glm-5.2
GitHub: ciprianveg/gb10-glm-5.2
在 8 节点 GB10 集群上通过 TP8+MTP 部署 GLM-5.2-Int4-Int8 量化大模型的高性能推理方案，包含针对 vLLM 的多项深度补丁与调度优化。
Stars: 6 | Forks: 0
# gb10-glm-5.2 — 在 8× DGX Spark (GB10, sm_121) 上运行 GLM-5.2-Int4-Int8Mix
## 概述
在 **8 节点 GB10 集群** 上通过 TP8 + PP1 及 MTP k=4 部署 [QuantTrio/GLM-5.2-Int4-Int8Mix](https://huggingface.co/QuantTrio/GLM-5.2-Int4-Int8Mix) (检查点内 MTP)。
**当前生产环境配置：** TP8 + PP1 (1,211 t/s prefill，35 t/s 连贯语料库 decode，54 t/s 游戏 benchmark，91/100 工具评估 — 依赖 `fix-fsm-toolcall` 修改来实现稳定的 MTP 工具调用)
**实验性配置：** TP4 + PP2 达到 1800tps prefill，但 MTP 接受率受阻，约为 8%，而预期约为 85%
| 配置 | Prefill (t/s) | Decode (t/s) | MTP 接受率 |
|--------|--------------|--------------|----------------|
| **TP8+PP1 (生产)** | **~1,211** | **~35** | ~85% |
| TP4+PP2 (实验) | ~1,800 | ~12 | ~8% |
## 快速开始
```
# 1. Clone dependencies
git clone https://github.com/eugr/spark-vllm-docker ../spark-vllm-docker
cd ../spark-vllm-docker && ./run-recipe.sh --discover # generates .env with cluster IPs
# 2. Build image
cd ../gb10-glm-5.2
./build.sh # builds + copies to all 7 workers (~13 min)
# ./build.sh --solo # 仅 build
# 3. Deploy & run（从 spark-vllm-docker）
cd ../spark-vllm-docker
./run-recipe.sh ../gb10-glm-5.2/recipes/glm52-int4int8-v16.yaml --setup
```
## 构建 Stack
以 CosmicRaisins 的 DCP1 方案 (TP8+PP1, MTP k=4, B12X_MLA_SPARSE) 为起点，此镜像升级至 codex/fathomless-firmament-v16-unified-20260712 统一分支，并添加了针对性的补丁和运行时修改。
### 基础版本
| 组件 | 版本 | 原因 |
|-----------|---------|-----|
| vLLM fork | `local-inference-lab/vllm` @ `5dffea8` (分支 `codex/fathomless-firmament-v16-unified-20260712`) | DSpark 支持，SM120 PCIe 服务，GLM-5.2 MTP kernel，MRv2 model runner，B12X MoE 集成 |
| b12x | `lukealonso/b12x` @ `97b3d64` (master) | W4A8 MoE，统一 SM120 稀疏 MLA，PCIe DCP collectives，decode 优化 (在旧分支上使用 MTP k=4 约为 28–49 t/s → 提升至 33–55 t/s 区间) |
| CUDA | 13.2.0 | GB10 / sm_121 支持 |
| PyTorch | 2.11.0 | 由 v16 分支锁定 |
| FlashInfer | 预构建的 sm_121 wheels | 稀疏 MLA attention kernel |
| NCCL | 2.30.4 (自定义 aarch64) | 支持 3 节点 mesh ring |
| transformers | ≥5.0 (`--tf5` 构建标志) | GLM-5.2 模型定义所需 |
### 补丁 (patches/v16-final/)
| 补丁 | 用途 | 生产环境? |
|-------|---------|:-----------:|
| `01-pr72-1-draft-dcp-config-propagation.patch` | DCP 配置 → draft 模型 (防止在 DCP>1 时 MTP 崩溃)。来自 CosmicRaisins 的 PR #72。 | ✅ |
| `03-draft-quant-packed-mapping.patch` | 量化 NextN draft token 映射 (如果没有此补丁，量化的 draft 会静默构建为未量化，导致 MTP 接受率暴跌)。来自 CosmicRaisins。 | ✅ |
| `04-v16-essential.patch` | 三个修复：(1) DeepSeekMTP `SupportsPP` 接口，(2) flashinfer_sm120 稀疏 MLA 中陈旧的 `topk_indices_buffer` (来自 PR #46994)，(3) PP 下的 MTP `embed_tokens` 加载。 | ✅ |
| `06-b12x-stale-topk-buffer.patch` | 将相同的陈旧 `topk_indices_buffer` 修复应用于 `b12x_mla_sparse.py` (PR #46994 中的修复 #4)。如果没有此补丁，`_maybe_share_lm_head` 会替换 indexer 的 buffer，但后端仍持有陈旧的引用 → 导致无效的 DSA attention 且接受率约为 30% 而非 ~85%。 | ✅ |
| `05-pp-mtp-broadcast-and-draft-relay.patch` | PR #46994 修复 #2 (将 padding 广播至 `max_sample_len`) + 修复 #3 (draft token 中继至非最后一个 PP rank)。 | 仅限 PP2 |
| `07-draft-pp-size-fix.patch` | 设置 draft `pipeline_parallel_size=1` 而不是复制 target 的值。 | 仅限 PP2 |
**生产镜像 (TP8+PP1) 仅使用补丁 01、03、04、06。**
### 运行时修改
**`fix-fsm-toolcall`** (PR #44993) — 修复在工具调用 + MTP 期间出现的 `"Failed to advance FSM"` 错误。v16 fork 已包含 PR #44297 (`trim_reasoning_for_advance`) 和 #46149 (结构化标签中的 `reasoning=reasoning_enabled`)，但 `should_advance()` 仍使用 `num_computed_tokens - num_output_placeholders` 来推导 delta 窗口 —— 这在 MTP 拒绝时会失效 (placeholder 数量保持 >0，窗口起点越过 reasoning-end 标记，语法从未被强制执行 → HTTP 500)。此修改将 `new_token_ids` 直接传递给 `should_advance()`，绕过有缺陷的 placeholder 计算，并将同步推进 (same-step advance) 扩展到所有后端类型。
**`decode-aware-scheduler`** (penguinchang，NVIDIA 开发者论坛 2026-07-15) — 防止在并发负载下，长 prefill 请求耗尽 decode 流的资源。当 decode 处于活动状态时，prefill 被限制在共享的 token 预算内 (生产环境中为 256 tokens/step)；当空闲时，prefill 获得完整的 batched token 预算。每个 step 最多只能有 1 个长 prefill，并进行轮转 (round-robin)。将 decode 停顿从数秒的阻塞减少至约 0.5 秒。有关调优指南，请参见 [mods/decode-aware-scheduler/README.md](mods/decode-aware-scheduler/README.md)。
## 配方文件 (Recipe Files)
- `recipes/glm52-int4int8-v16.yaml` — **生产环境** (TP8+PP1, DCP=1, MTP k=4)
- `recipes/glm52-int4int8-v16-pp2.yaml` — **实验性** (TP4+PP2, MTP k=4, MTP 接受率低)
两个配方文件都引用相同的镜像标签：`vllm-node-tf5-glm52-v16:latest`
## 环境要求
- 8× GB10 / DGX Spark (sm_121, aarch64)
- 节点间 RoCE v2 (ConnectX-7, 子网 192.168.177.0/24)
- 每个节点约 410 GB 权重 (或通过 NFS 挂载)
- eugr/spark-vllm-docker 用于构建 + 部署
## 性能表现 (llama-benchy, 连贯语料库, tg=1500)
| 深度 | Prefill (t/s) | 平均 decode (t/s) | 峰值 decode (t/s) | TTFR (ms) |
|-------|--------------:|-----------------:|------------------:|----------:|
| 0 | 1,211 ± 0.9 | 34.9 ± 2.8 | 53.5 ± 3.5 | 1,693 |
| 4k | 1,117 ± 100.7 | 38.3 ± 0.5 | 58.0 ± 0.0 | 5,461 |
| 16k | 1,215 ± 23.8 | 37.7 ± 0.0 | 58.0 ± 0.0 | 14,867 |
| 32k | 1,176 ± 4.7 | 33.3 ± 2.7 | 54.5 ± 2.5 | 28,963 |
| 100k | 1,128 ± 0.9 | 34.8 ± 3.8 | 51.5 ± 1.5 | 90,448 |
| 200k | 1,019 ± 0.0 | 37.8 ± 0.0 | 50.0 ± 0.0 | 198,327 |
**游戏 benchmark (Snake, 1500 tokens, temp=0, thinking=已禁用)：** 持续速度为 54.16 tok/s
```
=== Game Benchmark (Single-Stream, temp=0, thinking=disabled) ===
Waiting for server to be ready...
Server ready after 1s
Running game benchmark (Snake game generation)...
Completion tokens: 1500
Prompt tokens: 43
Total tokens: 1543
Wall time: 27.69s
Average tok/s: 54.16
```
**代码上下文** (与上述连贯语料库相比)：单一流 (single-stream) 下平均生成速度为 40–55 t/s，在 2 个并发请求下为 60–70 t/s。
**长上下文代码 benchmark** (4000-token 输入，1500-token 输出，单一流)：
```
=== Long-Context Benchmark ===
Type: coding
Target input: 4000 tokens
Output: 1500 tokens
Actual tokens: 3999 tokens (confirmed by server)
Sending request (streaming via httpx)...
============ Result ============
Input tokens: 4012
Output tokens: 1500
Wall time: 34.33s
TTFT: 2996.0 ms
Prefill tok/s: 1339.1
Gen tok/s: 47.8
Mean ITL: 20.9 ms
```
### 工具评估 (tool-eval-bench v2.0.0)
| 指标 | 得分 |
|--------|------:|
| **总体质量** | 91 / 100 (★★★★★ 优秀) |
| 响应能力 | 43 / 100 (中位回合：3.6s) |
| 可部署性 | 77 / 100 (α=0.7) |
| 通过率 | 59 通过，8 部分通过，2 失败 (126/138 pts) |
| Token 效率 | 0.6 pts/1K tokens (共 210K tokens) |
| 最弱类别 | Toolset Scale (62%) |
## 许可证
Apache-2.0 (本仓库)。部署 MIT 权重 (GLM-5.2 由 Z.ai 提供 → QuantTrio 量化版本)。
标签：DLL 劫持, GB10, vLLM, 人工智能, 大语言模型, 推理优化, 模型量化, 用户模式Hook绕过, 请求拦截, 逆向工具, 集群计算