GLM 5.2 对比 Opus

# GLM-5.2 vs Claude Opus 来源：https://techstackups.com/comparisons/glm-5.2-vs-opus/ GLM-5.2 刚刚发布，这是开放模型向前迈进的又一步。互联网很快炸开了锅，很难分辨哪些是真实信息，哪些是炒作。 因此，我们让它与 Claude Opus 4.8 进行正面较量：使用相同的单次提示词，从头开始用纯 WebGL 构建一个 3D 平台游戏。以下是我们运行测试、深入研究基准测试并听取各方评论后的看法。 **我们不会将主力模型从 Opus 换掉。** 在我们的测试中，Opus 速度更快，交付的游戏更干净、更正确，并且它可以检查自己的视觉输出，而纯文本的 GLM-5.2 做不到这一点。但 GLM-5.2 在武器库中赢得了永久席位：它是一个真正有能力的模型，价格却只有几分之一，而且因为是开放权重，它将*始终*可用。闭源模型可能会在几乎没有预警的情况下被停用或限制使用（Fable 就是最近的例子）；而你可以下载的权重则无法被剥夺。 你现在就可以试玩这两款游戏，或者直接获取源代码： - **GLM-5.2 的游戏：** [3dgame-glm.d.ritzademo.com](https://3dgame-glm.d.ritzademo.com/) - **Opus 的游戏：** [3dgame-opus.d.ritzademo.com](https://3dgame-opus.d.ritzademo.com/) - **两者的源代码：** [github.com/jamesdanielwhitford/glm-5.2-vs-opus-platformers](https://github.com/jamesdanielwhitford/glm-5.2-vs-opus-platformers) 两者都是从头开始编写的浏览器游戏，没有使用任何游戏引擎或像 Three.js 这样的 3D 渲染库。3D 模型是来自 [Kenney](https://kenney.nl/assets/platformer-kit) 的免费 CC0 资产。 以下是两次运行的比较情况： | 指标 | GLM-5.2 (Pi/OpenRouter) | Opus (Claude Code) | | :--- | :--- | :--- | | 墙钟构建时间 | 1小时10分40秒 | **33分30秒** | | 输出 Token 数 | 131,000 | 216,809 | | 峰值上下文窗口 | 1M 中的 16% | 1M 中的 19% | | 工具调用次数 | 128 | 153 | | 成本 | **$5.39 (实际账单)** | ~$21.92 (估算，标准定价) | GLM-5.2 的成本只有几分之一。Opus 在不到一半的时间内完成，并交付了一个更干净的游戏。 从纸面上看，[基准测试](https://techstackups.com/comparisons/glm-5.2-vs-opus/#the-benchmarks) 将 GLM-5.2 置于顶级闭源模型之后，而[网络热议](https://techstackups.com/comparisons/glm-5.2-vs-opus/#what-people-are-saying) 则是真实信号和人为炒作的混合体。我们将在游戏部分之后深入探讨这两者。 ## GLM-5.2 是什么 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#what-is-glm-52) GLM-5.2 是 Z.ai 最新的旗舰模型。它采用 MIT 许可证开放权重，因此你可以下载、自行运行，或者通过 Z.ai 的 API 调用。 它专为长时域任务而设计，即那种持续数小时的、多步骤的编码代理工作。它配备了 1M 令牌的上下文窗口和两种思考强度级别——高（High）和最高（Max），以速度换取能力。 > 注意 > GLM-5.2 是纯文本模型，不支持多模态。它无法读取图像，因此依赖截图或图表的工作流程仍需使用像 Claude Opus 这样的模型。 Z.ai 将其定位大致介于 Claude Opus 4.7 和 4.8 之间，使用相似的 Token 数量。如果你想了解更多，可以查看他们的公告： > [@Zai_org 在 X 上](https://twitter.com/Zai_org/status/2066938937344495629) ### 定价与访问 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#pricing-and-access) 因为开放权重，GLM-5.2 很便宜。通过 API 使用，它的成本只有 Opus 的一小部分，并且如果你有硬件，甚至可以免费自行运行。 定价（每百万 Token，来自供应商文档）： | | 输入 | 缓存读取 | 输出 | | :--- | :--- | :--- | :--- | | Claude Opus 4.8 | $5 | $0.50 | $25 | | GLM-5.2 | $1.4 | $0.26 | $4.4 | 在输出 Token 方面，GLM-5.2 的价格不到 Opus 的五分之一。 权重托管在 Hugging Face 和 ModelScope 上，采用 MIT 许可证，无区域限制。你可以使用 vLLM、SGLang 或 Transformers 等框架在本地提供服务。 ## 我们的体验测试：从零开始构建 3D 游戏 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#our-vibe-test-a-3d-game-from-scratch) 为了透过表象看本质，我们给 Opus 4.8 和 GLM-5.2 下达了相同的单次提示词：从零开始，使用原生 WebGL 构建一个 3D 平台游戏，不得使用任何游戏引擎或 3D 库。 ### 为什么选择这个任务 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#why-this-task) 一个模型可以零样本生成一个漂亮的着陆页，社区已经不把这种测试当回事了。原生 WebGL 的 3D 平台游戏无法用一个漂亮的单文件来蒙混过关。它拥有真正的结构：GLB 模型解析器、矩阵和向量数学、GLSL 着色器、蒙皮骨骼动画、固定时间步长循环、碰撞检测、跟随摄像机。 这种结构同时测试了人们争论的两个方面。将分层的、多文件的构建在许多步骤中维系在一起，是代理方面的能力，而这正是 GLM-5.2 的强项。确保引擎内部逻辑正确——那些看起来还行但会悄然出错的部分——则是推理和品味方面的能力，而这正是 Opus 被认为更胜一筹的地方。 我们将 3D 资产打包在本地，因此测试的是引擎和渲染能力，而不是工具能否获取模型文件。美术资产本身是一套人工制作的资源包——[Kenney 的 CC0 平台游戏套件](https://kenney.nl/assets/platformer-kit)——两个代理都获得了完全相同的文件。 ### 每个模型需要构建什么 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#what-each-model-had-to-build) 为了完成任务，每个模型都需要构建： - 一个纯原生 WebGL 的 3D 引擎和渲染器，不能使用 Three.js 或任何库。 - 一个用于加载提供的 3D 角色和世界模型的加载器。 - 一个在竞技场中奔跑和跳跃的角色，具备重力和碰撞检测。 - 一个跟随摄像机和键盘控制。 - 整个系统能在浏览器中用一条命令运行起来。 两者大部分工作都是手工完成的（通过工具？通过爪子？）：GLB 二进制解析器、矩阵和四元数数学、带 GLSL 蒙皮着色器的 WebGL2 渲染器，以及子步进 AABB 碰撞检测，以防止角色穿透平台。 两者都获得了相同的提示词、相同的资产，并且只有一次机会，没有任何提示。我们以高（high）扩展思维模式运行 Opus 4.8，GLM-5.2 的思考模式设置为高（GLM-5.2 还提供了一个更高的最高级 Max，我们没有使用）。你可以自行深入研究这两次运行： - **试玩 GLM-5.2 的游戏：** [3dgame-glm.d.ritzademo.com](https://3dgame-glm.d.ritzademo.com/) - **试玩 Opus 的游戏：** [3dgame-opus.d.ritzademo.com](https://3dgame-opus.d.ritzademo.com/) - **两者的源代码：** [github.com/jamesdanielwhitford/glm-5.2-vs-opus-platformers](https://github.com/jamesdanielwhitford/glm-5.2-vs-opus-platformers) - **Opus 构建记录：** [完整会话](https://gisthost.github.io/?6ae707dea3854638bbd1e9dde19fa4a7/page-001.html) - **GLM-5.2 构建记录：** [完整会话](https://gisthost.github.io/?8d6070dd5988092257ca359d8d583837/session.html) ### 花费的时间和成本 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#how-long-it-took-and-what-it-cost) Opus 4.8 在 Claude Code 中构建；GLM-5.2 在 Pi (通过 OpenRouter) 中构建。 *Opus 和 GLM-5.2 构建游戏的并排延时摄影* *并排延时摄影。Opus 在 34:00 完成，GLM-5.2 在 1:11 完成。* 延时摄影显示了整个构建过程的压缩：Opus 大约用了不到一半的墙钟时间完成工作，GLM-5.2 耗时更长但成本远低于后者。完整数据见顶部的结果表。 ### 试玩两款游戏 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#playtesting-both-games) 我们从头到尾玩了两款游戏。以下是各自的表现。 两者都构建了同类型的游戏：一个第三人称 3D 平台游戏，控制方式相同。你可以用 WASD 或方向键移动，空格跳跃，Shift 冲刺，通过拖拽鼠标旋转视角，滚轮缩放。目标也相同：收集平台上的金币并到达旗帜处，躲避尖刺危险，掉出世界则会回到起点。 #### GLM-5.2 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#glm-52) GLM-5.2 的游戏看起来有点粗糙。从试玩来看： - 整体视觉效果不佳。 - 角色缺少部分材质。 - 尖刺陷阱无法杀死角色。 - 到达旗帜处没有任何反应。没有胜利条件。 所以它并不怎么样。不过，它确实做好了一件事：弹簧。 *GLM-5.2 弹簧发射机制。* 你可以跳到弹簧上，然后弹射到下一个平台。 #### Opus (https://techstackups.com/comparisons/glm-5.2-vs-opus/#opus) Opus 的游戏更干净，玩起来也不错。从试玩来看： - 摄像机和控制器工作正常。 - 尖刺陷阱可以杀死玩家，逻辑正确。但它位于关卡的侧边而非路径上，所以你需要故意撞上去才会触发。 - 整体看起来很好，你可以到达旗帜并获胜。存在真实的胜利条件。 动画看起来不错，运行流畅，纹理应用得当。 *Opus：动画、纹理、控制器正常工作。* ### 每个模型如何检查自己的工作 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#how-each-model-checked-its-own-work) 两个模型都被要求在停止前验证自己的工作。代理常用的一种方法是截取最终产品的截图并查看，以检查是否有任何破损或缺失。这正是 Opus 在其会话中所做的。 GLM-5.2 在这里遇到了问题，因为它无法读取图像。它不支持多模态。因此，它没有查看截图，而是采用了一种取巧的变通方法：编写脚本来读取原始像素数据，并检查颜色是否大致符合预期。 #### 为什么 GLM-5.2 的自我检查未能发现错误 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#why-glm-52s-self-check-missed-the-bugs) 由于无法看到保存的截图，GLM-5.2 尝试通过读取像素来验证画面。以下摘自其最终报告，其中“分析”了保存的图像： > `final\_start/overview/flag\.png`经过分析，颜色包含：草绿、泥土棕、金币金、旗帜红、角色偏蓝、半兰伯特照明，没有黑色 它预期的颜色都在，因此它确认游戏已完成并停止了。但是，正如你在下面它自己的最终截图中看到的，角色是平坦的灰色，缺少纹理，调试覆盖层仍然显示在场景上。一个能够实际查看截图的代理很可能会发现这两个问题，并回去修复它们。 *GLM-5.2 的最终截图：角色纹理缺失，调试覆盖层仍在。它从未看到过这个画面。* 在一个具有视觉结果的任务中，能够理解图像为模型提供了比不能理解图像的模型更强的优势。 #### Opus 如何检查自己的工作 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#how-opus-checked-its-work) Opus 支持多模态，因此可以直接读取截图。它的工具（harness）渲染了游戏并捕获了一帧，Opus 作为验证的一部分检查了该图像。以下摘自[它的会话](https://gisthost.github.io/?6ae707dea3854638bbd1e9dde19fa4a7/page-001.html#msg-0409)，描述了它所看到的： > 最终场景渲染正确：顶部有草的方块、棕色泥土的侧面、向上的楼梯、金色/银色硬币和宝石、右侧岛屿上的蓝色尖刺方块障碍、顶部目标处的红色旗帜、角色站在起点广场以及分数 HUD。光照和阴影正确，几何体干净。 *Opus 的自我检查截图：干净的 HUD。* 因为它可以看到画面，Opus 注意到了它留在屏幕上的调试读数，并在完成前将其清除。 ### 错误 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#the-bugs) 两款游戏都有错误。以下是各自存在的问题。 #### GLM-5.2 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#glm-52-1) GLM-5.2 的错误频繁且明显，其中几个是基础性问题。 **角色朝向错误。** 它朝着正确的方向移动，但模型却一直背对着移动方向。 *GLM-5.2 角色行走及朝向错误* **纹理丢失和头部消失。** 角色渲染为平坦的灰色而非有纹理，并且每当摄像机移动时头部就会消失。Kenney 的模型指向一个单独的共享调色板文件，而非内嵌颜色，而 GLM-5.2 的渲染器从未加载该文件，因此退化为纯色。Opus 加载了调色板，因此它的角色是有纹理的。 *GLM-5.2 动画控制器错误* **致命尖刺不致命。** 角色直接落在尖刺陷阱上却毫无反应。没有死亡，没有重置。 *GLM-5.2 尖刺碰撞错误* #### Opus (https://techstackups.com/comparisons/glm-5.2-vs-opus/#opus-1) Opus 的错误更少且更微妙，是边界情况而非基础功能问题。 **站在半空中。** 角色可以在平台旁边半空中停留而不掉落。这是其“空中悬停”（coyote-time）的宽限期，即离开边缘后仍可短暂跳跃的时间窗口，但调校得有点过于慷慨。是过度调优的打磨功能，而非基础功能损坏。 *Opus 空中悬停错误：角色站在平台旁边不坠落* **在距离旗帜太远处获胜。** 角色距离旗帜还很远时就触发了胜利。 *Opus 过早完成错误：距离旗帜太远时触发胜利* ### 测试结果 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#what-the-test-showed) 两个模型都构建了一个完整、可运行的 3D 平台游戏，从头开始，没有使用引擎和 3D 库，且仅一次尝试。这是一个很高的门槛，不久之前两者都还无法达到。以下是它们的分化情况。 #### GLM-5.2：更慢、更粗糙、更便宜 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#glm-52-slower-rougher-cheaper) GLM-5.2 耗时超过两倍，交付了一款粗糙的游戏：灰色的无纹理角色、不致命的尖刺、不工作的胜利条件，以及结束时仍在屏幕上的调试覆盖层。大多数错误是基础性问题。成本是 Opus 的五分之一。 #### Opus：更快、更干净、更昂贵 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#opus-faster-cleaner-pricier) Opus 只用了一半的时间完成，并交付了更干净、更正确的游戏。它的错误是边界情况，而非基础功能问题。成本大约是 GLM-5.2 的四倍。 #### 多模态优势 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#the-multimodal-advantage) Opus 可以读取图像，因此它的自我检查查看了渲染后的游戏并发现了视觉问题。GLM-5.2 是纯文本模型：它通过数字验证，从未发现它的角色是灰色的，或者调试覆盖层还开着。在一个视觉任务上，这就是能否抓住粗糙边缘并修复的区别。 一个游戏只是一个数据点。下面的基准测试在大规模上测试了同类能力。 ## 基准测试 (https://techstackups.com/comparisons/glm-5.2-vs-opus/#the-benchmarks) Z.ai 在发布时随[模型卡](https://huggingface.co/zai-org/GLM-5.2)一同发布了这些基准测试数字。每一行的最佳结果以**粗体**显示。 `\*` = Anthropic 自行报告 (https://www.anthropic.com/news/claude-opus-4-8) | 基准测试 | GLM-5.2 | Opus 4.8 | GPT-5.5 | Gemini 3.1 Pro | | :--- | :--- | :--- | :--- | :--- | | **推理** | | | | | | HLE | 40.5 | **49.8**\* | 41.4\* | 45 | | HLE (使用工具) | 54.7 | **57.9**\* | 52.2\* | 51.4\* | | AIME 2026 | **99.2** | 95.7 | 98.3 | 98.2 | | GPQA-Diamond | 91.2 | 93.6 | 93.6 | **94.3** | | IMO AnswerBench | **91.0** | 83.5 | – | 81 | | **编码** | | | | | | SWE-bench Pro | 62.1 | **69.2** | 58.6 | 54.2 | | NL2Repo | 48.9 | **69.7** | 50.7 | 33.4 | | DeepSWE | 46.2 | 58 | **70** | 10 | | ProgramBench | 63.7 | **71.9** | 70.8 | 39.5 | | Terminal Bench 2.1 (Terminus-2) | 81.0 | **85** | 84 | 74 | | Terminal Bench 2.1 (最佳工具) | 82.7 | 78.9 | **83.4** | 70.7 | | SWE-Marathon | 13.0 | **26.0** | 12.0 | 4.0 | | **智能体** | | | | | | MCP-Atlas (公开) | 76.8 | **77.8** | 75.3 | 69.2 | | Tool-Decathlon | 48.2 | **59.9** | 55.6 | 48.8 | 由 [ArtificialAna](https://x.com/ArtificialAna/status/2066957783631800432) 进行的独立运行