AI 网关不是传统 API 网关的简单升级，而是面向 LLM 和 Agent 场景重新设计的流量控制中枢。它解决的核心问题是：如何让 AI 服务像微服务一样可控、可观测、可治理。

为什么需要 AI 网关？

传统 API 网关（如 Nginx、Kong、Envoy）设计用于 REST/gRPC 微服务，但 AI 应用引入了全新的挑战：

传统微服务 AI 服务
请求-响应模式，毫秒级响应 流式输出（SSE），秒级甚至分钟级响应
按请求计费，成本可预测 按 Token 计费，成本波动大
无状态，易于水平扩展 有状态（上下文、KV Cache），扩展复杂
错误明确（4xx/5xx） 错误模糊（幻觉、不安全输出）
认证鉴权即可 需要内容安全、Prompt 注入防护

核心问题：

  • 如何管理多个 LLM 提供商（OpenAI、Anthropic、本地模型）？
  • 如何控制 Token 消耗和成本？
  • 如何防止 Prompt 注入和不安全输出？
  • 如何追踪每个请求的 Token 消耗和延迟？
  • 如何实现模型的灰度发布和 A/B 测试？

这些问题催生了 AI 网关——专门为 LLM 和 Agent 流量设计的网关层。

AI 网关的核心能力

1. 多模型统一接入与智能路由

问题：应用需要调用多个 LLM 提供商，每个提供商的 API 格式不同。

解决方案：AI 网关提供统一的 OpenAI 兼容 API，屏蔽底层差异。

1
2
3
4
5
# 应用只需调用统一接口
response = client.chat.completions.create(
    model="gpt-4",  # 或 "claude-3", "llama-3", "local-model"
    messages=[{"role": "user", "content": "Hello"}]
)

智能路由策略：

策略 说明 适用场景
按模型路由 根据模型名称路由到对应提供商 多模型混合部署
按成本路由 优先选择成本最低的模型 成本敏感场景
按延迟路由 优先选择延迟最低的模型 实时性要求高
按能力路由 根据任务类型选择最合适的模型 复杂任务用大模型，简单任务用小模型
故障回退 主模型不可用时自动切换到备用模型 高可用要求

配置示例（Envoy AI Gateway）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: AIGateway
metadata:
  name: llm-gateway
spec:
  rules:
  - match:
      model: "gpt-4"
    backend:
      type: OpenAI
      endpoint: "https://api.openai.com/v1"
      apiKeySecret: openai-key
  - match:
      model: "claude-3"
    backend:
      type: Anthropic
      endpoint: "https://api.anthropic.com/v1"
      apiKeySecret: anthropic-key
  - match:
      model: "local-llama"
    backend:
      type: vLLM
      endpoint: "http://vllm-service:8000/v1"

2. Token 计量与成本控制

问题：LLM 按 Token 计费，成本难以预测和控制。

解决方案：AI 网关实时追踪 Token 消耗，实施配额和限流。

核心功能：

  • Token 计数：实时统计每个请求的 input/output tokens
  • 配额管理：为每个用户/租户设置 Token 配额
  • 限流策略：基于 Token 速率限流（而非请求速率）
  • 成本告警：Token 消耗超过阈值时告警
  • 账单生成：按用户/租户/模型生成详细账单

配置示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
rateLimit:
  type: TokenBased
  rules:
  - name: per-user-limit
    match:
      header: "x-user-id"
    limit:
      tokens: 100000  # 每个用户每分钟最多 10 万 tokens
      requests: 100   # 同时限制请求数

quota:
  - name: tenant-a-quota
    match:
      header: "x-tenant-id"
      value: "tenant-a"
    limit:
      monthlyTokens: 10000000  # 每月 1000 万 tokens
      action: reject  # 超额后拒绝请求

成本仪表盘示例：

1
2
3
4
5
6
7
8
9
10
用户 A：
  - 今日消耗：12,345 tokens
  - 本月消耗：456,789 tokens
  - 配额剩余：9,543,211 tokens (95%)
  - 预估成本：$45.67

模型分布：
  - GPT-4：30% tokens, 60% 成本
  - GPT-3.5：50% tokens, 20% 成本
  - Local LLaMA：20% tokens, 20% 成本

3. 内容安全与 Prompt 注入防护

问题：恶意用户可以通过 Prompt 注入操控模型行为，输出不安全内容。

解决方案：AI 网关在请求和响应两端实施安全检查。

防护机制：

请求端防护（Prompt 注入检测）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 检测常见 Prompt 注入模式
injection_patterns = [
    r"ignore previous instructions",
    r"you are now",
    r"new role:",
    r"system prompt:",
    r"jailbreak",
]

def check_prompt_injection(prompt: str) -> bool:
    for pattern in injection_patterns:
        if re.search(pattern, prompt, re.IGNORECASE):
            return True
    return False

# 网关拦截可疑请求
if check_prompt_injection(request.messages[-1].content):
    return Response(status=400, body="Potential prompt injection detected")

响应端防护（内容过滤）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 检测不安全输出
unsafe_patterns = [
    r"how to (hack|exploit|attack)",
    r"illegal activities",
    r"personal information:",
    r"password:",
]

def check_unsafe_content(response: str) -> bool:
    for pattern in unsafe_patterns:
        if re.search(pattern, response, re.IGNORECASE):
            return True
    return False

# 过滤或标记不安全输出
if check_unsafe_content(response.content):
    response.content = "[Content filtered due to safety concerns]"

PII（个人身份信息）保护

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 检测并脱敏 PII
import re

def mask_pii(text: str) -> str:
    # 邮箱
    text = re.sub(r'\b[\w\.-]+@[\w\.-]+\.\w+\b', '[EMAIL]', text)
    # 电话
    text = re.sub(r'\b\d{3}[-.]?\d{3}[-.]?\d{4}\b', '[PHONE]', text)
    # 身份证
    text = re.sub(r'\b\d{17}[\d|x]\b', '[ID]', text)
    return text

# 在响应返回前脱敏
response.content = mask_pii(response.content)

4. 可观测性与追踪

问题：LLM 请求链路复杂，需要端到端的可观测性。

解决方案：AI 网关收集完整的请求元数据和追踪信息。

关键指标：

指标 说明 用途
tokens.input 输入 Token 数 成本分析
tokens.output 输出 Token 数 成本分析
latency.first_token 首个 Token 延迟 性能监控
latency.total 总延迟 性能监控
model.name 使用的模型 路由分析
user.id 用户标识 用量分析
status.code 状态码 错误监控

追踪示例（OpenTelemetry）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
from opentelemetry import trace

tracer = trace.get_tracer("ai-gateway")

def handle_request(request):
    with tracer.start_as_current_span("llm-request") as span:
        span.set_attribute("llm.model", request.model)
        span.set_attribute("llm.user", request.user_id)
        span.set_attribute("llm.tokens.input", count_tokens(request.messages))
        
        response = call_llm(request)
        
        span.set_attribute("llm.tokens.output", count_tokens(response.content))
        span.set_attribute("llm.latency.first_token", response.first_token_latency)
        span.set_attribute("llm.latency.total", response.total_latency)
        
        return response

日志格式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
  "timestamp": "2025-11-25T10:30:00Z",
  "request_id": "req-123456",
  "user_id": "user-789",
  "model": "gpt-4",
  "tokens": {
    "input": 150,
    "output": 200
  },
  "latency": {
    "first_token_ms": 450,
    "total_ms": 2300
  },
  "cost": {
    "input_usd": 0.0045,
    "output_usd": 0.012
  },
  "status": 200,
  "trace_id": "abc123def456"
}

5. 缓存与性能优化

问题：相同或相似的请求重复调用 LLM，浪费 Token 和增加延迟。

解决方案：AI 网关实现语义缓存（Semantic Cache）。

语义缓存原理：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
from sentence_transformers import SentenceTransformer
import numpy as np

# 加载 Embedding 模型
embedding_model = SentenceTransformer('all-MiniLM-L6-v2')

# 缓存结构
cache = {}  # embedding -> response

def semantic_cache_lookup(prompt: str, threshold: float = 0.95):
    """语义相似度缓存查找"""
    prompt_embedding = embedding_model.encode(prompt)
    
    for cached_embedding, cached_response in cache.items():
        similarity = cosine_similarity(prompt_embedding, cached_embedding)
        if similarity >= threshold:
            return cached_response  # 命中缓存
    
    return None  # 未命中，需要调用 LLM

def cosine_similarity(a, b):
    return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))

缓存策略：

策略 说明 适用场景
精确匹配 完全相同的 Prompt 才命中 严格一致性要求
语义匹配 相似度 > 阈值即命中 通用场景，节省成本
TTL 过期 缓存设置过期时间 时效性要求
用户隔离 不同用户的缓存隔离 多租户场景

性能提升示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
无缓存：
  - 请求数：1000
  - LLM 调用：1000 次
  - 平均延迟：2.5s
  - Token 消耗：500,000
  - 成本：$15

有语义缓存（命中率 40%）：
  - 请求数：1000
  - LLM 调用：600 次（缓存命中 400 次）
  - 平均延迟：1.5s（缓存请求 < 100ms）
  - Token 消耗：300,000
  - 成本：$9
  
节省：40% Token，40% 成本，40% 延迟

6. 模型版本管理与灰度发布

问题：模型更新需要平滑过渡，避免影响所有用户。

解决方案：AI 网关支持模型版本管理和流量分割。

灰度发布策略：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# 金丝雀发布：10% 流量到新版本
routes:
- match:
    model: "gpt-4"
  backends:
  - name: gpt-4-v1
    weight: 90
    endpoint: "https://api.openai.com/v1"
  - name: gpt-4-v2
    weight: 10
    endpoint: "https://api.openai.com/v1"
    modelOverride: "gpt-4-turbo"

# A/B 测试：按用户分组
routes:
- match:
    model: "gpt-4"
    header: "x-user-group"
    value: "control"
  backend:
    name: gpt-4-v1
- match:
    model: "gpt-4"
    header: "x-user-group"
    value: "experiment"
  backend:
    name: gpt-4-v2

监控指标对比：

1
2
3
4
5
6
7
8
9
10
11
GPT-4 v1（控制组，90% 流量）：
  - 平均延迟：2.3s
  - 用户满意度：4.2/5
  - 错误率：0.5%

GPT-4 v2（实验组，10% 流量）：
  - 平均延迟：1.8s（-22%）
  - 用户满意度：4.5/5（+7%）
  - 错误率：0.3%（-40%）

结论：v2 性能更优，可以全量发布

AI 网关架构模式

架构 1：独立 AI 网关

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌──────────┐
│  应用层   │
└────┬─────┘
     │
┌────▼──────────────┐
│   AI Gateway      │
│  (独立部署)        │
│  - 路由           │
│  - 限流           │
│  - 缓存           │
│  - 安全           │
└────┬──────────────┘
     │
┌────▼─────┐
│ LLM 服务  │
│ (多模型)  │
└──────────┘

优点：职责清晰，易于管理和扩展
缺点：增加一跳延迟

适用场景：微服务架构，需要统一管理多个应用的 LLM 调用

架构 2：Sidecar 模式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
┌─────────────────────┐
│      Pod            │
│  ┌────────┐         │
│  │  App   │         │
│  └───┬────┘         │
│      │              │
│  ┌───▼──────────┐   │
│  │ AI Gateway   │   │
│  │  (Sidecar)   │   │
│  └───┬──────────┘   │
└──────┼──────────────┘
       │
┌──────▼─────┐
│  LLM 服务   │
└────────────┘

优点：低延迟，与应用紧密集成
缺点：每个 Pod 都有网关，资源消耗高

适用场景：对延迟敏感的应用，Kubernetes 环境

架构 3：Service Mesh 集成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌─────────────────────────────┐
│      Service Mesh           │
│  ┌──────────────────────┐   │
│  │   Control Plane      │   │
│  │  (Istio/Linkerd)     │   │
│  └──────────┬───────────┘   │
│             │               │
│  ┌──────────▼───────────┐   │
│  │   Data Plane         │   │
│  │  (Envoy Proxy)       │   │
│  │  + AI Gateway Filter │   │
│  └──────────┬───────────┘   │
└─────────────┼───────────────┘
              │
┌─────────────▼─────┐
│    LLM 服务        │
└───────────────────┘

优点：统一的流量管理，复用 Service Mesh 能力
缺点：复杂度高，需要 Service Mesh 基础设施

适用场景：已有 Service Mesh 的企业，需要统一的流量治理

主流 AI 网关方案对比

方案 类型 核心特性 适用场景
Envoy AI Gateway 开源 CNCF 项目，基于 Envoy，支持 MCP Kubernetes 环境，需要高度定制
Kong AI Gateway 开源/商业 插件生态丰富，易于扩展 已有 Kong 的企业
APISIX AI Gateway 开源 高性能，插件化 高并发场景
Cloudflare AI Gateway 商业 托管服务，全球 CDN 快速上手，无需运维
Portkey AI Gateway 开源/商业 功能全面，可观测性强 需要完整的 AI 可观测性
LiteLLM 开源 轻量级，易于集成 小型项目，快速原型

选型建议：

  • 快速验证：Cloudflare AI Gateway（托管服务，5 分钟上手）
  • 生产环境（K8s）：Envoy AI Gateway（CNCF 项目，社区活跃）
  • 已有 Kong：Kong AI Gateway（复用现有基础设施）
  • 完整可观测性：Portkey（内置丰富的监控和分析）

实践案例：构建企业级 AI 网关

场景描述

某企业需要：

  • 统一管理 3 个 LLM 提供商（OpenAI、Anthropic、本地 vLLM）
  • 控制每月 Token 成本在 $10,000 以内
  • 防止 Prompt 注入和不安全输出
  • 追踪每个部门的 Token 消耗
  • 实现模型的灰度发布

架构设计

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: AIGateway
metadata:
  name: enterprise-ai-gateway
spec:
  # 1. 多模型路由
  rules:
  - match:
      model: "gpt-4"
    backend:
      type: OpenAI
      endpoint: "https://api.openai.com/v1"
      apiKeySecret: openai-key
  - match:
      model: "claude-3"
    backend:
      type: Anthropic
      endpoint: "https://api.anthropic.com/v1"
      apiKeySecret: anthropic-key
  - match:
      model: "local-llama"
    backend:
      type: vLLM
      endpoint: "http://vllm-service:8000/v1"

  # 2. Token 限流与配额
  rateLimit:
    type: TokenBased
    rules:
    - match:
        header: "x-department"
      limit:
        tokens: 1000000  # 每个部门每月 100 万 tokens
        period: monthly

  # 3. 内容安全
  filters:
  - type: PromptInjectionDetection
    config:
      action: reject
  - type: ContentFilter
    config:
      categories: [hate, violence, self-harm]
      action: mask

  # 4. 语义缓存
  cache:
    type: Semantic
    config:
      embeddingModel: "text-embedding-ada-002"
      similarityThreshold: 0.95
      ttl: 3600  # 1 小时过期

  # 5. 可观测性
  observability:
    metrics:
      enabled: true
      exportTo: prometheus
    tracing:
      enabled: true
      exportTo: jaeger
    logging:
      enabled: true
      exportTo: elasticsearch

实施效果

成本节约：

  • 语义缓存命中率：35%
  • 月 Token 消耗：从 1500 万降至 975 万（-35%）
  • 月成本：从 $15,000 降至 $9,750（-35%）

安全提升：

  • 拦截 Prompt 注入攻击：127 次/月
  • 过滤不安全输出：45 次/月
  • PII 脱敏：234 次/月

性能优化：

  • 平均延迟：从 2.8s 降至 1.9s（-32%）
  • 缓存命中延迟：< 100ms

可观测性：

  • 100% 请求追踪
  • 按部门生成详细账单
  • 实时成本告警

最佳实践与建议

1. 分阶段实施

阶段 1：基础接入（0-1 个月）

  • 部署 AI 网关，统一接入多个 LLM
  • 实现基础路由和故障回退
  • 收集 Token 消耗数据

阶段 2：成本控制（1-3 个月）

  • 实施 Token 限流和配额管理
  • 引入语义缓存，降低成本
  • 建立成本监控仪表盘

阶段 3：安全加固（3-6 个月）

  • 启用 Prompt 注入检测
  • 实施内容过滤和 PII 脱敏
  • 建立安全告警机制

阶段 4：高级功能（6-12 个月）

  • 实现模型灰度发布和 A/B 测试
  • 集成完整的可观测性（Metrics、Logs、Traces）
  • 优化路由策略（按成本、延迟、能力）

2. 关键决策点

自建 vs 采购：

因素 自建（开源） 采购（商业）
成本 低（仅基础设施） 高（按用量计费）
定制性 高（完全可控） 低（受限于产品功能）
运维 高（需自行维护） 低（托管服务）
上手速度 慢（需开发） 快（即开即用）

建议：

  • 小型团队/快速验证：采购商业方案（Cloudflare、Portkey）
  • 大型企业/高度定制：自建开源方案（Envoy、Kong）

缓存策略：

策略 相似度阈值 TTL 适用场景
保守 0.98 1 小时 准确性要求高
平衡 0.95 6 小时 通用场景
激进 0.90 24 小时 成本敏感

建议：从保守策略开始，逐步调整阈值，监控缓存命中率和用户满意度。

3. 常见陷阱

陷阱 1：过度依赖缓存

  • 问题：缓存命中率过高，导致模型无法获取新数据
  • 解决：设置合理的 TTL，定期清除缓存

陷阱 2：安全策略过严

  • 问题：误拦截正常请求，影响用户体验
  • 解决：从宽松策略开始，逐步收紧，监控误报率

陷阱 3：忽视可观测性

  • 问题：上线后无法追踪问题，成本失控
  • 解决：从第一天就建立完整的可观测性

陷阱 4：单一模型依赖

  • 问题：某个 LLM 提供商故障，导致服务不可用
  • 解决：配置多个备用模型，实施故障回退

总结

AI 网关是 AI 原生基础设施的关键组件，它解决了 LLM 和 Agent 场景下的流量治理、成本控制、安全防护和可观测性等核心问题。

核心价值：

  1. 统一接入：屏蔽多模型差异，提供统一 API
  2. 成本控制：Token 计量、限流、语义缓存，降低 30-50% 成本
  3. 安全防护：Prompt 注入检测、内容过滤、PII 脱敏
  4. 可观测性：完整的追踪、指标、日志，支持成本分析和性能优化
  5. 灵活路由：智能路由、灰度发布、故障回退

实施建议：

  • 分阶段推进：从基础接入到高级功能，逐步演进
  • 工具选型：小型团队用商业方案，大型企业用开源方案
  • 安全优先：从第一天就建立安全策略和可观测性
  • 持续优化：监控缓存命中率、成本、延迟，持续调优

AI 网关不是可选项，而是 AI 原生应用的必需品。没有 AI 网关，AI 服务就像没有 API 网关的微服务——混乱、不可控、成本失控。

参考文献

许可协议

本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。