GLM-5 登場：Z.AI 的寫程式旗艦

GLM-5 是 Z.AI 的新旗艦模型。數字很硬，744B 總參數、40B active、28.5T pre-training tokens、200K context。講白了，這就是衝著寫程式和 agent 工作來的。

更狠的是 benchmark。Z.AI 公布 GLM-5 在 SWE-bench Verified 拿到 77.8，在 Terminal Bench 2.0 拿到 56.2。這不是普通聊天模型的分數，這是直接往 coding 模型主戰場丟球。

我覺得這次最有意思的地方，不是規格有多大，而是它很明確地瞄準 production workflow。它支援 thinking mode、function calling、structured output、streaming 和 context caching。說真的，這東西不是拿來拍 demo 的。

GLM-5 到底想解什麼題

Z.AI 把 GLM-5 定位成 agentic engineering 模型。這個詞有點行銷味，但意思不難懂。模型要能規劃、呼叫工具、跨多步任務維持上下文，還要自己修正路線。

這種模型適合的工作很實際。像前端頁面生成、後端系統工程、資料處理、翻譯、抽取、還有多步驟的辦公任務。你可以把它想成一個會一直記得目標的軟體工程助手。

官方文件還直接拿 Claude Opus 4.5 來比，說 GLM-5 的實際程式能力接近它。這種比較很大膽，因為開發者最後看的不是宣傳詞，而是它能不能少出 bug。

• 744B 總參數，40B active
• 28.5T 預訓練 tokens
• 200K context，128K 最大輸出
• 只支援文字輸入與輸出
• 支援 thinking mode、function calling、structured output

這組配置很像 Z.AI 在說一件事：它不想先做多模態聊天機器人。它想先做能扛長任務的 coding 引擎。這方向很務實，也很符合現在 agent 開發的需求。

為什麼參數變大，大家還是會在意

GLM-5 相比 GLM-4.7，總參數從 355B 拉到 744B。active parameters 也從 32B 漲到 40B。更重要的是，訓練資料從 23T tokens 增加到 28.5T。這些數字不會自動等於更強，但通常代表模型看過更多 code pattern 和指令風格。

對寫程式來說，這種差異很現實。模型如果看過更多 repo 結構、測試案例、錯誤訊息和修 bug 流程，遇到真實問題時就比較不容易亂答。尤其是 multi-step 任務，資料量和訓練方式都會影響穩定度。

Z.AI 另外提到一個叫 Slime 的 asynchronous reinforcement learning framework。白話一點，就是後訓練不再把每個 prompt 當單次事件，而是能在更長的 agent 互動裡持續學。這對工具調用很重要，因為模型要記住目標，也要知道自己前一步做錯了什麼。

它還用了 DeepSeek Sparse Attention。這點我覺得很實際。長 context 很吃算力，稀疏注意力可以壓部署成本。對要付 inference 費用的團隊來說，這種工程選擇比口號更有感。

• GLM-4.7：355B total、32B active、23T tokens
• GLM-5：744B total、40B active、28.5T tokens
• GLM-5 最大輸出 128K tokens
• 200K context 對長文件和大專案很有幫助

講白了，GLM-5 想解的是「長任務」這題。不是只會回一句漂亮答案，而是能一路跟著你把事情做完。

benchmark 數字代表什麼

Z.AI 最想讓人記住的，是 SWE-bench Verified 77.8 和 Terminal Bench 2.0 56.2。這兩個 benchmark 很有代表性，因為它們都不是單純考作文。它們考的是模型能不能真的動手修問題。

SWE-bench Verified 主要看模型能不能修 GitHub 上的真實 issue。Terminal Bench 2.0 則偏向命令列操作和工具鏈推理。前者像寫 code，後者像在終端機裡活下來。兩個都高，通常代表模型不只會講。

"The most important thing for any AI system is whether it can do useful work for people." — Sam Altman, OpenAI DevDay 2023

這句話出自 OpenAI DevDay 2023。放在這裡很合適。因為 coding model 的價值，不在於它能不能一次寫出華麗程式碼，而在於它能不能持續幫你把工作做完。

Z.AI 也說 GLM-5 在 frontend development、backend systems engineering 和 long-horizon execution 上，都比 GLM-4.7 好。這種說法如果之後能被第三方驗證，對開發者會很有參考價值。因為這些場景最接近真實工作。

把公開數字攤開來看，可以先得到幾個判斷：

• GLM-5 不是走便宜聊天模型路線
• 它把 agent 能力看得跟寫碼能力一樣重要
• 長 context 和工具使用是核心賣點
• 它在瞄準 premium coding assistant 市場

我會說，這些分數的重點不是「贏了誰」。重點是 Z.AI 已經把自己放進頂級 coding 模型的討論桌上了。

開發者怎麼接上去用

目前 GLM-5 的使用入口綁在 GLM Coding Plan。Z.AI 提供 Pro 和 Max 方案，走月費制。這種設計很像在跟開發者說：你不用先簽大合約，也能先試用。

它也支援常見的開發工具。像 Claude Code 和 Open Code 都能接。這點很重要，因為很多團隊不是缺模型，而是缺整合時間。能少改一層工具，就少一層麻煩。

API 方面，Z.AI 的入口是 api.z.ai。文件裡有 cURL、Python SDK、Java SDK，還有 OpenAI-style Python SDK。對已經用 chat-completions 介面的團隊來說，遷移成本會低很多。

如果你在比方案，可以先看這幾個面向：

• 200K context 適合長文件、長 repo、長對話
• 128K 輸出上限適合大段 code 生成
• function calling 和 structured output 適合 agent 流程
• sparse attention 可能有助於控制推理成本

我覺得這裡最實用的一點，是 Z.AI 沒有強迫你換一套新工作流。它想吃進既有 agent 生態，這比重新教育開發者容易多了。

跟其他 coding 模型怎麼比

如果把 GLM-5 放到整個 coding model 市場看，它的策略很清楚。它不是只追求聊天品質，而是把長 context、工具使用、程式修復、終端機推理一起包進來。這讓它更像一個工程助手，而不是單純的對話模型。

和一些主流模型相比，GLM-5 的公開賣點很集中。像 Claude 系列常被拿來看程式品質，GPT-4o 強在通用性和多模態，而 GLM-5 的重點是把 coding 和 agent 任務拉到最前面。這種切法很直接，也很容易讓人懂。

從公開資訊來看，GLM-5 有幾個比較點很值得注意。它的 200K context 很大，對長 repo 和長文件有利。它的 128K output 上限也很少見，對一次產出大量程式碼或規格整理很方便。再加上 40B active parameters，理論上比純粹堆總參數更能控制推理成本。

• 對比 Claude：GLM-5 更強調開放接入與長 context
• 對比 GPT-4o：GLM-5 更偏 coding 與 agent 工作
• 對比一般開源模型：GLM-5 的 benchmark 和規模更高
• 對比低成本模型：GLM-5 明顯不是走便宜路線

話說回來，benchmark 再漂亮，也還是要看真實 repo。CI 會不會壞，測試會不會漏，程式碼風格會不會亂，這些才是工程團隊每天在意的事。

這波更新放在產業脈絡裡怎麼看

現在的 AI coding 市場很擠。大家都在比誰能更穩地修 bug、更會調 tool、更能在長任務裡不失控。從 GitHub Copilot 到 Claude Code，再到各種 agent 框架，方向都很一致：模型要開始真的幹活。

GLM-5 的出現，代表中國系模型也在往這個方向硬碰硬。它不是只做通用聊天，而是把資源集中在 coding 與 agent。這種選擇很務實，因為開發者願意為能省時間的工具付費，尤其是能處理複雜專案的工具。

長 context 也不只是規格數字。對資料工程、文件處理、法遵摘要、內部知識庫問答來說，200K context 真的有用。你可以把更多背景一次塞進去，少一點切片、少一點上下文遺失。

另外一個現實是成本。模型越大，不代表每次都要暴力全開。GLM-5 的 40B active parameters 和 sparse attention，顯然是在找一條比較能落地的路。這對要上 production 的團隊，比單純的排行榜名次更重要。

接下來我會怎麼看

我對 GLM-5 的看法很直接。它不是那種只適合發新聞稿的模型。它的規格、API、工具支援和 benchmark，全部都在對準開發者日常工作。

接下來最值得看的是第三方實測。尤其是實際 GitHub repo、真實 CI、錯誤修復率，還有 agent 在長任務裡會不會自己走偏。這些結果如果站得住，GLM-5 就不只是名單上的新模型，而會變成團隊真的會拿來試的選項。

如果你現在就在評估 coding model，我會建議先拿一個真實專案測。不要只看 demo。把它丟進你自己的 repo，看它能不能修 3 個 issue、跑過測試、還能把改動講清楚。這才是答案。