Code Arena全球可用模型第一！智谱GLM-5.2上线并开源

SuaniCommunity

503人浏览 · 2026-06-17 14:42:04

SuaniCommunity · 2026-06-17 14:42:04 发布

刚刚，智谱上线并开源GLM-5.2。

全球百万用户参与盲测的前端开发评估系统Code Arena上，GLM-5.2取得全球可用模型第一（Claude Fable 5未解禁）。

全球最大的众包设计基准平台上，甚至超越未解禁的Claude Fable 5，取得第一。

GLM-5.2支持100万token上下文上，长程任务表现出色，同时以MIT协议完全开源。

长任务跑分

100万的上下文说起来容易，但在真正的工程压力下保持可靠性非常难。

GLM-5.2大幅扩展了针对编码智能体场景的100万上下文训练，涵盖大规模实现、自动化研究、性能优化和复杂调试。在三个长任务编程基准上表现优异。

FrontierSWE衡量智能体能否完成数小时到数十小时量级的开放性技术项目，覆盖系统优化、大规模代码构建和应用机器学习研究。GLM-5.2只落后Opus 4.8 1%，领先GPT-5.5 1%，领先Opus 4.7 11%。

PostTrainBench给每个智能体分配一张H100 GPU，看它能通过后训练把小模型改进多少，GLM-5.2超过Opus 4.7和GPT-5.5，仅次于Opus 4.8。

SWE-Marathon是超长任务软件工程基准，任务涉及构建编译器、优化算子、开发生产级服务，GLM-5.2与Opus 4.8还有13%差距，仍排第二，仅次于Opus系列。

三个基准，GLM-5.2是排名最高的开源模型，1M上下文确实转化成了实际的长任务交付能力。

在标准编程基准上，GLM-5.2是最强的开源模型，相比GLM-5.1提升明显，Terminal-Bench 2.1上81.0对63.5，SWE-bench Pro上62.1对58.4。

也基本追平闭源前沿，Terminal-Bench 2.1的81.0距离Claude Opus 4.8的85.0只差几点，同时领先Gemini 3.1 Pro。下图是标准编程基准的完整对比。

GLM-5.2还引入effort level（思考努力级别）控制，让用户显式平衡模型能力和任务执行速度、计算成本。

在相近token预算下，GLM-5.2的智能体编程表现明显强于GLM-5.1，能力大致位于Claude Opus 4.7和4.8之间。Max级别允许用户在难题上多花算力，进一步延展编程能力。

架构突破

为支撑1M上下文，GLM-5.2在架构上做了多项改动，整体结构见下图。

GLM-5.2把IndexShare用到DSA（Dynamic Sparse Attention，动态稀疏注意力）上，降低indexer（索引器）计算成本。

具体做法是每4个transformer层共享一个轻量级indexer，放在4层中的首层，topk索引被4层共用，省掉3/4层的indexer点积和topk运算。

1M上下文长度下，单token FLOPs减少2.9倍。

GLM-5.2从中间训练阶段就用128K序列长度配IndexShare训练，比GLM-5.1在长上下文基准上算得更少，跑得更好。稀疏注意力的核心痛点一直是indexer本身的开销随上下文变长急剧膨胀，IndexShare把这部分开销摊薄到4层上，长上下文才真正可工程化。

MTP（Multi-Token Prediction，多token预测）层用于投机解码，GLM-5.2也做了改进。

投机解码是现今大模型推理加速的主流手段之一，一次推测多个候选token再由目标模型验证，接受长度越长，推理越快。

两个目标，一是把MTP层当draft model（草稿模型）的成本降到最低，二是把投机解码接受率拉到最高。MTP层结构见下图。

为降低MTP层成本，MTP层上也用了IndexShare。

下表是各技术对接受长度的消融实验结果，用GLM-5.1的backbone和训练数据，训练和推理都设MTP步数为7。和基线比，最终MTP层接受长度提升20%。

GLM-5.2把最大上下文从200K扩到1M token，编程负载会更明显地向长prompt倾斜。推理瓶颈从计算量转到KV cache容量、长上下文kernel开销和CPU侧开销。在有限GPU资源下同时支撑更长上下文、更高并发、更高token吞吐，成了推理引擎优化的核心挑战，下图展示不同上下文长度下的吞吐表现。

团队沿三个方向优化推理引擎。一是在LayerSplit基础上引入更细粒度的内存管理和并行策略，提升KV cache容量，给超长上下文请求更多可用缓存空间。二是优化成本随上下文长度增长的kernel，让它和cache传输管线更好协同，把cache传输对prefill和decode性能的影响降到最小。三是优化CPU侧cache管理、请求调度和运行时执行路径，减少GPU执行管线的气泡，提升端到端吞吐。上下文越长，GLM-5.2的吞吐优势越大，长上下文推理场景下扩展性更强。