GLM-5.2-Int4-Int8 在 8× GB10 上：约 1,200 t/s 预填充，33–54 t/s 平均解码

Reddit r/LocalLLaMA 工具
glm-5.2 quantization inference gb10 dgx-spark tool-calling vllm

摘要

描述了在 8 节点 DGX Spark (GB10) 集群上使用定制 vLLM 分支部署和基准测试量化后的 GLM-5.2-Int4-Int8Mix 模型，实现了约 1,200 t/s 的预填充和约 35 t/s 的解码，支持 MTP 工具调用。

暂无内容
查看原文
查看缓存全文

缓存时间: 2026/07/14 22:32

ciprianveg/gb10-glm-5.2

Source: https://github.com/ciprianveg/gb10-glm-5.2

gb10-glm-5.2 — 在 8× DGX Spark (GB10, sm_121) 上运行 GLM-5.2-Int4-Int8Mix

概述

通过 TP8 + PP1 + MTP k=4 配置，在 8 节点 GB10 集群 上服务 QuantTrio/GLM-5.2-Int4-Int8Mix 模型（https://huggingface.co/QuantTrio/GLM-5.2-Int4-Int8Mix）（包含检查点内 MTP）。

当前生产配置： TP8 + PP1（预填充 1,211 t/s，解码连贯语料 35 t/s，游戏基准 54 t/s，工具评估 91/100 —— 依赖 fix-fsm-toolcall 模块实现稳定的 MTP 工具调用） 实验配置： TP4 + PP2 预填充 1800 tps，但 MTP 接受率仅 ~8%，远低于预期的 ~85%

配置预填充 (t/s)解码 (t/s)MTP 接受率
TP8+PP1 (生产)~1,211~35~85%
TP4+PP2 (实验)~1,800~12~8%

快速开始

# 1. 克隆依赖
git clone https://github.com/eugr/spark-vllm-docker ../spark-vllm-docker
cd ../spark-vllm-docker && ./run-recipe.sh --discover  # 生成包含集群 IP 的 .env 文件

# 2. 构建镜像
cd ../gb10-glm-5.2
./build.sh                # 构建镜像并复制到所有 7 个工作节点 (~13 分钟)
# ./build.sh --solo       # 仅构建

# 3. 部署并运行（在 spark-vllm-docker 目录下）
cd ../spark-vllm-docker
./run-recipe.sh ../gb10-glm-5.2/recipes/glm52-int4int8-v16.yaml --setup

构建栈

从 CosmicRaisins 的 DCP1 方案（TP8+PP1, MTP k=4, B12X_MLA_SPARSE）出发，此镜像升级至 codex/fathomless-firmament-v16-unified-20260712 统一分支，并添加了针对性补丁及运行时修改。

基础版本

组件版本原因
vLLM forklocal-inference-lab/vllm @ 5dffea8 (分支 codex/fathomless-firmament-v16-unified-20260712)DSpark 支持、SM120 PCIe 服务、GLM-5.2 MTP 内核、MRv2 模型运行器、B12X MoE 集成
b12xlukealonso/b12x @ 97b3d64 (master)W4A8 MoE、统一 SM120 稀疏 MLA、PCIe DCP 集合、解码优化（之前分支上 MTP k=4 时 ~28–49 t/s → 现在 33–55 t/s 范围）
CUDA13.2.0GB10 / sm_121 支持
PyTorch2.11.0由 v16 分支固定
FlashInfer预构建的 sm_121 wheels稀疏 MLA 注意力内核
NCCL2.30.4 (自定义 aarch64)3 节点网格环支持
transformers≥5.0（--tf5 构建标志）需要用于 GLM-5.2 模型定义

补丁 (patches/v16-final/)

补丁用途生产环境？
01-pr72-1-draft-dcp-config-propagation.patchDCP 配置 → 草稿模型（防止 DCP>1 时 MTP 崩溃）。来自 CosmicRaisins 的 PR #72。✅
03-draft-quant-packed-mapping.patch量化 NextN 草稿词元映射（否则量化草稿会静默构建为非量化版本，导致 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 会替换索引器的缓冲区，但后端持有陈旧引用 → 垃圾 DSA 注意力，接受率仅 ~30% 而非 ~85%。✅
05-pp-mtp-broadcast-and-draft-relay.patchPR #46994 修复 #2（广播填充至 max_sample_len）+ 修复 #3（将草稿词元中继到非最后 PP 等级）。仅 PP2
07-draft-pp-size-fix.patch将草稿的 pipeline_parallel_size 设置为 1，而不是复制目标的设置。仅 PP2

生产镜像 (TP8+PP1) 仅使用补丁 01、03、04、06。

运行时修改 (mods/fix-fsm-toolcall/)

fix-fsm-toolcall (PR #44993) — 修复工具调用 + MTP 期间的 "Failed to advance FSM" 错误。v16 分支已包含 PR #44297 (trim_reasoning_for_advance) 和 #46149（结构标签中的 reasoning=reasoning_enabled），但 should_advance() 仍使用 num_computed_tokens - num_output_placeholders 来推导 delta 窗口 —— 这在 MTP 拒绝时失效（占位符计数保持 >0，窗口起始位置越过推理结束标记，语法永远无法执行 → HTTP 500）。此修改将 new_token_ids 直接传递给 should_advance()，绕过了损坏的占位符计算，并将同步骤推进扩展到所有后端类型。

配方文件

  • 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)

深度预填充 (t/s)平均解码 (t/s)峰值解码 (t/s)TTFR (ms)
01,211 ± 0.934.9 ± 2.853.5 ± 3.51,693
4k1,117 ± 100.738.3 ± 0.558.0 ± 0.05,461
16k1,215 ± 23.837.7 ± 0.058.0 ± 0.014,867
32k1,176 ± 4.733.3 ± 2.754.5 ± 2.528,963
100k1,128 ± 0.934.8 ± 3.851.5 ± 1.590,448
200k1,019 ± 0.037.8 ± 0.050.0 ± 0.0198,327

游戏基准 (贪吃蛇, 1500 词元, temp=0, thinking=disabled): 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

编码上下文（与上方连贯语料对比）：单流平均生成 40–55 t/s，2 个并发请求时 60–70 t/s。

长上下文编码基准（4000 词元输入，1500 词元输出，单流）：

=== 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)
词元效率0.6 pts/1K 词元 (总计 210K 词元)
最弱类别工具集规模 (62%)

归属与致谢

本工作站在巨人的肩膀上：

贡献来源
基础 GLM-5.2-on-GB10 栈 — DCP 补丁 (PR #72)、index_topk_pattern 覆盖、B12X 配置、draft-quant-packed-mapping 修复、eugr/spark-vllm-docker 构建系统CosmicRaisins/glm-5.2-gb10 (https://github.com/CosmicRaisins/glm-5.2-gb10)
vLLM v16 分支 (DSpark, SM120 PCIe 服务, GLM MTP 修复, B12X MoE 内核, 默认 MRv2)local-inference-lab/vllm (https://github.com/local-inference-lab/vllm) @ codex/fathomless-firmament-v16-unified-20260712
b12x (W4A8 MoE, 统一 SM120 稀疏 MLA, PCIe DCP 集合, 80eb49b 解码优化)lukealonso/b12x (https://github.com/lukealonso/b12x) @ 97b3d64
PR #72 (DCP 草稿配置传播, B12X 的 topk_scores_buffer, build_for_drafting)m9e / voipmonitor
PR #46994 (V2+MTP+PP: SupportsPP, 广播填充, 草稿中继, embed_tokens, 陈旧 topk 修复)eastwood-c / vllm-project
FlashInfer SM120 内核FlashInfer 团队
DeepGEMM SM120 支持DeepSeek AI
QuantTrio GLM-5.2-Int4-Int8Mix (256 专家, 检查点内 MTP)QuantTrio / cyankiwi
NCCL 2.30.4 aarch64 wheelNVIDIA
eugr/spark-vllm-docker 构建系统 (多阶段 Docker, wheel 缓存, SCP 部署)ciprian / eugr

完整致谢见 ATTRIBUTION.md。

许可证

Apache-2.0 (本仓库)。服务 MIT 许可的权重 (GLM-5.2 由 Z.ai → QuantTrio 量化)。

相似文章