限流的配置分几层？全局与按用户

节假日景区限流从来不是一道闸门：先控制入园总量，再限制每个团队的入园速度，最后约束散客的票量——层层递进，才既保得住体验又挤不垮设施。大模型服务的限流同理，只设一层要么挡不住尖峰，要么误伤正常用户。这篇把分层配置的门道拆开。

先带走一个判断：限流的目的不是拒绝流量，而是让系统在过载时按计划降级，而不是随机崩溃。每一层闸门回答一个不同的问题，合起来才构成完整防御。

从全局到单用户的四层闸门

常见配置分四层。第一层全局总量：整个平台每秒能处理的请求数上限，保护的是机器与算力，这是最后防线。第二层按租户或应用：一个接入方能占用的份额，防止单一应用吃光公共资源。第三层按用户：单个最终用户的频次，防脚本刷量与滥用。第四层按接口或模型档位：重模型的调用单独设阈值，Kimi、文心一言这类多档模型平台普遍对高档模型单独限额。四层的阈值相互独立又彼此关联，自外向内逐层收紧。

四层闸门各卡谁、卡什么、防什么，并排看更清楚。

每层计数的窗口怎么选

限流靠计数，计数靠窗口。固定窗口实现简单，但边界突刺明显——两个窗口交界处可能瞬间放进双倍流量。滑动窗口记录时间序列，计数平滑，代价是存储与计算更多。令牌桶则以恒定速率生成令牌，允许短暂突发，最适合承接「有节奏的爆发」这类真实流量形态。分层时的经验搭配：全局层用滑动窗口保平稳，用户层用令牌桶容忍正常突发，接口层按模型特性单独选。窗口参数没有通用答案，以真实流量回放验证为准。窗口参数定了以后也别当成摆设，要随流量形态复盘：业务节奏变化后，原来合理的窗口可能开始误伤，触发数据是唯一的裁判。

超额之后返回什么

被限流不等于一拒了之。规范做法是返回明确的超额信号与重试提示：状态码区分超额与其他错误，响应里附带预计可重试的时间或剩余配额信息，让调用方能据此安排退避，而不是盲目重发。提示语面向终端产品时还要转译成用户能懂的说法——「操作太快了，请稍后再试」，而不是把内部状态码直接抛给用户。客户端按提示做退避重试的方式，见服务端的超时是怎么处理的？内部门道在这。

配置怎么避免互相打架

多层阈值若随手设置，会出现内层先于外层触发的倒挂：比如单用户阈值过高，全局阈值形同虚设；或某接口层阈值太紧，正常用户天天被误伤。协同原则有三条：各层阈值要有明确的数量级关系，逐层放宽；变更走评审，改一层前先看相邻层的余量；触发数据要回流到监控，哪层先满、谁被拒了，都是调参依据，指标取舍见监控大盘的指标是怎么挑的？关键步骤一次讲清。限流触发频次骤升也是业务异常信号，要不要升级告警，分级逻辑见告警的分级是怎么定的？从原理到落地；限流还直接影响调用费用与容量规划，成本侧的算账见多模型的成本对比是怎么跑的？过程拆开看。

限流分层速查表

• 四层闸门：全局总量 → 租户 → 用户 → 接口档位
• 窗口搭配：全局滑动窗口，用户层令牌桶
• 超额反馈：明确状态码 + 可重试时间
• 协同原则：逐层数量级递增、变更评审、触发数据回流

限流配置快问快答三则

• 被限流是服务故障吗？：是计划内的保护动作，说明系统在过载边缘被稳住了，客户端按提示退避重试即可。
• 突发流量全靠限流扛吗？：限流是兜底不是扩容，可预见的峰值应提前扩容或排队缓冲，限流只处理计划外的部分。
• 个人调用和商业调用限流一样吗？：多数平台分档管理，商业凭证额度更高且有独立队列，以各平台文档为准。