如果你正在替公司評估 Claude、GPT 之外的寫程式代理（coding agent）模型，GLM-5.2 值得排進下一輪測試。它的吸引力很明確：100 萬 token 的上下文窗口（context window）、最高 128K 輸出、MIT 授權的開放權重（open weights），加上官方把重點放在長時間、多步驟的工程任務。
GLM-5.2 值得用模型選型文來寫。讀者會先問四件事：它到底幾 B、能不能真的自己部署、MIT 開放權重能不能直接商用、租算力跑起來會不會比 Claude / Gemini / GPT 這類閉源 API 便宜。少了這層，讀者很難判斷它是研究玩具、成本替代品，還是能放進正式模型路由的候選模型。
真正要小心的地方也很明確。長上下文不等於每個任務都更可靠，排行榜高分也不等於能直接接管你的程式庫（repository）。GLM-5.2 比較適合被放進「長任務候選模型」試跑：先用非敏感程式庫、明確驗證標準和人工審查，確認它能不能穩定完成跨檔案理解、重構、測試與報告，再決定是否進入正式模型路由。
先回答：幾 B、能不能自架、成本約是閉源模型多少？
| 問題 | 目前可確認的答案 | 對讀者的決策影響 |
|---|---|---|
| 誰發布？ | Z.ai，在 Hugging Face Blog 與 Z.ai 文件同步揭露 GLM-5.2。 | 可回到官方模型卡、文件與 pricing 頁核對，不必只看社群截圖。 |
| 幾 B？ | Hugging Face 模型頁顯示 753B params；Artificial Analysis 寫成 744B total / 40B active parameters。 | 採購文件要寫清楚口徑：模型頁是 753B，第三方評測常用 744B/40B active。不要只寫「幾百 B」帶過。 |
| 真正開源嗎？ | Hugging Face 模型卡標示 MIT license，官方 blog 也寫 Pure Open / MIT open-source license；權重公開在 Hugging Face 與 ModelScope。 | 這比 API-only 模型更適合研究、自託管與合規評估，但仍要由法務確認模型卡、依賴與資料條款。 |
| 自家電腦能跑嗎？ | 753B 級模型即使用 BF16，光權重理論上就約 1.5TB，還沒算 KV cache、推理框架與長上下文記憶體。 | 一般 Mac、桌機或單張消費級 GPU 不適合。實務上先用 API 測任務；自託管應視為多 GPU / NPU 伺服器、雲端租機或機房題。 |
| 有哪些部署路徑？ | 模型卡列出 SGLang、vLLM、Transformers、KTransformers、xLLM 與 Ascend NPU 平台。 | 「能部署」不等於「家用電腦能部署」。部署入口存在，但工程門檻、硬體成本、量化品質與吞吐量都要測。 |
| API 價格？ | Z.ai pricing 頁列出 GLM-5.2 每 100 萬 token：input $1.4、cached input $0.26、output $4.4。 | 先用 API 跑 100–1,000 筆真實任務，估任務成功率與每任務成本，再決定是否租 GPU 或自託管。 |
| 成本約是閉源模型多少？ | 以 3:1 輸入/輸出粗估，GLM-5.2 API 約是 Claude Sonnet 4.5/4.6 的 36%；對 Gemini 2.5 Pro 標準 200K 以下區間約 63%，對 200K 以上區間約 38%。 | 它在 API 價格上有明顯優勢，但輸出 token、重試、工具呼叫、長上下文和人工 review 會改變總成本。 |
| 怎麼看跑分？ | 官方與 Artificial Analysis 都給出高分訊號；Artificial Analysis 把 GLM-5.2 放在 Intelligence vs Cost per Task 的效率前緣。 | 可以進候選名單，但企業仍要用自己的任務、工具、預算與審查標準重測。 |
對一般讀者來說，GLM-5.2 的新聞點在於開放權重模型正在往長任務和代理式開發工作流（agentic development workflows）逼近。過去開放模型常被放在成本模型或本機模型的位置；GLM-5.2 這次主打的是更接近高階閉源模型的長鏈路工程能力。
這次和 GLM-5.1 差在哪裡？
Z.ai 在官方發布文中列出四個核心變化：
- 100 萬 token 上下文：官方說 GLM-5.2 針對寫程式代理場景擴大了長上下文訓練，目標是讓模型在大型實作、自動化研究、效能最佳化和複雜除錯中維持工作狀態。
- 多種思考強度：Z.ai 文件寫明 GLM-5.2 支援
reasoning_effort，可在高推理與最大推理之間調整，讓團隊在品質、延遲和成本之間取捨。 - 架構效率調整：官方介紹 IndexShare，讓每四個稀疏注意力（sparse attention）層共用索引器，官方稱在 100 萬上下文長度下可降低每 token FLOPs 2.9 倍；MTP 層也改善了推測解碼接受長度。
- 更開放的部署入口：模型卡標示 MIT 授權，並列出 SGLang、vLLM、Transformers、KTransformers 與 Ascend NPU 平台部署路徑。
這些改動放在一起，代表 Z.ai 把問題從單次聊天品質推向長任務的三個成本：上下文會不會斷、推理資源怎麼分配、部署入口是否足夠自由。
基準測試要怎麼解讀？
GLM-5.2 的官方模型卡列出多組基準測試（benchmark）結果。軟體工程類包含 SWE-bench Pro、Terminal Bench 2.1；長任務類包含 FrontierSWE、PostTrainBench、SWE-Marathon；工具與代理評測則包含 MCP-Atlas、Tool-Decathlon。官方表格中，GLM-5.2 相比 GLM-5.1 在多個寫程式與代理式任務指標上提高不少。
第三方訊號也偏強。Artificial Analysis 在 2026-06-17 的文章中表示，GLM-5.2 在其智能指數（Intelligence Index v4.1）以 51 分成為當時領先的開放權重模型，並指出它位在「智能與單任務成本」的效率前緣（Pareto frontier）。這類結果對模型評估很有參考價值，因為它把成本、任務表現和輸出 token 放在同一張圖上。
但採購或導入時不能只讀排名。長任務模型的分數會受到工具存取、上下文管理、重試次數、時間限制、輸出預算、評分器和任務環境影響。Mason 在 OpenAI 第三方評測 playbook 的整理裡也提醒過：代理評測要一起看測試框架（harness）、工具、預算與總分（headline score）。
比較安全的讀法是：GLM-5.2 已經值得進入候選名單，但還沒有理由只靠公開分數替換現有工作流。
7 天試跑：工程團隊該怎麼測 GLM-5.2
如果你要評估 GLM-5.2，請不要第一天就讓它碰核心產品。先挑一個中型、可回滾、測試完整的 repository，跑 7 天任務分流。
| 測試任務 | 適合度 | 驗證重點 |
|---|---|---|
| 全 repo 架構盤點 | 高 | 模組邊界、API 契約、資料流是否正確，是否漏掉關鍵檔案。 |
| 文件、測試、型別補強 | 高 | 變更範圍（diff）是否收斂，測試是否真的覆蓋行為，沒有順手大改架構。 |
| 明確範圍的跨檔案重構 | 中高 | 是否保留既有 API、能不能跑完測試、是否提出可審查的分階段計畫。 |
| 效能最佳化或除錯 | 中 | 是否提出可量測假設，是否用基準測試或效能剖析（profile）驗證。 |
| 權限、金流、隱私、資料庫 migration | 低 | 人工主導；模型只適合產生測試、風險清單或替代方案。 |
每天記錄六個指標：任務成功率、人工 review 時間、首次 CI 通過率、需要返工的比例、輸出 token 與 API 成本、是否出現不存在的依賴或錯誤檔案。7 天後再決定它在模型路由中的位置。
一個務實的起點是：
- 長 repo 摘要、架構盤點、文件補強：優先測 GLM-5.2。
- 小修、格式整理、低風險測試：可和更便宜模型比較。
- 涉及安全、資料、合規或大型架構決策：保留高推理模型與人工審查。
這樣測，才知道 GLM-5.2 省下的是模型費、等待時間、review 時間，還是只是把成本轉移到工程師身上。
API、Coding Plan、自託管部署怎麼選？
Z.ai 目前給了三種入口，各自適合不同階段。
| 入口 | 適合誰 | 注意事項 |
|---|---|---|
| Z.ai API | 想快速接入、做自動化評測或模型路由的團隊 | 依 token 收費；長上下文任務要特別計算輸出、快取、重試與工具成本。 |
| GLM Coding Plan | 想在 Claude Code、Cline、OpenCode 等支援工具中試用的人 | 官方文件限制必須用支援工具；高峰與離峰扣點規則會影響實際可用量。 |
| 自託管部署 | 有多 GPU / NPU 資源、資料合規要求或高推理量的團隊 | 需要自己處理硬體、推理框架、監控、版本更新、安全邊界和吞吐量。 |
如果你只是想知道「GLM-5.2 能不能幫我處理長 repo」，API 或 Coding Plan 比較快。需要處理敏感程式碼、客戶資料或內部知識庫時，再評估自託管和資料治理。753B 級模型的自託管不該用「家裡電腦能不能跑」來想，合理問題是：你有沒有足夠的 GPU / NPU、量化方案、推理框架經驗、監控能力和穩定流量，讓租算力或自有機房成本攤得回來。如果你的需求只是一般本機 AI 或離線模型，先看 開源 LLM 與本地端 LLM 比較 和 Ollama 教學 會更實際。
成本可以先用 API 粗估。Z.ai pricing 頁列出 GLM-5.2 每 100 萬 token 的價格：輸入 $1.4、快取輸入 $0.26、輸出 $4.4。拿主流閉源模型做簡化對照：
| 對照模型 | GLM-5.2 輸入單價約為對方 | GLM-5.2 輸出單價約為對方 | 3:1 輸入/輸出混合成本約為對方 | 怎麼解讀 |
|---|---|---|---|---|
| Claude Sonnet 4.5 / 4.6（$3 input / $15 output） | 47% | 29% | 36% | 若任務品質接近，GLM-5.2 API 有明顯成本優勢。 |
| Gemini 2.5 Pro，200K 以下（$1.25 input / $10 output） | 112% | 44% | 63% | 輸入較貴一點，但輸出便宜很多；長輸出任務更有利。 |
| Gemini 2.5 Pro，200K 以上（$2.5 input / $15 output） | 56% | 29% | 38% | 長上下文情境下，GLM-5.2 的 API 價格帶更有吸引力。 |
這裡只比較 hosted API token 價格；租 GPU 自架的總持有成本要另算。租算力還要加上 GPU 時租、閒置率、量化後品質下降、吞吐量、批次排程、工程維運和安全控管。除非你有穩定高流量或強烈資料合規需求，第一步通常該先跑 API 成本實驗，再考慮自託管。
對台灣團隊的實際建議
GLM-5.2 對台灣團隊最有用的場景，可能是「補上長任務候選模型」而非全面替代 Claude。在 OpenAI Anthropic AI 價格戰 這類成本壓力下，更合理的用法是把它放進三層模型路由：
- 便宜模型層：處理格式、摘要、簡單抽取、低風險文件任務。
- 長任務候選層：讓 GLM-5.2 處理 repo 盤點、跨檔案理解、較長的寫程式代理任務。
- 高風險模型與人工層：保留給權限、金流、資安、資料庫和不可逆變更。
這個分層能把 GLM-5.2 的長上下文優勢用在該用的地方，也避免因為看到「開放權重」和「高分」就把所有任務一次搬過去。若你已經在做寫程式代理成本控管，也可以把 GLM-5.2 加進 寫程式代理 ROI 成本分析 的任務表，和審查時間、持續整合（CI）重跑與返工率一起算。
官方與參考來源
- Hugging Face Blog：GLM-5.2: Built for Long-Horizon Tasks
- Hugging Face 模型卡：zai-org/GLM-5.2
- Z.ai 文件：GLM-5.2
- Z.ai 文件：Pricing
- Z.ai 文件：Migrate to GLM-5.2
- Z.ai 文件：GLM Coding Plan Overview
- Artificial Analysis：GLM-5.2 is the new leading open weights model
- Anthropic：Pricing
- Google AI for Developers：Gemini API pricing
結論
GLM-5.2 的重要性在於，它把開放權重模型的討論從「能不能便宜完成簡單任務」推向「能不能承接長時間工程工作」。100 萬 token 上下文、128K 輸出、MIT 授權、753B 級模型規模和多種部署入口，讓它成為 2026 年值得測的長任務模型。
Mason 的建議是先測，不急著替換。把 GLM-5.2 放進 7 天試跑，用真實任務、測試、review 時間和成本紀錄判斷它的位置。若它能在長 repo 理解與跨檔案任務中穩定降低人工返工，再評估 API 路由、Coding Plan 或自託管。自託管要用多 GPU / NPU、穩定流量和總持有成本來算；一般家用電腦不適合當部署基準。