网关这扇门，不够用了

API 网关是微服务架构的"前门"。所有的请求都要经过网关，由网关负责路由、认证、限流、协议转换。这个模式用了十几年，一直很稳定。

但到了 AI 时代，这扇门开始扛不住了。

当你的系统里不只有微服务，还有大模型；当你的流量不只有 HTTP 请求，还有流式响应；当你的计费不只有请求次数，还有 Token 消耗——传统的 API 网关就显得力不从心了。

这不是网关的问题，而是时代变了。AI 应用带来了全新的需求，需要新一代的网关来承载。

API 网关的三代演进

第一代：反向代理（2010-2015）

最早的"网关"其实就是反向代理。Nginx、HAProxy 这些工具，做的事情很简单：

• 接收外部请求
• 根据路由规则转发到后端服务
• 返回响应

这个阶段的网关，核心能力是路由。

典型场景：前面一个 Nginx，后面几十个微服务，Nginx 根据 URL 路径把请求分发到不同的服务。

第二代：API 管理（2015-2023）

随着微服务架构的普及，简单的反向代理不够用了。企业需要：

• 认证授权：谁能访问哪个 API？
• 流量控制：每个用户每分钟能调用多少次？
• 协议转换：HTTP 转 gRPC，REST 转 GraphQL
• 监控分析：API 的调用量、延迟、错误率

于是出现了 Kong、Apigee、Tyk 这些 API 管理平台。它们不只是转发请求，还做了大量的管控工作。

这个阶段的网关，核心能力是管控。

第三代：AI 网关（2024-）

到了 AI 时代，需求又变了。当你的系统里开始调用大模型 API，你会发现：

• 模型有几十个，怎么选？
• Token 怎么计费？每个用户能用多少？
• 流式响应（SSE）怎么处理？
• Prompt 怎么审计？有没有敏感信息？
• 模型响应慢，怎么做负载均衡？

这些问题，传统的 API 网关解决不了。需要专门的 AI 网关。

这个阶段的网关，核心能力是智能。

三代对比

传统网关做了什么

在聊 AI 网关之前，先回顾一下传统 API 网关的核心能力。这些能力在 AI 时代依然重要，只是不够了。

路由

最基础的能力。根据请求的 URL、Header、参数，把请求转发到不同的后端服务。

1
2
3
4
5
6
7
8

# Kong 路由配置示例
routes:
  - name: user-service
    paths: ["/api/users"]
    service: user-service
  - name: order-service
    paths: ["/api/orders"]
    service: order-service

限流

防止某个用户或某个 API 被过度调用。

1
2
3
4
5
6

# 限流配置示例
plugins:
  - name: rate-limiting
    config:
      minute: 100
      policy: local

认证

验证请求的合法性，比如 API Key、OAuth Token、JWT。

1
2
3
4
5

# JWT 认证配置
plugins:
  - name: jwt
    config:
      key_claim_name: kid

协议转换

在不同的协议之间转换，比如 HTTP 转 gRPC。

监控

收集 API 的调用量、延迟、错误率等指标，用于监控和分析。

这些能力都很重要，但它们解决的是"传统微服务"的问题。当系统里开始调用大模型，新的问题就来了。

AI 时代网关面临的新挑战

挑战一：模型路由

传统微服务的路由很简单：根据 URL 路径转发到对应的服务。但大模型不一样，你可能有几十个模型：

• GPT-4、GPT-3.5、Claude、Gemini、Llama、Qwen……
• 不同模型的能力不同、成本不同、延迟不同

问题来了：当用户发起一个请求，应该路由到哪个模型？

如果按传统方式，写死路由规则：

1
2
3
4
5

routes:
  - name: gpt4
    paths: ["/api/gpt4"]
  - name: gpt35
    paths: ["/api/gpt35"]

这样用户需要自己选择模型，体验很差。更好的方式是智能路由：根据请求的内容、用户的需求、模型的负载情况，自动选择最合适的模型。

挑战二：Token 限流

传统 API 的限流是按请求次数：每分钟 100 次。但大模型的计费是按 Token：输入 Token + 输出 Token。

一个请求可能消耗 100 个 Token，也可能消耗 10000 个 Token。按请求次数限流没有意义。

需要的是 Token 级别的限流：

• 每个用户每月能用多少 Token
• 每个 API Key 每天能用多少 Token
• 超出配额后怎么处理（降级、拒绝、排队）

挑战三：流式响应

大模型通常支持流式响应（Streaming），用 Server-Sent Events (SSE) 逐步返回结果。

传统的 API 网关不太擅长处理流式响应：

• 流式响应是长连接，传统网关的超时机制会中断连接
• 流式响应的内容分块返回，传统的日志记录方式不适用
• 流式响应需要特殊的错误处理机制

挑战四：成本控制

大模型的调用成本远高于传统 API。一个复杂的 Prompt 可能花费几美元，如果没有限制，成本会失控。

需要：

• 实时监控 Token 消耗和成本
• 设置预算上限
• 按部门、按项目分摊成本
• 优化 Prompt，降低成本

挑战五：安全审计

大模型的输入（Prompt）和输出（Completion）可能包含敏感信息：

• 用户输入的 Prompt 可能包含个人隐私
• 模型输出的内容可能不准确或有误导性
• 某些场景需要审计所有的交互记录

传统网关的日志记录不够细，需要专门的 Prompt 审计能力。

AI 网关的核心能力

AI 网关是为了解决上面这些挑战而生的。它有几个核心能力：

1. 智能路由

智能路由不是简单的 URL 匹配，而是根据多个维度做决策：

按模型能力路由

不同类型的请求，适合不同的模型。比如：

• 复杂的推理任务 → GPT-4、Claude
• 简单的问答 → GPT-3.5、Llama
• 代码生成 → CodeLlama、StarCoder

按成本路由

如果多个模型都能完成任务，选择成本最低的。比如：

• 简单任务：优先用 GPT-3.5（便宜）
• 复杂任务：才用 GPT-4（贵）

按延迟路由

如果用户对延迟敏感，选择响应最快的模型。比如：

• 实时对话：优先用延迟低的模型
• 批量处理：可以用延迟高但质量好的模型

按负载路由

如果某个模型的请求队列太长，自动切换到其他模型，实现负载均衡。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# 智能路由伪代码
def route_request(request):
    # 分析请求的复杂度
    complexity = analyze_complexity(request.prompt)
    
    # 根据复杂度选择候选模型
    if complexity > 0.8:
        candidates = ["gpt-4", "claude-3"]
    else:
        candidates = ["gpt-3.5", "llama-3"]
    
    # 根据成本和延迟排序
    candidates.sort(key=lambda m: get_cost(m) * 0.6 + get_latency(m) * 0.4)
    
    # 选择负载最低的模型
    best_model = min(candidates[:3], key=lambda m: get_queue_length(m))
    
    return best_model

2. Token 级计量与配额

AI 网关需要精确计量每个请求的 Token 消耗：

输入 Token 计量

记录每个请求的 Prompt 消耗了多少 Token。

输出 Token 计量

记录每个请求的 Completion 消耗了多少 Token。对于流式响应，需要累加所有分块的 Token。

配额管理

为每个用户、每个 API Key、每个部门设置 Token 配额：

1
2
3
4
5
6
7

# Token 配额配置示例
quotas:
  - user: "user_123"
    daily_limit: 100000  # 每天 10 万 Token
    monthly_limit: 2000000  # 每月 200 万 Token
  - department: "engineering"
    monthly_limit: 10000000  # 每月 1000 万 Token

当配额用尽时，可以：

• 拒绝请求
• 降级到更便宜的模型
• 排队等待

3. Prompt 审计与安全

AI 网关需要审计所有的 Prompt 和 Completion：

敏感信息检测

自动检测 Prompt 中是否包含敏感信息（PII、密码、密钥），如果有，自动脱敏或拒绝。

内容过滤

过滤不合规的内容，比如暴力、色情、违法信息。

审计日志

记录所有的交互记录，包括：

• 请求时间
• 用户信息
• Prompt 内容
• Completion 内容
• 使用的模型
• Token 消耗
• 成本

这些日志可以用于合规审计、问题排查、成本分析。

4. 多模型负载均衡

当有多个模型可用时，AI 网关可以做负载均衡：

轮询

简单的轮询，把请求均匀分配到多个模型。

加权轮询

根据模型的能力、成本设置权重，按比例分配。

动态调整

根据模型的实时性能（延迟、错误率）动态调整权重。如果某个模型响应变慢，自动减少它的流量。

故障转移

如果某个模型故障，自动切换到备用模型，保证服务可用性。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 多模型负载均衡配置
load_balancing:
  models:
    - name: gpt-4
      weight: 0.3
      fallback: gpt-3.5
    - name: claude-3
      weight: 0.3
      fallback: gpt-3.5
    - name: gpt-3.5
      weight: 0.4
      fallback: llama-3

架构对比：传统网关 vs AI 网关

现在来做一个系统的对比：

架构差异

传统 API 网关架构

1
2
3

客户端 → API 网关 → 微服务 A
                  → 微服务 B
                  → 微服务 C

网关做的事情很简单：路由、认证、限流，然后转发到后端服务。

AI 网关架构

1
2
3
4
5
6
7

客户端 → AI 网关 → 智能路由 → 模型 A (GPT-4)
                             → 模型 B (Claude)
                             → 模型 C (Llama)
         ↓
    Token 计量
    Prompt 审计
    成本监控

AI 网关做的事情更多：智能路由、Token 计量、Prompt 审计、成本监控。

实际案例：某 SaaS 平台的网关迁移

背景

某 SaaS 平台提供智能客服服务，使用 Kong 作为 API 网关。2023 年开始集成大模型，为客户提供智能问答功能。

最初的做法很简单：在 Kong 后面加一个模型服务，所有的大模型请求都通过这个服务转发。

问题暴露

随着业务增长，问题逐渐暴露：

1. 成本失控

客户的使用量快速增长，但没有有效的成本控制机制。有些客户的 Prompt 很长，消耗大量 Token，但按请求次数计费，平台亏本。

2. 模型选择困难

平台接入了多个模型（GPT-4、GPT-3.5、Claude），但没有智能路由机制。所有请求都发到 GPT-4，成本高、延迟大。

3. 缺乏审计

客户投诉模型回答不准确，但平台没有完整的审计日志，无法排查问题。

4. 流式响应不稳定

Kong 对流式响应的支持不完善，经常出现连接中断、数据丢失。

迁移方案

2024 年初，平台决定迁移到专门的 AI 网关。经过评估，选择了 Portkey。

迁移步骤：

1. 并行运行：新旧网关同时运行，逐步切流
2. 配置迁移：把 Kong 的路由规则迁移到 Portkey
3. 功能验证：验证智能路由、Token 计量、Prompt 审计等功能
4. 全量切换：确认无问题后，全量切换到 Portkey

迁移效果

成本降低的原因：

• 智能路由：简单任务自动路由到 GPT-3.5，复杂任务才用 GPT-4
• Token 限流：防止客户过度使用
• Prompt 缓存：重复的 Prompt 直接返回缓存结果

延迟降低的原因：

• 智能路由：选择延迟最低的模型
• 负载均衡：避免单个模型过载
• 流式响应优化：Portkey 对 SSE 的支持更好

网关的未来：从流量入口到智能中枢

AI 网关不只是"支持大模型的 API 网关"，它代表了一种新的架构理念：网关从流量入口变成智能中枢。

趋势一：网关即 AI 编排层

未来的网关不只是转发请求，还会做复杂的 AI 编排：

• 把一个复杂任务拆分成多个子任务
• 调用多个模型，组合结果
• 做 RAG（检索增强生成），先检索再生成
• 做 Agent 编排，调用多个工具

这相当于把 AI 编排逻辑从应用层下沉到网关层。

趋势二：网关即数据层

AI 应用需要大量的上下文数据：用户画像、历史对话、知识库。未来的网关可能会集成向量数据库，直接在网关层做检索和上下文构建。

趋势三：网关即安全层

随着 AI 应用的普及，安全问题会越来越突出。未来的网关会成为 AI 安全的第一道防线：

• Prompt 注入检测
• 敏感信息过滤
• 输出内容审核
• 合规审计

API 网关的演进，反映了技术架构的演进。从反向代理到 API 管理，再到 AI 网关，每一次升级都是为了应对新的挑战。

AI 网关不是传统网关的替代品，而是补充。在未来的架构中，传统 API 网关和 AI 网关会并存：传统网关处理微服务流量，AI 网关处理大模型流量。

关键是理解自己的需求，选择合适的工具。如果你的系统里开始大量调用大模型，那么 AI 网关就不是可选项，而是必选项。

网关这扇门，该升级了。