推理网关模式：为什么每个生产环境 AI 团队都在构建同一套中间件

每个上线 LLM 功能的团队都会经历相同的演变曲线。一开始，你硬编码一个 OpenAI API 调用。然后加上重试逻辑。然后有人问你花了多少钱。然后某个周五下午供应商宕机了，于是你开始构建网关。

这并非偶然。推理网关是一种自然涌现的架构模式——应用与 LLM 提供商之间的中间件层，将限流、故障转移、成本追踪、提示词日志和路由整合到一个统一的关卡中。它是 AI 时代的负载均衡器，如果你在生产环境中运行模型，你要么已经有了一个，要么正在不知不觉中构建一个。

趋同问题

传统 API 网关处理确定性 HTTP 服务的请求路由、认证和限流。LLM 推理打破了这些网关赖以构建的每一个假设。

第一个问题是计费粒度。REST API 按请求或按席位收费。LLM 按 token 收费——输入 token 和输出 token 费率不同，缓存 token 又是另一个费率。一个请求的成本可能是 $0.001，也可能是$0.50，取决于上下文长度。你的 API 网关对此毫无概念。

第二个问题是流式传输。大多数生产环境的 LLM 调用使用服务器发送事件（SSE）向用户流式传输 token。传统网关将连接视为短暂的请求-响应周期。一个流式 LLM 响应可能保持连接打开 30 秒，同时逐步传递 token。按每秒请求数计数的限流器完全无法捕捉实际的资源消耗。

第三个问题是非幂等性。使用相同幂等键重试失败的支付 API 调用是安全的。重试失败的 LLM 调用意味着重新生成一个完全不同的响应——并为此支付两次费用。故障转移逻辑需要理解，LLM 语境下的"重试"与传统 API 中的重试具有不同的语义。

这三个特性——基于 token 的计费、长连接流式传输和非幂等响应——正是团队不能简单配置 nginx 或 Kong 就了事的原因。

网关实际做什么

推理网关向你的应用暴露一个统一且一致的 API（通常兼容 OpenAI），同时在后端管理多个提供商的复杂性。核心职责分为五个领域。

具备 token 感知的限流。 提供商的限流在组织或 API 密钥级别运作——每分钟请求数、每分钟 token 数、并发连接数。但企业需要按团队、按用户、按应用和按环境进行限制。网关在所有 API 密钥上追踪某个提供商的累计 token 消耗，并在接近限制时排队或重新路由请求。这与按请求计数的限流有本质区别。一个 100K 上下文的请求消耗的容量超过一千个短补全请求。

提供商故障转移和健康感知路由。 当你的主要提供商返回 429 或 5xx 错误时，网关自动路由到备用提供商。好的故障转移不仅仅是 DNS 切换——它在提供商之间转换请求格式，处理模型映射（Claude 的消息格式 vs. OpenAI 的 vs. Gemini 的），并尊重备用提供商自身的限流。生产网关实现带指数退避的熔断器，实时监控提供商健康状况，而不是等待你的应用浮现错误。

成本归因和追踪。 网关记录每个请求的 token 数量和模型标识符，生成跨所有提供商的实时成本仪表盘。这实现了内部成本分摊：你可以告诉工程部门搜索团队上个月在 Claude Opus 上花了 14,000 美元，而客服团队在 Haiku 上花了 3,200 美元。没有网关，你只能从每个提供商那里拿到一张没有按团队或功能拆分的账单。

提示词日志和可观测性。 每个请求和响应都流经网关，创建了一个天然的观测点。团队用此来调试生产问题、检测提示词注入尝试、监控响应质量退化，以及从真实流量中构建评估数据集。

A/B 路由和模型实验。 网关成为模型迁移的控制平面。想测试 Sonnet 4 是否比 GPT-4o 对你的摘要流水线效果更好？将 10% 的流量路由到新模型，比较延迟、成本和质量指标，然后逐步迁移流量。没有网关，这需要散布在各个服务中的应用级功能标志。

为什么现成的 API 网关不适用

我最常听到的反对意见是："我们已经有了 Kong / Envoy / AWS API Gateway。为什么不能加几个插件？"

你可以试试。以下是它崩溃的地方。

基于 token 的计量需要解析响应体（或 SSE 流）来计算 token。传统网关将响应体视为不透明的字节流。添加 token 计数意味着需要理解每个模型系列 tiktoken 编码的自定义插件——而这些编码随着每次模型发布都在变化。

成本计算需要一张将（提供商、模型、token 类型）映射到金额的价格表。这张表每隔几周就会随着提供商调整定价而改变。你的 API 网关限流配置不是为按月变化的定价模型设计的。

流式传输支持需要保持连接打开并处理增量数据块。许多 API 网关会缓冲完整响应再转发，这违背了流式传输的目的，并导致长响应的内存使用量膨胀。

跨提供商的故障转移需要请求转换。将 OpenAI 格式的请求发送到 Anthropic 的 API 是行不通的——消息格式、系统提示处理和工具调用模式都不同。你的网关需要一个在提供商之间保持一致性的转换层，这是一个巨大的工程面。

尝试插件方式的团队通常花费 3-6 个月构建和维护自定义插件，最终得出结论：他们不小心构建了一个推理网关——只不过是一个耦合在 API 网关插件系统上的版本。

自建还是购买的决策框架

推理网关市场已经爆发。Portkey、Helicone、LiteLLM、OpenRouter、Martian、Unify 等都在争夺这一层。自建还是购买的决策取决于三个因素。

数据敏感性。 如果你不能通过第三方代理发送提示词——这在医疗、金融和国防领域很常见——你需要自托管。LiteLLM 是这里的主流开源选项：完全自托管、高度可配置、支持 100 多个提供商。代价是运维负担——可用性、扩展和升级都由你负责。Helicone 也提供开源自托管选项，其基于 Rust 的代理实现了 8ms P50 延迟。

运维成熟度。 Portkey 和 OpenRouter 等托管网关可以让你在 5 分钟内启动运行。Portkey 将网关、路由、日志、成本可视性、护栏和治理捆绑到一个平台中——如果你没有专门的 ML 平台团队，这很有用。OpenRouter 以 5% 的 token 成本加价提供最简单的集成。问题是你是否愿意将生产流量路由通过另一个供应商的基础设施。

规模和成本。 在低流量下，托管网关的加价可以忽略不计。在每月 1 亿请求的规模下，50 万美元月度支出上的 5% 加价变成了 25,000 美元——足以资助一名专职工程师维护自托管方案。交叉点因团队而异，但大多数组织发现，当月度 LLM 支出在 5 万到 20 万美元之间时，自托管选项在经济上开始具有吸引力。

分阶段方法对大多数团队效果很好：

1. 从托管网关开始，获取可见性和凭证管理
2. 随着支出增长，添加成本控制和路由逻辑
3. 加入安全过滤和治理策略
4. 当经济性合理时评估自托管

新兴模式：网关即控制平面

推理网关正从简单的代理中间件演变为 AI 运营的完整控制平面。Kubernetes 已通过 Gateway API 推理扩展认识到这一点，该扩展将现有网络网关转变为推理感知路由器，具备模型级路由、每请求优先级类别和基于实时 GPU 利用率指标的负载均衡。

这很重要，因为 LLM 推理工作负载与 Web 流量有根本区别。单个 GPU 后端模型服务器维护内存中的 KV 缓存。将请求路由到已经缓存了相关上下文的服务器可以比路由到冷服务器快 2-5 倍。推理感知网关可以基于传统负载均衡器从未见过的模型指标来做出这些路由决策。

趋势很明确：正如服务网格成为微服务的标准基础设施，推理网关正在成为 AI 应用的标准基础设施。将此视为一等架构关注点——而不是在应用代码中用胶带粘合提供商 SDK——的团队，才是那些大规模交付可靠 AI 功能的团队。

下一步行动

如果你今天仍在应用代码中直接调用 LLM API，你正在积累技术债务。推理网关模式对于生产环境 AI 不是可选的——它是限流、故障转移、成本可视性和路由自然趋同的地方。

从小处开始。在你的应用和 LLM 提供商之间放置一个代理，即使它只是记录请求和计算 token。你会立即发现一些令你惊讶的使用模式——那个成本是你预期 10 倍的功能、那个耗尽限流的重试风暴、那个发送 50K token 而实际 5K 就够的提示词。

你为解决这些问题而构建的中间件就是你的推理网关。唯一的问题是你是有意构建它，还是在过去六个月里发现它一直在你的代码库中自然生长。