一、项目背景

我们网关团队接手一个 AI 服务平台后，最头疼的是稳定性：某业务线搞活动，瞬时流量把 GPU 打满，正常用户的请求排半天；个别热点模型被刷爆，长尾请求拖垮整池；更糟的是，限流一旦硬拒，前端直接报错，体验崩塌，投诉电话被打爆。早期网关只有一道全局闸刀，要么全放要么全拦，完全没有层次。我们这个项目要解决的，是把"限流"从粗暴的全局闸刀，升级成请求级、按维度分层、能整形而非硬拒的柔性治理，让稳定性与体验兼得。

二、落地场景

能力落在我们 AI 网关的接入层和路由层之间。每次请求进来，先按"模型、租户、用户、接口"维度做令牌桶限流；超过配额的进入排队整形而非立即拒绝；对热点模型设保护水位，超额请求降级到备用模型或返回"稍后重试"的友好态。运营侧能在管控台按维度看实时流量和限流命中，快速判断是哪条业务线在冲击容量。对调用方而言，突发时拿到的是"请稍候"而非"直接失败"，体感天差地别。

三、关键技术挑战与解决思路

第一难是多级限流维度。全局一个桶不够精细，我们做了维度叠加：先租户级总配额，再模型级热点保护，再用户级防刷。优先级从高到低，先拦最该拦的，把有限的容量留给正常流量。第二难是突发排队策略。硬拒体验差，我们用有界队列加短超时做"整形"：突发请求排队等待令牌，超过队列上限或等待超时才拒绝，把尖峰削平而不是一刀切。第三难是热点模型保护。我们对每个模型实例监控队列深度，超过水位就触发降级路由，把部分流量导到容量闲的实例或轻量模型，保住整体可用，避免单点被冲垮拖垮全局。

案例片段（已脱敏）： 限流配置： tenant_quota: 2000 req/min model_hotspot: gpt-class-7b, water_level=0.85 queue_max: 500, wait_timeout: 3s 压测日志： 峰值 3200 req/min 打入, 限流命中 1200, 排队整形承接 1800, 硬拒仅 200 P99 延迟从裸奔时的 9.8s 收敛到 2.1s

四、效果数据

脱敏压测与线上观察：活动峰值下，硬拒率从改造前的约百分之三十一降到约百分之六，绝大多数突发被整形消化；P99 延迟下降约百分之七十八；热点模型被打挂的次数从每周约两到三次降到约零；因限流导致的客诉下降约八成。稳定性提升的同时，业务侧的感知是"偶尔慢一点但基本不报错"，这比"快但动不动失败"受欢迎得多。

五、可复用经验总结

其一，限流要按维度分层，先租户再模型再用户，越往下越精准，别一上来就全局闸刀，误伤面太大。其二，突发用整形（排队加短超时）而非硬拒，用户体验和稳定性能兼得，这是柔性治理的精髓。其三，热点模型保护要靠实例级水位监控触发降级，这是防雪崩的最后一环，不能只靠前端限流。其四，限流参数要可观测，我们把每维度命中数都暴露到看板，调参才有依据，否则全是盲调。其五，限流信号可反向驱动底座弹性扩缩容，形成算力与流量联动闭环，这才是终极解法。

附：规模化落地的几点工程取舍

限流整形规模化后，第一个取舍是队列长度的代价。队列越大越能削峰，但等待中的请求占内存、占连接，我们按实例规格设了队列上限，超限就拒，把"保护系统"放在"承接一切"之前。第二是令牌桶的时钟一致性，分布式下各节点时钟漂移会让配额算错，我们用中心化配额服务加本地令牌预取，既准又不每请求都远程。第三是降级的触发阈值，水位设太高降级来不及、设太低又频繁误伤，我们按模型的历史负载分布动态标定，而非拍脑袋定值。第四是多维度限流的优先级冲突，租户配额和模型热点同时触发时，我们规定"模型热点优先"，因为单模型被打挂影响面是全局的。第五是限流策略的灰度，新业务上线先观察不拦截只打标，跑稳再切硬限流，避免误杀正常流量。网关稳定性这件大事，本质是无数个"保系统还是保体验"的小取舍，把每个取舍的边界量化，系统才既稳又不惹人烦。

附二：给同行落地限流整形的一点提醒

第一，限流维度一定要分层，先租户再模型再用户，越细越精准，全局闸刀误伤面太大。第二，突发用整形别用硬拒，排队加短超时的体验远好于直接报错，稳定性也更好。第三，队列长度要有上限，否则保护系统的机制反过来拖垮系统，取舍要果断。第四，令牌桶在分布式下得解决时钟一致性，中心化配额加本地预取是稳妥解。第五，降级阈值要按模型历史负载动态标定，别拍脑袋，否则要么来不及要么误伤。第六，新业务上线先打标观察再切硬限流，给系统一个适应期。第七，所有限流命中都要可观测，否则你不知道是哪条业务线在冲击容量。网关稳定这件大事，本质是把无数个保系统还是保体验的小取舍量化并固化，取舍清晰，系统才既稳又不惹人烦。