LLM 网关是如何工作的？面向工程团队的实用指南

LLM 网关位于你的应用与通过它接入的模型提供商之间，让你可以在同一处管理凭据并跟踪用量。

“目前简直是一团糟，”一位工程师于 2026 年 9 月在 Reddit 的 r/LLMDevs 版块写道。

“每个人都有自己的一套密钥，分别用于 Claude、OpenAI、AWS Bedrock，以及我们使用的所有其他推理提供商。”

BigGo 对 llm-proxy-tk 的报道（llm-proxy-tk 是一款轻量级 FastAPI 网关）将这种架构比作把 LLM 变成“企业自来水”，而网关就是整栋大楼的总阀门。

但在把如此多的信任托付给这套“管道”之前，我们先来看看你要安装的究竟是什么。

什么是 LLM 网关？

LLM 网关是用于模型调用的反向代理。你的应用将请求发送到网关，而不是直接发送给 OpenAI、Anthropic、Google 或你所使用的其他 LLM 提供商。网关会转发这些请求，并在转发途中应用你设定的规则。

每个 LLM 提供商都有自己的 API：有自己的请求结构、自己的身份验证方式，以及自己返回错误的方式。每家提供商还有各自的速率限制和故障模式。如果它们前面没有一个共享层，那么每个调用提供商的应用都得自己处理所有事情，而且做法还各有出入。

自来水的比喻只能说明到一定程度，但足以说明这一点：提供商只需在网关处接入一次。此后，每个应用都会获得自己的计量连接，因此你可以看到谁在使用什么，并能单独关闭任意一条线路，而不影响其他线路。

LLM、AI、MCP 和 API 网关：有什么区别？

LLM 网关如何运作？

让我们跟随一个请求，从你的应用出发，到达模型，再返回应用。

1. 请求到达网关：你的应用向网关的端点发送一个看似普通的聊天请求，通常采用与 OpenAI 兼容的格式。从应用的角度来看，这就是它访问模型时调用的地址。
2. 网关检查请求者的身份及其权限范围：在转发请求之前，网关会验证凭据，通常是发放给某个团队或产品的虚拟密钥。如果你接入了输入护栏，还可以扫描提示词，检查其中是否包含敏感数据，或是否试图覆盖模型的指令。
3. 网关检查是否已有答案：如果启用了缓存，符合条件的匹配请求可以直接使用已保存的响应作答，无需再次调用提供商。有些网关还提供语义缓存，它查找的是被判定为足够相似的请求，而非完全相同的请求。这比较适合常见问题类的流量。
4. 网关决定请求的去向：请求可能指定了某个具体模型或别名。网关会在你的配置中查找匹配的路由。你还可以配置备用路由：如果提供商 A 超时，网关可以改为尝试提供商 B。
5. 网关准备调用并返回响应：网关会将你的请求转换为所选提供商的格式，并对发出的调用进行身份验证。收到响应后，网关会立即将其转换为你的应用所需的格式。
6. 网关记录所发生的情况：启用日志记录后，网关会记录调用者、处理请求的模型、Token 数量、延迟和成本等详细信息。这正是引言中那位 Reddit 工程师所缺少的日志。

将网关投入生产环境前需要了解的 4 件事

上一节所述的一切之所以能够实现，是因为网关能看到经由它路由的每一个请求。这是它的卖点。但这同时也描述了你必须预先规划应对的攻击面和供应商依赖。

网关如今成了你的 AI 技术栈中最有价值的组件

网关集中了访问权限，因此也让大量凭据集中在单一服务的掌控范围内。Microsoft 安全团队列出了 LiteLLM 部署可能持有或获取的内容：提供商 API 密钥、其自身的主密钥、虚拟密钥记录、数据库连接字符串、路由设置以及租户策略。

2026 年 10 月，Check Point Research 披露了两个高风险漏洞，均存在于 LiteLLM 中：

• CVE-2026-35029 允许已通过身份验证的用户（包括只读用户）访问管理功能并接管实例。
• CVE-2026-59823 允许用户将请求重定向到其控制的服务器，并窃取提供商密钥。

这两个漏洞均已在 1.83.9 版中修复。使用网关的应用不应有权更改网关的设置。

你的护栏需要一套故障策略

Pillar Security 在 2026 年 10 月 4 日发布的一篇评测记录了各大主流网关中的第三方护栏集成，包括 LiteLLM、Kong、TrueFoundry、Portkey、Azure API Management 和 Apigee。（Pillar 本身就销售护栏产品，因此阅读其建议时请记住这一点。）

钩子（hook）是请求路径中的一个节点，通常位于提示词发送给模型之前或响应返回之后，网关可以在此将内容交给外部扫描器作出判定。阻断式检查会等待判定结果，然后才放行流量。Portkey 的文档将其称为 before_request_hooks 和 after_request_hooks；TrueFoundry 运行四个钩子，额外增加了 MCP 工具调用前后的检查。

那么，有两点需要检查：

• 如果扫描器本身发生故障会怎样？如果阻断请求，你可以拦住未经检查的流量，但可能会中断你的应用。如果放行，你的应用可以在缺少该检查的情况下继续运行。故障日志会在事后告诉你缺少了这项检查，这固然有用，但与实际执行了检查并不是一回事。
• 能否更换扫描器？如果网关不支持其他扫描器提供商，你可能需要更新应用，或使用另一个代理来连接。

TrueFoundry 的 MCP 钩子将网关的覆盖范围从模型请求扩展到了工具调用。但网关只能检查经过它的流量。在开发者机器上运行命令的编程智能体可能就不在其视野范围内。

Perplexity 的开源工具 Numbat 则负责这一侧。Numbat 通过本地钩子连接受支持的智能体，可在计划中的操作（如 shell 命令或文件写入）运行之前对其进行检查。阻断功能为可选项，默认处于关闭状态。网关能看到经由它路由的模型流量，而 Numbat 则补充了对智能体如何使用答案的可见性。

你需要知道网关的控制范围止于何处

Forkast News 指出，有三类不同渊源的产品正从不同方向朝网关演进：

• 以 LLM 为核心的网关：LiteLLM 和 Portkey 最初专注于模型调用，包括在提供商之间转换格式、路由请求和跟踪 Token。它们现在正在增加针对工具调用的控制。
• API 管理平台：Kong、Google 的 Apigee 和 Azure API Management 最初专注于身份验证、权限和流量管理，后来增加了对模型和 AI 专属规则的支持。
• 智能体原生基础设施：例如，agentgateway 就是围绕智能体与模型、工具及其他智能体之间的通信而构建的，包括通过 MCP 和 A2A 进行的通信。

区分的关键在于你要路由的是什么：

• 只有模型调用？LLM 优先的网关是不错的起点。
• 在已充斥着 API 规则的企业内部进行模型调用？从你现有的平台入手。
• 智能体调用工具，工具再调用模型？请确认这些连接也在覆盖范围内。

你引入了一个共享的单点故障

假设你的客服聊天机器人使用 OpenAI，研究工具使用 Anthropic，二者都通过同一个网关连接。一旦该网关停止工作，即使 OpenAI 和 Anthropic 运行正常，这两个工具也都会失去对各自模型的访问。

这种情况确实发生过。在 2025 年 6 月 12 日的故障期间，Cloudflare AI Gateway 的错误率最高达到 97%。该网关依赖 Cloudflare 的 Workers KV 存储服务来获取设置，而该服务当时出现了故障。

如果你自行运行网关，请另外保持一个副本运行，以便在其中一个发生故障时接管。如果由他人托管你的网关，请询问对方如何在故障期间维持网关运行，以及恢复期间你的请求会如何处理。

选择 LLM 网关时应关注的关键功能

你将把所有人的凭据访问权交给网关，因此理应对它作为回报所提供的功能提出严格要求。

• 在多个提供商前面提供统一 API：你的代码只需使用一种格式（通常是与 OpenAI 兼容的格式），由网关负责转换。LLM 提供商也在主动配合。例如，Perplexity 的 Agent API 支持 OpenAI 的 Responses API 接口，因此团队可以复用现有的 OpenAI 客户端库。
• 附带规则的虚拟密钥：每个团队或产品都有自己的密钥，并附带规则来管控允许使用的模型、请求限额和支出。
• 路由与回退：网关根据你的设置将请求发送给模型，这些设置可能侧重成本、速度或特定提供商。如果调用失败，网关可以尝试另一个模型。Perplexity 的 Agent API 允许你按偏好顺序列出最多五个模型，其中可以包括来自不同提供商的模型。
• 缓存：已保存的响应可以为你省去一次提供商调用。有些网关匹配完全相同的请求，另一些还能匹配含义相近的请求。请检查缓存的响应能否按用户或团队隔离，以及能否针对个性化或时效性强的回答关闭缓存。
• 流式传输与统一的错误格式：响应会在生成的同时陆续送达，提供商错误会被转换为你的应用能够处理的格式。请检查添加 AI 护栏后会发生什么。
• 日志记录与成本归因：网关会记录调用者、处理调用的模型、使用的 Token 数量、耗时以及预估成本。请检查日志是否包含提示词和响应，以及日志的保留时长。
• 护栏钩子：这些是请求路径中的节点，网关可在此将内容发送给外部扫描器作出判定。它们通常位于模型请求之前或响应之后。请检查扫描器发生故障时请求是会停止还是继续，以及能否接入其他扫描器。
• 可以锁定的管理界面：网关管理着对提供商凭据的访问以及所有人共用的规则。请确认你可以将管理员访问与应用流量分开限制，并且只读用户无法更改设置。总阀门需要一把锁。

可以使用哪些工具来构建 LLM 网关？

市面上各产品的功能列表大同小异。在一个关于内部模型访问的 Reddit 帖子中，发帖者问道：哪款网关不需要配备专职工程师？

我们认为这个问题问得很对，而答案有四种，取决于你愿意自己承担多少工作。

自行编写

一个最简单的网关只需处理几项工作：接收请求、检查调用方的密钥、添加提供商凭据、转发调用并记录结果。但支持不同提供商的格式会增加工作量，维持整个系统持续运行也是如此。

如果你已经在运行 Envoy，可以利用其外部处理过滤器接入一个服务，用于检查和修改请求与响应。不过，你仍然需要自行构建并运行该服务。

在一个讨论网关能否降低成本的 r/LLMDevs 帖子中，u/QuanTradin 表示，在每次调用时记录 Token 和缓存命中标记，帮助他们发现了两个为相同提示词支付全价的任务。

“……解决这个问题的价值，比任何路由层都要大。”

这只是一则用户自述的经验，但不失为一个好的起点。在构建复杂的路由方案之前，先弄清楚你在为什么付费。

自托管开源网关

LiteLLM 是这里的常见选择：与 OpenAI 兼容，支持众多提供商，并拥有庞大的社区。Bifrost 是另一种选择，专为降低单次请求开销而打造。如果可观测性是你功能需求清单上的首要项，Helicone 值得一看。

和所有产品一样，LiteLLM 对某些团队而言也有局限。在一个讨论自建之外还有哪些替代方案的 r/aiagents 帖子中，u/Own_Bar_920 表示，LiteLLM 处理路由毫无问题，但在跨团队的提示词版本管理以及更换模型时的持续评估方面无法满足他们的需求，这促使他们转而使用另一款工具。

这些需求已超出基本的网关路由范畴，而这恰恰说明了问题：如果路由是主要需求，LiteLLM 对他们来说表现可靠。

你可以获得一份现成的功能列表（部分功能取决于版本），并将网关保留在自己的网络内部。你还要自行负责打补丁（前文提到的 Check Point 漏洞披露已具体说明了这一点），以及网关的可用性（单点故障一节已对此作了说明）。

但要为此预留预算，安排专人负责。在一个关于内部访问网关的 r/LLMDevs 帖子中，其中一个担忧就是维护问题。u/Informal-Writer9685 想要一款“不需要专职工程师来维护”的工具，并询问据称 LiteLLM 升级不稳定的问题，在他们的规模下是否真的存在，还是只在生产环境中才需要担心。

使用托管网关

Cloudflare AI Gateway、Vercel AI Gateway、OpenRouter 和 Portkey 的托管网关会替你运行这项服务。对于兼容的应用，完成第一次请求可能只需要更改一个 URL 并提供一个 API 密钥。

这样做的代价是，每条提示词在到达提供商之前都要先经过第三方。这意味着你的合规文件中又多了一个数据处理方，而网关自身的故障属于供应商的事故，不由你来修复。

例如，2026 年 2 月 17 日和 19 日，由于一项缓存依赖出现故障，OpenRouter 分别发生了持续 38 分钟和 35 分钟的服务中断。部分客户收到“User not found”（未找到用户）错误，并花时间排查完全有效的 API 密钥。而问题其实出在网关的基础设施上。

不过值得肯定的是，OpenRouter 发布了一份详细的事后分析报告，并增加了保护措施，防止缓存故障压垮其数据库。像 OpenRouter 这样的托管网关可以简化访问，但正如 u/QuanTradin 在 r/LLMDevs 中指出的，合并账单并不会自动降低支出。

扩展你现有的 API 网关

如果你的服务前端已经部署了 Kong、Apigee 或 Azure API Management，它们各自都具备 AI 专属功能：Kong AI Gateway、Apigee 的 AI 网关策略和 Azure API Management 的 AI 网关。你可以在现有的身份验证、网络规则和运维流程基础上，通过插件或策略添加模型控制。

在大公司中，这可能是组织阻力最小的路径。与独立网关相比，这些 AI 功能推出时间更晚、成熟度也更低。务必在你计划使用的整套插件或策略下，测试基于 Token 的速率限制和流式传输。

所以，尽管去安装这个总阀门——也就是那个无所不能的网关吧。不过，开头提到的那位工程师说得也有道理：一家公司能否访问模型，不应取决于谁的抽屉里碰巧放着对的那把密钥。

网关通过将这些密钥集中管控来解决这个问题，但这也让抽屉一旦没关好，后果会更加严重。你必须清楚这个抽屉归谁管。

LLM 网关常见问题

LLM 网关是免费的吗？

如果你指的是这一类产品，有些 LLM 网关提供免费版本。

LLM 网关的价格区间很广：从免费的开源软件，到起价约每月 50 美元的付费套餐，再到为企业级部署定制的价格。也有一些按百分比收费，例如 OpenRouter 的 Standard 套餐会在积分购买金额上加收 5.5%。

哪款 LLM 网关最好？

你愿意自己承担哪些工作？

• 如果你希望自行托管并掌控配置，可以看看 Bifrost 或 Helicone。
• OpenRouter 或 Vercel AI Gateway 这类托管方案，适合希望把服务交给他人运维的团队。
• 如果你已经在使用 Kong 或 Azure API Management，不妨先看看它们的 AI 功能。

用你自己的实际请求来测试入围产品，包括某个提供商出现故障时的表现。

AWS 有 LLM 网关吗？

有。Amazon Bedrock AgentCore Gateway 支持通过 AWS 所称的“推理目标”（inference targets）进行模型调用。借助推理目标，应用可以通过同一个端点访问 Amazon Bedrock、OpenAI 和 Anthropic 等提供商，而提供商凭证和路由则由网关负责处理。