GLM-5.2 发布之后圈子里讨论得挺热闹。这个模型在代码生成和智能体任务上的表现确实亮眼但有个挺现实的问题摆在很多团队面前——手上那批还在服役的 A100 或者 A800 集群官方 vLLM 和 SGLang 居然直接跑不起来。不是硬件不够强是软件层面的支持缺了一块。这篇文章把我们在八卡 A800-80G 上完整验证的过程整理出来包括怎么绕过 SM80 的架构限制、实测性能数据以及怎么推到百万级上下文。相关的修复正在往 vLLM 上游合合入之前可以先拿我们打包好的镜像直接用。官方为什么跑不了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 都是 Ampere 架构SM80这两个库一启动就报错。SGLang 那边情况也差不多。结果就是大量还在产线服役的 A100 集群面对 GLM-5.2 这种新模型硬件性能其实完全够用但软件层面没有路可走。社区方案的来龙去脉这个问题社区其实一直在补。去年五月 haosdent 就提交了 PR #38476用纯 Triton 实现了 TRITON_MLA_SPARSE 后端SM80 和 SM121 都能跑。后来 timinar、RefalMachine 这些人陆续在评论区补充了针对 GLM-5.2 的适配步骤。但原 PR 长期没有 rebase想跑通 GLM-5.2 得手动拼接四五处散落在评论区的补丁挺折腾的。我们把这些工作整合成了两样东西一个预构建的 Docker 镜像拉下来就能跑还有两个正在评审的上游 PR分别是 #47629 和 #47644。#47629 把 TRITON_MLA_SPARSE 后端完整 rebase 到了最新 main加上 SM80 的修复包括 fused indexer 的 fp8e4nv 守卫、块大小声明、SM12x 优先级这些细节。#47644 则是一个核心竞态修复影响所有用流水线并行的用户。两个 PR 都已经 ready for reviewmaintainer 也在原 PR 里表态说 rebase 后愿意合入。环境准备与硬件要求想跑这个镜像手头需要八张 A100 或者 A80080GB 显存版本PCIe 或者 SXM 都可以。磁盘至少留出 440GB因为模型权重就有 435GB。驱动方面我们实测过 580.95支持 CUDA 12.9 就行。KV cache 只能走 bf16SM80 上这条路径不支持 fp8 KV。模型权重从 Hugging Face 下载NVFP4 量化版在 SM80 上通过 Marlin 内核跑没有 FP4 张量核也没关系。社区实测 AIME-2026 带工具能到 99%精度损失在可接受范围。镜像使用与启动流程镜像基于官方 vllm/vllm-openainightly固定在 2026 年 6 月 22 日的 maincommit 435f82d61然后 cherry-pick 了 PR #38476冲突也处理好了。构建脚本来自 PR 评论区 RefalMachine 验证过的配方Dockerfile 完全公开可以自行审计或者重建。拉镜像之后启动参数需要特别注意几个点。张量并行开八卡启用专家并行dtype 和 kv-cache-dtype 都指定 bfloat16max-model-len 先设 131072。gpu-memory-utilization 拉到 0.95max-num-seqs 设 4关掉异步调度。工具调用解析器用 glm47推理解析器用 glm45再打开自动工具选择和字符串格式的 chat template。加载 435GB 权重大概需要十五到二十五分钟日志里出现这两行就说明稳了plainUsing 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就可以开始验证了。实测性能与验证结果我们在八卡 A800-80G PCIe 上跑了一圈数据如下。单流 decode 速度大概每秒三十三个 token四并发合计能到一百零七 tok/s。七万九千 token 的 prefill 大概三十秒完成。KV cache 容量在十三万一千上下文下能放二十万零两千多个 token并发系数 1.55 左右。冷启动连权重加载一起算二十分钟上下。如果是 A100 SXM 版本NVLink 互联更好社区有人测到单流三十九到四十四 tok/s。这个速度做日常 coding agent 或者内部知识库问答完全够用追求吞吐的场景可以把 max-num-seqs 往上调。验证的时候先跑基础对话再测工具调用。GLM-5.2 是深度思考模型思考内容放在 reasoning 字段里所以 max_tokens 建议给足不然思考过程就把额度吃光了。工具调用的请求返回 finish_reason 为 tool_calls同时带出结构化的 tool_calls 字段就算跑通了。需要注意的边界这个镜像目前只推荐张量并行八卡的模式。如果尝试流水线并行会遇到两个坑。第一个是启动报 No common block size for 16加 --block-size 128 可以绕过根因是后端缺失块大小声明已经在 #47629 里修复了。第二个更隐蔽长上下文加流水线并行下会随机崩溃报 illegal memory access。这是 vLLM 核心里的一个竞态 bug流水线并行的 batch queue 下pinned 输入缓冲区会在上一步的异步 H2D 拷贝完成前被下一步覆写。只在流水线并行加 --no-async-scheduling 的组合下触发纯张量并行完全不受影响。修复在 #47644 里只有九行 diff但镜像基于六月的 main不包含这个修复。顺带提一句如果你在其他模型上见过运行几小时后输出变成一串感叹号、logprobs 出现 NaN、重启就恢复的现象比如 issue #42426 里报告的很可能也是这个竞态的静默形态。用 #47644 验证一下应该就能确认。百万级上下文的进阶玩法GLM-5.2 原生支持百万级上下文max_position_embeddings 设到了 1048576。MLA 模型的 KV cache 在张量并行下是全卡复制的十三万一千基本就是八卡张量并行的极限。但流水线并行按层切分 KV八张八十GB 的卡足够放下百万上下文——前提是解决上面说的两个流水线并行问题。所以得用包含全部修复的源码分支。clone 下来之后切到 triton-mla-sparse-sm80 分支再 cherry-pick 竞态修复。Python-only 的修改不需要编译 CUDA下载官方预编译内核几分钟就能装完。启动的时候有个关键技巧不均匀分层。默认均分会让最后一个流水线 stage 背着 LM head 和十五万词表的采样缓冲内存直接爆掉。把最后一层减到七层前面几层按 11、10、10、10、10、10、10、7 这样分配就能顺利启动。实测结果挺稳的。GPU KV cache size 能到 1,062,656 tokens完整百万上下文bf16 KV不需要 FP8。二十五万 token 的大海捞针测试把针埋在二十万 token 深度精确命中端到端一百零八秒。代价是并发基本只能单请求独占系数 1.01。日常用还是建议张量并行八卡跑十三万一千上下文遇到长文档场景再切百万配置。上游进展与怎么帮忙这套工作正在往 vLLM 官方合。#47629 保留了原作者 haosdent 的署名#47644 惠及所有流水线并行用户。如果你手上有 A100 或者 A800用这个镜像跑通了去 PR 下面留一条测试结果就行——GPU 型号、模型、吞吐这些数据就够了。来自真实硬件的验证反馈是推动合入最有效的方式。等合入之后官方 nightly 镜像就能开箱即用这个临时镜像也就可以退役了。资源汇总Docker 镜像openguardrails/vllm-glm52-sm80:435f82d61-pr38476后端 PRvllm-project/vllm/pull/47629竞态修复 PRvllm-project/vllm/pull/47644源码分支github.com/thomaslwang/vllm/tree/triton-mla-sparse-sm80原始社区讨论vllm-project/vllm/pull/38476模型权重huggingface.co/nvidia/GLM-5.2-NVFP4致谢haosdent 是 TRITON_MLA_SPARSE 后端的原作者这一切的地基是他打的。timinar 和 RefalMachine 贡献了 GLM-5.2 的适配步骤和 Dockerfile 配方。ehfd 和 Ph0enix89 持续提供测试反馈和关键问题报告。还有 vLLM 社区 PR #38476 讨论串里的每一位参与者。