在8×A100上跑通GLM-5.2：开箱即用的Docker镜像（附1M上下文配方）

TL;DR：vLLM / SGLang 官方目前都无法在 A100（SM80）上运行 GLM-5.2。我们基于社区 PR 构建了一个开箱即用的 Docker 镜像 openguardrails/vllm-glm52-sm80，在 8×A800-80G 上完成了完整验证：131k 上下文、单流 ~33 tok/s、工具调用可用；通过源码分支还能跑到 1,048,576（1M）上下文。相关修复正在推动合入 vLLM 官方仓库（#47629、#47644），合入前可以先用本文的镜像。

为什么官方跑不了

GLM-5.2 用的是 DSA 稀疏注意力架构（GlmMoeDsaForCausalLM，和 DeepSeek-V3.2 同源的 sparse MLA + indexer 设计）。vLLM 里这条路径依赖两个只支持 Hopper/Blackwell（SM90+）的库：

• DeepGEMM —— indexer 的 FP8 MQA logits 计算
• FlashMLA-Sparse / FlashAttn-MLA-Sparse —— 稀疏 MLA 注意力本体

A100/A800 是 SM80（Ampere），两者都不可用，启动直接报错。SGLang 的情况类似。也就是说：**大量还在服役的 A100 集群，面对 GLM-5.2 这类新模型是"硬件还行、软件没路"**。

社区一直在补这条路：@haosdent 去年 5 月提交了 PR #38476，用纯 Triton 实现了 TRITON_MLA_SPARSE 后端（SM80/SM121 可用）；后来 @timinar、@RefalMachine 等人陆续贡献了针对 GLM-5.2 的适配步骤。但原 PR 长期没有 rebase，跑通 GLM-5.2 需要手工拼接四五处散落在评论区的补丁。

我们把这些工作整合成了两样东西：

1. 一个预构建镜像（本文主角），拉下来就能跑
2. 两个正在评审的上游 PR：#47629（TRITON_MLA_SPARSE 后端的完整 rebase + SM80 修复）和 #47644（一个影响所有流水线并行用户的核心竞态修复）。合入需要时间和评审流程，等不及的可以先用镜像。

快速开始

硬件要求

第一步：下载模型

pip install -U "huggingface_hub[cli]"
hf download nvidia/GLM-5.2-NVFP4 --local-dir /mnt/data/models/GLM-5.2-NVFP4
# 435GB，视网络情况需要数小时

NVFP4 量化版在 SM80 上通过 Marlin 内核运行（没有 FP4 张量核也没关系），精度损失可接受——社区实测 AIME-2026 带工具可到 99%。

第二步：拉镜像

docker pull openguardrails/vllm-glm52-sm80:435f82d61-pr38476

镜像内容完全透明：官方 vllm/vllm-openai nightly（固定在 2026-06-22 的 main，commit 435f82d61）+ cherry-pick PR #38476 + 冲突解决，构建脚本源自 PR 评论区 @RefalMachine 验证过的配方。Dockerfile 在这里可以自行审计或重建。

第三步：启动

docker run -d --name glm52 \
  --gpus all --ipc host --shm-size 32g \
  -p 8000:8000 \
  -v /mnt/data/models:/models:ro \
  openguardrails/vllm-glm52-sm80:435f82d61-pr38476 \
  --model /models/GLM-5.2-NVFP4 \
  --served-model-name glm-5.2 \
  --host 0.0.0.0 --port 8000 \
  --trust-remote-code \
  --tensor-parallel-size 8 \
  --enable-expert-parallel \
  --dtype bfloat16 --kv-cache-dtype bfloat16 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.95 \
  --max-num-seqs 4 \
  --no-async-scheduling \
  --tool-call-parser glm47 --reasoning-parser glm45 \
  --enable-auto-tool-choice \
  --chat-template-content-format=string

加载 435GB 权重约需 15–25 分钟，请耐心。就绪的标志是日志出现：

Using TRITON_MLA_SPARSE attention backend out of potential backends: ['TRITON_MLA_SPARSE']
DeepGEMM not supported on this platform; using Triton fallback for sparse attention indexer.
...
Application startup complete.

第四步：验证

# 基本对话
curl -s localhost:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{
  "model": "glm-5.2",
  "messages": [{"role":"user","content":"17乘以24等于多少？"}],
  "max_tokens": 2000}'

# 工具调用（glm47 解析器）
curl -s localhost:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{
  "model": "glm-5.2",
  "messages": [{"role":"user","content":"北京今天天气怎么样？"}],
  "tools": [{"type":"function","function":{"name":"get_weather",
    "description":"查询城市天气",
    "parameters":{"type":"object","properties":{"city":{"type":"string"}},"required":["city"]}}}],
  "max_tokens": 2000}'

第二个请求应返回 finish_reason: "tool_calls" 和结构化的 tool_calls 字段。GLM-5.2 是深度思考模型，思考内容在响应的 reasoning 字段里，max_tokens 建议给足（思考会消耗不少 token）。

性能预期（8×A800-80G PCIe 实测）

A100 SXM（NVLink）互联更好，PR 评论区实测单流 39–44 tok/s。这个速度做日常 coding agent、内部知识库问答完全够用；追求吞吐的场景可以提高 --max-num-seqs。

已知边界（重要）

这个镜像只推荐 TP=8（张量并行）模式，也就是上面的启动命令。如果你尝试流水线并行（PP），会遇到两个问题：

1. 启动报 No common block size for 16 —— 加 --block-size 128 可绕过（根因已在 #47629 修复：后端缺失块大小声明）
2. 长上下文 + PP 下随机崩溃 illegal memory access —— 这是 vLLM 核心的一个竞态 bug：PP 的 batch queue 下，pinned 输入缓冲区会在上一步的异步 H2D 拷贝完成前被下一步覆写。只在 PP + --no-async-scheduling 组合下触发，TP-only 完全不受影响。修复在 #47644（9 行 diff），但镜像基于 6 月的 main，不包含它。

顺带一提：如果你在别的模型上见过"运行几小时后输出变成 !!!!!!、logprobs 出现 NaN、重启恢复"的现象（如 #42426），很可能也是这个竞态的静默形态——欢迎用 #47644 验证。

进阶：1M 上下文（需要源码分支）

GLM-5.2 原生支持 1M 上下文（max_position_embeddings: 1048576）。MLA 模型的 KV cache 在 TP 下是全卡复制的，131k 基本是 TP=8 的极限；但 PP 按层切分 KV，8×80GB 足够放下 1M——前提是解决上面两个 PP 问题，所以要用包含全部修复的源码分支：

git clone https://github.com/thomaslwang/vllm && cd vllm
git checkout triton-mla-sparse-sm80
# 叠加竞态修复（PP 必需）
git fetch origin fix-pp-pinned-buffer-race && git cherry-pick FETCH_HEAD

# Python-only 修改，无需编译 CUDA（下载官方预编译内核，几分钟装完）
uv venv --python 3.12 && VLLM_USE_PRECOMPILED=1 uv pip install -e . --torch-backend=auto

启动时有一个关键技巧：不均匀分层。默认均分会让最后一个 PP stage（背着 LM head 和 15 万词表的采样缓冲）内存不足，把它减到 7 层：

VLLM_PP_LAYER_PARTITION="11,10,10,10,10,10,10,7" \
.venv/bin/vllm serve /mnt/data/models/GLM-5.2-NVFP4 \
  --served-model-name glm-5.2 --host 0.0.0.0 --port 8000 \
  --trust-remote-code \
  --tensor-parallel-size 1 --pipeline-parallel-size 8 \
  --dtype bfloat16 --kv-cache-dtype bfloat16 \
  --max-model-len 1048576 --block-size 128 \
  --gpu-memory-utilization 0.96 --max-num-seqs 2 \
  --no-async-scheduling \
  --tool-call-parser glm47 --reasoning-parser glm45 --enable-auto-tool-choice

实测结果：

• 启动成功，GPU KV cache size: 1,062,656 tokens——完整 1M，bf16 KV，不需要 FP8
• 250,857 token 的大海捞针测试（"针"埋在 20 万 token 深度）：精确命中，端到端 108 秒
• 代价是并发（1M 时 1.01×，基本单请求独占）；日常还是建议 TP=8 @131k，长文档场景再切 1M 配置

上游进展与如何帮忙

这套工作正在推动合入 vLLM 官方：

• #47629 —— TRITON_MLA_SPARSE 后端 rebase 到最新 main + SM80 修复（fused indexer 的 fp8e4nv 守卫、块大小声明、SM12x 优先级），保留原作者 @haosdent 的署名
• #47644 —— PP batch queue 的 pinned 缓冲竞态修复，惠及所有流水线并行用户

两个 PR 都已 ready for review，maintainer 已在原 PR 里表态"rebase 后愿意合入"。如果你手上有 A100/A800 并且用这个镜像跑通了，去 PR 下面留一条测试结果（GPU 型号、模型、吞吐即可）——来自真实硬件的验证反馈是推动合入最有效的方式。合入之后，官方 nightly 镜像开箱即用，本文的临时镜像就可以退役了。

致谢

• @haosdent —— TRITON_MLA_SPARSE 后端原作者，这一切的地基
• @timinar、@RefalMachine —— GLM-5.2 适配步骤与 Dockerfile 配方
• @ehfd、@Ph0enix89 —— 持续的测试反馈与关键问题报告
• vLLM 社区 PR #38476 讨论串里的每一位

链接汇总