AI网关 限流策略-智能客服
- null
- 二、你这个场景的“硬指标”
- 三、第一层：全局入口 QPS 限流（兜底）
- 四、第二层：按上下文池限流（最重要）
- 五、第三层：token 级限流（真正专业的做法）
- 六、第四层：用户 / 租户限流（防止“好人被坏人拖死”）
- 七、关键：超限时“怎么处理”（比限流本身更重要）
- 八、一个完整的 AI 网关路由决策示例（你会用得上）
- 九、为什么这是“AI 网关”，而不是普通网关？
- 十、一句话总结（最重要）
- 一、先给你一个一句话答案
- 二、你现在混淆的是两个概念
- 三、用“收费站”打个完全贴切的比喻
- 四、用你这段配置逐行解释
- 五、为什么不是直接 qps_limit = 500？
- 六、为什么“这一层不看 token”？
- 七、完整流程（你现在应该这样理解）
- 八、用一句工程化的话收尾
AI 网关的限流不是一个维度，而是四层叠加：
- 全局入口限流（保护系统）
- 按上下文池限流（保护 GPU）
- 按用户 / 租户限流（防滥用）
- 按 token 预算限流（真正对齐算力）
QPS 只是第一道闸门，token 才是核心资源。
二、你这个场景的“硬指标”
已知
-
峰值 QPS：500
-
预留 buffer 后 token 预算：600k token/s
-
GPU 池：
- 2048 ctx：6 张 GPU
- 4096 ctx：4 张 GPU
三、第一层：全局入口 QPS 限流（兜底）
目的：防止系统被瞬间打死
位置：L7（Nginx / Envoy / Kong）
global:
qps_limit: 550
burst: 100
action: reject
说明：
- 550 ≈ 500 × 1.1
- burst 只允许短抖动
- 超过直接 429，不进模型系统
这一层不看 token，只看 QPS，是最外层防火墙
四、第二层：按上下文池限流（最重要）
这是 AI 网关和传统 API 网关的根本区别。
2048 上下文池
- token 预算：420k token/s
- 单请求 token ≈ 1000
- 理论 QPS ≈ 420
配置：
route: vllm-2048
limit:
qps: 420
burst: 50
action: degrade_or_queue
4096 上下文池
- token 预算：180k token/s
- 理论 QPS ≈ 180
route: vllm-4096
limit:
qps: 180
burst: 30
action: degrade
注意：这里不是“平均比例”，
而是算力反推出来的上限。
五、第三层：token 级限流（真正专业的做法）
为什么 QPS 不够？
因为：
- 1 QPS = 300 token
- 1 QPS = 3000 token
对 GPU 来说是两个世界。
Token Bucket（推荐）
if input_tokens + max_tokens > user_token_budget:
reject(429)
if pool_token_bucket.try_consume(input_tokens + max_tokens):
route()
else:
queue_or_degrade()
对你这个系统：
| 池 | token/s budget |
|---|---|
| 2048 | 420k |
| 4096 | 180k |
六、第四层：用户 / 租户限流（防止“好人被坏人拖死”）
示例（企业客服场景）：
per_user:
default:
qps: 5
token_per_min: 50k
vip:
qps: 20
token_per_min: 300k
七、关键：超限时“怎么处理”（比限流本身更重要）
❌ 错误做法
- 一律 reject
- 一律排队
✅ 推荐策略（智能客服）
| 场景 | 行为 |
|---|---|
| 2048 超限 | 降级回答（短答 / 模板） |
| 4096 超限 | 回落到 2048 |
| 总入口超限 | 直接 429 |
八、一个完整的 AI 网关路由决策示例（你会用得上）
tokens = estimate_tokens(input, max_tokens)
if tokens > 4096:
reject("too long")
if tokens <= 2048:
route("vllm-2048")
elif tokens <= 4096:
if pool_4096.has_token(tokens):
route("vllm-4096")
else:
route("vllm-2048", degrade=True)
九、为什么这是“AI 网关”，而不是普通网关？
因为它：
- 理解 token
- 理解 上下文成本
- 理解 模型池差异
- 能 动态降级，而不是简单拒绝
这正是你前面问的那句：
“是不是智能体先调 AI 网关，再由 AI 网关决定走哪个模型？”
是的，而且这是生产级做法。
十、一句话总结（最重要）
QPS 是表象，token 才是资源；
AI 网关的限流，本质是 token 调度。
如果你愿意，下一步我可以直接帮你：
- 给你一份 Envoy / Kong 的真实限流配置样例
- 或把 2048 / 4096 混合流量 → GPU 利用率画成一张表
你已经在做正确的架构决策了，继续往下走就是落地细节。
一、先给你一个一句话答案
500 QPS 以内的请求，当然是全部正常访问的。
qps_limit: 550不是把 500 挡住，而是给 500 留缓冲带。
如果 500 都进不来，这个限流就完全失去意义了。
二、你现在混淆的是两个概念
❌ 常见误解
“qps_limit = 550，是不是 500 就已经被限制了？”
✅ 实际含义
qps_limit 是“允许的上限”，不是“开始限制的阈值”
三、用“收费站”打个完全贴切的比喻
把 AI 网关想成高速收费站：
- 正常车流：500 辆 / 秒
- 收费站最大处理能力：550 辆 / 秒
- 临时插队 / 抖动：burst 100 辆
会发生什么？
1️⃣ 车流 ≤ 500
- 全部正常通过
- 没有任何限流发生
2️⃣ 车流 500～550
- 仍然全部放行
- 这是 安全冗余区
3️⃣ 车流瞬间跳到 620
-
前 550：直接过
-
多出来的 70：
- 如果 burst 还有余额 → 放行
- 否则 → 拒绝（429）
四、用你这段配置逐行解释
qps_limit: 550
burst: 100
qps_limit: 550
含义：
-
系统允许的“长期稳定速率”
-
小于等于 550 QPS：
- 100% 正常放行
-
不会在 500 就开始挡
burst: 100
含义：
- 允许短时间超速
- 可以在极短时间内承受：
550 + 100 = 650 QPS（瞬时）
前提：
- burst 是可消耗的
- 用完就没了
- 要等流量回落才会慢慢恢复
action: reject
含义：
- 一旦超过 qps_limit + burst
- 直接返回 429
- 请求 根本不进模型系统
五、为什么不是直接 qps_limit = 500？
这是工程里的一个关键点。
如果你写成：
qps_limit: 500
burst: 0
会发生什么？
-
实际流量永远有抖动
-
真实 500 QPS ≈ 480～520 摆动
-
结果：
- 明明系统没满
- 用户却频繁 429
👉 这是一个“假性限流”灾难
六、为什么“这一层不看 token”？
因为这是最外层的“物理保护”：
-
目的是：
- 防 DDoS
- 防 Bug
- 防配置错误
-
不追求精度
-
只追求：
- 快
- 简单
- 一定要挡住异常流量
token 级限流：
- 成本高
- 逻辑复杂
- 应该放在 内层 AI 网关
七、完整流程（你现在应该这样理解）
客户端
↓
【全局 QPS 防火墙】
- qps_limit = 550
- burst = 100
↓
【AI 网关：token / 上下文路由】
↓
【vLLM 实例池】
八、用一句工程化的话收尾
500 QPS 是业务目标，
550 QPS 是系统能力，
burst 是现实世界的不完美。
如果你愿意，下一步我可以帮你把这套限流：
- 映射成 Nginx / Envoy 的真实配置
- 或画一张 QPS vs token 的限流层级图
你已经理解到“对的层级”了，这一步跨过去，后面会非常顺。
浙公网安备 33010602011771号