Z.ai 釋出開源模型 GLM-5.2：穩定 1M 上下文主打長程程式設計

GLM-5.2 是 Z.ai 剛剛開源的旗艦級程式設計模型，核心主打需要長時間持續推進的長程複雜任務，並把工程可用的上下文長度直接拉到了 1M token。整個模型遵循 MIT 開源協議釋出，沒有任何地域使用限制，相關技術細節和權重已經在 Hugging Face 和官方部落格公開。

長程任務與實測表現

大多數長上下文模型在面對真實程式碼工程時，往往只是形式上能塞進大量 token，一旦執行軌跡變長就會陷入混亂。GLM-5.2 重點針對耗時數小時甚至數十小時的複雜工程場景進行了大規模訓練，涵蓋底層系統最佳化、編譯器構建、自主研究與複雜除錯。

在衡量長程軟體工程能力的幾個核心基準測試上，GLM-5.2 成為了目前排名最高的開源模型。在針對數小時至數十小時專案的 FrontierSWE 測試中，GLM-5.2 的成績僅比閉源頂尖模型 Claude Opus 4.8 低了 1%，同時以 1% 的優勢擊敗了 GPT-5.5，並領先 Opus 4.7 達 11%。

在評估 Agent 能否利用單張 H100 最佳化小模型的 PostTrainBench 上，它同樣超過了 Opus 4.7 和 GPT-5.5，僅次於 Opus 4.8。在涉及核心最佳化和工業級服務開發的 SWE-Marathon 上，它落後 Opus 4.8 約 13%，依然穩居開源第一。

在常規程式設計測試中，GLM-5.2 同樣大幅重新整理了前代的紀錄。它的 Terminal-Bench 2.1 得分從上一代的 63.5 飆升至 81.0，逼近 Opus 4.8 的 85.0，並領先 Gemini 3.1 Pro；SWE-bench Pro 分數也從 58.4 提升到了 62.1。

為了平衡效能和延遲，GLM-5.2 還引入了思考力度調節機制。使用者可以在輕量任務中使用較低檔位以節省計算資源，在遇到極端複雜的程式碼重構或除錯時開啟 Max 檔位，投入更多推理算力以換取更高的完成度。

怎樣把 1M 上下文跑得又快又穩

把上下文拉長到 1M token，最大的障礙是計算開銷和視訊記憶體瓶頸。GLM-5.2 在架構上提出了名為 IndexShare 的稀疏注意力機制。簡單來說，它讓連續 4 層 Transformer 共享同一個輕量索引器，只在第一層計算 top-k 索引，後三層直接複用。這項改動讓模型在 1M 上下文下的單 token 計算量直接降低了 2.9 倍。

在推測解碼方面，團隊改進了多 token 預測層，通過複用 KV 快取與索引、引入拒絕取樣和端到端全變差損失訓練，消除了前代訓練與推理不一致的缺陷，使投機解碼的平均接受長度提升了 20%。

在部署工程層面，團隊優化了底層推理引擎。通過精細化的視訊記憶體管理擴充套件 KV 快取容量，配合 FP8 格式和 CPU 側的請求排程最佳化，減少 GPU 執行時的流水線空轉。

為了支撐長程強化學習，Z.ai 採用了名為 slime 的基礎設施框架，支援長軌跡壓縮與基於評論家的 PPO 訓練，兩天內就完成了十幾個專家模型的並行融合。針對程式設計智慧體容易偷懶抄答案的現象，團隊還專門設計了反作弊模組，防止模型通過在工作區搜尋隱藏測試用例或呼叫遠端程式碼來刷分。

為什麼重要

如果你正在搭建自主程式碼 Agent，或者需要讓模型一次性消化一整套大型程式碼倉庫，GLM-5.2 是目前開源領域最值得部署的選擇。它徹底抹平了開源模型在超長上下文程式設計任務中與頂尖商業模型之間的代差，甚至在部分嚴苛基準上壓過了 GPT-5.5。

更難得的是它徹底的 MIT 協議和無地域限制策略。不過開發者也需要清醒地看到，即便通過 IndexShare 砍掉了將近三分之二的單 token 算力消耗，1M 上下文帶來的 KV 快取容量壓力依然擺在那裡。要想在本地或私有叢集完整跑滿 1M 上下文的併發服務，硬體門檻和視訊記憶體排程依然是一筆不可忽視的硬成本。