GLM 限流字段怎么读：并发、频次与提额路径

数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。

先说结论：智谱开放平台的速率限制，主口径是「并发请求数」，也就是同一时刻正在处理中的请求数量，而不是很多人下意识以为的每分钟请求数。 并发上限按「模型 × 账户」两个维度分别计算，不同类别的模型（通用模型、图像视频生成模型、向量模型、实时音视频模型等）各有各的并发上限；量级则由你的用户权益等级决定。如果你用的是 GLM Coding Plan 套餐，那是完全另一套口径——并发跟套餐等级绑定，平台会动态调整，而且官方明确写了套餐用户不支持申请调整并发。真正会让你踩坑的是：撞限流时返回的 HTTP 状态码是 429，但 429 底下藏着十几个含义完全不同的业务错误码，有的是并发满了，有的其实是欠费，有的是 Key 类型用错了。不分清楚，重试策略写得再漂亮也没用。

限的是并发，不是频次，这个先掰正

官方《速率限制》文档里有一句被加粗的注释：并发数指的是同一时刻正在处理中的请求数量。这一句决定了你的排查方向。

如果限的是频次，那么减小请求间隔、加个令牌桶就能解决；但限的是并发，意味着单个请求处理得越慢，你占用的并发槽位就越久。同样是每秒发十个请求，输出短的任务可能一直不触发限流，而输出很长的流式任务就会把并发槽位持续占满。这也是为什么很多人会觉得「我明明没提速，怎么突然开始报限流了」——不是发得快了，是任务变重了。

文档把速率限制的表现拆成四类：并发请求数限制、不同模型独立的并发限制、不同用户权益等级和套餐对应的不同并发限制，以及高峰期的动态限流与平台级保护策略。前三条是你能预估的，最后一条不是——它属于平台侧的动态调整，你只能在客户端准备好退避重试。想先建立通用认知的，可以先看站内那篇讲跨厂商口径的限流机制：RPM 与 TPM 到底怎么算，再回来对照 GLM 的具体形态。

你的限额到底在哪儿看

官方文档给的入口不是一个，而是三个，分别对应三种身份，别看错页面：

• 通用 API 用户：控制台的「速率限制」页，能查到当前账户各模型可调用的速率。
• 看等级和积分：控制台的「用户权益」页，显示你的积分与用户权益等级。
• GLM Coding Plan 用户：套餐概览页，看的是套餐等级，不是并发数值。

这里有个反直觉的地方：Coding Plan 那一侧，官方压根没给你一个「并发数是多少」的数字，给的是使用建议——Lite 建议同时进行单个项目的开发，Pro 建议同时进行一到两个项目，Max 建议两个以上项目。并且文档明确说明，套餐用户在低峰期会享有更高的并发权益，属于动态提升。所以你在高峰期测出来的可用并发，和低峰期不是一回事，拿它当容量规划的依据会翻车。

权益等级怎么涨，以及为什么你充了值等级没动

通用 API 这一侧，并发量级挂在用户权益等级上，等级由积分决定，官方划了 V0、V1、V2、V3 四档，主要权益分别是基础服务、并发权益、更高并发、最高并发。数值区间以官方用户权益页为准，这里只讲会让你白忙一场的几条规则：

• 积分来自现金余额消耗和购买资源包，按花费金额一比一兑换。
• 赠金账户的余额消耗不换算积分。这一条最坑——用平台送的额度把项目跑通了，积分是零，等级不会动，并发自然也不会涨。
• 消耗资源包里的 tokens 不增加积分，只有消耗现金余额、或三方支付购买产品时才产生积分。
• Batch 推理按实际扣费金额计算积分。
• 退款会让积分对应减少，退款当月的积分要扣掉退款金额。

等级更新是延后的：平台在次日更新积分，并按官方口径取最近一段时间内的最高积分来确定当月等级（具体窗口以官方用户权益页为准）。也就是说，今天大额充值并投入使用，指望明天早上并发就翻上去，节奏对不上。要靠提等级来扛业务高峰，得提前规划。

撞上限流，先读业务码不要只看 429

这是本篇最值钱的部分。官方错误码表里，HTTP 状态码同为 429 的业务码有一长串，含义完全不同：

• 1302 触发用户速率限制：文案是账户已达到速率限制、请控制请求频率。典型原因是当前模型的并发请求数达到账户上限，或短时间内请求过密。这是真正意义上的「你自己发多了」。
• 1305 平台服务过载：文案是该模型当前访问量过大、请稍后再试。官方明确说明这类情况属于平台服务过载，与单一账户的调用行为无直接关系——触发场景包括某模型整体访问量激增、底层算力高负载、平台维护扩容或异常恢复。降低自己的并发解决不了它。
• 1113 账户已欠费：注意，欠费返回的也是 429。如果你的重试逻辑是「见到 429 就退避重试」，欠费时会变成无意义的空转。
• 1308 / 1310 使用上限：这两条虽然都是「用量撞顶」，但文案模板不是同一个，解析的时候要分开写。1308 的文案是「已达到 ${number} ${unit} 的使用上限。您的限额将在 ${next_flush_time} 重置」，带 number、unit、next_flush_time 三个占位字段，前两个给出上限的数值与单位，后一个是限额重置时间；1310 的文案是「您已达到每周/每月使用上限，您的限额将在 ${next_flush_time} 重置」，周期是直接写在文案里的，占位字段只有 next_flush_time 一个。拿 1308 的模板去解 1310，number 和 unit 会取不到值。两条共有的是 next_flush_time，真正该做的是把它解析出来，等到那个时间点再发，而不是固定间隔硬撞。
• 1311 套餐未开放某模型权限：文案里带 model_name 占位字段。这其实是权限问题，不是限流。
• 1315 Key 类型不匹配：该 API Key 仅限企业编程套餐场景使用，需要到官网换成对应产品类型的 Key。同样穿着 429 的外衣。
• 1313 公平使用策略：账户当前使用模式不符合公平使用策略，请求频率被限制，官方给的恢复路径是到个人中心的编程套餐总览页面顶部申请解除限制。
• 1309 / 1314 套餐到期或企业套餐失效，以及一组带「主账号余额不足，无法使用超额按量付费」「已达子账号月消费上限」「已达企业级月消费上限」的错误码——它们说明的是费用侧的闸门，而不是算力侧的拥堵。

所以一个能用的处理规则是：把 429 当成一个信封，拆开看里面的业务码再决定动作。 1305 退避重试，1302 降并发，1113 去充值，1308/1310 按 next_flush_time 排期，1311/1315 改配置。站内那篇429 的通用处理套路讲的是骨架，GLM 这份码表就是它的具体填充；另外还有一篇专门写 GLM 429 限流现场处理，可以对照着看。

不提额，也有三条路能扛住

官方在「如何合理应对速率限制」这一节给的建议，按可操作性排一下：

第一是控制并发与请求频率。 文档写得很直白：使用请求队列或并发池，避免瞬时洪峰式请求，避免固定间隔的高频重试。最后一条容易被忽略——固定间隔重试在限流场景下会形成同步的脉冲，一群请求同时醒来同时撞墙。

第二是走异步请求。 对话补全有异步版本，提交走 /paas/v4/async/chat/completions，结果通过 /paas/v4/async-result/{id} 查询。请求不再挂着等生成完成，占用实时并发槽位的时间就短了。

第三是走 Batch 批量处理。 官方批量处理文档写的是 Batch API 无并发限制；FAQ 里补充得更准确：Batch 的并发限制与现有的每模型并发限制是分开的，但它引入了另外两类限制——单个 Batch 文件的请求条数与文件大小上限，以及每个模型的 Batch 最大排队限制，达到队列上限时要等当前任务完成再提交新任务；向量模型的 Batch 文件请求数量另有单独上限。具体数值见官方文档。另外两条别忘：调用 Batch API 必须先完成实名认证；Batch 未能及时完成会被标记为过期，未完成的请求会被取消，但已完成的那部分仍然要付费。

顺带一个容易被漏掉的场景：实时音视频模型这条线，官方文档对音频发送速率另有上限说明，超过后会被限流丢弃，并建议把实时音频流按固定帧长切分、匀速发送——具体速率与帧长以官方文档为准。它和文本接口的并发限制不是同一套机制。

提额路径：能申请的和不能申请的

通用 API 用户，如果业务确实需要更高并发，可以在控制台提交速率限制调整申请，表单要填三样：需要调整的模型、期望增加的并发数量、实际使用场景与业务说明。平台审核完成后，结果会通过注册手机号或站内通知告知（审核时长以官方页面为准）。官方文档里没有说明这三项各自的权重、也没有给出审核标准，所以第三项「实际使用场景与业务说明」写细一点总没坏处：把业务形态、请求会集中在什么时段、当前撞的是哪个模型的并发交代清楚，比只写一句「不够用」更省事。

GLM Coding Plan 用户则是另一回事：官方在文档里用提示框单独写了一句，套餐用户按订阅套餐等级统一并发，暂不支持申请调整。想要更高并发只有升级套餐这一条路。另外套餐侧还有几条使用规范会直接触发限流：套餐仅限订阅人专享，禁止账号共享或多人共用；仅限在官方指定的工具与产品环境中使用，用于非支持工具会被限制权益；违反订阅协议可能触发风控，处置手段包括限流和冻结，多次违规可能封禁账号，命中风控后可在控制台套餐概览页查看提示并发起申诉。还有一条给用通用 Agent 工具的人：官方说明这类工具采用次级调度与尽力交付策略，Coding Agent 任务享有资源抢占优先权，高负载下通用 Agent 工具的任务会自动触发动态排队、限流等公平使用策略。套餐用量的完整规则可以看GLM Coding Plan 用量规则。

最后，最容易栽的一个坑

不是并发没算准，是把「限流」和「限额」当成了一件事。并发是同一时刻的槽位，撞了就退避，过几秒就能恢复；使用上限是一个时间窗内的总量，撞了就得等 next_flush_time 到点，退避多少次都没用。这两类在 GLM 这里都返回 429，只有业务码能区分。

所以真正该做的第一步很朴素：把错误响应里的业务码和错误文案原样记进日志，别只记 HTTP 状态码。等你手里有一周的码分布，是该降并发、该提等级、还是该把离线任务迁到 Batch，答案自己就浮出来了。