GLM-5.2 NVIDIA 免费 API 有一个有趣的原因：NVIDIA 使得一个庞大的 Z.ai 模型易于测试，但端点的实际限制与模型的完整能力并不相同。
简短版本：
我将其视为一个有用的评估设置。每分钟 40 次请求足以用于原型、代理评估和手动比较。最大令牌是令人烦恼的部分，而这部分你需要自己测试，因为模型规格和提供者端点限制可能会有所不同。
GLM-5.2 NVIDIA 免费 API：变化
GLM-5.2 是 Z.ai 的新旗舰模型。NVIDIA 的模型文档将其描述为一个753B参数的专家混合模型，旨在处理长期任务、代理、编码和工具使用。Z.ai 自己的文档强调了 1M 上下文和最多 128K 输出令牌。
这就是模型级别的定位。
NVIDIA Build 页面是实际层面。GLM-5.2 在那里列出了一个免费端点、合作伙伴端点和下载选项。Python 示例调用了 NVIDIA 的 OpenAI 兼容的集成 API 端点，模型为 `z-ai/glm-5.2`。示例将 `max_tokens` 设置为 16,384。
我不会将“GLM-5.2 仅为 32k”作为模型事实。我会这样写：在 NVIDIA 的免费端点上，最大令牌空间似乎受到提供者的限制，与模型的更大上下文窗口相比。如果你在实践中看到 32k，请将其视为需要针对你的账户、请求形状和 NVIDIA 当前配置进行测试的端点观察。
这种区分很重要。一个模型可以支持长上下文，而一个免费端点则暴露出较低的输出限制、更少的能力和更严格的速率限制。
基准测试：GLM-5.2 vs GLM-5.1
NVIDIA 发布了 GLM-5.2 与 GLM-5.1 以及其他几个前沿模型的基准数字。最干净的比较从 GLM-5.1 开始，因为它显示了 Z.ai 在模型上的进步。
| 基准 | GLM-5.2 | GLM-5.1 | 差异 | 重要性 |
|---|---|---|---|---|
| --- | ---: | ---: | ---: | --- |
| HLE | 40.5 | 31.0 | +9.5 | 硬知识和推理任务 |
| HLE with tools | 54.7 | 52.3 | +2.4 | 工具支持的问题解决 |
| AIME 2026 | 99.2 | 95.3 | +3.9 | 竞争数学和严格推理 |
| GPQA-Diamond | 91.2 | 86.2 | +5.0 | 专家级科学问题 |
| SWE-bench Pro | 62.1 | 58.4 | +3.7 | 在类库环境中的代码修复 |
| NL2Repo | 48.9 | 42.7 | +6.2 | 从自然语言构建代码跨越类库上下文 |
| Terminal Bench 2.1 | 81.0 | 63.5 | +17.5 | 基于终端的工程任务 |
| MCP-Atlas | 76.8 | 71.8 | +5.0 | MCP 和工具导向的代理任务 |
| Tool-Decathlon | 48.2 | 40.7 | +7.5 | 广泛的工具使用能力 |
推理和数学
AIME 2026 的 99.2 和 GPQA-Diamond 的 91.2 是强有力的数字。它们表明 GLM-5.2 不仅仅被定位为编码模型。它在严格推理、专家问题和模型不能仅靠模糊模式匹配完成的任务上也有很强的表现。
编码和代理工作流
让我印象深刻的数字是 Terminal Bench 2.1：81.0 对 63.5。这不是一个表面的改进。如果这个结果在实际测试中成立，GLM-5.2 将在类库工作、CLI 工作流和代理工程任务中变得有趣，模型必须检查状态、运行步骤、解释错误并继续。
这就是我开始测试的地方。没有诗意的提示。没有通用的聊天。我会将其应用于真实的开发工作流：破损的构建、小的 PR 修复、面向类库的调试和 MCP 工作，其中模型必须保持多个工具与目标一致。
每分钟 40 次请求比听起来要好
如果你考虑一个有许多并发用户的生产系统，每分钟 40 次请求听起来很低。但对于评估来说，情况就不同了。
每分钟 40 次请求足以：
这对于以下情况来说是不够的：
对我来说，GLM-5.2 在 NVIDIA 的免费端点上是一个评估表面，而不是一个生产表面。这就是我首先使用它的方式。
我有一些应用和代理的想法想要用这样的模型进行测试，但在进行真实测试之前我不会透露它们。每分钟 40 次请求足以了解模型是否理解工作流。这不足以证明它在生产中能否保持稳定。
最大令牌：32k 是测量的限制
如果端点在实践中给你 32k 最大令牌，那并不是没用的。这仍然是一个真实的限制。
对于正常的编码提示，32k 输出是很多。对于长代理流程、完整的类库上下文、长日志和生成的补丁，它可能会很快变得紧张。尤其是当你希望模型进行推理、计划、返回代码并保持可追溯性时。
这是我会运行的测试列表：
| 测试 | 我会测量什么 |
|---|---|
| --- | --- |
| 长类库提示 | 模型是否丢失重要文件或约束？ |
| 大日志加修复 | 它能否在不重写错误模块的情况下找到根本原因？ |
| 补丁输出 | 答案是完整的还是被截断的？ |
| 工具使用循环 | 它能否在多个步骤之间保持状态？ |
| 40 RPM 负载 | 429 开始出现的时间，以及重试/回退的稳定性如何？ |
| 令牌上限 | 限制是 16k、32k，还是依赖于账户/端点？ |
| 比较模型 | 它是否在同一任务上超过当前模型，还是仅在发布的基准中？ |
最后一行最为重要。基准测试告诉你模型可能强大的地方。你自己的任务告诉你它是否有用。
一个 NVIDIA 警告
NVIDIA 的 API 文档描述 GLM-5.2 支持多轮聊天、工具调用、结构化输出和推理跟踪。同时，NVIDIA Build 页面显示免费模型的功能调用、结构化输出和推理在侧边栏中标记为“未支持”。
我不会假设模型可以支持的地方就具备完整的代理功能。我会首先测试实际的 NVIDIA 端点作为 OpenAI 兼容的聊天/完成表面，然后单独验证每个功能。
这是一个常见的提供者分歧：模型卡描述模型，而端点描述你可以使用的产品。
声明检查
我的第一次阅读
GLM-5.2 在正确的基准上表现强劲。对我来说，最清晰的信号不是 AIME 数字，尽管 99.2 是极端的。更有用的信号是 Terminal Bench 2.1、NL2Repo、SWE-bench Pro、MCP-Atlas 和 Tool-Decathlon 的组合。
这就是模型开始对真实开发工作流产生影响的地方。
NVIDIA 的免费端点降低了门槛。每分钟 40 次请求使其对严肃测试有用。最大令牌限制意味着你不应该将其视为完整的生产表面。
我的看法是：GLM-5.2 现在值得与自己的代理工作流进行基准测试。记录每个请求，测量输出截断，将相同的案例与其他模型进行比较，并将 NVIDIA 免费 API 视为测试平台，直到你在实践中验证限制。
工作不是追逐炒作。工作是找出模型是否能解决真实任务，而不迫使你围绕其弱点构建整个系统。