GLM-5.1-HighSpeed实测：400 token/s，速度与智商兼得，国产大模型首次突破

GLM-5.1-HighSpeed 正式登场，输出速度达到每秒 400 token。不仅快，而且性能强悍，表现令人惊叹。我第一时间进行了实测，下面直接展示效果。

我在 Claude Code 中分别配置了 GLM-5.1 和 GLM-5.1-HighSpeed，先直观感受一下两者的速度差异。

GLM-5.1：发送两个指令后，从发出到收到回复大约需要 31 秒。

GLM-5.1-HighSpeed：同样的两个指令，发出后仅需 11 秒。

Claude Opus 4.7：可能受网络因素影响，Opus 4.7 耗时约 47 秒。

接下来验证 GLM-5.1-HighSpeed 的实际效果，视频均为正常速度，未做加速处理。让 GLM-5.1-HighSpeed 生成一个网页，40 秒即可完成：

再测试生成 Word 文件，20 秒搞定：

GLM-5.1 高速版打破了行业常规认知。此前业界普遍认为只有小尺寸模型才能实现高速推理，但小模型往往伴随着智商下降的问题。

然而，GLM-5.1 高速版基于智谱旗舰模型 GLM-5.1，这是国产大模型首次同时实现顶级智能与极致速度。

美中不足的是，GLM-5.1-HighSpeed 的上下文窗口仍为 200K。期待未来推出 1M 版本。

01 效果如何？

在模型智能方面，GLM-5.1 高速版完整保留了 GLM-5.1 的能力。

我测试了几个案例，看看 GLM-5.1 高速版的实际表现。首先生成一个类似《我的世界》的 3D 游戏提示词：“帮我生成一个3d的游戏，类似我的世界。 我能直接在网页中玩”。

代码生成后直接运行，没有任何报错。输入上述提示词后，系统先利用 superpowers 的 brainstorming 功能进行头脑风暴，与 AI 多轮对话以收敛需求，随后编写 Spec 文档和计划文档。最后拆解为 10 个子任务，由 SubAgent 逐一实现，最终完成整个 MVP 版本。

如果使用之前的 GLM-5.1 或 Opus 4.7，这一流程至少需要 1 到 2 个小时，而现在仅需 11 分钟即可完成。而且交付质量也有保障。

前置的头脑风暴追问与澄清一个接一个，速度快到让我完全跟不上反应。

对于我这种深度依赖 Claude Code 的用户，这种体验和感受极具冲击力。此外，我还自测了几个简单案例，供大家参考。主要对比 GLM-5.1，看速度提升后模型能力是否下降。

网站生成： 与 GLM 5.1 对比，使用相同提示词和相同环境，仅模型不同。提示词：“基于桌面上的个人介绍文件, 生成一个个人介绍的网站, 风格使用 Awesome Design 里面的 Claude 的风格, 不需要头脑风暴,直接来吧。”

GLM-5.1：

GLM-5.1-HighSpeed：

直观感受上，GLM-5.1-HighSpeed 的效果确实稍好一些，而且比 GLM-5.1 快了 5 到 6 倍。我将两者生成的内容交给 Claude Opus 4.7 进行评分，最终结论是 GLM-5.1-HighSpeed 的交付结果更优。

办公场景： 提示词：“读取桌面上的测试文件中的两个文件,一个是月报 word 模板,一个是近期用户投诉梳理表格. 请你从投诉数据中找出重复投诉,分析一下相关问题,基于 word 模板写一个月报总结。”

同样将交付结果交由 Claude Opus 4.7 评判。

02 为什么这么快？

GLM-5.1 高速版由智谱 GLM 团队与 TileRT 团队联合打造，在三个层面进行了同步优化：

• 推理引擎层： 针对 GLM-5.1 的架构特点，重写了核心推理路径，提升了单卡吞吐能力。
• 调度系统层： 优化了动态批处理、请求合并和 KV 缓存调度，在高并发场景下显著降低了尾延迟。
• 基础设施层： 对推理集群部署、网络链路和负载均衡进行了协同优化，确保 400 TPS 并非峰值数字，而是稳定的生产可用水平。

但最核心的创新在于 TileRT 推理引擎本身。

模型推理速度的上限由硬件决定，但实际系统往往远未达到这个上限。以 8 卡 H200 服务器为例，聚合内存带宽约为 38TB/s，理论上 decode 速度上限接近 1000 token/s，但实际推理服务通常只能跑出几十 token/s。

问题出在推理框架的调度方式上。主流框架以 operator/kernel 为基本调度单元，每个算子都要经历完整的启动、读取权重、计算、写回、同步流程。当推理进入单 token、小 batch、多卡场景时，算子被切分到微秒级，原本可忽略的调度、访存与同步开销被急剧放大。GPU 并不缺乏算力，而是算力被限制在了 kernel 边界之间。operator/kernel 这一执行抽象本身，已成为阻碍推理逼近硬件上限的结构性瓶颈。

TileRT 的做法是彻底抛弃 Runtime 层的动态调度，在编译期将整个计算图静态编排为一个常驻 GPU 的 persistent Engine Kernel。

单卡内部，计算、异步 IO 与通信被拆解为 Tile 级微任务。整个推理过程只启动一次，算子间的中间结果不再写回 Global Memory，而是通过 Register、Shared Memory 与 L2 Cache 直接传输。

在多卡场景下，不同 GPU 不再执行同构逻辑，而是根据计算密度与数据依赖被特化为不同的 worker。以 GLM-5.1 为例，GPU 0 专职 Sparse Indexer，GPU 1 到 7 承担 MLA 注意力主干，跨卡的广播、归约与残差加被压缩进同一个通信原语。

最终，推理的调度单元从 operator/kernel 降维到了 tile。

03 利好响应速度要求高的 AI 产品

如果模型的智能不衰减，而响应速度大幅提升，许多产品的用户体验将提升一个量级。例如，我最近开源了一个语音优先的 Agent：Lumi。它可以通过唤醒词激活，常驻在电脑中，用户直接语音告知任务，完成后也会语音回复。

• 开源地址：https://github.com/Wechat-ggGitHub/Lumi

比如我说：“钱多多，请你帮我把桌面上的文件整理一下。” 这个任务实际需要五六分钟才能完成。下面的视频做了倍速处理。

你看，等任务完成后，语音播报反馈给用户：“主人，我帮你整理好了。” 但如果 5 分钟后用户早已忘记这回事，这句任务完成的语音回复带来的就不是惊喜，而是惊吓了——突然冷不丁冒出一句话，体验很不友好。

但如果模型推理速度极快，Agent 调用链路足够高效，再配合一些产品细节打磨，这种场景的用户体验就会大幅提升。至少从我最近 Vibe Coding 开发 Lumi 的切身感受来看，速度是影响用户体验非常关键的一环。相信后续许多对时延要求很高的 AI 产品，都会选择 GLM-5.1-HighSpeed 作为底模。

04 点击下方卡片，关注逛逛 GitHub

这个公众号历史发布过很多有趣的开源项目。如果你懒得翻文章一个个找，直接关注微信公众号：逛逛 GitHub，后台对话聊天即可：