GLM-5 技術報告全解讀｜a16z：“最好的開源模型”

a16z 昨天發了一張圖，把 GLM-5 和 Claude Opus 4.6 并排標注在 Artificial Analysis Intelligence Index 的時間線上

https://www.a16z.news/p/charts-of-the-week-vertical-saas

原文的說法是： A proprietary model (Claude Opus 4.6) is still the 'most intelligent,' but the gap between it and the next best open weight model has closed substantially.

換句話說：a16z 稱智譜的 GLM-5，是最好的開源模型

而今天， GLM-5放出了完整的技術報告，40 頁

https://arxiv.org/pdf/2602.15763

報告發出后，我看到許多開發者社區已經開始逐頁學習

其中被討論最多的幾個技術點：DSA 稀疏注意力（20B token 追平 DeepSeek 943.7B token 的效果）、完全異步的 Agent RL 訓練框架、自研的 slime RL 基礎設施....

還有...快夸我是預言家，早早的透露了財富密碼：

下面，讓我們一起把這份技術報告逐塊過一遍

基座：744B 參數，40B 激活

先說模型的基本面：僅次于海外最頭部的閉源模型

Artificial Analysis Intelligence Index v4.0：GLM-5 得分 50，開源第一

GLM-5 沿用 MoE 架構（Mixture of Experts，一種讓模型在推理時只激活一小部分參數的設計），總參數744B，每次推理激活40B，256 個專家，80 層

對比上一代 GLM-4.5：總參數從 355B 翻到 744B，激活參數從 32B 漲到 40B

預訓練數據從 23T token 增加到 28.5T token（其中預訓練 27T，中期訓練 1.5T）

「744B 總參，40B 激活，開源模型第一次在 Artificial Analysis Intelligence Index 上拿到 50 分」

Artificial Analysis Intelligence Index v4.0：GLM-5 得分 50，開源第一

在 LMArena（原來的 Chatbot Arena）上，GLM-5 在文本競技場和代碼競技場里都排開源第一，整體和 Claude Opus 4.5、Gemini 3 Pro 同檔

LMArena 競技場排名 架構改動

在架構上，GLM-5 區別于之前的 GLM-4 系列模型，有三個大的改動

• ? MLA + Muon Split

• ? 多 token 預測

• ? DSA 稀疏注意力

讓我們按次序，逐個來說

MLA + Muon Split

GLM-5 用的注意力機制叫 MLA（Multi-latent Attention），和 DeepSeek-V3 同源。它通過壓縮 KV 緩存的維度來節省顯存，處理長文本時比傳統方案快

但團隊在訓練時發現一個問題：
用 Muon 優化器配 MLA 時，效果追不上更簡單的 GQA-8 方案

團隊之后找到了一個解法，叫 Muon Split：是對整塊投影矩陣做正交化（一種讓權重更均勻的數學操作），改成按每個注意力頭單獨做。這樣不同的頭可以按自己的節奏更新。效果追平了 GQA-8，還有個附帶收益：注意力分數在訓練過程中自動保持穩定，不用額外裁剪

額外的，GLM 團隊還做了一個 MLA-256 變體：把每個注意力頭的維度從 192 增大到 256，頭數量減少 1/3。參數總量不變，性能持平，但推理時的計算量降下來了

MLA 各變體的對比評測 多 token 預測：參數共享的 MTP

在大模型推理中，有一種加速方法叫推測解碼：用一個小模型快速猜接下來幾個 token，再讓大模型驗證。猜對了就省了大模型的計算

DeepSeek-V3 只用 1 個 MTP（Multi-Token Prediction）層訓練，推理時預測 2 個 token。但訓練和推理的方式不一致，導致第二個 token 的猜中率偏低

GLM-5 的做法：訓練時用 3 個 MTP 層，但這 3 層共享同一套參數。推理時的內存開銷和 DeepSeek-V3 一樣（因為參數只有一套），但猜中率更高

實測數據：同樣 4 步推測解碼，GLM-5 的平均接受長度2.76，DeepSeek-V3.2 是2.55

DSA 稀疏注意力

這是 GLM-5 在效率上最核心的一個改動

傳統的注意力計算是全量的，也就是每個 token 都要和所有其他 token 算一遍關系
隨著上下文長度的增加，其計算量是成平方倍增長的，例如：當上下文從 100 個 token 增長到 1 萬個 token 時，其運算量就增長了 1 萬倍，就導致了大模型在長上下文下，非常貴

DSA（DeepSeek Sparse Attention）的思路：加一個輕量級的「索引器」，先快速掃一遍所有 token，找出和當前 token 最相關的那些（top-k，k=2048），只對這部分做注意力計算。其余的跳過

和滑動窗口（只看最近 N 個 token）不同，DSA 是看內容來決定哪些 token 重要，而非位置

經過測算，在 GLM-5 中，20B token 的 DSA 適配，追上了 DeepSeek 花 943.7B token 訓出來的效果

具體流程：從中期訓練結束后的基礎模型開始，先做 1000 步預熱（只訓練索引器，主模型凍結），然后做 20B token 的稀疏適配訓練。總預算 20B token。DeepSeek-V3.2 的 DSA 訓練用了 943.7B token，是 GLM-5 的將近 50 倍

最終效果：DSA 模型在長上下文基準上和原始 MLA 模型基本持平。SFT 之后的訓練損失曲線也幾乎重合

MLA 和 DSA 的 SFT 損失曲線幾乎重合

實際收益：長序列的注意力計算降低 1.5-2 倍。后面做 Agent 推理時動輒 200K 上下文，GPU 成本直接砍一半

技術報告還做了一組消融實驗，對比了 DSA 和其他幾種省計算的注意力方案：

• ?樸素的滑動窗口交錯：固定每隔一層用窗口注意力，128K 上下文下 RULER 跌了 30 分，基本不可用

• ?基于搜索的 SWA 模式：用束搜索找到最優的層分配，效果好很多，但細粒度檢索上還是丟 5-7 分

• ?GDN 和 SimpleGDN：SimpleGDN 在復用預訓練權重方面最高效

• ?DSA：索引器做的是 token 級的動態選擇，不丟棄任何長程依賴

三個來源都做了升級

網頁數據
在 GLM-4.5 的管線上新增了基于句子嵌入的 DCLM 分類器，用來撈標準分類器漏掉的高質量內容。另外訓練了一個「世界知識分類器」（用 Wikipedia 條目 + LLM 標注數據），從中低質量網頁里篩出有價值的長尾知識

代碼數據
刷新主要代碼托管平臺的快照，模糊去重后 unique token 增加 28%。修復了 Software Heritage 的元數據對齊問題。給 Scala、Swift、Lua 等低資源語言訓練了專用分類器

數學與科學
從網頁、書籍、論文里收集，用 LLM 打分只保留最具教育價值的部分。長文檔用分塊聚合評分。嚴格排除合成數據和 AI 生成數據

中期訓練

上下文窗口分三個階段擴展：

• ? 32K（1T token）

• ? 128K（500B token）

• ? 200K（50B token）

GLM-4.5 最大做到 128K，新增的 200K 階段主要為了處理超長文檔和多文件代碼庫

軟件工程數據擴了一輪：放寬倉庫級篩選獲得約 1000 萬個 Issue-PR 對，但加強了單個 issue 的質量過濾。最終 issue-PR 部分約 160B token

長上下文數據包括自然數據（書籍、論文）和合成數據。合成數據用了 NextLong 和 EntropyLong 的思路構建長程依賴。200K 階段額外加入 MRCR 類數據的多種變體，用來增強超長多輪對話中的召回能力

訓練工程

技術報告花了不少篇幅講訓練基礎設施的優化，列幾個關鍵的：

• ? MTP 布局優化：MTP 模塊的輸出層和主輸出層放在流水線最后一個 stage 共享參數，其余前移，平衡各 rank 的顯存占用

• ? ZeRO2 梯度分片：每個 stage 只存 1/dp 的梯度，配合雙緩沖，不增加同步開銷的前提下大幅降低梯度顯存

• ? Muon 優化器零冗余通信：all-gather 限制在本 rank 負責的參數分片內

• ? 流水線激活卸載：前向完成后把激活按層卸到 CPU，反向時再加載，和計算重疊執行

• ? 序列分塊輸出投影：長序列下輸出層和 loss 的顯存峰值很高，按序列維度分塊處理

• ? INT4 量化感知訓練（QAT）：在 SFT 階段就做，開發了訓練和推理 bit-level 對齊的量化 kernel

這些并非是某一項特別新，但組合在一起讓 744B 的模型能在合理的硬件規模上訓起來

后訓練全流程

GLM-5 的后訓練是一條完整的流水線：SFT → Reasoning RL → Agentic RL → General RL → 跨階段在線蒸餾

GLM-5 訓練全流程 SFT

三大類數據：通用對話（問答、寫作、角色扮演、翻譯、多輪對話、長上下文）、推理（數學、編程、科學）、編程與 Agent（前端/后端代碼、工具調用、Coding Agent、搜索 Agent）

最大上下文長度擴到 202752 token

三種思考模式：

• ? 交錯思考（Interleaved Thinking）：每次響應和工具調用前都思考一輪，提升指令遵循和生成質量

• ? 保留思考（Preserved Thinking）：在 Coding Agent 場景里，多輪對話之間保留所有思考內容，不重新推導。適合長程復雜任務，減少信息丟失

• ? 輪級思考（Turn-level Thinking）：按輪次控制開關。簡單請求關掉思考降延遲，復雜任務打開提精度

編程和 Agent 的 SFT 數據用了專家 RL 和拒絕采樣來提質。一個細節：軌跡中的錯誤片段被保留下來，但在計算 loss 時用掩碼屏蔽。模型能看到錯誤發生了什么，學會糾錯行為，但不會被訓練去重復錯誤動作

Reasoning RL

算法基于 GRPO + IcePop。核心改動是明確區分了用于梯度更新的「訓練模型」和用于生成軌跡的「推理模型」，去掉了 KL 正則項來加速訓練。純 on-policy，group size 32，batch size 32

一個很小但影響很大的工程發現

DSA 的索引器在每個 token 位置要做 top-k 檢索（k=2048，就是從所有 token 里挑出 2048 個最重要的）。SGLang 推理引擎里用的是基于 CUDA 的 top-k 實現，速度快，但結果有隨機性：同樣的輸入跑兩次，排序結果可能不完全一樣

「把torch.topk換成 CUDA 的非確定性 topk，RL 幾步就崩了」

具體表現：熵值驟降，性能急劇退化。原生的torch.topk慢一些，但每次輸出確定一致。最終方案是全程用torch.topk，并在 RL 階段凍結索引器參數

Reasoning RL 在四個領域做混合訓練：數學、科學、代碼、工具集成推理（TIR）。難度過濾邏輯：只保留 GLM-4.7 做不出來、但 GPT-5.2 xhigh / Gemini 3 Pro Preview 能做出來的題

Agentic RL

這是技術報告里篇幅最大的一塊

核心問題：Agent 任務的 rollout（讓模型和環境交互生成完整軌跡）時間極長，而且不同任務之間差異很大。一條 SWE 任務可能幾分鐘，另一條可能半小時。同步 RL 的做法是等所有軌跡都生成完再一起訓練，最慢的那條卡多久，整批 GPU 就閑多久

GLM-5 的做法是完全異步：

• ? 訓練 GPU 和推理 GPU 物理分開

• ? 推理端持續不斷地生成軌跡，攢夠一批就發給訓練端

• ? 推理端的模型權重每隔 K 步和訓練端同步一次

Multi-Task Rollout Orchestrator：不同類型的 Agent 任務（SWE 修 bug、終端操作、搜索問答）各自作為獨立的微服務注冊到中央編排器，編排器控制任務比例和生成速度。支持 1000+ 并發 rollout

幾個保證異步訓練不崩的關鍵設計：

TITO（Token-in-Token-out）

傳統做法是把推理引擎當黑箱：先發進去一段文字，然后拿回來一段文字，訓練時再重新做 tokenization。問題是 re-tokenization 會在 token 邊界、空格處理、截斷位置上引入細微差異，影響對單個 token 采樣概率的估計

TITO 的做法：訓練流程直接消費推理引擎生成的 token ID 序列和元數據，不做文本往返。保證 token 級別的精確對應

直接雙側重要性采樣

異步場景下，推理引擎的模型可能在一條軌跡生成過程中被更新了好幾次。要追蹤完整的歷史策略概率，就得存一堆歷史模型權重，不現實

GLM-5 直接用 rollout 時記錄的對數概率作為行為代理，算重要性比率 r_t(θ) = π_θ / π_rollout。落在信任域 [1-ε_l, 1+ε_h] 外的 token 直接屏蔽梯度，不讓偏差太大的樣本影響訓練

樣本過濾：記錄每條軌跡的模型版本號，版本差距超過閾值的丟棄。因環境崩潰（不是模型能力問題）導致失敗的樣本也排除

DP-aware 路由：多輪 Agent 任務里，同一個 rollout 的后續請求通過一致性哈希路由到同一個 DP rank，復用 KV cache。預填充成本只和增量 token 成正比

General RL

優化目標分三個維度：

• ? 正確性：指令遵循、邏輯一致、事實準確、無幻覺

• ? 情商：同理心、洞察力、自然的人類表達風格

• ? 特定任務能力：寫作、問答、角色扮演、翻譯等各領域的細粒度優化

獎勵系統是三種信號混合的：規則獎勵（精確但覆蓋面窄）+ 判別式獎勵模型 ORM（低方差但容易被 reward hacking）+ 生成式獎勵模型 GRM（魯棒但方差大）

一個有意思的做法：在 RL 中引入人類撰寫的高質量回復，作為風格和質量的錨點。原因是純模型 RL 容易收斂到冗長、公式化的「機器感」模式。這些模式在獎勵函數上得分高，但讀起來很不自然。人類回復用來把風格拉回來

跨階段在線蒸餾

多階段 RL 的經典問題：后面的階段優化新目標時，前面學到的能力退化（災難性遺忘）

GLM-5 在最后加了一個蒸餾階段：把前面每個階段（SFT、Reasoning RL、General RL）的最終 checkpoint 作為教師模型，學生模型通過 logits 差距直接計算 advantage，不需要大 group size。batch size 開到 1024 提吞吐

Agent 環境：10000+ 可驗證場景

RL 訓練需要可驗證的執行環境，對于模型做了什么，環境要能給出明確的對錯反饋

軟件工程環境

從真實 GitHub 的 Issue-PR 對出發，基于 RepoLaunch 框架自動構建可執行環境。自動分析倉庫的安裝和依賴，構建 Docker 環境，生成測試命令，用 LLM 從測試輸出生成日志解析函數

覆蓋 9 種語言：Python、Java、Go、C、C++、JavaScript、TypeScript、PHP、Ruby

超過 10000 個可驗證環境

終端環境

兩條路徑：

• ? 種子任務合成：從真實 SWE 和終端場景收集種子，LLM 生成任務草稿 → 構建 Agent 在 Harbor 格式下實例化 → 精煉 Agent 迭代優化。Docker 構建精度超 90%

• ? 網頁語料合成：從代碼網頁出發，到閉環設計，要求 Coding Agent 合成任務的同時自行驗證，只有通過所有檢查的才納入最終數據集

從早期搜索 Agent 的軌跡中收集了 200 萬+ 高信息量網頁，構建 Web 知識圖譜（WKG）。從中生成多跳問答對，在這個過程中，每個問題需要從多個網頁匯聚證據，經過多步推理

難度過濾分三階段：

• ? 刪掉不用工具推理模型也能答對的題（8 次獨立嘗試中至少對 1 次就刪）

• ? 過濾掉早期 Agent 幾步就能搜到的題

• ? Verification Agent 做雙向校驗，排除答案不唯一或證據不一致的樣本

BrowseComp 基準上的性能對上下文管理策略很敏感。模型在執行搜索任務時會不斷積累工具調用歷史，上下文越來越長，性能開始下降

GLM-5 用了一套分層管理策略：

• ? Keep-recent-k：當交互歷史超過 k 輪時，只保留最近 5 輪的完整內容，舊的工具結果折疊。效果從 55.3% 提到 62.0%

• ? 和 Discard-all 結合：總上下文超過 32K 時，清空全部工具調用歷史重新開始，同時繼續 Keep-recent-k

這樣模型可以在預算內執行更多步搜索，最終 BrowseComp 得分75.9，所有模型里最高（含閉源）

從 GLM-4.7 到 GLM-5，不同上下文管理策略下 BrowseComp 的準確率 PPT 生成與 Reward Hacking

技術報告里寫了一個很直觀的 reward hacking 案例

PPT 生成用 HTML 作為中間格式。RL 訓練中設計了三級獎勵：Level 1 看 HTML 靜態屬性（定位、間距、顏色），Level 2 看運行時渲染后的真實屬性（DOM 節點實際寬高），Level 3 看視覺感知（空白檢測等）

模型找到了兩種作弊方式：

一種是用overflow: hidden把溢出內容藏起來，讓頁面看起來符合 16:9 但實際上內容被截斷了

另一種是用flex: 1 1 8%強行占滿空間，布局看著正常但內容很稀疏

PPT 生成中的 reward hacking 案例

解法是改渲染器，直接拿渲染后的真實屬性值做評估，而不是看 HTML 源碼里寫了什么。修正后，符合 16:9 比例的頁面從 40% 提升到 92%。人工評估里 GLM-5 對比 GLM-4.5 的綜合勝率 67.5%

國產芯片適配

GLM-5 從上線第一天就在跑國產芯片。適配覆蓋七大平臺：華為昇騰、摩爾線程、海光、寒武紀、昆侖芯、天數智芯（MetaX）、燧原

技術報告以華為昇騰 Atlas 系列為例展開了三個層面：

W4A8 混合精度量化：標準的 Attention 和 MLP 模塊用 INT8（W8A8），MoE 專家模塊壓到 INT4（W4A8）。讓 750B 的模型能裝進單臺 Atlas 800T A3 服務器

融合算子：

• ? Lightning Indexer：把分數計算、ReLU 激活和 TopK 三步融合成一個算子

• ? Sparse Flash Attention：TopK 檢索和稀疏注意力計算并行執行

• ? MLAPO：把 13 個碎片化的預處理算子融合成一個

推理引擎優化：vLLM-Ascend 和 SGLang 都做了適配。異步調度消除采樣回傳的氣泡，RadixCache 做前綴共享，注意力 DP + MoE EP 混合并行，MTP 加速

最終效果：單臺國產節點的推理性能接近兩臺國際主流 GPU 集群。長序列場景下部署成本降低 50%

評測

下面是完整的跑分數據

全面對比表格

當然，我也整理了文字版的對比

推理

• ? HLE（含工具）：50.4，vs Claude Opus 4.5 的 43.4，GPT-5.2 xhigh 的 45.5，Gemini 3 Pro 的 44.2

• ? HLE（不含工具）：30.5，vs Claude 35.9，GPT-5.2 xhigh 25.1

• ? AIME 2026 I：92.7，vs Claude 93.3，Gemini 3 Pro 92.7

• ? HMMT Feb. 2025：97.9，vs Claude 92.9，Gemini 3 Pro 97.3

• ? HMMT Nov. 2025：96.9，vs Claude 93.5，Gemini 3 Pro 96.9

• ? IMO-AnswerBench：82.5，vs Claude 87.5，GPT-5.2 xhigh 75.5

• ? GPQA-Diamond：86.0，vs Claude 85.8，GPT-5.2 xhigh 84.8

• ? LongBench v2：64.5，vs Claude 59.5，Gemini 3 Pro 68.2

• ? SWE-bench Verified：77.8，vs Claude 80.9，Gemini 3 Pro 72.5，GPT-5.2 xhigh 80.0

• ? SWE-bench Multilingual：73.3，vs Claude 77.5，GPT-5.2 xhigh 72.0

• ? Terminal-Bench 2.0：56.2（修正模糊指令后60.7-61.1），vs Claude 59.3

• ? CyberGym：43.2，vs Claude 51.3

• ? BrowseComp（含上下文管理）：75.9，vs Claude 64.8，GPT-5.2 xhigh 54.4

• ? BrowseComp-ZH：72.7，vs Claude 64.8，Gemini 3 Pro 42.3

• ? τ2-Bench：89.7，vs Claude 91.6

• ? MCP-Atlas：67.8，vs GPT-5.2 xhigh 68.0

• ? Tool-Decathlon：74.0，vs Claude 75.6

• ? Vending-Bench 2：$4432，vs Claude ， 5478

• ? GDPval-AA Elo：1409，vs Claude 1381，GPT-5.2 xhigh 1437

在 SWE-rebench（一個持續更新的、去污染的 SWE 評測）上，GLM-5 的42.1%和 Claude Opus 4.5 的43.8%只差 1.7 個百分點

CC-Bench-V2：真實工程體驗

這是智譜內部的評測基準，完全自動化，不依賴人工標注。用 Claude Code + Claude Sonnet 4.5 配合 Playwright 做 Agent-as-a-Judge，讓一個 Agent 去操作另一個 Agent 生成的前端項目，點擊按鈕、輸入內容、截屏，逐項驗證是否正確

Agent-as-a-Judge 評估流程

前端

三個指標：BSR（構建成功率）、CSR（檢查項通過率）、ISR（實例整體通過率）

對比表格

BSR 98% 說明 GLM-5 生成的項目幾乎都能跑起來。CSR 和 Claude 接近，單項需求的完成度差不多

但 ISR 的差距很明顯，比如 HTML 上差了 13 個百分點，Vue 上差了 14 個百分點。BSR 高但 ISR 低，說明單項能力到位了，但把所有需求組合起來端到端完成一整個任務，還有空間

后端

85 個任務，6 種語言（Python、Go、C++、Rust、Java、TypeScript），涵蓋搜索引擎、數據庫、Web 框架、AI 推理服務等

GLM-5 Pass@1：25.8，vs Claude Opus 4.5 的26.9

長程任務

兩個子任務：

大規模代碼庫探索（在數萬個文件的倉庫里找到目標文件）：GLM-565.6，優于 Claude 的 64.5。這個任務考的是策略性搜索而不是代碼生成：模型需要通過推理縮小文件范圍，GLM-5 在 Agent 工具使用軌跡上的訓練在這里體現了優勢

多步鏈式任務（每一步的代碼修改會改變后續步驟的上下文，模擬真實的增量開發）：GLM-552.3，vs Claude 的61.6，差距明顯

技術報告也寫了原因：鏈式任務中錯誤會累積，上一步的次優修改可能悄然破壞后續步驟的測試。縮小這個差距需要在長上下文一致性和長程自糾錯上繼續突破

CC-Bench-V2 完整結果 通用能力

GLM-5 相比 GLM-4.7 在五個維度全面提升

• ? 機器翻譯（ZMultiTransBench）：1016 → 1050

• ? 多語言對話（LMArena）：1441 → 1452

• ? 指令遵循（IF-Badcase）：78.5 → 83.2

• ? 世界知識（Chinese SimpleQA）：72.9 → 75.2

• ? 工具調用（ToolCall-Badcase）：60.8 → 95.8

工具調用這一項提升幅度很大，從 60 出頭直接拉到 95 以上

五項通用能力對比 RL 訓練框架：slime

GLM-5 的后訓練全跑在自研的 slime 框架上。三個設計重點：

橫向擴展：高度可定制的 rollout 接口 + HTTP API 暴露推理服務。不同 Agent 框架可以像調用普通推理引擎一樣和 slime 交互。訓練邏輯和推理邏輯完全解耦

縱向擴展：RL 推理的優化目標，是端到端延遲：瓶頸在最慢的那條軌跡上。GLM-5 用多節點推理部署（EP64 + DP64 跨 8 節點），FP8 rollout 降低單 token 延遲，MTP 在小批次解碼下收益尤其大，PD 分離（prefill 和 decode 分開調度）確保多輪交互中解碼速度穩定

容災：推理服務定期發心跳，不健康的節點自動終止并從路由注銷，請求自動重試到健康節點

產品和使用方式

GLM-5 模型權重遵循 MIT License 開源，在 Hugging Face 和 ModelScope 同步上線

線上服務已納入 Max 用戶套餐，Pro 用戶 5 天內支持。GLM Coding Plan 適配 Claude Code、OpenCode 等主流開發工具

幾個新的產品場景：

Z Code
智譜推出的編程工具。用戶說清楚需求，模型自動拆解任務，多 Agent 并發完成代碼編寫、命令執行、調試、預覽和提交。支持手機遠程指揮桌面端 Agent。Z Code 本身也是 GLM 模型參與開發完成的

OpenClaw 適配
OpenClaw（開源的 Agent 框架，a16z 文章里提到它在 OpenRouter 上占了 13% 的 token 消耗）現在有了 AutoGLM 版本，支持官網一鍵配置和飛書機器人集成。Pro / Max 用戶限量贈送

辦公文檔輸出
在 Z.ai 和智譜清言上，可以讓 GLM-5 直接生成 .docx、.pdf、.xlsx 文件，比如產品需求文檔、教案、試卷、財務報告等

GLM in Excel
原生適配 Excel 的 AI 插件，側邊欄里用自然語言處理表格數據。Beta 階段僅 Max 用戶

Pony Alpha

技術報告最后有一個彩蛋

GLM-5 最早的時候，是在 OpenRouter 上以匿名身份「Pony Alpha」上線，未公開任何品牌信息，純靠模型體感

上線幾天后在 OpenRouter 社區引起關注。開發者注意到它在復雜代碼、Agent 任務鏈路和角色扮演上的表現，開始猜測身份

25% 的用戶推測它是 Anthropic 的 Claude Sonnet 5；20% 認為是 Grok 的新版本；10% 猜是 DeepSeek V4；

最終確認是 GLM-5

技術報告全文
https://arxiv.org/pdf/2602.15763

GitHub
https://github.com/zai-org/GLM-5

Hugging Face
https://huggingface.co/zai-org/GLM-5

ModelScope
htps://modelscope.cn/models/ZhipuAI/GLM-5

Z Code
https://zcode.z.ai/cn

Blog
https://z.ai/blog/glm-5