GLM-5 由 Zhipu AI（Z.ai）於 2026 年 2 月 11 日發佈，相較於 GLM-4.7 在架構上實現了大幅躍進：更大的 MoE 規模（≈744B vs ~355B 總參數）、更高的活躍參數容量、更低的可測量幻覺率，並在代理型與程式碼基準上有明顯提升——代價是推理複雜度與（有時）延遲的增加。
什麼是 GLM-5，為何其發佈具有重要意義？
GLM-5 是哪一類模型？
GLM-5 是 Zhipu AI（Z.ai）最新的前沿開放權重大型語言模型，於 2026 年 2 月 11 日 發佈。它是一個 Mixture-of-Experts（MoE）Transformer，將 GLM 系列擴展至 ~7440 億總參數，而每次推理僅啟用約 400 億參數（即透過 MoE 路由使活躍計算遠小於總參數量）。該模型以 MIT 授權釋出，並針對 代理型 工作負載進行優化——如工具編排、程式碼撰寫與修訂、文件工程，以及複雜知識工作等長時間、多步驟任務。
與早期 GLM 變體相比的重點改進是什麼？
最關鍵變更的簡要清單：
- 參數擴展：GLM-5 約為 744B 總參數（40B 活躍）對比 GLM-4.7 的 ~355B 總參數 / 32B 活躍——模型規模約 2× 躍升。
- 基準與事實性：在獨立基準上大幅提升（Artificial Analysis Intelligence Index：GLM-5 = 50 vs GLM-4.7 = 42），並在 AA Omniscience 指標上大幅降低幻覺（相對 GLM-4.7 報告降低 56 個百分點）。
- 代理型能力：在工具呼叫、方案分解與長期執行方面更可靠（Z.ai 將 GLM-5 定位於「agentic engineering」）。
- 部署與晶片：針對國產中國推理硬體（華為 Ascend 等）進行構建與評測，反映 Z.ai 走向多元晶片棧。
為何重要：GLM-5 進一步縮小開放權重與專有前沿模型在代理型與知識任務上的差距——讓高能力、開源模型對需要可控部署與授權彈性的企業更具可行性。
GLM-5 的新特性（詳解）
定位：大規模「代理型工程」
Z.ai 將 GLM-5 明確定位為「代理型工程」模型：在此類用例中，模型會規劃、發出工具呼叫、檢視結果，並在多步驟中自動迭代（如搭建 CI 流水線、分流並修復失敗測試、或整合微服務）。這標誌著從純單輪程式碼生成轉向面向執行軌跡與工具輸出的跨步驟推理型模型。
思考模式：保留/交錯推理
GLM-5 引入更精煉的「思考」模式（在文件中有時標為 interleaved thinking、preserved thinking），使模型能輸出並在後續回合與工具呼叫中重用其內部推理軌跡。實務上，這可降低長工作流程中的重推導成本，並在代理需跨工具結果維持計畫狀態時提升一致性。GLM-4.7 已引入早期思考變體與工具感知行為；GLM-5 進一步優化其機制與訓練配方，使這些軌跡更可靠且可重用。
長上下文工程與系統穩定性
GLM-5 的訓練與微調明確測試在超長上下文下的生成（SFT/評測期間達 202,752 tokens）。當你需要模型在同一提示中同時處理多個版本庫、測試日誌與編排輸出時，這是非常實用的提升。對於部分推理工作負載，評測設置將生成長度推至 131,072 tokens。這是一項顯著的工程投入，旨在緩解在巨大上下文條件下常見的不穩定性。
架構與擴展（MoE）
公開報告顯示，GLM-5 採用大型 MoE 架構，總參數數百億級（公開統計約 ~744–745B）。GLM-4.7 具有面向不同部署取捨的 MoE 與 Flash 變體（例如活躍參數更小、適用於本地或低成本推理的「Flash」變體）。MoE 設計幫助 GLM-5 在保持活躍計算可控的同時推進峰值能力，並提供配置選擇（較低活躍參數以降低推理成本）。具體延遲與 VRAM 表現會因部署變體而異。
Z.ai 如何擴展並訓練 GLM-5，相較於 GLM-4.7 有何不同？
核心架構差異
| 特性 | GLM-5 | GLM-4.7 |
|---|---|---|
| 發佈日期 | 2026 年 2 月（旗艦） | 2025 年 12 月 |
| 模型世代 | 最新一代 | 前一代 |
| 總參數量 | ~744B | ~355B |
| 活躍參數（MoE） | ~40B（每次前向傳播） | ~32B（每次前向傳播） |
| 架構 | 專家混合加稀疏注意力 | 具思考模式的 MoE |
| 上下文視窗 | ~200K tokens（相同基礎大小） | ~200K tokens |
重點： 相較 GLM-4.7，GLM-5 的總容量幾乎翻倍，並提升活躍參數，這有助於強化推理與綜合能力，尤其體現在長篇技術內容、延展推理流程與複雜程式工程任務上。
架構：有哪些變化？
GLM-4.7 在較大型變體中採用 MoE 設計（文件記載約 355B 總參數，且每 token 的活躍集合較小以提高效率）。GLM-5 保留 MoE 式的稀疏思路，並疊加新的稀疏注意力機制——報告稱為 DeepSeek Sparse Attention（DSA）——能動態將注意力資源分配給被判定為重要的 token。據稱 DSA 能在維持（或提升）長上下文推理的同時降低訓練/推理成本，使模型在處理遠超既有檢查點的長上下文時仍能保持可控計算。
規模：參數與資料
- GLM-4.7：主流 MoE 版本記載為約 3550 億總參數（每次前向傳播的活躍參數集合遠小於總量以求效率）。
- GLM-5：據報為 ~7440 億參數，並以約 28.5 兆 tokens 的預訓練配額進行訓練，且特別強調程式碼與代理型序列。此組合旨在提升程式碼合成與持續代理規劃能力。
參數躍升、token 預算擴張與架構更新，是 GLM-5 在程式碼與代理型排行榜上取得更佳數字表現的主要輸入面原因。
訓練策略與後訓練（RL）
相較 GLM-4.7 為改善多步推理與工具使用而引入的「交錯/保留思考」變體，GLM-5 將管線正式化，包含：
- 透過中期訓練排程擴大上下文長度（團隊報告逐步延長至 200K tokens）。
- 實作序列式 RL 後訓練流程（Reasoning RL → Agentic RL → General RL），並採用同策略的跨階段蒸餾以避免災難性遺忘。
- 加入非同步 RL 與解耦展開引擎，在 RL 過程中擴展代理軌跡而不受同步瓶頸制約。
這些方法旨在特別提升長期代理行為——例如在多次相依的工具呼叫與程式碼修改中，長時段會話內維持穩定的內部狀態。
GLM-5 與 GLM-4.7 在效能與能力上的比較
基準與智能衡量
| 評測領域 | GLM-5 | GLM-4.7 |
|---|---|---|
| 程式設計（SWE-bench） | ~77.8%（開源模型 SOTA） | ~73.8%（SWE-bench Verified） |
| 工具與 CLI 任務 | ~56%（Terminal Bench 2.0） | ~41%（Terminal Bench 2.0） |
| 推理（HLE 與擴展） | ~30.5 → ~~50（啟用工具，內部基準） | ~24.8 → ~42.8（HLE 啟用工具） |
| 代理型與多步任務 | 顯著更強（更長推理鏈） | 強（思考模式）但不及 GLM-5 的深度 |
解讀：
- GLM-5 全面優於 GLM-4.7，在核心程式設計與推理基準上均有可量化優勢。這在多步自動化、問題分解、深層邏輯任務中尤為明顯。
- 提升非同小可：例如 Terminal Bench 能力由 ~41% 躍升至 56%，屬於代理型自動化可靠性的重大相對增益。
- 在推理測試（如內部 HLE 指標）中，GLM-5 展現更強的原生與工具增強推理輸出。
- 實務代理測試亦見增益：在 CC-Bench-V2 前端 HTML ISR 指標中，GLM-5 在部分前端任務子集記錄 38.9%，對比 GLM-4.7 的 35.4%。此為展示實際前端開發能力的自動化評測指標之一。
上下文大小與長文任務
- 兩者均支援大上下文（~200k tokens）——可同時讀入與推理更長的文檔、程式碼庫或對話。
- 實務零星回報顯示，GLM-5 部署在部分平台上偶爾出現被感知的「上下文管理問題」——但這或反映平台特定限制，而非模型設計本身。
工具與函式呼叫
兩者皆支援結構化函式/工具調用；GLM-5 在更複雜腳本邏輯與更長分支操作中表現出更高的忠實度。
範例：任務輸出品質有何不同
程式範例（概念性）
- GLM-4.7： 產出合格的單檔腳本，語法正確、邏輯清晰。
- GLM-5： 擅長多檔案程式碼生成、深入除錯建議，並能在長迴圈反饋中減少上下文截斷問題。
推理與規劃
- GLM-4.7： 具備良好的多步推理，但在非常深的推理鏈上偶有停滯。
- GLM-5： 更擅長切分推理、回溯早先步驟並導航長鏈——對資料綜整與跨領域策略尤為有利。
從 GLM-4.7 遷移到 GLM-5，延遲與成本有何變化？
延遲權衡與 GLM-4.7 仍具優勢之處
短訊息與靈敏 UI： 實務者基準顯示，GLM-5 在短回應上可能增加一個小幅固定開銷（路由與專家選擇簿記），在極小負載下表現為略高延遲。對追求極低延遲的小訊息 UI，GLM-4.7 或其 Flash 變體仍具吸引力。
GLM-5 與 GLM-4.7 對比：
- GLM-4.7： 輸入 $0.60/1M tokens，輸出 $2.20/1M tokens。
- GLM-5： 輸入 $1.00/1M tokens，輸出 $3.20/1M tokens。
成本 vs. 人工編輯的權衡
當 GLM-5 能顯著減少下游人力時間（如審核合併請求、分流並修復自動化修補、或避免重複模型呼叫），較高的模型價格即可被合理化。一個簡單決策準則：
若 GLM-5 將人工編輯時間降低超過 X%（X 取決於人工費率與每個工作流程的 token 數），則儘管單位 token 成本較高，整體仍可具成本效益。多篇部落格分析建立了此類損益模型，發現對重度、重複的代理型工作流程（如大規模自動化程式碼修復），GLM-5 往往能帶來回報。
延遲與硬體
推理 VRAM 與延遲取決於變體（Flash、FlashX、完整 MoE）。社群指南顯示 GLM-4.7 的 FlashX 與 30B Flash 變體可在 24GB GPU 上部署；完整 MoE 變體則需要大型多 GPU 配置。GLM-5 的完整配置在相同吞吐下對資源需求更高，儘管 MoE 稀疏性有助於降低單 token 的活躍計算。預期需投入工程精力以調校量化、記憶體對映與串流，方能達成生產環境要求。
何時應從 GLM-4.7 升級到 GLM-5？
適合升級若：
- 你需要更強的多檔案程式碼推理、長上下文代理編排，或更高的端到端代理成功率。
- 任務價值高，足以承擔更高的每次請求基礎設施複雜度與成本。
若下列情況，建議維持 GLM-4.7：
- 你的工作負載為高頻、短提示（分類、標註），更看重成本與延遲的可預測性，而非邊際品質提升。
- 偏好維持 GLM-4.7 的用例
- 高吞吐、短負載： 聊天機器人、自動補詞、微型改寫任務——GLM-4.7（尤其是 Flash 變體）通常更便宜且延遲更低。
- 預算受限且規模化任務： 標註、分類或微任務等大規模執行場景，GLM-4.7 的效率與較低單價更具吸引力。
- 缺乏處理 MoE 分片/複雜自動擴縮的基礎設施或預算。
在 API 呼叫中如何選擇模型？（範例）
cURL — 切換 model ID（CometAPI / 與 OpenAI 相容的範例）：
# GLM-4.7
curl -X POST "https://api.cometapi.com/v1/chat/completions" \
-H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-d '{"model":"glm-4.7","messages":[{"role":"user","content":"Summarize this repo..."}],"max_tokens":800}'
# GLM-5
curl -X POST "https://api.cometapi.com/v1/chat/completions" \
-H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-d '{"model":"glm-5","messages":[{"role":"user","content":"Summarize this repo..."}],"max_tokens":1200}'
Python（requests）：將 model 欄位改為 GLM-4.7 或 GLM-5，其餘客戶端程式碼可保持不變。
最終評估：
GLM-5 屬於演進式且具有重要拐點的版本：
- 演進式：延續 GLM 家族的 MoE 與以推理為先的設計，並持續沿 4.5 → 4.6 → 4.7 → 5 的迭代改進路徑。
- 拐點：在規模上顯著擴大、引入 DSA，並採用專為長期代理任務量身訂製的 RL 課程——三者共同帶來在多種實用基準上的顯著、可量化提升。
若只看排行榜名次，GLM-5 宣稱在多項指標上位居開放權重領先地位，並進一步縮小與頂級專有系統在代理型與程式任務上的差距。若評估開發者體驗與延遲敏感場景，實務上的利弊仍需更大規模的部署與時間驗證。這意味著：當用例需要持續的代理能力時，GLM-5 具備強大吸引力；而對許多當前生產需求而言，GLM-4.7 仍是成熟、更快、成本更精實的選擇。
開發者現在可透過 CometAPI 存取 GLM-5 與 GLM-4.7。開始前，可先在 Playground 探索模型能力，並參考 API guide 取得詳細指引。存取前請先登入 CometAPI 並取得 API key。CometAPI 提供遠低於官方的價格，協助你整合上線。
Ready to Go?→ 立即註冊 GLM-5！