大模型API限流配置：按用户与模型分层的实操方案

给大模型 API 加限流，核心是回答三个问题：限谁、按什么维度限、超限后返回什么。
对零基础用户来说，最省事的做法是在 API 入口统一做一层限流，而不是在每个业务代码里各写一遍。
下面按准备、配置、避坑、验证的顺序讲清楚，环境以 Linux 上的 Nginx 反向代理或自建 API 网关为例，具体路径和参数请按你的实际部署调整。

先想清楚限流维度和额度来源

限流配置不是先写代码，而是先定规则。
常见维度有三种：按调用方（API Key 或用户 ID）、按模型（不同模型成本差异大）、按时间窗口（每秒或每分钟）。

• 按调用方限流：防止单个用户刷爆额度，最常用。
• 按模型限流：给高成本模型单独设更低阈值。
• 按全局限流：保护上游供应商配额，作为兜底。

额度来源要写清楚：是上游供应商给你的每分钟请求数，还是你自己业务能承受的并发。不要凭感觉填数字，先查上游控制台的配额说明，再留 20% 左右余量。

准备条件与前置检查

动手前确认三件事：入口流量是否都经过同一个代理层、是否已有调用方标识（如请求头里的 API Key）、日志能否记录到被限流的请求。
检查命令示例：

nginx -v
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1/v1/models

第一条确认 Nginx 版本，limit_req_zone 在常见版本中均可用；
第二条确认入口可达。
如果请求头里没有稳定的调用方标识，先补一个，否则限流只能做成全局的，粒度不够。

Nginx 层限流配置写法

在 http 块中定义限流区域，按 API Key 做键：

limit_req_zone $http_authorization zone=llm_per_key:10m rate=30r/m;
limit_req_zone $server_name zone=llm_global:10m rate=300r/m;

10m 是共享内存大小，用于存放计数状态；rate=30r/m 表示每个键每分钟 30 次。
然后在 location 中引用：

location /v1/ {
    limit_req zone=llm_per_key burst=10 nodelay;
    limit_req zone=llm_global burst=50 nodelay;
    limit_req_status 429;
    proxy_pass http://llm_backend;
}

burst 是允许的突发请求数，nodelay 表示突发部分立即处理而不是排队。超限时返回 429 而不是 503，便于调用方识别并做退避重试。
改完执行 nginx -t 检查语法，再 nginx -s reload 平滑生效。

如果使用 API 网关（如 Kong、APISIX 一类），思路相同：在路由或消费者上挂限流插件，按 Key 或按 IP 设阈值，超限返回 429。
具体插件名和字段以你部署版本的文档为准。

容易踩坑的几个地方

• 键选错导致误伤：用 $remote_addr 做键时，经过 CDN 或负载均衡后所有请求可能来自同一 IP，等于全局限流。应改用调用方标识或正确配置真实 IP 透传。
• 只限入口不限上游：入口限流了，但内部任务直接调上游，仍会打满供应商配额。内部调用也要走同一入口。
• 返回码不统一：有的地方返回 503、有的返回 429，调用方无法区分是限流还是故障。统一用 429，并在响应体里带上重试建议。
• 窗口设置过死：严格按秒限流会让正常突发请求大量失败，合理使用 burst 吸收短时峰值。
• 改了配置没验证：nginx -t 通过不代表规则生效，必须实际压测确认。

验证限流是否真的生效

用循环请求快速触发阈值，观察状态码分布：

for i in $(seq 1 60); do
  curl -s -o /dev/null -w "%{http_code}\n" \
    -H "Authorization: Bearer test-key" \
    http://127.0.0.1/v1/models
done | sort | uniq -c

预期结果是大部分 200，超出阈值的部分出现 429。
如果全部 200，说明键没匹配上或阈值太高；
如果全部 429，先检查是否所有请求共用了同一个键。
同时到日志里确认被限流的请求有记录，方便后续调参。

上线后的调参节奏

限流阈值不是一次定死的。
上线后观察一周的 429 比例：比例长期接近零说明阈值偏松，起不到保护作用；
比例过高说明阈值偏紧，正常用户被误伤。
按实际流量逐步调整 rate 和 burst，每次只改一个参数并保留变更记录，出问题能快速回滚。

大模型API限流配置的关键不在配置本身，而在于先明确调用方标识和额度来源，再选对限流维度，最后用压测确认阈值合理。
按本文步骤执行后，如果仍出现上游配额被打满，优先检查是否有绕过入口的内部调用。