4. 令牌桶算法详解：原理、参数配置与API网关实现

令牌桶算法（Token Bucket Algorithm）是API流量整形中最经典、应用最广泛的限流算法之一。它通过一个“桶”来平滑突发流量，同时保证长期平均速率不超过设定阈值，非常适合模型推理API这种既有突发请求、又需要控制整体调用量的场景。

4.1 核心原理

令牌桶算法的核心思想是：系统以恒定速率向一个容量有限的桶中放入令牌，每个请求到达时必须从桶中获取一个或多个令牌才能被处理；如果桶中令牌不足，请求将被排队等待或直接拒绝。

4.2 关键参数配置

令牌桶算法有两个核心参数，它们共同决定了流量整形效果：

4.3 算法工作过程详解

令牌桶算法在每个时间步的执行逻辑可以用以下伪代码精确描述：

// 令牌桶状态
capacity = b          // 桶容量
tokens = b            // 当前令牌数，初始为满
last_time = now()     // 上次更新时间

// 每次请求到达时执行
function allow_request():
    // 1. 计算时间差，补充令牌
    now = current_time()
    elapsed = now - last_time
    tokens = min(capacity, tokens + elapsed * r)
    last_time = now

    // 2. 判断是否放行
    if tokens >= 1:
        tokens = tokens - 1
        return true    // 放行
    else:
        return false   // 拒绝或排队

4.4 在API网关中的实现架构

在实际的API网关（如Kong、APISIX、Nginx + Lua）中，令牌桶算法通常作为插件或中间件实现，部署在模型API的前端。以下是典型的实现架构：

4.5 主流网关的令牌桶实现对比

4.6 实际配置案例：模型推理API限流

假设你有一个基于GPT的文本生成模型API，单实例稳定处理能力为 50 QPS，允许短时突发到 100 QPS。以下是Kong网关的令牌桶配置示例：

# Kong 声明式配置 (declarative config)
_format_version: "3.0"
services:
  - name: gpt-inference
    host: model-internal.example.com
    port: 8080
    protocol: http
    routes:
      - name: generate-route
        paths:
          - /v1/generate
        methods:
          - POST
    plugins:
      - name: rate-limiting
        config:
          minute: 3000          # 每分钟3000次，对应50 QPS
          hour: 180000
          policy: local         # 使用本地内存
          fault_tolerant: true
          limit_by: consumer    # 按消费者限流
          # 令牌桶模式参数（通过自定义插件或扩展实现）
          # rate: 50            # 令牌放入速率 r = 50 令牌/秒
          # burst: 100          # 桶容量 b = 100 令牌

4.7 令牌桶 vs 漏桶算法

在流量整形领域，令牌桶常与漏桶算法（Leaky Bucket）对比。下表总结了二者的核心差异：