API Rate Limiting 与 Token Bucket 滥用防护

可视化演示

滥用风险与目标

水库管理员最怕的不是正常用水，而是有人开着水泵连夜抽水。对大模型 API 来说，恶意脚本、被攻破的账号、批量爬虫就是那台“水泵”——它们不关心下游还有没有水，只想趁管理员不注意把水库抽干。这就是接口被滥用的真实写照。

接口滥用的形态主要有三种：脚本高频轮询套取模型回复、多账号共享接口批量抓取数据、利用免费额度反复重试。传统 Web 服务被刷最多浪费一点带宽，但大模型 API 每次调用都在烧 GPU 和 token 费用，滥用直接转化为账单上的数字。

滥用的后果可以量化：单次请求平均消耗 token 成本乘以请求次数，就是一次攻击造成的经济损失。更糟的是，少数人的滥用会拖垮整座水库，让正常用户也拿不到水。因此限流的目标非常明确——保护后端资源、控制成本预算、保证租户间公平。

明白了“为什么要限流”，就像管理员终于看清了水泵的威胁。接下来要回答的问题是：用什么机制管住这些水泵？答案就是本文的主角——令牌桶。

---

令牌桶原理

假设水库管理员的规则很简单：上游小溪每秒注入 0.6 立方米水，水库最多存 10 立方米。任何人来取水，先看库里有没有水，有就取走 1 立方米，没有就请回。这就是令牌桶的全部直觉——令牌就是水，请求就是取水人。

把“水”翻译成工程技术语言，令牌桶是一个带容量的计数器：系统按固定速率 r 生成令牌放入桶中，桶满则新令牌丢弃；每个请求到来时必须消耗一个令牌才能通过，没有令牌就直接拒绝。桶的容量 C 决定了最多能“囤”多少令牌，也就是短期突发允许有多大。

这个机制的妙处在于“限均值、放突发”：从长期看，放行的平均速率约等于注入速率 r，水流不会超过小溪的补给能力；但从短期看，只要桶里有存货，一批请求可以同时冲进来，把积攒的令牌一口气花光。对 LLM API 来说，这正好匹配真实业务——平时请求平稳，促销、热点事件时允许短时并发峰值。

令牌桶用“水龙头 + 水桶”两个零件就实现了限均值、放突发，简单而优雅。但它是唯一的方案吗？当然不是，要理解它的优势，得先看看其他常见的水管工们是怎么干活的。

---

算法对比

水库管理员还有三种备选工具。第一种是“计数器法”：每分钟记一个数，超过阈值就拒绝，像在闸门上挂一块白板记人次；第二种是“滑动窗口”：把最近一分钟切成小格，滚动统计，比白板更平滑；第三种是“漏桶”：水进来先落进一个带小孔的漏斗，无论上游多猛，下游永远匀速滴水。

计数器法的缺点是临界突刺：假设阈值 60 次/分钟，攻击者可以在第 59 秒打 60 次、第 61 秒再打 60 次，两秒内打了 120 次，白板却只记了两次"60"。滑动窗口通过细分时间片解决这个漏洞，但实现更复杂。漏桶则走向另一个极端——它完全抹平突发，即使桶里积了水也必须是涓涓细流，对需要短时爆发的业务（比如批量推理任务）不够友好。

令牌桶和漏桶都是“桶”，但性格完全相反：漏桶是市政供水，恒压恒流；令牌桶是蓄水池，平时蓄水、关键时刻可以开闸放水。选型建议很简单——下游服务扛不住任何波动就选漏桶；业务有真实突发需求、又想约束长期均值，就选令牌桶；需要精细控制时间窗口边界的，可以在令牌桶之上叠加滑动窗口统计。

对比完四种算法，令牌桶在“简单、允许突发、均值可控”三个维度上取得了最佳平衡。但光会用还不够，参数怎么定才是真正的工程学问。

---

参数设计

水库管理员要回答两个核心问题：水库修多大？小溪注入多快？修大了，短期能扛住洪峰，但长期注水不足时反而给人“有大量可用水”的错觉；注快了，下游又可能承受不住。令牌桶的参数设计，就是在这两个问题之间找平衡。

第一个参数是桶容量 C：它决定了一次性允许的突发上限。一个估算思路是，统计业务最坏情况下的峰值并发请求数，再乘上一个容忍系数。比如线上观测到瞬时峰值是 20 个并发，C 可以设在 20~30。第二个参数是补充速率 r：它决定了长期平均吞吐，通常按“预计正常流量 × 安全余量”来定，比如正常均值 50 请求/秒，r 可以设在 60~70，留出 20% 余量。

两个参数配合后，可以计算一个关键指标——突发窗口，即桶从满到空能撑多久。它告诉我们：如果攻击者以远高于平均速率的流量冲击，系统能硬扛多长时间才触发拒绝。这个数字对容量规划和告警阈值设计非常重要。

参数设计本质上是“钱怎么分”：容量是备用金，速率是月薪，备用金越厚越能扛短期冲击，但长期消费水平最终还是由月薪决定。设计好参数后，还有一个问题：是所有人都共用一座水库，还是每人分一座？这就进入多维度限流的讨论。

---

多维度限流

一座水库如果只在大坝上装一个总水表，管理员根本分不清是哪家农田在偷水。聪明的做法是给每户装分水表：按用户限流、按 IP 限流、按模型限流，层层设卡。这样任何一方想搞事，只会在自己那一层被拦住，影响不到别人。

按用户限流是最基础的维度，用 API Key 或账号作为分桶键，防止单用户脚本循环调用；按 IP 限流针对的是分布式爬虫——单个用户可能换号绕过，但出口 IP 资源有限；按模型限流则是给不同的模型（比如最贵的 GPT-4 级别模型）单独设配额，保护稀缺 GPU 资源。

组合策略的核心规则是“短板效应”：最终放行判断取各维度限流结果的最小值。任何一条线先到顶，就按最紧的那条来拦。比如用户维度允许 100 请求/分钟，但该用户的出口 IP 只允许 30，那就按 30 执行。这种设计让攻击者除非同时突破所有维度，否则总会撞上某一道墙。

多维度限流像小区的三道门禁：单元门、小区门、地下车库门，各管一段。规则定好了，接下来的问题是在哪里落地这些水表——这就是工程实现要解决的事。

---

工程实现

水库管理员的规则再合理，也得有人站在大坝上执行。在大模型服务架构中，这个“大坝”通常是 API 网关。网关是所有请求的必经之路，天然适合做限流前置校验——请求还没进入模型服务，先被网关拦住检查令牌。

单机部署用内存计数器就够了，但生产环境往往是多副本网关，每一份令牌桶必须共享状态，否则攻击者轮流打不同的网关副本就能绕过限制。这时 Redis 登场：桶的容量、当前令牌数、上次补充时间都存进 Redis。每次请求过来，网关执行一个 Lua 脚本完成“补充令牌 + 扣减令牌 + 判断是否放行”，三步一气呵成。

为什么一定要用 Lua 脚本？因为 Redis 是单线程执行脚本，整个检查过程原子完成，不会出现两个并发请求同时读到同一个令牌数、都认为自己拿到了最后一个令牌的竞态问题。这是分布式限流的灵魂。落地时还需要注意降级响应：当 Redis 故障或超时，网关不能无限等待，常见策略是“失败放行但记日志”或“本地降级为简易计数器”，并返回 429 时带上 Retry-After 头，引导客户端退避重试。

工程实现把令牌桶从一个数学模型变成了生产环境里真实运转的闸门。但上线只是开始，闸门的松紧还要根据水流动态调整——这就要靠最后一节：调优与监控。

---

调优与监控

水库管理员最关心的仪表盘上有三个数字：放水量、拒绝量、水库水位。对应到 API 限流，就是实际通过速率、429 拒绝率、令牌消耗曲线。没有这些指标，调参就像闭着眼拧水龙头，全凭感觉。

核心指标是限流利用率：实际请求速率占限流阈值的百分比。利用率长期低于 30%，说明限流阈值设得太宽，资源白白闲置；长期高于 90%，说明业务已经贴着天花板运行，需要扩容或调参。告警策略建议分级：利用率超过 70% 通知值班、超过 85% 触发预警、超过 95% 立即响应，避免告警疲劳。

动态调参要结合业务节奏：工作日白天调高速率，夜间和节假日调低；大促前临时增大桶容量，大促后恢复。容量规划则依据历史利用率数据推算——如果利用率月环比持续增长，预示着需要提升限流阈值、扩容后端模型服务，而不是一味地压紧闸门。

至此，一座完整的“限流水库”已经建成：目标清晰、原理扎实、算法选对、参数可算、维度齐全、落地可靠、监控闭环。下次有人问起“为什么大模型 API 要限流”，你可以用这座水库，把从风险到实现的整条链路讲得明明白白。

---

AI 应用场景

Python 演示

import threadingimport time  class TokenBucket:    """令牌桶：固定速率注入令牌，容量有限，允许短时突发。"""     def __init__(self, capacity, refill_rate):        self.capacity = capacity        self.refill_rate = refill_rate        self.tokens = capacity        self.last_refill = time.monotonic()        self.lock = threading.Lock()     def _refill(self):        now = time.monotonic()        delta = now - self.last_refill        self.tokens = min(self.capacity, self.tokens + delta * self.refill_rate)        self.last_refill = now     def try_acquire(self, need=1):        with self.lock:            self._refill()            if self.tokens >= need:                self.tokens -= need                return True            return False  class LLMGateway:    """模拟 LLM API 网关：每个 API Key 对应一个令牌桶。"""     def __init__(self, rpm, burst):        self.rate_limiters = {}        self.rpm = rpm        self.burst = burst     def _bucket(self, api_key):        if api_key not in self.rate_limiters:            self.rate_limiters[api_key] = TokenBucket(                capacity=self.burst,                refill_rate=self.rpm / 60.0,            )        return self.rate_limiters[api_key]     def call_llm(self, api_key, prompt):        bucket = self._bucket(api_key)        if bucket.try_acquire():            return "ok: %s" % prompt[:12]        raise RuntimeError("429 Too Many Requests")     def stats(self, api_key):        b = self.rate_limiters.get(api_key)        return round(b.tokens, 2) if b else None  if __name__ == "__main__":    gw = LLMGateway(rpm=120, burst=10)    for i in range(300):        try:            out = gw.call_llm("user-a", "prompt-%d" % i)        except RuntimeError as exc:            out = exc        if i % 50 == 0:            print(i, out, "剩余令牌:", gw.stats("user-a"))    print("最终剩余令牌:", gw.stats("user-a"))

1. self.tokens = min(self.capacity, self.tokens + delta * self.refill_rate)惰性补充：只在请求到来时按时间差补齐令牌，省去后台定时任务。
2. time.monotonic()用单调时钟而非 time.time()，避免系统改时间导致限流失效。
3. with self.lock:加锁保证多线程环境下扣减令牌的原子性，防止两个线程同时取走最后一个令牌。
4. refill_rate=self.rpm / 60.0把“每分钟请求数”换算成“每秒令牌数”，注入速率与业务口径对齐。
5. raise RuntimeError("429 Too Many Requests")模拟网关返回 429，调用方需据此做退避重试。
6. if api_key not in self.rate_limiters:按 API Key 动态创建独立桶，实现多租户隔离。

常见误区

面试题