GLM-5.1：专为长周期任务重构的旗舰大模型

GLM-5.1 是智普为 AI 智能体场景打造的新一代旗舰大语言模型。相比前代 GLM-5，它的代码生成能力有了质的提升：不仅拿下了 SWE-Bench Pro 榜单的当前 SOTA，在 NL2Repo 代码仓库级生成、Terminal-Bench 2.0 真实终端任务的评测中，性能也全面领先前代产品。

但 GLM-5.1 真正的突破，从来不是单次交互的输出质量。包括前代 GLM-5 在内的主流大模型，都有一个通病：长任务续航能力极差。它们往往能在任务初期快速给出可用的基础方案，之后便陷入长期的性能停滞，哪怕给再多的算力和运行时间，也很难再有实质性的优化。

GLM-5.1 则从底层架构上针对长周期任务做了重构。经测试发现，面对路径不明确、需求模糊的复杂工程问题时，它能保持稳定的判断能力和持续的优化动力。

它可以独立完成复杂系统的拆解、验证实验的运行、日志反馈的解读，快速定位代码中的卡点问题。通过不断迭代、自查逻辑、调整优化策略，GLM-5.1 能在上千轮交互和工具调用中，始终保持高效的优化节奏——简单来说，就是运行周期越长，最终交付的成果质量越高。

为了验证这项能力，模型团队在三类不同反馈机制的场景中做了专项测试，覆盖了从有明确量化指标的结构化任务，到完全开放式的探索型任务。

场景一：历经 600 轮迭代的向量数据库优化

VectorDBBench 是一个开源的编码评测项目，核心是评估大模型从零构建高性能 ANN（近似最近邻）向量数据库的工程能力。

标准测试流程中，模型会拿到一套带 HTTP API 端点和空实现逻辑的 Rust 项目骨架，需要通过调用系统工具完成文件读写、编译、测试和性能分析，且工具调用次数被限制在 50 轮以内。最终成品会在 SIFT-1M 标准数据集上跑分，核心指标是 QPS（每秒查询率），同时要求召回率 Recall ≥ 95%。在执行测试前，该约束下的最高纪录是 Claude Opus 4.6 跑出的 3547 QPS。

模型团队也在思考：50 轮的调用限制，会不会掩盖了模型的真实优化潜力？于是基于 Claude Code 框架重构了评测流程，给模型增加了外部优化循环。在新的测试沙盒里，模型可以无限制调用工具修改代码、重新编译和做深度性能分析，自主决定何时提交新版本、选择哪个方向做优化。

实测数据令人震撼：GLM-5.1 在超过 50 轮、100 轮迭代后，不仅没有出现性能停滞，反而在 600 多轮迭代、累计超 6000 次工具调用的过程中，持续找到有效的优化方案。最终它跑出了 21.5k QPS 的成绩，是 50 轮限制下历史最好成绩的近 6 倍。

复盘它的优化轨迹，发现了非常清晰的「阶梯式」爬升规律：模型会先在当前技术路线下做精细化的渐进式微调，再通过底层代码的重构，突破当前的性能上限。其中有两次关键的架构调整，直接带来了性能的大幅跃升：

整个测试周期里，模型完成了六次同等级别的架构重构。每一次性能跃升，都来自它对 benchmark 报错日志的分析和对 IO 瓶颈的精准定位。测试图表里的红叉，是召回率跌破 95% 的失败尝试，这些失误大多集中在架构重构的阶段——这也说明，模型在探索新方案时，会战略性地暂时放宽短期的精度约束，等新架构跑通后，再回调参数满足召回率要求，重新实现性能和精度的平衡。

场景二：突破 1000 轮交互的机器学习负载优化

KernelBench 是一个面向 GPU 算子生成的硬核评测基准，核心考察大模型能否在保证输出张量完全一致的前提下，把原生 PyTorch 参考代码优化为高效的 GPU 底层算子。

这个基准按照优化深度和系统复杂度分为三个等级，难度最高的 Level 3 覆盖了端到端全模型架构的优化，包含 MobileNet、VGG、MiniGPT 和 Mamba 在内的 50 个高难度测试用例。

先给出原生编译工具的加速效果作为参考基准：

• 默认配置的torch.compile，提速比为 1.15×
• 开启max-autotune参数后，提速比提升至 1.49×

智普选了四款主流旗舰大模型，在 Level 3 级别做了对比测试，统计了 50 个测试用例的几何平均提速比随工具调用轮次的变化情况。

这次测试清晰地展现了不同模型在长周期优化上的能力差异：

• GLM-5：初期优化速度很快，但很快就进入性能停滞期，后续几乎没有提升；
• Claude Opus 4.5：优化的持续时间比 GLM-5 更长，但到测试中后期也基本停止了性能增长；
• GLM-5.1：突破了前代的性能上限，最终平均提速比达到 3.6×，并且在千轮迭代的整个测试周期里，都保持着稳定的优化效率；
• Claude Opus 4.6：依然是这个赛道的标杆，最终以 4.2× 的平均提速比收尾，哪怕到测试末期，依然有性能提升的空间。

场景三：耗时 8 小时从零构建 Linux 桌面环境

前两个测试场景都有明确的量化指标，模型可以通过跑分结果直接调整优化方向。但前端 Web 应用生成是一个强主观的场景，没有绝对的对错标准。交付质量的高低，取决于功能完整度、UI/UX 设计的完成度和交互细节的打磨程度。

测试团队给了模型一个完全开放式的任务：从零把一个标准的 Linux 桌面系统重构成 Web 应用。整个过程中，不提供任何初始骨架代码、设计稿，也不做任何人工干预。

在常规的单次交互模式下，包括早期 GLM 系列在内的绝大多数模型，都只会输出一个非常简陋的半成品：通常只有静态任务栏和一两个占位窗口，就宣布任务完成。核心问题是，这类模型没有完善的自我审查机制，无法从全局视角判断任务的完成度。

针对这个问题，测试团队给 GLM-5.1 加了一套简单的自循环驱动逻辑：每完成一轮代码编写，模型必须先做自我审查，找出缺失的功能、不完善的 CSS 样式和有问题的 DOM 交互逻辑，再继续迭代优化。整个自循环迭代过程持续了 8 小时，最终的成品效果远超预期。

项目初期，GLM-5.1 输出的还是带任务栏和基础窗口的粗糙布局，和短会话模式下的半成品没什么区别。但随着迭代的持续推进，它逐步完成了大量功能的开发：文件资源管理器、终端模拟器、代码编辑器、系统资源监视器、计算器，甚至还有内置的小游戏。更重要的是，这些功能不是简单的堆砌，而是遵循了统一的 UI 设计规范，交互逻辑也完全打通。

迭代过程中，它不断优化系统面板的样式、窗口拖拽的动效，也修复了大量极端场景下的边界问题。8 小时迭代结束后，最终得到了一个功能完整、设计风格统一的浏览器端虚拟桌面。这也说明，只要给大模型足够的运行时间和完善的自审查机制，它能完成的开发任务，远比我们之前预想的要复杂得多。

从这三个测试场景就能看出，决定模型长周期任务能力的，从来不是单纯的运行时间堆砌，而是它能不能把额外的算力和时间，转化为实实在在的优化成果。在这一点上，GLM-5.1 相比前代 GLM-5，有了跨越式的提升。

当然，从 KernelBench 的测试结果也能看到，长周期优化依然是一个充满挑战的前沿领域，智普还有很多问题需要解决：

1. 当渐进式微调无法带来性能提升时，如何让模型更敏锐地跳出当前的局部最优解？
2. 如何在数千次的工具调用过程中，保证模型全局执行逻辑的连贯性？
3. 在没有明确量化指标的开放式任务中，如何让模型建立更精准的自我评估标准？

GLM-5.1 是智普在长周期大模型这个方向上迈出的关键一步，后续也会在这个领域持续深耕。