推理 API 限流怎么做：从单卡 Token 预算到全局并发熔断

nginx 的 limit_req 对推理 API 几乎没用——它限制的是请求速率，不是计算量。一个 500 Token 的请求和一个 50000 Token 的请求，对 GPU 的压力差 100 倍。

第一层：Token 预算（最准的限流维度）

按用户/租户分配每日 Token 配额，网关层拦截：

# 伪代码：网关层 Token 预算
remaining = quota.get(user_id)
if remaining < estimated_tokens(request):
    return 429
# 请求完成后扣减实际消耗
quota.deduct(user_id, actual_tokens)

估算用 len(prompt) / 3 + max_tokens 粗算，误差 20% 可接受。

第二层：队列深度限制

vLLM 的 --max-num-seqs 控制并发请求数。超了排队，排队超时就 429。网关层也该有一层快速失败：

# 网关检查 vLLM 队列深度
queue_depth = http://localhost:8000/metrics | grep waiting
if queue_depth > 50:
    return 503  # 别让客户端傻等

第三层：租户隔离配额

• 免费用户：max_tokens 上限 2048，RPM 5
• 付费用户：max_tokens 16384，RPM 60
• 企业用户：独占实例或预留容量，不限流

第四层：全局熔断

GPU 温度 >85°C / 显存 >95% / 连续 OOM 3 次 → 全局拒绝新请求 10 秒，给冷却窗口。别等卡死再处理。

别做的事

• 别用 nginx limit_req 的 burst 参数当推理限流——burst 只是排队，GPU 队列也在排队，双层排队延迟爆炸
• 别按 QPS 限流——一个长请求占 30 秒，QPS 才 0.03 但 GPU 已经满
• 别让客户端自选 max_tokens 无上限——有人设 131072 直接把 KV Cache 打爆

推理 API 部署：云数方舟 GPU 推理节点