2. 核心思想
一句话理解：LLM Gateway 的核心思想是用一层统一的抽象，把“模型在哪里、用哪家供应商、失败怎么办、成本怎么算”从业务代码里拿出来，交给平台集中决策。
8 大横切能力
1. Provider 抽象
业务方不直接调用 OpenAI、Azure、vLLM、Triton，而是调用 Gateway 暴露的统一模型别名，例如 gpt-4o。Gateway 负责把别名解析成真正的上游 endpoint。
业务请求 model=gpt-4o
↓
Gateway 解析：gpt-4o → [OpenAI, Azure, vLLM]
↓
按策略选一个 provider 调用Provider 抽象带来几个好处：
- 供应商无关：切换 provider 不用改业务代码。
- 多版本共存：同一个模型可以同时挂载正式版和实验版。
- 灰度发布：新 provider 先给 5% 流量，观察后再全量。
2. 统一 OpenAI-compatible API
OpenAI 的 API 设计已经成为事实标准。大多数 LLM Gateway 都向上暴露 /v1/models、/v1/chat/completions、/v1/embeddings、/v1/completions 等端点，让业务方可以直接用 OpenAI SDK 调用任何后端。
vLLM、Triton、LiteLLM、SGLang 都支持 OpenAI-compatible 接口，这进一步降低了网关层的标准化成本。
3. 路由（Routing）
路由决定“一个请求应该去哪个 provider”。常见策略：
| 策略 | 说明 | 适用场景 |
|---|---|---|
| Round-robin | 轮流选择候选 provider | 上游同质、成本相近 |
| Weighted | 按权重分配 | 控制不同供应商/集群流量比例 |
| Least-latency | 选最近 N 次平均延迟最低的 | 对延迟敏感 |
| Priority | 主备模式，主失败才切备 | 成本优先，备用更贵 |
| Cost-based | 选当前 cheapest 的 | 成本优先 |
| Content-based | 按 prompt 长度/语言/安全等级路由 | 长文走低价、敏感走合规供应商 |
| KV-cache-aware（2025 起新范式） | 按上游副本的 KV cache 前缀命中与队列深度路由 | 自托管 vLLM/SGLang 集群，显著提升 TTFT |
4. 负载均衡（Load Balancing）
路由是“选哪一家”，负载均衡是“选哪一台/哪个实例”。在自托管 vLLM/Triton 集群中，Gateway 需要维护上游实例列表，并按连接数、GPU 显存、队列长度做更细粒度的分发。
5. 限流（Rate Limiting）
LLM 调用成本高昂，限流是生产刚需。限流维度包括：
- 全局限流：保护整个网关不被打爆。
- 按 api_key / tenant：每个租户有独立配额。
- 按 model：限制某个昂贵模型的总调用量。
- 按用户：同一租户内不同用户再细分。
常用算法：
- Token Bucket：允许突发，平滑限流，最常用。
- Fixed Window：简单，但窗口边界容易突发。
- Sliding Window Log：精确，但内存开销大。
- Leaky Bucket：强制匀速，适合严格 QoS。
6. 重试、降级与熔断
LLM 调用失败场景比其他 HTTP 服务多得多：
429：速率限制，通常带Retry-After。500/502/503：上游临时不可用。- 超时：长上下文或高负载导致。
- 内容审查：模型拒绝生成。
Gateway 需要：
- 重试：指数退避，只针对可重试错误。
- 降级：主 provider 失败时切到备用 provider 或更便宜模型。
- 熔断：连续失败超过阈值后快速失败，避免拖垮上游和自身。
7. 认证与授权
Gateway 是入口，天然适合做：
- API Key 校验：把用户 key 映射到 tenant / quota。
- Token 校验：OAuth / JWT，适合企业内应用。
- 请求签名：防止请求被篡改或重放。
- 权限控制：哪些 tenant 能调哪些 model。
生产注意：不要在 Gateway 里明文存 key，应接入 Vault、AWS Secrets Manager、Azure Key Vault 等。
8. 可观测与成本追踪
Gateway 是统一观测点，必须输出：
- 延迟：首 token 延迟（TTFT）、完整响应延迟、每输出 token 延迟。
- 吞吐量：QPS、并发数。
- Token 用量：input tokens、output tokens、total tokens。
- 成本：按 provider/model 实时估算。
- 成功率/错误码：2xx/4xx/5xx 分布。
- 缓存命中率：如果实现了 prompt 缓存。
这些指标通常以 Prometheus 格式暴露，再由 Grafana 做大盘。2025 年后，主流网关把 GenAI 专属指标纳入标准导出：TTFT、TPOT、各类型 token 分开计量（input / output / cached / reasoning tokens），并对接 OpenTelemetry GenAI 语义约定与 OpenInference 追踪格式；Agent Router v1.1（2026 年 8 月）起支持跨 provider token 计数与可选的 OTel GenAI 追踪，2026 年多档缓存计费普及后 cached token 计量已从“可选”变为成本核算刚需。
2025-2026 新增的三类横切能力
随着语义缓存、Guardrails 与 MCP 协议的普及，现代 LLM Gateway 的能力集在 8 大基础能力之上又长出了三个新模块。
9. 语义缓存（Semantic Caching）
传统缓存按 prompt 文本哈希做精确匹配；语义缓存则把 prompt 向量化后按余弦相似度命中近义请求：
新请求 prompt
├─ 1. 精确缓存查询（哈希）—— 命中直接返回
└─ 2. embedding → 向量库近邻搜索（阈值如 0.9）
├─ 命中 → 返回缓存答案，延迟降低一个数量级
└─ 未命中 → 调上游，结果写回两级缓存关键设计点：
- 双层级联：先精确、后语义，兼顾成本与命中率。
- 相似度阈值：过高则命中率低，过低则答案“串味”，通常 0.85~0.95 可调。
- 敏感数据不缓存：含 PII 或商业机密的请求应带跳过标记。
- 流式缓存：缓存与回放都要支持 SSE chunk 格式。
典型实现：Kong ai-semantic-cache（3.8+）、APISIX ai-cache、Portkey simple+semantic 双模缓存、LiteLLM Redis 缓存。
10. Guardrails 与内容安全
网关从“可选插件”走向“策略执行点”，在请求和响应两侧做实时检测：
- 输入侧：PII 识别与脱敏、越狱 / Prompt Injection 检测、敏感词过滤。
- 输出侧：内容审核、敏感信息回显检查、引用来源校验。
- 执行方式：规则引擎（Kong
ai-prompt-guard）、小型分类模型，或外接 Guardrails 服务（LiteLLM 的 guardrails hook、Portkey 50+ 内置规则）。
与“认证授权”不同：认证回答“你是谁”，Guardrails 回答“这次对话的内容是否允许”。
11. MCP 工具治理（MCP Gateway）
当客户端从“人写的应用”变成“Agent”，网关需要理解 MCP 协议语义：
- 工具注册表：聚合多个上游 MCP Server 的工具列表，对外暴露统一入口。
- 工具级鉴权：deny-by-default 白名单，按虚拟 key / JWT claims 决定能调哪些工具（Agent Router 的
MCPRouteSecurityPolicy用 CEL 表达式实现）。 - 工具级限流与计量：按工具名（如
create_order）分别限流、计费、观测。 - 协议适配：新旧 MCP 协议转换（Higress 支持 modern↔legacy 双向桥接）。
控制面 vs 数据面
现代 LLM Gateway 通常拆成两个面：
- 控制面（Control Plane）：配置管理、provider 注册、路由规则、配额策略、密钥管理、审计日志。
- 数据面（Data Plane）：接收请求、执行认证、限流、路由、转换、调用上游、记录指标。
控制面可以独立部署、热更新；数据面需要无状态、可水平扩展。
本章小结
LLM Gateway 的 8 大基础能力——Provider 抽象、统一 API、路由、负载均衡、限流、重试降级、认证、可观测——构成了 AI 控制面的最小可行集合；语义缓存、Guardrails、MCP 工具治理则是 2025-2026 年在成本与安全压力下长出的新标配。理解它们之间的边界与组合方式，是后续学习架构与源码的基础。
参考来源