请求的限流计数是怎么清零的？每一步都讲透

用任何 AI 平台时都见过「今日额度已用完」的提示，这背后是限流计数在工作，而计数是怎么清零的，直接决定你什么时候能恢复调用。

可以把它想成健身房的次卡：按次划，月底重置。这个类比的失效之处在于，次卡按时间一刀切，限流计数可能是固定窗口，也可能是滚动窗口，两种清零方式的体感完全不同。带走一个判断：额度什么时候回来，不取决于你等多久，而取决于窗口怎么设计。

计数的三个维度和清零时机

常见的计数维度有三个：请求数、token 消耗量和并发数，三者通常同时设上限。

清零时机由维度决定：请求数和 token 多按时间窗口清零，并发数不累计、随连接释放即时回落。理解自己撞的是哪个维度的上限，才能对症处理——是等清零，还是减少并发，还是压缩请求体量。并发数最容易被误解：它属于瞬时值而非累计值，连接一断就回落，所以看到「并发超限」不必等清零，把同时发起的请求数降下来立刻就能恢复，完全不用干等。

清零是定时还是滚动：两种窗口

固定窗口像整点发车：每天零点或每小时整点统一清零，简单可预期，但边界处可能被集中抢注。滚动窗口像全年无休的便利店：以你最近一次请求为起点往前看一个窗口，逐笔滑出计数，更平滑却不好预估。通义千问、智谱清言等平台的文档会写明自己的窗口类型，调用前查一眼能省不少猜测，也能帮你预判额度何时回来。

窗口之外还有一个常被忽略的细节：计数按「受理」还是按「成功」算。多数平台按受理算，请求一进门就计数，哪怕后面被拦、超时或返回错误。这意味着每次失败重试都在真实消耗额度，重试策略里必须有间隔和上限。部分企业版提供按成功计数的选项，失败不扣量，但会搭配更严格的单请求校验。接入前把窗口类型和计数口径这两件事问清楚，能用掉后面一多半的排障时间，比盲目重试划算得多。

为什么有时计数看起来没清零

三个常见原因：一是看错了窗口类型，以为是定时清零，实际是滚动窗口；二是多应用共享配额，另一个应用把额度用掉了；三是被拦截的请求也计入了口径，反复重试反而把计数推得更高，被拦请求的处置见敏感词拦截在哪个环节？从原理到落地。逐一核对这三点，大多数「没清零」的疑惑都能解开。

什么时候该怀疑计数出了问题

明明没发几个请求却提示超额，或清零时间过了额度仍未恢复，可以先查用量明细对账，明细与账目的关系见服务端怎么记录 token 用量？账单的来源；对不上再通过反馈渠道找平台核实。服务整体异常时的额度表现也可能失真，可用性判断见推理服务的健康检查是怎么做的？。重试密集时每次都要重新走一遍预填充，计数涨得更快，两阶段的分工见预填充和解码差在哪？两阶段的分工。

限流计数速查表：

• 撞请求数上限：等窗口清零或申请提额
• 撞 token 上限：压缩提示词、缩短输出
• 撞并发上限：降低同时发起的请求数

先分清撞的是哪条线，再决定怎么办。

关于限流计数，问得最多的三个

• 清零时间可以自定义吗？：多数平台固定为零点或整点，企业版可申请自定义窗口。
• 失败的请求算次数吗？：通常算，只要服务端受理过就会计数，所以盲目重试很耗额度。
• 不同模型共用一个额度池吗？：看平台策略，有的分池有的共池，文档里会写明。

把清零规则摸清楚，额度就不是玄学，而是可以精打细算的账。