AI网关（限流/路由/大模型灰度）
1 限流
结论先行：
你给的代码：
if input_tokens + max_tokens > MAX_MODEL_LEN:
raise ValueError("input too long")
在 AI 网关语义下，它属于：
请求准入控制（Admission Control）的一部分
而不是模型逻辑。
二、AI 网关里的“限流”其实分三类（很关键）
很多人把它们都叫“限流”，但本质不同。
1️⃣ 资源限流（QPS / 并发）
每秒最多 100 请求
并发最多 20
→ 传统 API Gateway 能力
2️⃣ 容量限流（Token Budget） ← 你这个属于这里
这次请求会不会压垮模型？
判断依据包括：
- input_tokens
- max_tokens
- 目标模型的 max-model-len
- 当前模型规格（4k / 8k）
3️⃣ 策略限流（业务规则）
普通用户不能用 8k 模型
三、AI 网关里“正确”的写法是什么样？
1️⃣ 不直接 raise，而是“标准化拒绝”
在网关中，更像这样：
if input_tokens + max_tokens > model.max_model_len:
return {
"status": 400,
"error_code": "CONTEXT_LENGTH_EXCEEDED",
"message": f"input({input_tokens}) + max_tokens({max_tokens}) > {model.max_model_len}"
}
原因：
- 统一错误码
- 可监控
- 可统计
- 可 A/B
2 路由. 短请求路由到 小上下文模型服务， 长请求路由到大 上下文模型服务
if input_tokens + max_tokens <= model_4k.max_model_len:
route("vllm-4k")
elif input_tokens + max_tokens <= model_8k.max_model_len:
route("vllm-8k")
else:
reject()
五、那“token 计算”谁来做？
AI 网关必须自己算，不能信任调用方。
典型方式：
- 使用和模型一致的 tokenizer
- 或近似估算（fast path）
input_tokens = tokenizer.count(prompt)
路由-灰度
模型多版本 → 多推理实例 → AI 网关做灰度路由
这是大模型/小模型灰度上线的标准架构范式。
你提到的两点本身没有问题：
- 不同模型版本部署在不同推理服务实例
- Agent 不直连模型，通过 AI 网关统一调度与灰度
这是工业上必须要有的一层抽象。
二、标准工业架构分层（补齐全貌）
我把完整架构按“职责分层”拆开，你可以对照理解你现在的设计在哪一层。
[ Agent / 业务系统 ]
│
▼
[ AI 网关 ]
（灰度 / 路由 / 策略）
│
▼
[ 推理服务集群（多版本） ]
├─ Model v1（稳定）
├─ Model v2（灰度）
└─ Model v3（实验）
三、你说的方案 = 工业标准方案（逐点确认）
1️⃣ 模型版本 → 不同推理服务器（✔ 正确）
“模型版本不一样，要部署到不同的推理服务器”
这是必须的，原因有三点：
- 模型权重不同（LoRA / base / 超参）
- 灰度与回滚必须做到物理隔离
- 不允许“热切权重”影响稳定流量
常见实现方式：
| 方式 | 说明 |
|---|---|
| 独立 Pod / 容器 | K8s 最常见 |
| 不同 GPU 实例 | A100 / L40 |
| 不同 vLLM 实例 | 每实例加载一个模型版本 |
工业上不会在同一个进程里动态切换模型版本。
2️⃣ Agent → AI 网关统一调用（✔ 非常关键）
“Agent 调用通过 AI 网关”
这是架构成熟度的分水岭。
AI 网关负责的不是“转发”，而是：
- 灰度路由
- 策略控制
- 统一观测
- 降级兜底
如果 Agent 直连模型，灰度就几乎不可控。
3️⃣ AI 网关根据灰度规则路由（✔ 正确，但可以讲得更细）
你现在的描述已经对了，但面试中建议升级成：
AI 网关根据灰度规则（规则 + 比例 + 标签），将请求路由到不同模型版本的推理服务。
四、AI 网关里“真正重要的设计点”（面试加分）
1️⃣ 灰度不是只看“比例”
工业灰度几乎从不只按随机比例。
常见灰度维度包括：
| 灰度维度 | 示例 |
|---|---|
| 用户维度 | 高客单 / 内测用户 |
| 会话维度 | 新会话 / 首轮 |
| 场景维度 | Objection 阶段 |
| 业务维度 | 某产品线 |
| 风险维度 | 非退款 / 非投诉 |
所以 AI 网关的判断逻辑通常是：
if match(gray_rules):
route_to(model_v2)
else:
route_to(model_v1)
2️⃣ 必须保证“会话一致性”
这是一个非常关键但常被忽略的点。
同一会话，不能中途切模型版本。
否则会出现：
- 行为风格跳变
- 话术不一致
- 业务逻辑断裂
因此 AI 网关一般会：
- 根据
conversation_id - 在首轮选定模型版本
- 后续强制 stick 到同一实例
3️⃣ 灰度 ≠ 并发能力测试
灰度上线的目标是：
- 验证行为正确性
- 验证业务指标
- 验证是否有副作用
而不是压测。
所以：
- 灰度实例 QPS 通常较低
- 不追求极致吞吐
- 更重可观测性
五、完整“工业级灰度路由流程（文本）”
你可以在面试中这样讲：
Agent 请求
↓
AI 网关接收请求
↓
读取会话信息 / 用户标签 / 场景标签
↓
匹配灰度规则（版本、比例、范围）
↓
选定模型版本（一次会话内固定）
↓
路由到对应推理服务实例
↓
返回结果 + 打版本标记
六、灰度上线必须配套的“非功能能力”
如果你再补这几点，面试官会非常安心：
- 每次响应打
model_version - 灰度流量单独统计指标
- 支持一键回滚
- 灰度失败自动熔断
七、你这个设计在面试中可以这样总结（强烈推荐）
在架构上，我们通过多版本模型独立部署，由 AI 网关统一调度。
AI 网关基于用户、场景和比例等灰度规则，将请求路由到不同版本的推理服务，并保证会话内版本一致性。
这样可以实现模型的灰度上线、指标对照和快速回滚，是工业中常见且成熟的做法。
八、下一步我可以继续帮你拆的方向
如果你愿意继续深挖，我可以直接帮你拆：
- AI 网关灰度规则的配置模型（字段级）
- 如何同时灰度 Prompt / 模型 / RAG
- 灰度失败时的自动降级策略
- vLLM 多模型部署的最佳实践
你选一个，我直接继续。
浙公网安备 33010602011771号