X记录空间前言
无论是开发一个 AI Chat 产品，还是搭建企业内部 AI 平台，几乎都会遇到同一个问题：
如何统一管理所有 AI 模型请求？
很多团队初期的架构通常是这样的：
Web
↓
Node.js
↓
OpenAI API
这种架构在 Demo 阶段非常简单。
但随着业务的发展，问题会越来越多：
- 接入多个模型（OpenAI、Claude、Gemini 等）
- 不同用户使用不同模型
- API Key 数量不断增加
- 需要统计 Token 消耗
- 限流、鉴权、日志越来越复杂
- 希望支持模型切换而不修改业务代码
如果所有逻辑都直接写在业务代码中，系统很快就会变得难以维护。
因此，大多数成熟 AI 产品都会引入一个新的组件：
AI API Gateway（AI 网关）。
它不是简单的反向代理，而是整个 AI 系统的流量入口。
什么是 AI API Gateway？
可以把 AI Gateway 理解成：
模型与业务之间的中间层。
推荐架构：
Web
↓
Gateway
↓
Auth
↓
Rate Limit
↓
Router
↓
Provider
↓
OpenAI
Claude
Gemini
业务代码永远只调用 Gateway。
Gateway 再决定：
最终请求哪个模型。
这样最大的好处就是：
业务和模型解耦。
以后新增模型时，不需要修改前端和业务逻辑。
Gateway 应该负责什么？
很多团队把 Gateway 当成：
HTTP 转发。
这是远远不够的。
一个成熟 Gateway 至少需要负责：
认证
例如：
- JWT
- API Key
- OAuth
确保请求来自合法用户。
模型路由
例如：
普通用户：
gpt-4.1-mini
企业用户：
gpt-4.1
代码生成：
Claude
图像任务：
GPT Image
业务层无需关心这些规则。
Token 统计
每一次请求都应该记录：
- 输入 Token
- 输出 Token
- 模型名称
- 用户 ID
- 请求耗时
- 是否成功
这些数据不仅用于计费，也用于后续优化。
限流
避免：
某一个用户一分钟发起几百次请求。
推荐：
- 用户限流
- IP 限流
- API Key 限流
结合 Redis 实现。
日志
至少记录：
request id
model
latency
status
tokens
provider
发生异常时，才能快速定位问题。
为什么不要把 Provider 写死？
错误示例：
const client = new OpenAI(...)
整个系统都依赖一个 SDK。
未来如果切换模型：
几乎所有代码都要修改。
更好的方式是抽象 Provider：
Provider
↓
OpenAI
Claude
Gemini
Gateway 负责统一接口。
业务永远只依赖：
Provider Interface。
如何设计统一请求结构？
不同模型：
参数名称并不完全一样。
例如：
有的使用：
temperature
有的：
支持：
top_p
还有：
推理模型。
图像模型。
Embedding。
因此：
Gateway 应定义：
统一 Request。
例如：
{
"model": "...",
"messages": [],
"stream": true
}
内部再转换成：
不同 Provider 的格式。
Streaming 如何设计？
Streaming 不应该直接透传。
建议：
Gateway：
统一：
SSE。
以后：
即使底层 Provider 更换。
前端：
也无需修改。
这是很多大型 AI 平台采用的方式。
熔断机制
如果：
OpenAI：
突然不可用。
Gateway：
应该：
自动切换：
备用 Provider。
而不是：
全部请求失败。
例如：
OpenAI
↓
失败
↓
Claude
↓
Gemini
这就是：
Failover。
为什么 Gateway 是 AI 平台的核心？
随着模型越来越多。
真正复杂的。
已经不是：
Prompt。
而是：
模型治理。
Gateway：
负责：
路由。
日志。
监控。
限流。
认证。
成本控制。
未来几乎所有 AI SaaS 都会拥有自己的 AI Gateway。
总结
AI Gateway 并不是一个简单的代理服务器。
它更像 AI 平台的大脑。
真正优秀的 Gateway，不仅能转发请求，更能统一模型管理、控制成本、提高稳定性，并为后续扩展提供坚实基础。
