API 网关的演进：从流量管控到 AI 网关的新一代架构设计

Thu, 09 Jul 2026 21:30:00 +0800

网关这扇门，不够用了

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 网关。

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

三代对比

维度	第一代：反向代理	第二代：API 管理	第三代：AI 网关
核心能力	路由	管控	智能
典型产品	Nginx、HAProxy	Kong、Apigee、Tyk	Portkey、LiteLLM、Helicone
流量类型	HTTP 请求	REST/gRPC	HTTP + SSE + WebSocket
计费维度	无	请求次数	Token 消耗
路由策略	静态规则	权重轮询	智能路由（能力/成本/延迟）
安全能力	基础认证	OAuth、JWT	Prompt 审计、内容过滤
监控维度	连接数、延迟	QPS、错误率	Token 用量、模型性能

传统网关做了什么

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

路由

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

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

限流

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

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

认证

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

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

协议转换

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

监控

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

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

AI 时代网关面临的新挑战

挑战一：模型路由

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

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

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

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

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（贵）

按延迟路由

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

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

按负载路由

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

# 智能路由伪代码
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 配额：

# 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 网关可以做负载均衡：

轮询

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

加权轮询

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

动态调整

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

故障转移

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

# 多模型负载均衡配置
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 网关	AI 网关
路由策略	URL 路径匹配	智能路由（能力/成本/延迟/负载）
限流维度	请求次数	Token 消耗
响应类型	同步响应	同步 + 流式响应（SSE）
计费方式	按请求次数	按 Token 消耗
安全能力	认证、授权	认证、授权 + Prompt 审计、内容过滤
监控维度	QPS、延迟、错误率	Token 用量、模型性能、成本
负载均衡	轮询、加权轮询	动态调整、故障转移、智能路由
协议支持	HTTP、gRPC、WebSocket	HTTP、gRPC、WebSocket + SSE
缓存策略	响应缓存	Prompt 缓存、语义缓存
典型产品	Kong、Apigee、Tyk	Portkey、LiteLLM、Helicone

架构差异

传统 API 网关架构

1
2
3

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

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

AI 网关架构

客户端 → 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。

迁移步骤：

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

迁移效果

指标	迁移前 (Kong)	迁移后 (Portkey)	改善
模型调用成本	$15,000/月	$9,500/月	-37%
平均延迟	3.2s	2.1s	-34%
流式响应成功率	87%	99%	+12%
审计覆盖率	30%	100%	+70%
客户满意度	3.8/5	4.5/5	+0.7

成本降低的原因：

智能路由：简单任务自动路由到 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 网关就不是可选项，而是必选项。

网关这扇门，该升级了。

AI网关 on 文艺技术笔记