智能限流策略：AI 可以算阈值，但降级预案要人先写好

智能限流策略：AI 可以算阈值，但降级预案要人先写好

后端限流从来不是简单的 QPS 数字。大模型应用还要考虑 token 成本、模型并发、队列堆积、租户等级、下游错误率。AI 可以根据历史流量推荐阈值，但限流触发后系统怎么降级，必须提前设计。

限流不是拒绝请求，而是保护核心链路。没有降级预案的智能限流，只是更高级的 429。

一、限流信号要多维

flowchart TD A[QPS] --> E[Rate Limit Decision] B[Token Usage] --> E C[Queue Lag] --> E D[Downstream Error Rate] --> E E --> F[Allow Or Degrade]

只看 QPS 不够。一个长 prompt 的成本可能比十个短请求还高。队列堆积也比瞬时 QPS 更能反映压力。

二、阈值要按场景拆

limit_policy: chat_interactive: max_concurrency: 100 max_queue_wait_ms: 500 document_batch: max_concurrency: 10 max_queue_wait_ms: 30000

交互请求和批处理任务不能用同一套阈值。用户等待聊天结果，和后台跑文档导入，是两种体验目标。

三、降级动作要提前定义

degrade_actions: - switch_to_smaller_model - reduce_top_k - disable_rerank - queue_batch_jobs - return_cached_answer

AI 可以建议什么时候触发，但动作本身要经过架构评审。比如降低 top_k 会影响答案质量，切小模型会影响准确率，这些都要被产品接受。

四、限流结果要可解释

{ "status": "degraded", "reason": "model_gateway_concurrency_high", "fallback": "small_model", "trace_id": "tr_0703" }

后端、前端和客服都需要知道发生了什么。否则用户只看到回答变短，团队却不知道系统在降级。

限流策略还要灰度。新阈值不要一次性应用到全部租户，可以先在低风险租户或内部流量上观察。AI 推荐的阈值尤其需要回放历史流量，确认不会误伤正常高峰。

limit_rollout: shadow_evaluate internal_tenant 5_percent 25_percent full_rollout

如果误伤率高，就回到上一档。限流策略本身也要可回滚。

五、总结

智能限流可以利用 AI 推荐阈值，但必须基于 QPS、token、队列、错误率等多维信号，并提前设计降级动作。

AI 可以算阈值，不能替团队决定牺牲什么体验。降级预案先写好，限流才是保护，不是混乱。

架构评审时应该问清楚：降级时牺牲的是准确率、实时性、完整性，还是排队时间？这个问题不回答，智能限流就没有业务边界。

降级触发后还要自动恢复。很多系统只设计了怎么降级，没有设计什么时候恢复，最后小模型、低 top_k 或排队模式长期挂着。

recover_policy: error_rate_below_threshold_for: 5m queue_lag_below_threshold_for: 5m gradual_restore: true

恢复也要渐进，不要刚恢复就把流量一次性放回去，造成二次抖动。