智能限流策略：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
恢复也要渐进，不要刚恢复就把流量一次性放回去，造成二次抖动。
