LLM Proxy 与 AI Gateway：架构、控制与取舍

LLM Proxy 与 AI Gateway 可以位于同一个网络位置，但它们承担的职责并不一定相同。Proxy 主要负责转发模型请求与响应；AI Gateway 通常还会增加模型感知能力，例如路由策略、回退、用量记录、成本归因以及工作负载级访问控制。

这些名称不是统一标准。有些产品把具备模型感知能力的 Gateway 称为“Proxy”，也有产品只提供一个托管端点，却使用“Gateway”这一名称。可靠的选择方法不是看产品标签，而是比较实际需要的职责、能够验证的行为，以及如果不使用这一层，应用团队必须自行建设和维护哪些能力。

从职责出发，而不是从产品名称出发

这两类组件通常都位于应用和一个或多个模型提供商之间：

应用或 Coding Agent
        ↓
LLM Proxy 或 AI Gateway
        ↓
模型提供商与所选模型

仅凭这张图无法判断中间层实际做了什么。更有效的评估方式，是先建立职责矩阵。

职责	以传输为主的 LLM Proxy	具备模型感知能力的 AI Gateway
TLS 终止和 HTTP 转发	常见	常见
上游 URL 和 Header 处理	常见	常见
转发流式响应	通常支持	通常支持，但仍需验证具体事件契约
隔离模型提供商凭据	部分支持	较常见，但必须验证存储和访问边界
OpenAI 兼容请求入口	部分支持	较常见，但兼容范围随模型和功能变化
模型或提供商感知路由	有限，或由应用负责	常见
重试和有序回退策略	最多提供基础上游重试	通常能感知模型和失败类型
按工作负载限速或限额	通常由外部系统负责	常见
Token、用量和成本记录	通常由外部系统负责	常见
单请求延迟诊断	通常由外部系统负责	常见
策略与审计控制	通常由外部系统负责	取决于具体产品

“常见”并不等于“保证支持”。对于每一项关键职责，都应该核对确切的请求契约、失败行为、系统产生的记录，以及运营人员可以配置的控制项。

LLM Proxy 通常负责什么

当主要目标是在上游 API 前提供一个稳定入口时，以传输为主的 Proxy 可能已经足够。它可以统一 TLS、上游主机名、部分 Header、请求大小限制、超时和基础日志。针对 LLM 的 Proxy 还可能理解 Server-Sent Events，从而在不缓冲的情况下转发流式响应。

这些仍然是有价值的基础设施。它为应用提供可控的网络路径，也可以避免某些客户端环境直接接触模型提供商凭据，并为传统鉴权和网络策略提供统一位置。

当 Proxy 开始转换请求格式、选择提供商、统计模型 Token 或计算单请求成本时，边界就会变得模糊。这些已经属于模型感知行为。即使产品名称仍然使用“Proxy”，也应该按照 Gateway 的标准进行评估。

以下情况通常更适合从简单 Proxy 开始：

• 一个应用只使用一个提供商和少量固定模型；
• 应用已经自行负责重试、用量核算和事故诊断；
• 必须原样透传提供商原生功能，不能经过协议转换；
• 不需要按团队或工作负载设置路由策略；
• 团队希望中间层尽可能精简。

AI Gateway 增加了什么

AI Gateway 不会把模型请求只当成普通 HTTP 流量。它可以结合请求模型、协议、API Key 策略、分组可用性、限额以及此前尝试结果，决定请求应该走向哪个路径；请求完成后，还可以把最终尝试与 Token 用量、时序、状态和成本记录关联起来。

不同产品的能力范围并不一致。例如，Cloudflare AI Gateway 文档把分析、日志、缓存、限流、重试和回退纳入 Gateway；Kong 的 AI Gateway 指标文档则介绍了模型、Token、成本、缓存、延迟和错误指标。这些例子说明“Gateway”通常意味着具备 AI 感知能力的控制层，但它们并没有定义一个通用的最低标准。

当以下多项需求同时出现时，AI Gateway 的价值会更加明显：

• 多个应用或 Agent 需要使用可分别归因的 API Key；
• 同一请求模型可以通过多个合格路径提供；
• 限额必须在上游产生工作量或成本之前生效；
• 运营人员需要区分鉴权、路由、等待上游、首次有效输出和生成阶段；
• 模型用量和最终扣费必须能够按请求解释；
• 主路径需要明确且有序的回退策略；
• 团队需要在同一运营视图中观察多个模型分组。

Gateway 不会让所有提供商自动变得可以互换，也不会免除应用侧的职责。应用仍需验证模型输出、保证工具执行幂等、保护应用中的秘密，并测试提供商特有功能。

使用工作负载决策矩阵

与仅根据产品分类做选择相比，下面的工作负载矩阵更有参考价值。

工作负载	核心需求	合理的起始层	原因
内部服务只使用一个提供商和一个模型	稳定网络路径	直连 API 或轻量 Proxy	路由和成本控制层可能增加的复杂度大于收益。
面向客户的应用，同一模型存在多条合格路径	可用性与尝试记录	AI Gateway	路由选择、有界回退和逐次诊断需要统一 owner。
工程团队统一使用 Coding Agent	Key、额度、用量归因和离职回收	AI Gateway	共享提供商 Key 和无法归属的消耗会成为运营风险。
应用需要新的提供商原生功能	精确 Wire Contract	先使用原生端点，再接入经过验证的 Proxy 或 Gateway	统一协议可能暂未覆盖或会丢失提供商特有字段。
批处理任务已经拥有自己的队列与重试控制器	吞吐和应用侧恢复	关闭或限制重试的 Proxy/Gateway	多层重试会放大故障并重复执行任务。
受监管或包含敏感数据的工作负载	数据路径、保留和访问证据	取决于经过验证的控制能力	“Gateway”这个名称本身不能证明安全或合规边界。

随着工作负载成熟，选择也可以变化。应用先直连一个提供商，之后再引入 Gateway 是合理路径，前提是应用保留清晰的模型客户端边界，并对迁移契约进行验证。

计算容易被忽略的代价

新增的一跳必须测量

Proxy 或 Gateway 会增加网络和处理层，不能只用一个平均延迟描述其代价。应当在真实并发下分别测量上游响应头、首次有效输出、适用时的首段可见文本、总耗时和输出速度。Gateway 即使增加了少量固定开销，也可能缩短运营恢复时间，但这属于具体工作负载的取舍，不能写成普遍性能结论。

兼容性必须按功能验证

“OpenAI 兼容”可能只覆盖 Base URL、鉴权 Header 和 Chat Completions 请求，却在 Responses 事件、结构化输出、工具调用、用量字段或错误结构上存在差异。应用使用的每个功能都需要单独测试。OpenAI 兼容 API 指南提供了迁移基线；Responses API 与 Chat Completions解释了为什么不能仅凭端点推断完整兼容性。

集中化也会形成故障域

把 Key、路由、限额和日志集中到一个层，可以简化职责，但也会让这一层变得关键。需要了解配置如何版本化和回滚、控制面不可用时会发生什么，以及运营配置变化时，已经开始的请求能否正常完成。

成本记录需要明确的真相来源

部分 Gateway 根据提供商公开价格估算成本；另一些使用配置价格、分组倍率或记录下来的计费表达式。需要确认价格在什么时间点确定、是否为单次请求冻结、缓存 Token 和工具费用如何表示，以及最终扣费是否能追溯到实际用量。AI API 成本追踪介绍了应当保持独立的成本层次。

退出成本同样重要

在采用统一请求入口之前，应识别应用代码中哪些部分依赖 Gateway 专用 Header、模型别名、路由名称或日志 API。好的 Gateway 应该让当前路径更容易运营，而不是让底层协议变得无法恢复。

三个实际场景

单一提供商的内部助手

某个内部助手只向一个固定模型发送中等数量的非流式请求。应用已经记录自己的任务 ID，并由服务端持有一个提供商 Key。在这种情况下，传统 Proxy 可能已经足够；增加跨提供商路由和独立成本控制层，并没有解决当前实际问题。

架构仍应保留以后引入 Gateway 的空间：把模型客户端封装在统一的内部接口之后，保留提供商请求 ID，并避免浏览器或桌面客户端直接接触提供商 Key。

多路径生产应用

面向客户的应用希望某个上游账号饱和时，请求的目标模型仍然可用；团队还需要知道最终由哪个路径处理请求，以及哪次尝试产生了成本。这属于 Gateway 场景，因为回退、计费和诊断需要共享同一个请求身份。

回退应保持请求契约。切换到另一个模型可能改变质量、延迟、工具行为或价格，因此应该成为明确的产品策略，而不是不可见的恢复捷径。可靠的 AI API 路由指南介绍了有序分组和单请求证据之间的关系。

工程团队统一使用 Coding Agent

Coding Agent 可能从多台开发者设备发起较长且工具密集的会话。共享一个提供商 Key 会让额度、归因、轮换和离职回收变得困难。Gateway 可以签发按工作负载区分的 Key、限制访问、把用量关联到团队或项目，并提供统一的故障检查入口。

Gateway 仍无法判断一次工具操作是否安全，也不能证明生成的补丁正确。仓库权限、沙箱、工具审批和代码验证依然属于模型路由层之外的职责。

Modelflare 位于哪一层

Modelflare 的定位是提供具备 AI 感知能力的访问与路由层，而不仅是透明 HTTP Relay。普通 API Key 可以选择一个主模型分组以及有序的回退分组；Smart API Key 可以按配置策略评估合格分组。两种方式都是为请求的模型寻找合格路径，不应该静默替换成另一个模型。

分组 RPM 会针对实际选中的分组执行，并且发生在计费和上游请求之前。当该分组已满时，系统可以继续考虑下一个合格分组；如果不存在剩余路径，请求返回 429。这使路由容量决策与已经发送到上游的工作量相互分离。

用量日志会把完成的请求与状态、Token 用量、成本和时序元数据关联。时序字段能够区分鉴权、分组选择、上游响应头、首个上游事件、首次有效输出、首段可见文本、上游完成和 Handler 总时长，而且无需把 Prompt、响应正文、完整 API Key 或原始请求 Body 放入时序记录。

这里还有一项重要兼容边界：GPT、Codex 和 OpenAI 流量是完整适配目标；其他 OpenAI 兼容模型家族应当视为原始 Chat Completions 透传，除非其额外行为已经单独验证。因此，共享 Base URL 并不代表每个模型都拥有相同的 Responses、工具或结构化输出契约。

可以通过模型与价格查看当前公开的模型和分组，并在 Modelflare Docs 中查找不同客户端的配置方法。

生产评估清单

选择任一层之前，都应测试应用真正依赖的行为。

• **协议：**是否保留应用实际使用的请求和响应结构？
• **流式：**是否能在不缓冲、不丢失、不打乱工具参数顺序的情况下转发事件？
• **模型身份：**路由变化时，是否能避免静默更换请求模型？
• **回退：**哪些失败可以触发回退、会发生多少次尝试、什么时候停止重试？
• **限额：**限速和额度判断是否发生在上游工作和计费之前？
• **用量：**适用时，能否准确表示输入、输出、缓存、推理和工具用量？
• **成本：**记录的扣费是否与本次请求使用的价格和路径关联？
• **诊断：**运营人员能否区分 Gateway 处理、等待上游、首次输出和生成速度？
• **秘密：**谁可以读取提供商凭据、请求正文和响应正文？
• **变更控制：**路由和策略变更是否可以审查和回滚？
• **退出路径：**应用能否在不重写的情况下返回提供商原生端点？

执行这份清单时，应保持模型、Prompt 类型、输出长度、流式模式、工具、区域和真实并发一致。一次成功的“Hello World”只能证明端点可达，不能证明具备生产兼容性。

常见问题

所有 OpenAI 兼容 Proxy 都是 AI Gateway 吗？

不是。OpenAI 兼容描述的是请求入口的某一部分，而 Gateway 描述的是运营职责。Proxy 可以提供 OpenAI 形状的端点，却不负责路由、成本、限额或诊断。

AI Gateway 会彻底消除提供商 Key 吗？

不一定。有些 Gateway 代管提供商凭据，有些采用 BYOK，还有一些建立自己的计费关系。必须确认凭据存放在哪里，以及谁有权使用或导出。

AI Gateway 会让请求更快吗？

不会自动变快。它增加了一跳，但可能带来更好的路径可用性和更清晰的诊断。应该针对自己的工作负载测量完整请求时序，而不是依赖泛化的延迟宣传。

回退是否应该选择另一个模型？

只有应用明确接受这一取舍时才应该这样做。更安全的默认方式，是为请求的模型和协议寻找另一条合格路径。跨模型替换需要单独的质量、兼容性、延迟和价格策略。

因此，实际区别可以归纳为：如果主要需要一条受控的传输路径，选择 Proxy；如果模型感知路由、工作负载策略、用量、成本和请求证据需要由一个明确 owner 负责，则选择 AI Gateway。无论使用哪个名称，都需要逐项验证这些职责，因为产品标签本身不是证据。