什么是网关限流？给 API 加一道闸

调大模型接口跑得好好的，突然返回一段「请求过于频繁」的报错，不少新手第一次撞上这堵墙都会懵。这堵墙就是网关限流。这篇讲清它挡的是什么、为什么必须有、撞上了怎么办。

限流像景区的闸机

景区再大，瞬时涌入几万人也会瘫痪，所以在门口装闸机，控制单位时间进园的人数。网关限流是同一个思路：在用户请求和服务之间立一道闸，按规则放行，超出的部分排队或劝返。

它拦的对象有两类。一类是恶意流量：有人写脚本高频轰炸接口，不设闸的话，算力和账单都会被打穿。另一类是正常但过量的流量：活动日请求陡增，闸机让系统按自己的节奏消化，而不是直接趴下。

一道闸管三件事

第一件是定额度：常见的是每分钟多少次请求，以及每分钟多少 token，前者卡频率，后者卡总量，两头一起算账。第二件是分身份：不同的账户等级配不同的额度，付费档位宽一些，试用档位紧一些，闸机的放行速度随身份变化。第三件是保后端：闸后面的推理服务能力有限，限流把超过承载力的请求挡在外面，保住已进来的请求能按时完成。

对调用方来说，理解这套规则的价值在于：报错不一定是故障，很多时候只是你在闸机口排满了，等一会儿再试就好。

超了怎么办：排队与拒绝

闸机面对超额请求有两种态度。一种是拒绝，直接返回错误码，请用户稍后再来，简单粗暴但干净；一种是排队，把请求放进缓冲区按序处理，用户体感是变慢而不是失败。多数开放平台采用两者的组合：小幅超出进缓冲，大幅超出直接拒。

写程序调接口时，正规的姿势是识别限流错误码并主动退避：收到限流提示后等待片刻再重试，重试间隔逐次拉长。不做退避、被拒后立刻狂发重试，只会把自己牢牢堵在闸外，还可能触发更严的限制。

两种态度与平台常见做法并排看：

限流自查清单

• 报错是不是 429 类错误码？是限流不是故障
• 自己的调用频率离文档标的上限还有多远
• 重试逻辑有没有做退避，别火上浇油
• 批量任务能否错峰，挪到低峰时段跑

先看报错码，再看自己的频率，九成限流问题出在调用方节奏上。

自建服务也要装闸门吗

自己搭推理服务、只给自己用，似乎不需要限流——恰恰相反，给自己用更要装。一条失控的重试循环能把自家显卡吃满，其他正常请求全部堵死。网关层限流是装在最外层的熔断器，成本极低，作用是在异常流量拖垮核心服务之前先踩刹车。主流的推理框架和网关组件都内置限流配置，开箱就有。

与闸门和平共处

限流不是刁难，是闸机在替所有人维持秩序。调用方做好三件事：读文档里的额度、程序里写退避、批量任务错峰。遇到限流报错，先当排队处理而不是当故障排查。服务搭建的基础见推理框架怎么选？主流引擎的定位，多卡扩容看什么是模型切分？一个模型多张卡，闸门放行的每个请求如何留痕，读什么是调用日志？排查与审计，通俗版解释；账号层面的防护还有什么是密钥轮换？定期换钥匙，看完就会判断。

聊聊网关限流的常见疑问

• 限流错误和付费额度用尽是一回事吗？：不是。限流卡的是瞬时频率，额度卡的是总量，报错信息和错误码都不一样，处理方式也不同。
• 为什么深夜也限流，不是没人用吗？：限流按账户规则执行，和全局拥挤程度无关；有些平台有动态限流，深夜会宽松些，以各家文档为准。
• 多把密钥轮着用能避开限流吗？：平台条款普遍禁止此类做法，可能触发封禁，正经路子是升级档位或优化调用节奏。