GLM-5.1 是我們專為 Agentic 工程打造的下一代旗艦模型，其程式編寫能力相較前代有顯著提升。它在 SWE-Bench Pro 上達到了業界領先（SOTA）的表現，並在 NL2Repo（儲存庫生成）和 Terminal-Bench 2.0（真實世界終端機任務）上大幅領先 GLM-5。
但其最具意義的躍進不僅止於初次嘗試的表現。先前的模型（包括 GLM-5）往往會過早耗盡其解題招式：它們會套用熟悉的技術以快速取得初步進展，隨後便進入停滯期。即便給予更多時間也無濟於事。
相較之下，GLM-5.1 專為在更長的時間跨度上有效執行 Agentic 任務而設計。我們發現該模型在處理模糊問題時展現出更佳的判斷力，並能在更長的工作階段中保持生產力。它能精準地將複雜問題拆解、執行實驗、解讀結果並找出瓶頸。透過反覆審視其推理過程並修正策略，GLM-5.1 能在數百輪迭代與數千次工具呼叫中持續最佳化。執行時間越長，結果越好。
我們透過三項回饋機制漸進複雜的任務來展示此能力：一個由單一數值指標評分的向量搜尋最佳化問題、一個包含個別問題加速測量的 GPU 核心基準測試，以及一個開放式的網頁應用程式建置任務——該任務完全沒有評分指標，僅仰賴模型自身的判斷來決定下一步該改善什麼。
情境一：歷經 600 次迭代的向量資料庫最佳化
VectorDBBench 是一項開源程式設計挑戰，旨在評估模型建置高效能資料庫以執行近似最近鄰搜尋的能力。模型會獲得一個具備 HTTP API 端點與空白實作殼層的 Rust 骨架，隨後需在 50 回合的工具呼叫額度內，使用基於工具呼叫的代理程式來讀寫檔案、編譯、測試與效能分析。最終結果會在 SIFT-1M 資料集上進行基準測試：模型依據 Recall ≥ 95% 限制下的 QPS 進行排名。在此設定下，先前最佳結果為 Claude Opus 4.6 達到的 3,547 QPS。
一個自然的問題是：這 50 回合的額度是否即為瓶頸？我們將評估重構為一個外層最佳化迴圈，並使用 Claude Code 框架：在每次迭代中，模型可使用任意數量的工具呼叫來編輯程式碼、編譯、測試與效能分析，隨後提交新版本進行基準測試。模型可自主決定何時提交以及下一步該嘗試什麼。
GLM-5.1 並未在 50 或 100 次提交後停滯，而是在 600 多次迭代與 6,000 多次工具呼叫中持續尋找有意義的改善，最終達到 21.5k QPS——約為單一 50 回合階段最佳結果的 6 倍。最佳化軌跡呈現出階梯狀特徵：在固定策略內進行增量調整的時期，穿插著推進效能前沿的結構性變革。
兩次轉折清楚呈現了此模式。約在第 90 次迭代時，模型從全庫掃描轉換為帶有 f16 向量壓縮的 IVF 叢集探測，QPS 躍升至 6.4k。約在第 240 次迭代時，其引入了兩階段管線——u8 預評分加上 f16 重新排序——達到 13.4k QPS。整個過程中共發生了六次此類結構性轉變，每一次皆由模型在分析自身基準測試日誌並識別當前瓶頸後主動發起。圖表中的紅色叉號標記了 Recall 低於 95% 的迭代——這些點集中在每次重大轉折附近，顯示模型在探索新方向時暫時突破限制，隨後再進行調整以恢復標準。
情境二：歷經 1,000+ 回合的機器學習工作負載最佳化
KernelBench 評估模型能否根據參考 PyTorch 實作，產出輸出一致但更快的 GPU 核心。該基準測試分為三個層級，最佳化範疇與系統複雜度逐級遞增：第一級涵蓋單一運算子，第二級涵蓋融合運算子序列，第三級則涵蓋完整模型（如 MobileNet、VGG、MiniGPT 與 Mamba）的端對端最佳化，共計 50 道題目。作為參考，torch.compile 在預設設定下於這些問題上達到 1.15 倍加速；在 max-autotune 設定下則為 1.49 倍。我們在第三級上運行了四個模型，並以工具使用回合數為變數，報告所有 50 道題目的幾何平均加速倍率。
這些軌跡突顯了長跨度最佳化行為的差異。GLM-5 起初進步迅速，但較早進入停滯期。Claude Opus 4.5 持續時間稍長，但其增益在後期也逐漸遞減。GLM-5.1 則進一步推進了此一前沿，達到 3.6 倍加速，並在過程中持續取得進展。儘管其改善速率同樣隨時間放緩，但其能維持有效最佳化的時間顯著長於 GLM-5。在此設定下，Claude Opus 4.6 仍是表現最強的模型，最終達到 4.2 倍加速，且在結束時仍顯示尚有發揮空間。
情境三：歷經 8 小時的 Linux 桌面環境建置
前兩個情境具有明確的數值目標——QPS、加速倍率——供模型進行基準測試比對。網站生成本質上則較為主觀：根據自然語言提示，產出一個可運作的網頁應用程式。這裡沒有單一的評分指標；「好」的標準取決於完整性、視覺質感與互動品質。
我們以一個極具企圖心的提示詞進行測試：建置一個 Linux 風格的桌面環境作為網頁應用程式。無入門程式碼、無設計稿、無過程指引。在單次執行中，大多數模型（包括舊版 GLM）很快就會放棄：它們產出一個包含靜態工作列與一兩個佔位視窗的基本骨架，隨即宣告任務完成。模型缺乏退一步思考「還缺什麼」的機制。
我們將 GLM-5.1 封裝在一個簡單的框架中以改變這點：每輪執行結束後，模型會審視自身輸出，找出可改善之處——缺少的功能、粗糙的樣式、故障的互動——然後繼續。此迴圈運行了 8 小時，成果斐然。
影片連結：
初期，GLM-5.1 產出基本的版面配置與一個簡單視窗——與短時間工作階段的產出相似。但故事並未就此結束。隨著持續運作，系統逐步充實：檔案瀏覽器、終端機、文字編輯器、系統監控器、計算機、遊戲——每項新功能都整合進連貫的使用者介面中，而非事後拼湊。樣式更加精緻，互動更加流暢，邊緣案例亦得到處理。最終成果是一個在瀏覽器中運作、完整且視覺一致的桌面環境——這具體展示了當模型被賦予時間與持續精進的能力時，能達成何種成就。
在這三個情境中，關鍵變數不僅是執行時間，而在於額外的執行時間是否仍具效益。GLM-5.1 將此「有效生產力跨度」較 GLM-5 實質延伸，然而在 KernelBench 等任務上的差距顯示，長跨度最佳化仍是待探索的前沿領域。目前仍存在重大挑戰：如何在增量調整不再奏效時更早跳出區域最佳解、如何在跨越數千次工具呼叫的執行軌跡中維持連貫性，以及——或許最重要的是——如何在沒有數值評分指標的任務中發展可靠的自我評估機制。GLM-5.1 是我們在此方向邁出的第一步，我們將持續推進這些領域的發展。
GLM-5.1 已依 MIT 授權條款開源。GLM-5.1 亦可在開發者平台 api.z.ai 與 BigModel.cn 上使用，並相容於 Claude Code 與 OpenClaw。
開始使用 GLM-5.1
透過 GLM Coding Plan 使用 GLM-5.1
在您慣用的程式編寫代理工具中嘗試 GLM-5.1——支援 Claude Code、OpenCode、Kilo Code、Roo Code、Cline、Droid 等多種工具。https://docs.z.ai/devpack/overview
GLM Coding Plan 訂閱用戶專用：我們正逐步向所有 Coding Plan 用戶推出 GLM-5.1。您現在即可將模型名稱更新為 "GLM-5.1" 來啟用（例如在 Claude Code 的 ~/.claude/settings.json 中設定）。作為我們最強大的模型，GLM-5.1 在尖峰時段消耗 3 倍配額，離峰時段消耗 2 倍配額。作為限時推廣優惠（至四月底），離峰使用量將以 1 倍配額計費。（尖峰時段為每日 UTC+8 14:00–18:00）。
偏好圖形化介面？我們提供 Z Code——單一介面整合多個代理程式協同運作。可透過 SSH 在遠端機器上開發，或從手機發起任務並稍後查看進度。
立即開始建構： https://z.ai/subscribe
在 Z.ai 上與 GLM-5.1 對話
GLM-5.1 將於近日在 Z.ai 上線。
在本機部署 GLM-5.1
GLM-5.1 的模型權重已公開於 HuggingFace 與 ModelScope。進行本機部署時，GLM-5.1 支援包含 vLLM 與 SGLang 在內的推論框架。詳細部署說明請參閱官方 GitHub 儲存庫。
附註
- Humanity’s Last Exam (HLE) 及其他推理任務：我們以最大生長度 163,840 tokens 進行評估（
temperature=1.0, top_p=0.95, max_new_tokens=163840）。預設情況下，我們報告純文字子集的結果；標有 * 的結果來自完整資料集。我們使用 GPT-5.2 (medium) 作為評審模型。對於 HLE-with-tools，我們使用最大上下文長度 202,752 tokens。 - SWE-Bench Pro：我們使用 OpenHands 執行 SWE-Bench Pro 測試套件，並搭配客製化的指令提示詞。設定：
temperature=1,top_p=0.95,max_new_tokens=32768，上下文視窗為 200K。 - NL2Repo：我們以
temperature=1.0,top_p=1.0,max_new_tokens=32768及 200k 上下文進行評估。為防止駭客行為，我們使用基於規則的預先偵測來攔截惡意指令（例如未授權的 pip 或 curl 操作），隨後輔以模型判斷。惡意行為將立即被攔截。 - BrowserComp：在無上下文管理的情況下，我們保留最近 5 回合的細節。在啟用上下文管理的情況下，我們採用與 GLM-5 及 DeepSeek-v3.2 相同的全數捨棄策略。
- Terminal-Bench 2.0 (Terminus 2)：我們使用 Terminus 框架進行評估，設定為
timeout=3h, temperature=1.0, top_p=1.0, max_new_tokens=8192，上下文視窗為 200K。資源限制上限為 16 顆 CPU 與 32 GB RAM。 - Terminal-Bench 2.0 (Claude Code)：我們在 Claude Code 2.1.14 (think 模式) 中進行評估，設定為
temperature=1.0, top_p=0.95, max_new_tokens=131072。我們移除了實際運行時間限制，但保留每項任務的 CPU 與記憶體限制。我們修正了 Claude Code 引入的環境問題，並在一個經過驗證的 Terminal-Bench 2.0 資料集上報告結果，該資料集解決了指令模糊不清的問題（參見：https://huggingface.co/datasets/zai-org/terminal-bench-2-verified）。分數為 5 次運行的平均值。 - CyberGym：我們在 Claude Code 2.1.56 (think 模式，無網頁工具) 中進行評估，設定為 (
temperature=1.0, top_p=1.0, max_new_tokens=32000)，每項任務限時 250 分鐘。結果為 1,507 項任務的單次執行 Pass@1。 - MCP-Atlas：所有模型均在 think 模式下，於 500 項任務的公開子集上進行評估，每項任務限時 10 分鐘。我們使用 Gemini-3.0-Pro 作為評估的評審模型。
- τ³-bench：我們在所有領域的使用者模擬器中額外加入提示詞，以避免因使用者過早結束互動而導致的失敗模式。銀行領域使用基於終端機的代理搜尋檢索 (terminal_use)。使用者模擬器：GPT-5.2 (reasoning_effort: low)，共 4 次嘗試。
- Vending Bench 2：運行測試由 Andon Labs 獨立執行。
- KernelBench Level 3：50 道題目各自在配備一顆 H100 GPU 的獨立 Docker 容器中執行，限制為 1200 次工具使用回合。正確性 (
atol=rtol=1e-4) 與效能均在獨立的 CUDA contexts 中，以 PyTorch eager 基準進行評估。所有解決方案均經過 Claude Opus 4.6 (max effort) 與 GPT-5.4 (xhigh) 獨立審計，以確認是否存在基準測試漏洞：每次審計均驗證最佳化過程未利用基準測試特性行為、適用於任意新輸入，且所有計算均在預設 CUDA stream 上執行。最終採用審計中較低的加速倍率，並設定 50 倍硬性上限以限制異常值的影響。