滚动用量窗口（Rolling Usage Window）是一种"永远只看最近一段时间"的额度计算方式：系统不会在某个整点把你的用量清零，而是把过去 X 小时（或 X 天）内发生的用量加总，再和上限比较；只有当旧记录滑出这个时间范围，额度才会一点一点恢复。
打个比方。想象一条匀速前进的传送带，上面放着你刚发出的每一次请求，每条都贴着时间戳，尽头是一个回收桶。任何时刻，数一数传送带上还剩多少条，就是"当前窗口用量"。没有人会在整点把传送带清空，只有最早的那几条自己走到尽头掉下去。所以，额度恢复的曲线是一条斜线，而不是台阶。
这能解释一个常见困惑：为什么"我明明停手了，额度还是没回来"。因为你的用量往往集中在一小段时间里发出，它们会扎堆到期；在到期之前，窗口里的加起来的总量没有变化。反过来，如果你一直匀速使用，看到的可用额度就相对平稳。过去一年里，几家头部对话产品都调整过自己的额度规则：有的把"每几小时重置一次"换成更长周期的额度，有的调整订阅档位的总量，有的取消了固定时点的赠送重置。名称各不相同，背后的计算方式基本就是滚动窗口。具体规则以各家官方页面为准。
它容易和两个相邻概念混淆：
- 固定窗口（Fixed Window）：按自然时段切分，比如"每小时"或"每天零点"，到点整批清零。好理解，但会诱导用户卡在窗口开头集中发出请求，形成一波高峰。
- TPM / RPM 限流（AI 词典：Token">Tokens Per Minute / Requests Per Minute）：这是速率限制，时间尺度在秒和分钟，目的是防止瞬时突发压垮服务；一旦触发，通常直接返回错误、让你稍后重试。它管"你这一秒有多猛"，滚动窗口管"你这一段总共能用多少"。
| 维度 | 滚动用量窗口 | 固定窗口 | TPM / RPM 限流 |
|---|---|---|---|
| 时间尺度 | 小时到天、周 | 自然时段（整点、每日） | 秒到分钟 |
| 解决的问题 | 一段时间内总量多少 | 同上，但按自然时段结算 | 瞬时并发与突发 |
| 额度恢复 | 旧记录逐条滑出，斜线恢复 | 到点整批清零，台阶式 | 持续补充 |
| 撞上之后 | 暂停或降级使用 | 等到下一个时段 | 单次请求被拒，重试即可 |
对普通职场人，实用结论有三条：一是别等整点，要看你最早那批请求是什么时候发出的；二是把批量生成、长文档处理这类用量大的任务拆开、错开；三是读产品公告时先抓两个参数：窗口多长、过期是逐条还是整批。
对做产品的人，配额设计基本就是拧四个旋钮：窗口长度、计量单位（按请求数还是按 token，不同模型是否加权）、账户维度（个人额度还是团队共享池）、超限反馈（报错、降级还是排队）。旋钮不同，用户体验差别很大，但底层都是同一条传送带。