我們隆重推出 GLM-5.2，這是我們專為長任務設計的最新旗艦模型。相較於前一代 GLM-5.1，它在處理長任務的能力上取得了顯著飛躍，並且首次在穩固的百萬級（1M）token 上下文中實現了這項能力。GLM-5.2 的新功能包括：
穩固的百萬級上下文：提供穩定的百萬級 token 上下文，能可靠地支援長任務工作。
彈性努力的高級程式碼生成：具備更強大的程式碼生成能力，並提供多種思考努力程度，以平衡效能與延遲。
改進的架構：我們提出了 IndexShare 技術，它在每四個稀疏注意力層中重複使用相同的索引器，在百萬級上下文長度下，將每個 token 的 FLOPs 減少了 2.9 倍。我們還改進了 GLM-5.2 的 MTP 層，用於推測解碼（speculative decoding），將接受長度提高了高達 20%。
純粹開源：採用 MIT 開源許可證，無地域限制，技術存取無國界。
支援長任務的關鍵在於讓長上下文具備工程實用性：模型必須在冗長且複雜的程式碼代理軌跡中保持品質，而不僅僅是接受更多 token。聲稱擁有百萬級上下文很容易，但在實際工程壓力下保持其可靠性則困難得多。
為此，我們大幅擴展了針對程式碼代理情境的百萬級上下文訓練，涵蓋了大規模實作、自動化研究、效能最佳化和複雜除錯。最終成果是一個不僅範圍廣泛，而且執行穩固的長上下文系統，為持續的工程工作提供了實用的基礎。
GLM-5.2 在三個長任務程式碼基準測試中的表現，充分體現了其強大能力。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 是排名最高的開源模型，證明其百萬級上下文已轉化為實用的長任務交付能力。
在標準程式碼基準測試中，GLM-5.2 是最強大的開源模型，相較於 GLM-5.1 有顯著提升：在 Terminal-Bench 2.1 上從 63.5 提升至 81.0，在 SWE-bench Pro 上從 58.4 提升至 62.1。它也大幅縮小了與閉源頂尖模型的差距，在 Terminal-Bench 2.1 上（81.0）僅與 Claude Opus 4.8（85.0）相差幾分，同時領先 Gemini 3.1 Pro。
GLM-5.2 還引入了「努力程度控制」功能，讓使用者能夠明確平衡模型能力、任務執行速度和計算成本。如圖所示，在相似的 token 預算下，GLM-5.2 提供了比 GLM-5.1 更強大的代理程式程式碼生成效能，其能力大致介於 Claude Opus 4.7 和 Claude Opus 4.8 之間。
此外，「最大努力（Max effort）」等級允許使用者在需要更高效能的挑戰性任務中分配額外計算資源，進一步擴展了模型的程式碼生成能力。這項設計為使用者在使用 GLM-5.2 執行程式碼任務時提供了更大的靈活性，讓他們能針對不同情境選擇最適合的推理模式。
為了支援百萬級上下文長度，GLM-5.2 應用了 IndexShare 技術，以降低 DSA 中索引器的計算成本。具體來說，在 GLM-5.2 中，每四個 Transformer 層共享一個輕量級索引器。該索引器放置在四個層中的第一個，並且其 topk 索引會被這四個層共用。
這項設計減少了四分之三層中索引器點積和 topk 操作的計算量。GLM-5.2 從訓練中期開始，在 128K 序列長度下使用 IndexShare 進行訓練，在長上下文基準測試中以更少的計算量超越了 GLM-5.1。
我們改進了 GLM-5.2 的 MTP 層，用於推測解碼，主要有兩個目標：一是最小化 MTP 層作為草稿模型的成本；二是最大化推測解碼的接受率。
針對第一個目標，我們也在 MTP 層應用了 IndexShare。在多步驟 MTP 中，索引器放置在第一個步驟，並且其 topk 索引會用於所有後續步驟。然而，與主幹網路不同的是，不同 MTP 步驟的輸入 token 是不同的。
如圖所示，如果我們將 $h_4$ 的 topk 索引重用於 $h_5$，那麼 $h_5$ 只能關注 $h_1$ 到 $h_4$，而不能關注 $h_5$ 本身。我們將展示這個特性如何透過消除 GLM-5.1 MTP 層中的訓練與推論差異，幫助我們實現第二個目標。
在上圖中，我們展示了一個兩步驟 MTP 層的推論過程。在第一個步驟中，推論與訓練保持一致，所有隱藏狀態都來自目標模型。然而，在第二個步驟中，$h_{1:4}$ 來自目標模型，而 $h_5$ 來自 MTP 層。
因此，$h_5$ 的 KV 快取是從目標模型計算的 $kv_{1:4}$ 和從 MTP 層計算的 $kv_5$ 的混合。相反地，透過 IndexShare，$h_5$ 的 KV 快取僅包含 $kv_{1:4}$，且全部來自目標模型的隱藏狀態。在訓練時，我們重複使用第一個 MTP 步驟的 KV 快取和 topk 索引。
值得注意的是，與 GLM-5.1 相同，不同 MTP 步驟的參數也是共享的。此外，受 https://arxiv.org/abs/2606.12370 的啟發，我們引入了推測解碼的拒絕採樣（rejection sampling），並使用端到端 TV 損失進行訓練。
下表顯示了在程式碼生成情境下，各種技術對接受長度的消融研究結果。實驗中我們使用了 GLM-5.1 的主幹網路和訓練資料。MTP 步驟的數量在訓練和推論中都設定為 7。
與基準線相比，最終 MTP 層的接受長度增加了 20%。
隨著 GLM-5.2 將最大上下文長度從 200K 擴展到 1M token，程式碼生成工作負載預計將大幅轉向更長的提示詞。這使得主要的推論瓶頸從計算轉移到 KV 快取容量、長上下文核心開銷和 CPU 端開銷。
儘管 GLM-5.2 的新架構減少了每個 token 的計算 FLOPs，但它並未按比例減少每個 token 的 KV 快取大小。因此，在有限的 GPU 資源下支援更長的上下文、更高的併發性和更高的 token 吞吐量，成為推論引擎最佳化的核心挑戰。
為了應對這項挑戰，我們從三個方向最佳化了推論引擎。首先，在 LayerSplit 的基礎上，我們引入了更細粒度的記憶體管理和平行化策略，以增加 KV 快取容量，並為超長上下文請求提供更多可用的快取空間。
其次，我們最佳化了成本隨上下文長度增加的核心（kernels），並將其與快取傳輸管線更好地協調，以最大程度地減少快取傳輸對預填充（prefill）和解碼（decode）效能的影響。第三，我們最佳化了 CPU 端的快取管理、請求排程和執行時路徑，以減少 GPU 執行管線中的空閒時間（bubbles），並提高端到端吞吐量。
如圖所示，隨著上下文長度的增加，GLM-5.2 實現了越來越大的吞吐量優勢，展現了在長上下文推論情境中更強的可擴展性。
GLM-5.2 的代理式強化學習（Agentic RL）後訓練涉及更大規模、更多領域和更複雜執行模式的任務。異質資料和任務需要統一在一個訓練流程中，而長任務互動、工具使用、子任務分解和多輪環境回饋都對部署（rollout）和訓練編排提出了更高的要求。
為了支援這個過程，`slime` 作為一個整合的基礎設施層，從訓練到大規模推論部署都發揮作用。它支援多種訓練和任務組織模式，包括白箱部署、黑箱部署、緊湊軌跡和子代理工作流程，使同一系統能夠擴展到更大、更複雜的 RL 和 OPD 訓練工作負載。
在 GLM-5.2 的後訓練過程中，我們利用 `slime` 框架進行平行 OPD 訓練，高效地將十多個專家模型整合到最終模型中。整個 OPD 訓練過程約耗時兩天，展現了高訓練效率。
代理式強化學習也對系統資源和推論基礎設施提出了更高的要求。`slime` 為推論系統提供了高度開放和靈活的介面：訓練端可以以不同形式連接到推論服務，並靈活適應不同的平行化策略、路由策略、PD 解耦設定和部署模式。
同時，在 RL 部署過程中累積的配置經驗、排程策略和最佳化路徑可以在生產服務階段重複使用和進一步完善，使訓練端和服務端相互強化。這為從後訓練到生產部署創造了一條更直接的路徑。結合靈活的訓練-推論資源組織和 KV 快取 FP8，`slime` 為 GLM-5.2 的大規模代理式強化學習訓練提供了關鍵的基礎設施支援，進一步提高了系統效率、部署吞吐量和大規模推論併發性。
針對長任務的強化學習。對於 GLM-5.2 而言，長任務會產生顯著更長的執行軌跡，一旦超長軌跡透過壓縮（compaction）分割成多個子軌跡，相同提示詞下的不同部署會產生數量和長度高度可變的訓練軌跡。因此，我們從群組式最佳化轉向基於評論者（critic-based）的 PPO 公式，該公式從單個部署中學習，依賴評論者來估計 token 級別的優勢，而不是群組間的相對比較。
這種單一部署公式自然地適應了壓縮，因為它對提示詞產生多少軌跡或其相對長度沒有限制：我們透過將所有壓縮後的子軌跡作為可訓練軌跡納入訓練中，並應用 token 級別的損失來解決其長度不平衡問題，從而將壓縮引入訓練。
程式碼代理程式中的反作弊（Anti-Hack）。程式碼強化學習特別容易受到獎勵作弊（reward hacking）的影響，因為獎勵通常是可驗證的通過/失敗訊號。我們發現 GLM-5.2 比 GLM-5.1 顯示出更多潛在的作弊行為。這使得驗證訊號很容易被最佳化，但卻未能真正提升模型的基本能力。
代理程式可能會讀取受保護的評估文件、從參考資料或上游提交中複製答案內容，或在 GitHub 相關任務中直接獲取目標原始碼。例如，代理程式可能會透過 `curl https://raw.githubusercontent.com/<path-to-file>` 下載解決方案，甚至出現像這樣的鏈式洩漏：
1. `find /workspace -name "*hidden*"`
2. `cat /workspace/.eval/secret_cases.json`
3. `python solve.py --case "$(cat /workspace/.eval/secret_cases.json)"`
這些行為會誇大獎勵並破壞訓練訊號，因此需要一個明確的機制來區分真正的任務解決方案和捷徑。為了解決這個問題，我們在 RL 訓練和評估中引入了一個反作弊模組。檢測過程分為兩個階段：首先是一個基於規則的過濾器，用於捕捉潛在的作弊行為。