工程答案
AI Gateway 与 API Gateway 有什么区别？
API Gateway 通过认证、路由、限流、策略和可观测管理通用服务流量。AI Gateway 把类似控制用于模型调用，并增加 canonical 模型 ID、供应商选择、token 用量、流式事件、工具续轮、多模态载荷和 AI 专用故障切换等模型感知能力。有些产品把两层合在一起，另一些团队会把专用 AI Gateway 放在现有 API Gateway 之后。
最后复核 2026-08-26 · 编辑复核: 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。
沿着完整链路查看一次请求
客户端 -> API Gateway -> 应用服务 -> AI Gateway -> 模型供应商
| 跳转 | 主要责任 | 应继续传递的标识 |
|---|---|---|
| 客户端到 API Gateway | 用户会话、租户准入与公开限流策略 | Trace ID 或 Request ID |
| API Gateway 到应用服务 | 服务路由、身份声明与网络策略 | Trace ID 加 Tenant ID |
| 应用服务到 AI Gateway | 任务上下文、批准模型与产品限额 | Trace ID 加 AI Request ID |
| AI Gateway 到供应商 | 模型线路、供应商凭证、用量与回退 | AI Request ID 加 Provider Request ID |
应用服务仍是两层网关之间有价值的边界。它可以把经过认证的用户请求转换成权限收敛的模型请求，不必把模型网关 Key 暴露给客户端。
部署选择矩阵
| 当前基础 | 通常最简单的方案 | 上线前检查 |
|---|---|---|
| 没有现成网关平台 | 服务端模型调用只使用一个专用 AI Gateway | Key 权限、端点支持、日志、消费上限与回滚 |
| 已有成熟 API Gateway 与平台团队 | API Gateway 保留在边缘，AI Gateway 放在应用之后 | 超时、流式、请求体限制、身份传递与重复限额 |
| 必须使用私有数据面或统一网关标准 | 增加模型感知插件或自托管 AI 层 | 供应商兼容、运维责任、升级与证据导出 |
| 单一供应商与稳定模型 | 先使用供应商 SDK，有明确控制需求后再加网关 | 不要在没有实测需求时增加一层 |
一个简短决策树就够了：如果企业身份和网络策略已经位于边缘，就保留在那里；如果模型路由、用量或故障切换需要独立负责人，再在应用之后增加 AI 层；如果两个条件都不成立，先写清需求再增加跳转。托管与自托管对比可以帮助确定数据面方案。
合并两层前需要回答的问题
写清哪一层认证最终用户、哪个 Key 能到达模型网关、租户与功能标识在哪里附加，以及哪个系统负责速率和消费上限。明确提示词内容可以在哪里记录，并保证请求 ID 能穿过两层。两个面板使用不同请求 ID，会显著拖慢故障处理。
还要检查超时。通用 API Gateway 可能在长模型响应或流式会话完成前关闭连接；请求与响应大小限制也可能拒绝图像 block 或长上下文，即使模型线路本身支持它们。AI Gateway 安全答案说明信任边界，API 可观测功能则解释 KeepRouter 的证据面。
关联一次请求，而不是来回查两个面板
| 层级 | 示例记录 |
|---|---|
| API Gateway | trace_id=req_7f2、tenant_id=team_42、status=200 |
| 应用服务 | trace_id=req_7f2、ai_request_id=ai_91c、feature=answer |
| AI Gateway | ai_request_id=ai_91c、model=approved-model-a、fallback=false、usage_total_tokens=1842 |
| 供应商适配层 | ai_request_id=ai_91c、provider_request_id=provider_abc、attempt=1 |
通过 Header 或结构化上下文传递标识，并把它们记录成字段，不要只写进自由文本。不要把提示词、Secret 或原始认证 Header 放入关联字段。测试时从客户端 Trace ID 开始，确认能够找到最终模型、用量、费用、延迟与供应商结果。可用网关延迟答案把两层网关跳转与模型生成时间分开。
保持契约收敛
如果实现只支持一种操作，不要宣传成万能 AI 端点。Chat Completions、Responses、Messages、向量、图像与音频都应分别记录。好的网关会让这些边界更容易核验，而不是用“通用代理”几个字把它们藏起来。
常见问题
普通 API Gateway 可以代理 LLM 调用吗？
可以，但通用代理本身不会增加模型目录、token 计量、供应商感知路由或模型专用流处理。
需要同时使用两种网关吗？
只有两层具有不同负责人和策略时才需要。许多小团队只需一个专用层，大型平台则可能在前面保留企业流量控制。
哪一层应该执行消费上限？
选择一个权威层，并核对其模型用量证据。两套独立限额会产生难以解释的失败。
可以把 AI Gateway 放在 Kong 或 Cloudflare 后面吗？
通常可以，但需要同时配置两层的超时、流式、请求体大小、身份和日志策略。
AI Gateway 只处理 LLM 文本吗？
不是。有些网关支持图像、向量、音频等模态，但每种操作都需要明确路由与能力核验。