工程答案
AI Gateway 与 API Gateway 有什么区别？
API Gateway 通过认证、路由、限流、策略和可观测管理通用服务流量。AI Gateway 把类似控制用于模型调用，并增加 canonical 模型 ID、供应商选择、token 用量、流式事件、工具续轮、多模态载荷和 AI 专用故障切换等模型感知能力。有些产品把两层合在一起，另一些团队会把专用 AI Gateway 放在现有 API Gateway 之后。
最后复核 2026-08-15 · 编辑复核: KeepRouter Editorial
两者确实重叠，但处理的流量不同
| 关注点 | 通用 API Gateway | AI Gateway |
|---|---|---|
| 调用方认证 | API Key、OAuth、mTLS 或签名请求 | Gateway Key，加模型与端点权限范围 |
| 路由目标 | 服务、版本、区域或上游 | 模型 ID、供应商线路、端点族或回退 |
| 用量单位 | 请求数、字节与时长 | 请求数，加输入、输出、缓存 token 或生成资产 |
| 流式 | 通用 HTTP 或事件流 | 模型专用 SSE、部分输出与终止用量 |
| 策略 | 速率、身份、网络与 Schema | 模型白名单、消费上限、提示词或响应控制 |
| 失败处理 | 在服务实例间重试 | 只在模型能力与副作用边界内重试或切换 |
普通网关可以代理模型 HTTP 流量，但不会自动理解 token 计量、工具调用状态、模型能力、供应商错误，或 Chat Completions 与 Responses 的差别。AI Gateway 可以实现这些模型感知能力，但每个产品的具体范围并不相同。
三种常见架构
- 只使用专用 AI Gateway。 小团队把 SDK 指向托管模型网关，由服务方负责模型访问与计费。
- 在 AI Gateway 前保留 API Gateway。 外层处理企业身份、网络策略与租户准入，内层处理模型、token 和供应商线路。
- 在现有网关内安装 AI 插件。 平台团队为 Kong、Envoy 等网关增加模型感知插件，把数据面留在自己的基础设施里。
正确安排取决于谁已经负责流量策略。如果 API 平台团队已有成熟的身份与网络控制，用另一个公共入口替换它们可能制造重复策略。如果小型产品团队没有网关平台，只为模型调用运营一套基础设施也可能不划算。增加服务前先阅读什么时候需要 AI Gateway。
合并两层前需要回答的问题
写清哪一层认证最终用户、哪个 Key 能到达模型网关、租户与功能标识在哪里附加，以及哪个系统负责速率和消费上限。明确提示词内容可以在哪里记录，并保证请求 ID 能穿过两层。两个面板使用不同请求 ID，会显著拖慢故障处理。
还要检查超时。通用 API Gateway 可能在长模型响应或流式会话完成前关闭连接；请求与响应大小限制也可能拒绝图像 block 或长上下文，即使模型线路本身支持它们。AI Gateway 安全答案说明信任边界，API 可观测功能则解释 KeepRouter 的证据面。
保持契约收敛
如果实现只支持一种操作，不要宣传成万能 AI 端点。Chat Completions、Responses、Messages、向量、图像与音频都应分别记录。好的网关会让这些边界更容易核验，而不是用“通用代理”几个字把它们藏起来。
常见问题
普通 API Gateway 可以代理 LLM 调用吗？
可以，但通用代理本身不会增加模型目录、token 计量、供应商感知路由或模型专用流处理。
需要同时使用两种网关吗？
只有两层具有不同负责人和策略时才需要。许多小团队只需一个专用层，大型平台则可能在前面保留企业流量控制。
哪一层应该执行消费上限？
选择一个权威层，并核对其模型用量证据。两套独立限额会产生难以解释的失败。
可以把 AI Gateway 放在 Kong 或 Cloudflare 后面吗？
通常可以，但需要同时配置两层的超时、流式、请求体大小、身份和日志策略。
AI Gateway 只处理 LLM 文本吗？
不是。有些网关支持图像、向量、音频等模态，但每种操作都需要明确路由与能力核验。