四款大模型网关怎么选：托管、自治与治理

模型调用能跑通，只是 AI 应用上线的第一步。账单失控、供应商故障、请求去向不明，才是接入生产流量后会碰到的问题。这篇 2026 年的网关选型文章，把 OpenRouter、LiteLLM、Portkey 和 Kong AI Gateway 放在一起，给出的结论很直接：先看团队受什么约束，再选工具。

它适合正在给 AI 应用补生产能力的程序员。不过，原文提供的是选型经验，没有性能压测、成本对照或故障演练数据。可以拿它筛选方向，具体能力还需要验证。

什么时候值得在模型前面加一层网关

LLM 网关位于应用与模型供应商之间。应用把请求交给网关，由它决定调用谁、是否复用结果、是否允许继续花钱，以及留下哪些记录。

作者把它的职责分成四项：

• 路由：供应商故障时切换上游，也可以把适合的长尾请求分给便宜的小模型。
• 缓存：语义相同的提示词可以复用结果，减少重复调用。
• 成本与限流：按团队设置预算、按密钥设置调用速率，避免失控任务持续消耗额度。
• 可观测性：记录每次请求的延迟、token 用量和错误，方便定位问题。

这里的语义缓存，不只比较两段文字是否完全相同，还会判断它们表达的意思是否接近。它对重复查询较多的应用有吸引力，但原文没有给出命中率、节省比例，也没有展开误命中的处理方式。

真正需要网关的信号，是模型供应商地址开始成为可变配置。

当业务需要替换模型、分配流量或故障切换，把供应商 URL 固定在业务代码里，就会增加维护成本。但原文用「超过少量请求就需要」来描述必要性，判断略宽。请求量之外，业务能否容忍中断、预算是否需要分摊，同样重要。

四个产品，分别替你承担什么工作

OpenRouter 的定位是快速接入多个模型。作者描述的用法是设置它的 base URL，再通过修改一个字段切换模型，例如从 Claude 换成其他供应商的小模型。对还在比较模型的团队，这能减少反复改接入代码的工作。

代价是多一跳网络请求，以及作者所说的供应商选择粒度和审计入口较少。原文还称其价格包含供应商成本与少量加价，但没有提供具体费率，因此不能据此算出高流量下的成本差距。

LiteLLM 则把代理交回团队自己运行。它是 Python 代理，将 OpenAI 风格的调用映射到 100 多个后端，可以作为容器部署在应用旁边。密钥和代理日志能够保留在自己的基础设施中，适合已有 Docker 部署经验、愿意承担运维的团队。

相应地，代理的可用性、安全补丁和扩容也归团队负责。「容器能启动」与「生产代理能长期稳定运行」，中间还有工作要做。

Portkey 提供网关之外的管理能力，包括按项目设置预算、语义缓存、提示词保护和仪表盘，同时支持托管与自托管。它解决的是另一类问题：团队已经接入模型，现在需要控制使用方式和开支。功能更多，也会增加配置与学习成本。

Kong AI Gateway 的价值主要来自复用已有设施。已经用 Kong 管理 REST API 的团队，可以让 AI 流量沿用路由、认证和策略。作者不建议小团队只为 AI 调用引入整套 Kong，这个取舍围绕的是接入成本，而非证明它的 AI 能力弱于其他产品。

先按约束筛选，再接上现有监控

原文的选型路径可以归纳成四个问题：还在挑模型吗？代理必须自己运行吗？是否急需预算和保护规则？公司是否已经使用 Kong？

对应的起点分别是 OpenRouter、LiteLLM、Portkey 和 Kong AI Gateway。它们并不是按能力高低排列，而是承担了不同范围的工作。

作者还给出一个流量参考：每天不到几百次请求时，OpenRouter 这类托管路由通常更简单，之后可以迁移。但「几百次」只是经验尺度，没有测算依据。一次请求包含多少 token、上下文有多长、是否反复重试，都可能改变成本判断。

另一个更扎实的建议是尽早接入现有监控。网关有自己的仪表盘，并不代表业务故障就容易定位。应用请求与模型调用记录需要关联起来，才能查清失败发生在哪一层，以及最终调用了哪个模型。

我的判断

我认同作者先看约束的思路。对小团队来说，少维护一个服务，可能比拥有更多路由开关更有价值；对已有 Kong 的组织，复用认证和策略也有明确理由。

但这篇文章更适合作为候选名单，不能当作完整评测。它没有给出相同负载下的延迟、吞吐、缓存收益、故障切换成功率，也没有详细比较各产品的审计和路由能力。所谓「最快」「最灵活」，都属于作者的经验判断。

还要修正一个容易误读的前提：自托管网关只能控制代理这一层，不能自动保证提示词不离开自己的网络。 如果 LiteLLM 的上游仍是外部模型 API，请求仍然需要发送出去。原文将自托管与不能外发提示词的需求联系起来，却没有交代上游部署方式。

替代方案也不只有四选一。需求很少时，直接调用供应商 API，加上必要的超时、预算告警和调用日志，也可以作为起点。网关值得引入，是因为它能集中解决已经出现的问题，而不是因为所有 AI 应用都必须先装一层代理。

能拿来做什么

• 在 Node 服务中集中管理模型调用配置，避免业务代码到处写死供应商 URL，为后续接入网关或替换模型留出入口。
• 如果每天只有几百次以内的调用，且仍在比较模型，可以先评估托管路由，把接入成本、额外延迟和费用一起纳入判断。
• 如果考虑自托管 LiteLLM，先画清提示词、密钥和日志的流向，再确认代理维护责任，以及上游模型是否满足数据要求。
• 给现有 AI 应用补齐请求关联记录，至少能查到调用模型、延迟、token 用量和错误，再验证故障时是否真的能切换。