先说结论：如果你手头有 8 张 A100 或者 A800，想跑 GLM-5.2，但发现 vLLM 和 SGLang 官方都报错——你不是一个人。我踩了整整一周的坑，最后总算搞定了。这篇文章就是把我踩过的坑、找到的补丁、验证过的配置全部记录下来，希望能帮你省掉这个时间。

简单说一下背景。GLM-5.2 是 NVIDIA 最近开源的一个 MoE 模型，用的 DSA 稀疏注意力架构（官方叫 GlmMoeDsaForCausalLM，跟 DeepSeek-V3.2 同源的 sparse MLA + indexer 设计）。这玩意儿在推理框架里依赖两个只有 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. 一个预构建 Docker 镜像 — 拉下来就能跑，不用自己折腾编译
2. 两个正在评审的上游 PR — #47629（TRITON_MLA_SPARSE 后端的完整 rebase + SM80 修复）和 #47644（一个影响所有流水线并行用户的核心竞态修复）

如果你等不及官方合入，直接用镜像就行。下面我把完整步骤和原理都写清楚。

---

快速开始

硬件要求

先确认你的环境：

项目	要求
GPU	8× A100/A800 80GB（PCIe 或 SXM 均可）
磁盘	≥ 440 GB（模型权重 435 GB）
驱动	支持 CUDA 12.9（我实测 driver 580.95 没问题）
KV cache	只能 bf16（SM80 上这条路径不支持 fp8 KV）

注意最后一条——KV cache 只能用 bf16，别想着用 fp8 省显存，这条路在 SM80 上没通。后面讲 1M 上下文的时候你会看到，这个限制其实还好，因为 bf16 的 KV cache 在 PP 模式下也能塞下 1M token。

第一步：下载模型权重

pip install -U "huggingface_hub[cli]"
hf download nvidia/GLM-5.2-NVFP4 --local-dir /mnt/data/models/GLM-5.2-NVFP4

这个模型是 NVFP4 量化版，435GB。下载时间取决于你的网络，我这边大概花了 3-4 小时。

这里顺便解释一下为什么用 NVFP4 量化版：SM80 上没有 FP4 张量核，但 Marlin 内核可以在 SM80 上用纯软件方式跑 FP4 量化权重。社区实测 AIME-2026 带工具可以到 99%，精度损失完全可以接受。

第二步：拉取 Docker 镜像

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

这个镜像的内容是完全透明的：基于官方 vllm/vllm-openai nightly（固定在 2026-06-22 的 main，commit 435f82d61），然后 cherry-pick 了 PR #38476，并且解决了 cherry-pick 过程中产生的冲突。构建脚本来自 PR 评论区 @RefalMachine 验证过的配方。

Dockerfile 在这里可以查看，你可以自己审计或者重建。我建议信任但验证——至少看一眼 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.

第一行说明注意力后端正确切换到了 Triton 实现（而不是报错退出）；第二行说明 DeepGEMM 回退成功；第三行说明服务启动完成。

第四步：验证功能

基本对话

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
  }'

正常应该返回 408，并且 reasoning 字段里能看到模型的思考过程。

工具调用

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，我一般给 2000 以上。

---

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

我在 8 张 A800-80G PCIe 上跑的实际数据：

指标	数值
单流 decode	~33 tok/s
4 并发合计	~107 tok/s
79k token prefill	~30 s
KV cache 容量 @131k	202,688 tokens（约 1.55× 并发）
冷启动（含权重加载）	~20 min

A100 SXM（NVLink 互联更好）的话，PR 评论区实测单流能到 39–44 tok/s。这个速度做日常 coding agent、内部知识库问答完全够用。如果你想提高吞吐，可以增加 --max-num-seqs 的值，但要注意显存占用。

---

已知边界（重要，必看）

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

问题一：启动报错 "No common block size for 16"

这个报错的意思是注意力后端没有声明它支持的块大小，导致 vLLM 找不到可用的块大小配置。加 --block-size 128 可以绕过，但根本原因已经在 #47629 修复了——后端缺失块大小声明。

问题二：长上下文 + PP 下随机崩溃 "illegal memory access"

这是 vLLM 核心的一个竞态 bug。简单解释一下：PP 模式下，不同 stage 之间通过 pinned 缓冲区传递数据。pinned 缓冲区的好处是 H2D（Host to Device）拷贝可以异步进行，不阻塞 CPU。但问题在于，PP 的 batch queue 机制下，上一步的异步 H2D 拷贝还没完成，下一步就覆写了同一个 pinned 缓冲区——于是就出现了 illegal memory access。

这个 bug 只在 PP + --no-async-scheduling 组合下触发，TP-only 完全不受影响。修复在 #47644（只有 9 行 diff），但镜像基于 6 月的 main，不包含它。

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

---

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

GLM-5.2 原生支持 1M 上下文（max_position_embeddings: 1048576）。但为什么默认配置只给 131k？因为 MLA 模型的 KV cache 在 TP 下是全卡复制的（每张卡都存一份完整的 KV cache），8×80GB 的显存，131k 基本是极限。

PP 就不一样了——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

关键技巧：不均匀分层

启动时有一个非常关键的技巧——不均匀分层。默认均分（每张卡 12 层）会让最后一个 PP stage 内存不足，因为它不仅要存自己的层权重，还要背着 LM head 和 15 万词表的采样缓冲。这个采样缓冲不小，会吃掉不少显存。

解决方法是把最后一个 stage 减到 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

注意这里 --tensor-parallel-size 1 和 --pipeline-parallel-size 8——TP=1 意味着不做张量并行，只用流水线并行。

实测结果

• 启动成功，日志显示 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 讨论串里的每一位

---

链接汇总

资源	地址
Docker 镜像	docker pull openguardrails/vllm-glm52-sm80:435f82d61-pr38476
后端 PR	https://github.com/vllm-project/vllm/pull/47629
竞态修复 PR	https://github.com/vllm-project/vllm/pull/47644
源码分支	https://github.com/thomaslwang/vllm/tree/triton-mla-sparse-sm80
原始社区讨论	https://github.com/vllm-project/vllm/pull/38476
模型权重	https://huggingface.co/nvidia/GLM-5.2-NVFP4

---

希望这篇笔记能帮你省掉我踩过的那一周的坑。如果跑通了，记得去 PR 下面留个言，让官方知道有人在用——这样合入速度会快很多。