# GLM 5.2 上手 24 小时：能力到位了，服务还没到

> **[Peri Code](https://github.com/konghayao/peri)** — 用 Rust 写的开源 Coding Agent，兼容 Claude Code 生态。<https://github.com/KonghaYao/peri>

GLM 5.2 上线当天，我们用已有的 Max Coding Plan 高强度跑了一整天——多文件架构重构、56 参函数参数对象化、SQLite 读写路径强类型改造，代码生成和跨文件修复一路顺手。第二天再打开，全是 429 限流（API 请求频率超过服务器限制时的拒绝响应）。模型本身的能力和它背后的服务稳定性，不在同一个量级。

## 第一天：跨 crate 一致性修复没有掉链子

首日我们用 GLM 5.2 处理了几个典型的高负载工程任务。多文件跨 crate 重构中，模型需要同时理解多个模块的接口约定和调用关系——GLM 5.2 在一致性修复上没出过张冠李戴的错误，改 A 文件不会破坏 B 文件的类型约束。两次 Full Compact（上下文压缩后重建对话摘要）和四次工具调用穿插的 ReAct 循环（模型每步工具调用后都要再请求一次模型）全程流畅，没有中断、没有重试。

首日跑完，团队的一致判断是：这个模型在工程任务上的理解深度和跨文件一致性，比此前用过的一圈替代方案都高出一截。Max 配额的 5 小时重置周期还有余量，体验上没有任何瓶颈。

## 第二天：付费也买不到稳定服务

第二天打开终端，429 开始密集出现。上午 9 点起，团队群聊从「GLM 5.2 在跨文件修复上确实稳」「输出质量比上一代有明显提升」切换成了清一色的限流截图——每隔几十秒就有人贴一张返回。偶尔有一两个请求通过，群里跟中奖一样。

429 发生在网关层。请求还没到计费那一步就被拦下来，个人配额还剩多少变得无关紧要。Max 付费顶配的用户也不能幸免——限流不区分付费等级，所有人一起排队。

这里有一个需要说清楚的边界：我们不知道服务器端的具体容量，也不确定是所有用户都在排队还是我们恰好撞上了某个片区的限流窗口。智谱没有发布服务状态公告，也没有公开容量数据。能确认的只有两点：模型能力在第一天得到了验证；第二天我们为这个能力付了费，却用不上。

## 模型能力和服务可用性之间的落差

GLM 5.2 这次经历最值得记录的地方，不是限流本身——新模型上线初期遇到容量压力并不罕见——而是**能力到位了，服务还没到**这个状态。

传统 SaaS 的叙事通常是：产品好用 → 用户增长 → 扩容跟上 → 服务稳定。但在国产大模型这边，我们看到的顺序是：模型能力先突破（GLM 5.2 在工程任务上确实能打），但配套的服务容量、网关策略、付费体验没有同步跟上。付费用户掏了钱，得到的是一个能力很强的模型和一个暂时用不了的服务——这两个东西被绑在同一条 API 上，你只能同时接收它们。

模型评测已经是一个拥挤的赛道了——LMSYS（大模型竞技场）、HumanEval（代码生成评测）、SWE-bench（软件工程任务评测），每个榜单都在比分数。但这些榜单测的是静态能力，不测你付费之后能不能稳定调用。GLM 5.2 用自己的 429 给国产模型行业提了一个问题：**模型做出来了，服务什么时候能跟上。**

项目地址：[github.com/konghayao/peri](https://github.com/konghayao/peri)
