GLM 5.2 上下文窗口:1 百万 token 到底意味着什么

大多数 AI 模型逼着你把大文档切成碎片,逐块处理,再手动把答案拼起来。你会丢失跨段落的上下文,得写胶水代码,还得接受模型永远无法一次性看到全貌这件事。GLM 5.2 的 1,048,576 token 上下文窗口,就是专门为了让这个问题消失而存在的。

一句话版本

GLM 5.2 能把大约 1,500 页文本 —— 约 75 万个英文单词 —— 装进一个提示词。这是 GPT-4o 的 128K 上限的 8 倍,是 Claude Opus 4.8 的 200K 上限的 5 倍。完整 1M token 输入的成本是 $1.40。在这个价格下,把整个软件代码库、一年的会议纪要或一份 200 页的技术规格书一次性加载进一个请求,是经济上合理的选择,而不是奢侈。速度不会在重负载下崩塌:GLM 5.2 以每秒 158 token 运行,在 Artificial Analysis 的前沿模型速度榜上排名第 3。

快速规格一览

1 百万 token 在现实中长什么样

token 数听起来很抽象,直到你把它映射到真实文件。一个 token 大约相当于 0.75 个英文单词或 4 个字符。按这些比例算:

GPT-4o 的 128K 上限意味着任何超过约 96,000 词的单次输入都需要切块。Claude Opus 4.8 的 200K 上限抬高了这道门槛,但仍无法一次容纳大型代码库。Gemini 2.5 Pro 在 1M token 上与 GLM 5.2 持平,但价格显著更高。GLM 5.2 是唯一把 1M 上下文和 $1.40/M 的输入价格结合起来的模型。

为什么切块会毁掉分析

当文档超过模型的上下文上限时,标准的变通办法是切成块、逐块查询。这会产生三个容易被低估的问题。

跨块上下文丢失。 第 12 页的合同条款可能与第 87 页的定义互相矛盾。如果这两页落在不同的块里,模型永远看不到这个矛盾。你得到的答案局部正确、全局错误。

手工综合的开销。 把 10 个块的部分答案合并成一份连贯的最终答案,要么需要再调一次 LLM(增加成本和延迟),要么需要人来判断(增加时间)。两者都不是免费的。

索引维护。 检索增强生成(RAG)系统需要嵌入流水线、向量数据库,以及针对你具体文档结构调优的检索逻辑。这套基础设施有持续的维护成本和故障模式。1M 上下文窗口并不能替代每一个 RAG 用例,但只要完整文档装得进内存,它就能消掉对检索层的需求。

真实世界的用例

全代码库代码审查

一个 50 万行 Python 的生产仓库大约落在 500,000–700,000 token 之间。在 GLM 5.2 的上下文窗口内,你可以粘贴整个仓库,问跨文件的问题:「找出所有认证 token 未加密存储的地方。」「哪些函数调用了已废弃的 parse_legacy_format() 方法?」「总结这个 API 契约被违反的每一处。」

换成 GPT-4o,这种体量的仓库需要逐文件切块,这意味着模型无法同时看到定义和使用处,除非它们恰好落在同一个块里。GLM 5.2 能一次性容纳全部。

按每完整 1M token 输入 $1.40 算,一次全代码库审查的花费不到两美元。如果命中缓存($0.26/M),对同一代码库的重复查询只花这个数的零头。

法律与合规文档分析

大型合同、监管申报文件和合规材料包通常在 200 到 500 页。一份 200 页的 PDF 大约占 80,000–120,000 token —— 文档精简的话在 GPT-4o 的上限之内,但在边界上很危险。一份带附件的 400 页合同是 160,000–240,000 token,稳稳落在 GLM 5.2 的窗口内,同时超出 GPT-4o 的窗口。

把一个完整文档一次送进一个提示词,就能做切块无法可靠实现的交叉引用分析:「第 14 条的赔偿条款与附录 C 的责任上限冲突吗?」模型同时看到两个章节,不经过任何近似就在它们之间推理。

长程智能体会话

在智能体工作流里,每次工具调用的结果都会追加到对话历史。一个浏览 50 个网页、读取 20 个文件、执行 30 次工具调用的会话,上下文会迅速累积。在 128K 上限下,智能体必须实现上下文压缩或摘要 —— 在这个过程中丢失细粒度信息。在 1M token 下,会话在撞上天花板之前可以运行得更久,而且模型在生成下一步动作时,保留着之前每一步的完整细节。

GLM 5.2 在 Terminal-Bench v2.1 上拿到 78%,在 SWE-bench Pro 上拿到 62.1% —— 这两个 benchmark 专门衡量多步智能体任务的完成情况。长上下文与强智能体 benchmark 分数的组合,让它成为生产智能体流水线的实用选择。

研究与系统综述

学术系统综述需要阅读数百篇论文,并综合所有论文的发现。一篇典型论文约 6,000–10,000 词,约合 8,000–13,000 token。五十篇论文落在 400,000–650,000 token 之间 —— 在 GLM 5.2 的窗口内。研究者可以在一个提示词里问跨整个文献集合的比较性问题,而不是一篇一篇地查、丢掉论文之间的上下文。

长上下文摘要

一份 10 小时的会议纪要 —— 季度业务回顾、董事会会议、多日工作坊 —— 大约 200,000 token。把它作为单份文档来摘要,能保住叙事弧线、决策的演进,以及对早前讨论点的回指。切块摘要会压平时间线,丢掉结论如何形成的结构。

如何用上 1M 上下文窗口

GLM 5.2 通过 Z.ai 的 API 提供。标准的 OpenAI 兼容客户端库无需修改即可使用。

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_Z_AI_KEY",
    base_url="https://api.z.ai/v1",
)

# Load your large document
with open("large_document.txt", "r") as f:
    document = f.read()

response = client.chat.completions.create(
    model="glm-5.2",
    messages=[
        {
            "role": "user",
            "content": f"Analyze the following document and identify all compliance risks:\n\n{document}"
        }
    ],
    max_tokens=4096,
)

print(response.choices[0].message.content)

GLM 5.2 也可以通过 OpenRouter 使用,模型标识符为 z-ai/glm-5.2。开放权重(MIT 许可证)发布在 Hugging Face 的 THUDM/GLM-5.2,供自托管部署使用。

想无代码访问、又不需要 API key,glm5.app/chat 提供了一个浏览器界面,完整上下文窗口都可用。

上下文窗口 vs benchmark 表现

长上下文只有在模型能跨它准确推理时才有用。一个能装 1M token、却会从第 600 页开始编造引文的模型,还不如一个能在 200K 上可靠推理的更小模型。GLM 5.2 的 benchmark 分数为评估大规模下的准确性提供了依据。

GPQA Diamond 测试生物、化学、物理的研究生级推理 —— 这些领域需要综合多步证据链,而长文档分析需要的正是同一种认知模式。这里拿到 89%,说明在复杂问题上,模型的推理质量不会随上下文长度增加而下降。

SWE-bench Pro 和 Terminal-Bench v2.1 衡量真实的软件工程任务:在真实仓库里找 bug、修 bug,执行多步终端工作流。这些正是生产环境里最直接受益于大上下文窗口的任务。

长上下文选项对比

对于落在 128K token 之内的任务,GPT-4o 和 Claude Opus 4.8 是合理的替代选项。对于需要 200K–1M token 的任务,选择收窄到 GLM 5.2 和 Gemini 2.5 Pro。GLM 5.2 平价的 $1.40/M 定价比 Gemini 的分档结构更容易做预算,而且它 158 t/s 的生成速度意味着长上下文响应到达得更快。

GLM 5.2 不支持图像或音频输入 —— 它是纯文本的。如果你的长上下文任务包含扫描版 PDF(图像格式)或需要在模型内转写的音频纪要,在发给 GLM 5.2 之前,先确认你的流水线能不能处理文本提取这一步。

常见问题

GLM 5.2 真的会用满 100 万 token 吗,还是说准确率会在边缘衰减?

所有长上下文模型在上下文窗口的远端边缘都会出现一定衰减 —— 这是一个已知现象,有时被称为「lost in the middle」:超长上下文里开头或结尾的信息比埋在中间的信息更容易被检索到。GLM 5.2 也不例外。对于最关键内容分布在全文各处(而不是集中在特定章节)的文档,用你的真实负载去测试才是正确做法。对大多数实用场景 —— 代码库、合同、纪要 —— 500K–700K token 上的准确率,显著好于根本看不到跨文档关系的切块分析。

完整 1M token 输入实际要花多少钱?

按每百万输入 token $1.40 算,一个 1M token 请求要花 $1.40。如果你的用例涉及对同一份大文档的重复查询,缓存命中 $0.26/M 会显著降低后续成本。一个先加载大代码库一次、再跑 10 个不同分析查询的工作流,首次加载付 $1.40,缓存查询约 $0.26 × 10 = $2.60,十次全代码库分析总计约 $4.00。

最大输出长度是多少?

1,048,576 token 的限制适用于输入与输出合计的上下文。实际上,输出长度受你 API 调用里 max_tokens 参数的限制,也受模型倾向于给出聚焦而不是面面俱到的回答的影响。对大多数摘要和分析任务,输出在 1,000–4,000 token 之间,把绝大部分上下文预算留给输入。

我能拿 GLM 5.2 处理图片密集的 PDF 吗?

GLM 5.2 是纯文本模型。它不处理 PDF 里嵌入的图片、图表或示意图。如果你的文档重度依赖视觉内容 —— 架构图、财务图表、扫描页 —— 这些部分需要多模态模型,或者在发给 GLM 5.2 之前加一步单独的 OCR 来提取文本。

MIT 许可证对商用足够开放吗?

是的。MIT 是最宽松的开源许可证之一。商用、修改和再分发都允许,只要保留署名。企业用例的自托管部署 —— 本地部署、气隙环境或私有云 —— 完全覆盖。

GLM 5.2 的 MoE 架构如何影响长上下文表现?

GLM 5.2 使用混合专家(MoE)架构,总参数 753B,但每次前向传播只激活 40B(每层 256 个专家中激活 8 个)。这意味着即使总参数量大得多,每个 token 的计算成本仍接近一个 40B 稠密模型。对长上下文任务来说这很重要,因为处理 1M token 的上下文要求模型高效地执行很多次前向传播。MoE 设计让每 token 计算量保持在可控范围,这正是 GLM 5.2 在参数庞大的情况下仍维持 158 t/s 吞吐量的原因之一。

上下文长度影响每 token 价格吗?

不影响。GLM 5.2 对每百万输入 token 统一收取 $1.40,与总上下文长度无关。长上下文请求没有附加费。这是一个刻意的定价决策,让 1M token 请求在经济上可预测。

写在最后

GLM 5.2 的 1,048,576 token 上下文窗口,对任何文档体量大、跨章节推理要紧的任务都有实际意义。全代码库审查、完整法律合同、整年纪要和大型研究语料,都能以每百万 token $1.40 的成本装进一个提示词。模型的 benchmark 分数 —— GPQA Diamond 89%、SWE-bench Pro 62.1% —— 证明它能在收到的内容上准确推理。对那些目前靠切块流水线或检索系统绕开上下文上限的团队,GLM 5.2 值得作为更简单、更便宜的替代方案评估。

试试 GLM 5.2 —— 不需要 API key:glm5.app/chat。

Sources

• Artificial Analysis — GLM 5.2 Model Profile
• Z.ai API Documentation
• THUDM/GLM-5.2 on Hugging Face
• OpenRouter — z-ai/glm-5.2
• GLM 5.2 Pricing