LLM 网关架构——路由、限流与成本控制
LLM 网关的架构设计。讨论多模型接入场景下的网关定位，列出核心能力、五类路由策略与三维限流设计，并对比自研、开源与托管方案。
LLM网关架构路由限流成本控制
分类：工程与基础设施 › 推理服务与成本优化
发布于 2026-09-22
16 次浏览
一 LLM 网关在架构中的位置
当一个应用要调用多个模型供应商（GPT / Claude / Gemini / 自研 / 本地 vLLM），且要统一处理鉴权、限流、重试、缓存、审计、计费时，LLM 网关（LLM Gateway / AI Proxy）就成了独立一层。类比：传统 API 网关（Kong / Envoy）管的是"请求怎么到后端"，LLM 网关管的是"这个语义请求该发给哪个模型、花多少钱、失败怎么办"。
触发条件：同时满足三个之一就需要网关——① 多供应商混用（>2 家）② 需要按租户/功能做成本归因 ③ 需要统一的重试/降级策略。只调一家 API 且无多租户，轻量 SDK 就够了，不必过早引入网关（不过早抽象是对的，但"没有弹性"也是早期架构最常见的坑）。
二 核心能力清单
| 能力 | 做什么 | 不做会怎样 |
|---|---|---|
| 统一适配层 | 各家 API 转成同一套内部协议（chat / token 计数 / 错误码归一） | 每加一家供应商改一遍业务代码；换供应商是重构级项目 |
| 智能路由 | 按任务类型 / 成本 / 延迟 / 配额选模型（简单任务小模型，复杂任务大模型） | 所有请求都走最贵模型，成本无出口 |
| 限流与配额 | 按租户 / 功能 / API key 做 RPM / TPM / 日预算三方限流 | 单租户刷爆配额拖垮全体；成本失控无刹车 |
| 重试与降级 | 按错误类型分级重试（429 退避 / 5xx 换供应商 / 超时换短 prompt） | 供应商抖动直接透传成业务故障 |
| 响应缓存 | 相同 prompt + 参数命中缓存直接返回（语义近似 + 精确两层） | 重复查询反复烧钱（客服场景重复问题占 30%+） |
| 审计与日志 | 全量记录 request / 模型 / token / 成本 / 延迟 / 结果状态 | 成本无法归因；安全事件无法取证 |
| 安全过滤 | 输入侧 PII 检测 / 注入检测；输出侧敏感词 / 结构校验 | 数据泄露与注入风险无统一拦截点 |
| 用量与计费 | 按租户出用量账单；支持预付费余额 / 后付费账期 | 对内核算扯皮；对外无法商业化 |
三 路由策略：请求与模型的匹配方法
- 任务分级路由（cascade）：所有请求先走轻量模型，输出置信度低（自评 / 格式校验失败 / 长度异常）或命中"复杂"标记时才升级到重型模型。简单任务占比常超 70%，成本直降一个数量级。注意：级联本身有延迟代价（小模型跑一遍+大模型跑一遍），只适合延迟敏感度中等的场景。
- 质量-成本双目标：每个任务类型维护"最低可用模型 + 优选模型"两级，路由器先看预算池（本租户本月剩余额度）再决定走哪级——预算充足走优选，紧张走最低可用。
- 多活与配额打散：同任务允许多家供应商并存（GPT-4o + Claude 各 50%），按实时错误率动态调整权重——本质是把"单供应商依赖"降为"多供应商妥协"。
- 本地模型兜底：自研 / 本地 vLLM 作为最后一层兜底（外部供应商全挂时保底），同时敏感数据场景可强制路由本地（数据不出域）。
- 路由规则版本化：路由策略本身是配置，要版本化、可灰度、可回滚——"路由器变更"是一种变更，不是随手改配置。
四 限流设计：三个维度缺一不可
| 维度 | 单位 | 保护对象 | 典型值参考 |
|---|---|---|---|
| 请求速率（RPM） | 次 / 分钟 / 租户 | 防止突发流量拖垮网关与下游 | 按业务峰值 × 2-3 设上限 |
| Token 速率（TPM） | token / 分钟 / 租户 | 防止长上下文用户挤占带宽 | 按供应商配额反算，留 30% 余量 |
| 预算（日 / 月费用） | 元 / 租户 / 周期 | 成本硬刹车 | 业务预算 × 1.2 设告警线、× 1.5 设熔断线 |
实现要点：预算限流必须真实计算成本而非估算——每次响应后按实际 token 数回写用量，不要靠"请求数 × 平均成本"的估算（长尾请求的单价差异会让估算失真）。限流触发的响应要返回明确的 429 + Retry-After，让上游能退避重试，而不是裸的错误。令牌桶 / 滑动窗口二选一即可，区间内保证单调性。
五 重试与降级：按错误类型分流
| 错误类型 | 网关行为 | 上游感知 |
|---|---|---|
| 429（供应商限流） | 指数退避重试 2-3 次；仍失败则换备用供应商 | 延迟增加但成功 |
| 5xx / 网络超时 | 立即换备用供应商（同一请求不重复发给同一家） | 延迟轻微增加 |
| 内容拦截（供应商安全过滤） | 换供应商重试一次；仍拦截则返回结构化错误 | 明确告知"输入被安全策略拦截" |
| 输出格式错误 | 带错误信息重发（提示修复）或降级到小模型重试 | 透明 |
| 持续降级（预算耗尽 / 全供应商故障） | 按优先级切功能级降级：关闭批量任务 → 只保留低延迟同步接口 → 只读兜底 | 200 + 降级的能力声明 |
关键原则：写操作不自动重试（工具调用 / 外部副作用），读操作可重试；重试必须有上限与总时长上限，防止"重试暴走"（retry storm）放大故障。降级路由（fallback route）要在网关层预配置并演练，不是故障时现场决定。
六 缓存：语义缓存的边界
- 精确缓存：prompt + model + 参数完全一致 → 直接返回。命中率取决于重复查询比例（客服 / FAQ 类场景高，创作类低）。
- 语义缓存：嵌入相似度超阈值视为命中，返回近似结果。风险：相似 ≠ 等价（"退款政策"与"退货政策"嵌入很近但答案不同），必须限定在"事实上可复用"的任务域（问答 / 查询类），且阈值宁紧勿松（0.95+）。
- 缓存键设计：必须包含 model 与 prompt_version——模型升级或提示词变更后旧缓存自动失效，防止"旧版答案污染新版系统"。
- 带 TTL 与版本：时间敏感内容（价格 / 库存 / 新闻）不设缓存或极短 TTL；缓存条目带"生成时间戳"对外可追溯。
- 缓存命中也要记成本：命中成本≈0 但占用存储；命中率本身要进观测（缓存命中率是成本优化第一抓手）。
七 实现路线：自研 vs 开源 vs 托管
| 路线 | 代表 | 适合 | 代价 |
|---|---|---|---|
| 开源网关 | LiteLLM（Python，路由/限流/缓存一体）、Portkey、Higress（云原生 AI 网关）、one-api | 想快速具备多供应商 + 限流 + 成本核算，团队能维护 | 二次开发深度有限；复杂路由逻辑要改源码 |
| 托管服务 | 云厂商 AI 网关 / OpenAI 网关类服务 / Cloudflare AI Gateway | 不想维护、接受锁定、网络边缘就近 | 合规边界（数据过境）；计费不透明 |
| 业务框架内嵌 | LangChain / 自研 SDK 层直接封装 | 单供应商或能力简单 | 无多活 / 无统一限流；规模一大就回炉 |
实践建议：起步用 LiteLLM / one-api 这类轻量开源网关（一个容器就起），业务规模上来后再评估"要不要自研路由层"——多数团队到 3-5 个模型供应商、10 类任务分级时，开源网关的 CRU 能力已经够，复杂性主要在"路由策略配置"而非"网关代码"。
八 安全设计：网关是最后一道闸
- 密钥集中管理：供应商密钥只存在网关（HSM / 加密存储），业务代码拿不到原始密钥，只持有内部 token——换供应商不影响业务侧。
- 输入过滤前置：PII 脱敏 / 注入检测 / 超长截断放在网关，避免"脏数据"进入模型与下游存储。
- 输出审计前置：敏感字段白名单（允许输出的域名 / 路径 / 数据格式）在网关统一校验，业务侧不用各自重复实现。
- 配额即安全：单 API key 的 TPM 上限是"被盗密钥的爆炸半径"——一个 key 泄露最多烧掉其配额，不是全账户。
- 审计不可篡改：审计日志写一次后不可修改（append-only），安全事件追溯依赖它；保留期按合规要求（通常 1 年+）。
九 常见误区
| 误区 | 问题 |
|---|---|
| "网关=反向代理" | 反代只管路由转发；LLM 网关的核心是"语义级"的决策（模型选择 / 成本 / 降级），纯反代解决不了 |
| "只按供应商分路由" | 更有效的路由维度是"任务类型"，GPT-4o 跑简单任务 + Claude 跑复杂任务的反模式比"按供应商平均分"浪费更多 |
| "缓存能省 50% 成本" | 语义缓存只在重复查询占比高的任务域成立；先测命中率再决策，别先开缓存再算账 |
| "限流靠供应商配额就够" | 供应商配额是"你最多能花多少钱"；预算限流是"你最多想花多少钱"，两者差 10 倍，内部配额必须独立 |
| "加了网关就不用做观测" | 网关是观测的天然汇聚点（所有请求都过网关），但"过网关"不等于"看得见"——日志与指标管道不建，网关就是个黑盒 |
| "网关越强大越好" | 每个抽象层都有成本（延迟 + 运维 + 故障面）；单供应商 + 单团队场景，直接调 SDK 是更优解 |
十 落地清单
- 第 1 步：盘点在调的模型与任务类型，画出"任务 → 模型 → 供应商"映射表
- 第 2 步：上轻量网关（LiteLLM / one-api），所有请求改走网关（业务无感）
- 第 3 步：配三方限流（RPM / TPM / 预算），每租户设上限并演练 429 响应
- 第 4 步：配降级路由（每家供应商的 fallback 目标 + 触发条件），做一次故障注入演练
- 第 5 步：开精确缓存（低风险任务域优先），两周后看命中率决策是否上语义缓存
- 第 6 步：审计 + 成本看板上线，按租户 / 功能 / 模型三方出账
一句话收束：LLM 网关的价值不在"多了一层"，在"把供应商差异、成本、风险从业务代码里抽走"——业务只关心"要一个回答"，网关负责"用什么模型、花多少钱、挂了怎么办"。分层正确的是，业务越简单，整体系统越稳。
关键词
LLM网关架构路由限流成本控制 000056