百萬上下文
GLM 模型如何實現並高效服務 100 萬 token 上下文窗口：IndexShare 稀疏注意力、KVShare 與 MTP 技術，以及每 token FLOPs 降低 2.9 倍的關鍵改變。
GLM 模型如何實現百萬上下文
將上下文上限從 200K 提升到 100 萬 token 是一個工程問題，而非配置參數。三項改動是關鍵。
IndexShare 稀疏注意力
每四個 Transformer 層共享一個輕量索引器。它位於四個層中的第一個，其 top-k 索引被其餘三層複用 — 消除了四分之三層中的索引器點積和 top-k 計算。結果：在 100 萬上下文長度下每 token FLOPs 降低 2.9 倍。從訓練中期 128K 序列長度開始引入 IndexShare。
MTP 配合 IndexShare 與 KVShare
多 token 預測層在首個草稿步運行一次索引器，並在後續步驟中複用索引，消除了限制上一代的訓練/推理 KV 緩存不匹配。結合拒絕採樣和端到端 TV 損失，接受長度從 4.56 提升至 5.47 — 約 20% — 跨越 7 個 MTP 步驟。
| 基線 | 4.56 |
| + IndexShare + KVShare | 5.10 |
| + 拒絕採樣 | 5.29 |
| + 端到端 TV 損失 | 5.47 (+20%) |
高效服務百萬上下文
超過幾十萬 token 後，瓶頸不再是計算，而是 KV 緩存容量、長上下文內核和 CPU 開銷。三項修復：基於 LayerSplit 的細粒度內存管理和並行化、與緩存傳輸管道協調的上下文長度縮放內核優化，以及 CPU 側緩存管理、請求調度和運行時路徑調優。吞吐量優勢隨上下文增長而擴大。
歸一化吞吐量優勢
智能體強化學習訓練
訓練棧（slime）結合白盒和黑盒 rollout、緊湊軌跡和子智能體工作流。並行 OPD 訓練在大約兩天內合併了十餘個專家模型，FP8 KV 緩存確保 rollout 內存不超預算。
反獎勵黑客
長週期 RL 會誘生捷徑，因此可疑動作先通過基於規則的召回過濾器，再經 LLM 裁判精確度檢查。確認的黑客行爲被在線攔截並以虛擬工具結果回應，使 rollout 得以繼續而非被丟棄。基於 Critic 的 PPO 在單個 rollout 上保持壓縮子軌跡的可訓練性。