--- title: "2026 年 LLM 网关对比：LiteLLM、OpenRouter、Portkey、RouteLLM" canonical: https://wavect.io/zh/blog/llm-gateway-router-comparison-2026/ language: zh description: "2026 年 LLM 网关对比。网关做什么（一个端点、回退、缓存、花费上限、路由），以及 LiteLLM、OpenRouter、Portkey 和 RouteLLM 在自托管对托管、成本跟踪和可观测性上的区别。" image: "https://wavect.io/img/blog/headers/header_llm-gateway-router-comparison-2026.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 9 min 阅读 · 27 Jun 2026 [**下一篇**](/zh/blog/reduce-llm-token-costs-2026/) # 2026 年 LLM 网关对比：LiteLLM vs OpenRouter vs Portkey vs RouteLLM 要点速览 LLM 网关把一个端点摆在多家供应商前面，将回退、缓存、花费上限、路由和可观测性收在一处。所比较的四个名字并不能互换：LiteLLM 是自托管的开源代理，OpenRouter 是托管聚合器（一个 key 接入 300+ 模型），Portkey 以可观测性和护栏为主打（开源核心加云），而 RouteLLM 是路由研究框架，不是完整网关。RouteLLM 在自己的基准上报告只用 14% 的强模型调用就达到约 95% 的 GPT-4 质量；请当作方向性数据，并在你的流量上重新证明。按约束你的那条限制来选，先定托管还是自托管，再装上仪表。数据时间为 2026 年 6 月；投入前请核对。 相关服务: [AI Agent 与产品](/zh/services/artificial-intelligence/) 大多数团队把产品直接接到某一家供应商的 SDK 上。一开始没问题，直到出问题。供应商一宕机，你的应用跟着倒下。然后财务来问，为什么一个失控的任务一个下午就烧掉了一个月的预算。然后出了一个新 [模型](/zh/glossary/llm/) ，对你一半的流量来说更便宜也更好，可换过去意味着要动每一处调用点。于是团队开始往上拧重试、花费上限、第二家供应商、一个缓存，一个季度下来，就在自己的代码里草草搭出了半层 [agent](/zh/glossary/ai-agents/) 基础设施，没有人真正负责它。 这层缺失的东西有个名字：LLM 网关。一个端点摆在多家供应商前面，把回退、缓存、花费上限和路由都收在一处。这是工程视角，不是供应商推销。下面的功能与价格信息是方向性的，时间为 2026 年 6 月，取自各工具的公开文档与官网，投入前请重新核对。参考点来自 Wavect 在 [AI 产品](/zh/services/artificial-intelligence/) 上的工作，我们把网关放在了生产流量前面，也和它的取舍一起过了日子。 ## LLM 网关到底做什么？ 网关是一个代理，坐在你的应用和模型供应商之间。你的代码调用一个端点，通常是 OpenAI 的请求格式，网关把这个调用翻译并转发给应该来处理它的供应商。这一道接缝，正是你拿到那些本来要手搓的功能的地方： - 一个端点覆盖多家供应商。 把 Claude 换成 GPT、换成 Gemini、换成开源权重模型，只要改一个配置值，而不是改一处调用点。供应商 SDK 的锁定消失了。 - 回退。 当一家供应商返回错误或超时，网关会向另一个模型或另一家供应商重试，这样单点宕机不会把你的产品一起拖下水。 - 缓存。 相同或语义相似的请求可以返回一份已存的响应，完全跳过模型调用，在重复流量上同时省成本和延迟。 - 花费上限与 key。 按 key、按用户、按团队设预算和速率限制，这样一个坏循环不能掏空账户，你也能给每个团队发一个受限的虚拟 key。 - 路由。 把简单的大多数发给便宜模型，把困难的少数发给 frontier 模型，可以按规则，也可以按学习出来的策略。 - 可观测性。 一处就能看到每个请求的成本、延迟和 token，按模型、key 和功能拆开。 路由是多数人冲着来的那个成本杠杆，它的经济账我们在 [如何在 2026 年降低 LLM token 成本](/zh/blog/reduce-llm-token-costs-2026/) 里讲过。这篇文章讲的是给你这个杠杆、外加这一整层其余部分的那些工具。 ## LiteLLM、OpenRouter、Portkey 和 RouteLLM 有什么区别？ 这四个名字常被一起提起，但它们不是同一类东西。两个是完整网关，一个是托管聚合器，一个是路由研究框架。下面是每一个的轮廓，能力已在 2026 年 6 月对照各工具自己的文档核实。请当作快照，投入前重新核对。 | 工具 | 类型 | 托管方式 | 路由 / 回退 | 缓存 | 可观测性 | 最适合 | | --- | --- | --- | --- | --- | --- | --- | | LiteLLM | 开源代理（OSS + 付费企业版） | 自托管（或托管版） | 有，跨 100+ 供应商的负载均衡与回退 | 有，含基于 Redis | 日志、花费跟踪、集成（Langfuse、OTel） | 想在自己基础设施上拥有完全控制的团队 | | OpenRouter | 托管聚合器 / 市场 | 由其代为运行（SaaS） | 有，供应商故障转移 | 透传供应商侧 prompt 缓存 | 仪表盘与用量分析 | 用一个 key 快速接入 300+ 模型 | | Portkey | 网关 + 可观测性 + 护栏（OSS 核心 + 云） | 核心自托管，或云；企业版可气隙部署 | 有，跨 1,600+ 模型的路由、回退、重试 | 有 | 深，日志、追踪、分析、 [50+ 护栏](https://github.com/Portkey-AI/gateway) | 想要内建护栏与可观测性的生产团队 | | RouteLLM | 开源路由框架（研究） | 自托管，由你嵌入 | 只做路由决策，不是完整网关 | 无 | 无 | 在自己的栈里构建成本-质量路由器 | [LiteLLM](https://github.com/BerriAI/litellm) 是开源主力：一个你自己部署的代理，把 100+ 供应商归一到一个 OpenAI 格式的端点后面，并把虚拟 key、预算、速率限制、回退和日志集中在一个你在自己 repo 里版本化的配置文件里。 [OpenRouter](https://openrouter.ai/) 是托管聚合器：一个 key、数百个模型、由其代为运行，带一个市场模式，让你在新模型上线当天就能用上，而不用在每家供应商都开账户。 [Portkey](https://portkey.ai/) 是一个以可观测性和护栏为主打的网关；它在 2026 年把核心网关开源，同时也卖云版。 [RouteLLM](https://github.com/lm-sys/RouteLLM) 是另一类：来自 LMSYS 和伯克利的研究框架，用来训练和服务路由决策本身，而不是围绕它的网关。 ![Kevin Riedl](/img/team/kevin.webp) "这四个里三个是网关，一个是路由器。拿 RouteLLM 和 LiteLLM 比，就是拿大脑和身体比。多数团队两者都需要，而多数团队先去拿身体。" ## 自托管还是托管：你该选哪个？ 这是第一个真正的决定，通常它就决定了工具。取舍是控制权和数据驻留，对上运维负担。 - 托管（OpenRouter、Portkey 云）。 一个下午就拿到这层，没有基础设施要运维。代价是一个你控制不了的依赖，而在 OpenRouter，是数据经由第三方流转，欧盟团队得对照自己的数据驻留立场来权衡。OpenRouter 的目录价大体与各供应商公布的价格一致，但要查 [平台和信用卡手续费](https://openrouter.ai/docs/faq) ，小额充值时它们可能加上可观的百分比，还有每月请求量超过某个门槛后的 BYOK 费用。做预算前请重新核实当前费用。 - 自托管（LiteLLM、Portkey 核心、RouteLLM）。 你在自己的基础设施上运行代理，所以数据路径和升级节奏都归你。LiteLLM 作为开源免费，没有用量费，但你要运维代理外加它的 Postgres 和 Redis，那份运维时间才是真正的成本。对一个有 DevOps 能力、又有合规要求的团队，这通常是对的选择。对一个赶时间的两人产品团队，这是它还不需要的额外开销。 诚实的默认：先用托管来证明这层值得它的位置，等数据驻留、规模上的成本或控制权逼出这个问题时，再转到自托管。这呼应了我们在 [AI 产品](/zh/services/artificial-intelligence/) 项目中一以贯之的自建对外购逻辑，包括像 [Twinsoft AI](/zh/case-studies/twinsoft-ai/) 这样的工作。 ## 成本跟踪和可观测性做得怎么样？ 财务为什么这么晚才注意到账单，是因为供应商的 SDK 几乎不给你按功能或团队看花费的视角。网关就是这个视角所在的地方，而这四个工具深浅各异。 - LiteLLM 按 key、用户和团队跟踪花费，强制预算和速率限制，并把日志送往 Langfuse 和 OpenTelemetry 这类工具。它很扎实，而且因为是你的部署，数据留在你手里。 - Portkey 以可观测性为主打。日志、追踪和分析就是产品本身，它按记录的日志而非原始请求计费，所以价格跟着你观测多少走。如果你想开箱即用的仪表盘、护栏和审计轨迹，它是四个里最深的。 - OpenRouter 给你一个用量仪表盘和你所调用模型的分析，对很多团队够用，而且零配置。 - RouteLLM 这些都不给你。它是路由决策，不是围绕它的平台，所以可观测性是你自己在外面包出来的东西。 我们总会补一句提醒：花费仪表盘告诉你付了多少，不告诉你质量有没有守住。一个悄悄把更难的查询发给更便宜模型的路由器，在成本图上看着像赢，在生产里却是输。你需要在网关旁边放一个评估框架来抓住这点，而没有哪个网关自带它。这份纪律在你身上。 ## RouteLLM 放在哪里合适，那些数字是真的吗？ RouteLLM 是这四个里唯一纯粹围绕路由决策的：给定一个查询，把它发给强模型还是便宜模型。公布的数字确实亮眼，值得谨慎引用。LMSYS 和伯克利团队 [报告](https://lmsys.org/blog/2024-07-01-routellm/) ，在用了增强训练数据后，他们的矩阵分解路由器只把 14% 的调用发给强模型，就达到约 95% 的 GPT-4 性能，他们把这折算成比随机基线便宜约 75%，在 MT Bench 评测上降本超过 85%。 请把这些数字当作方向性的，并按来源的口径来读：它们来自 RouteLLM 的 [原始论文](https://arxiv.org/abs/2406.18665) ，在特定数据集（MT Bench、MMLU、GSM8K）上、对照一个 GPT-4 级强模型测得，2024 年发表，并在 ICLR 2025 上展示。你的流量不是这些基准，所以在你工作负载上的节省会有出入。诚实的要点是那个形态，而不是确切的百分比：一个学习出来的路由器能守住大部分质量，只把少数调用发给昂贵模型。在信任它之前，你仍然得在自己的评估上把它证明一遍。 在实践中，你不会用 RouteLLM 来取代网关。你可以让 RouteLLM 当路由大脑，在外面包一个网关来做回退、key、缓存和可观测性；或者你用网关自带的更简单的路由规则，省掉这个框架。当路由是你最大的单一成本杠杆、而基于规则的路由正把节省留在桌上时，RouteLLM 才挣到它的位置。 如果你正在具体评估 OmniRoute，应把产品问题与品类对比区分开。我们的 [OmniRoute AI 路由配置与生产检查清单](/zh/blog/omniroute-ai-routing-setup/) 覆盖路由设计、访问强化、故障演练和上线前的评估门槛。 ## 你该怎么选？ 把工具映射到真正约束你的那条限制上，而不是最长的功能清单： 1. **今天就要，没有基础设施可运维。** 选托管方案。要模型广度、一个 key 就够，选 OpenRouter；如果还想从第一天起就有可观测性和护栏，选 Portkey 云。 2. **数据驻留或完全控制要紧。** 自托管。想要一个轻量、被广泛使用的开源代理，选 LiteLLM；如果可观测性和护栏是头等要求，选 Portkey 的开源核心。 3. **可观测性和护栏是优先项。** Portkey 是围着它们建的。其他几个会记日志；Portkey 把日志做成了产品。 4. **路由是你最大的成本杠杆。** 把 RouteLLM 作为路由大脑放进你选定的网关里，并在自己的评估上证明节省。 5. **你拿不准。** 先用一个托管网关，给它装上仪表，让两周真实的按功能花费数据告诉你该优化什么。数据回答这个问题，比对比表更快。 只要你让应用始终说 OpenAI 的请求格式，这些里没有哪个是永久承诺。这正是整个模式安静的好处：网关是你能换掉的那个，恰恰因为它把你代码所依赖的那道接缝标准化了。 ## 最终思考 LLM 网关是大多数团队在意识到它有名字之前，就草草重建过的那一层。早早放进去，你就在一处、在一个端点后面拿到回退、缓存、花费上限、路由和可观测性，而你的代码可以继续调用这个端点，同时你换掉它背后的东西。 这四个工具不能互换。LiteLLM 是自托管的开源主力。OpenRouter 是通往众多模型最快的托管路径。Portkey 以可观测性和护栏为主打，既给你开源也给你云。RouteLLM 是路由大脑，不是网关，数字亮眼但与基准绑定，你必须在自己的流量上重新证明。按约束你的那条限制来选，先定托管还是自托管，再装上仪表，让你自己的花费和评估数据，而不是某家供应商的图表，来决定下一步优化什么。 ## 你可能也喜欢.. [**如何在 2026 年降低 LLM Token 成本** 网关所启用的成本手册：缓存、批处理、路由、把模型选对档位，按优先级排列。](/zh/blog/reduce-llm-token-costs-2026/) [**Wavect vs 一家通用型开发外包** 通用型卖产能，我们卖产品判断加上能交付的工程能力。](/zh/compare/wavect-vs-dev-agencies/) 模型与基础设施 ## 继续浏览此集群 [从核心文章开始**在欧盟自托管 LLM：开放权重模型何时才真正划算**](/zh/blog/self-hosting-llms-eu-cost/) - [OmniRoute AI 路由：配置指南与生产检查清单](/zh/blog/omniroute-ai-routing-setup/) - [Gemini Robotics 2：全身控制与试点决策](/zh/blog/gemini-robotics-2-whole-body-control/) - [pdf-inspector 评测：先本地解析 PDF，再调用 OCR](/zh/blog/pdf-inspector-ocr-routing/) - [本地多模态 AI 编程助手：语音、OCR 与隐私架构](/zh/blog/local-multimodal-ai-coding-assistant/) - [一台 AI PC 本地运行 DeepSeek V4 Flash 0731，现实效果如何？](/zh/blog/deepseek-v4-flash-0731-local-ai-pc/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 9 min 阅读 · 27 Jun 2026 [**下一篇**](/zh/blog/reduce-llm-token-costs-2026/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/llm-gateway-router-comparison-2026/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/zh/blog/llm-gateway-router-comparison-2026/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "LLM 网关把一个端点摆在多家供应商前面，将回退、缓存、花费上限、路由和可观测性收在一处。所比较的四个名字并不能互换：LiteLLM 是自托管的开源代理，OpenRouter 是托管聚合器（一个 key 接入 300+ 模型），Portkey 以可观测性和护栏为主打（开源核心加云），而 RouteLLM 是路由研究框架，不是完整网关。RouteLLM 在自己的基准上报告只用 14% 的强模型调用就达到约 95% 的 GPT-4 质量；请当作方向性数据，并在你的流量上重新证明。按约束你的那条限制来选，先定托管还是自托管，再装上仪表。数据时间为 2026 年 6 月；投入前请核对。", "articleBody": " 博客概览/AI 与智能体/模型与基础设施 2026 年 LLM 网关对比：LiteLLM vs OpenRouter vs Portkey vs RouteLLM 要点速览 LLM 网关把一个端点摆在多家供应商前面，将回退、缓存、花费上限、路由和可观测性收在一处。所比较的四个名字并不能互换：LiteLLM 是自托管的开源代理，OpenRouter 是托管聚合器（一个 key 接入 300+ 模型），Portkey 以可观测性和护栏为主打（开源核心加云），而 RouteLLM 是路由研究框架，不是完整网关。RouteLLM 在自己的基准上报告只用 14% 的强模型调用就达到约 95% 的 GPT-4 质量；请当作方向性数据，并在你的流量上重新证明。按约束你的那条限制来选，先定托管还是自托管，再装上仪表。数据时间为 2026 年 6 月；投入前请核对。 相关服务: AI Agent 与产品 大多数团队把产品直接接到某一家供应商的 SDK 上。一开始没问题，直到出问题。供应商一宕机，你的应用跟着倒下。然后财务来问，为什么一个失控的任务一个下午就烧掉了一个月的预算。然后出了一个新模型，对你一半的流量来说更便宜也更好，可换过去意味着要动每一处调用点。于是团队开始往上拧重试、花费上限、第二家供应商、一个缓存，一个季度下来，就在自己的代码里草草搭出了半层 agent 基础设施，没有人真正负责它。 这层缺失的东西有个名字：LLM 网关。一个端点摆在多家供应商前面，把回退、缓存、花费上限和路由都收在一处。这是工程视角，不是供应商推销。下面的功能与价格信息是方向性的，时间为 2026 年 6 月，取自各工具的公开文档与官网，投入前请重新核对。参考点来自 Wavect 在 AI 产品上的工作，我们把网关放在了生产流量前面，也和它的取舍一起过了日子。 LLM 网关到底做什么？ 网关是一个代理，坐在你的应用和模型供应商之间。你的代码调用一个端点，通常是 OpenAI 的请求格式，网关把这个调用翻译并转发给应该来处理它的供应商。这一道接缝，正是你拿到那些本来要手搓的功能的地方： 一个端点覆盖多家供应商。把 Claude 换成 GPT、换成 Gemini、换成开源权重模型，只要改一个配置值，而不是改一处调用点。供应商 SDK 的锁定消失了。 回退。当一家供应商返回错误或超时，网关会向另一个模型或另一家供应商重试，这样单点宕机不会把你的产品一起拖下水。 缓存。相同或语义相似的请求可以返回一份已存的响应，完全跳过模型调用，在重复流量上同时省成本和延迟。 花费上限与 key。按 key、按用户、按团队设预算和速率限制，这样一个坏循环不能掏空账户，你也能给每个团队发一个受限的虚拟 key。 路由。把简单的大多数发给便宜模型，把困难的少数发给 frontier 模型，可以按规则，也可以按学习出来的策略。 可观测性。一处就能看到每个请求的成本、延迟和 token，按模型、key 和功能拆开。 路由是多数人冲着来的那个成本杠杆，它的经济账我们在如何在 2026 年降低 LLM token 成本里讲过。这篇文章讲的是给你这个杠杆、外加这一整层其余部分的那些工具。 LiteLLM、OpenRouter、Portkey 和 RouteLLM 有什么区别？ 这四个名字常被一起提起，但它们不是同一类东西。两个是完整网关，一个是托管聚合器，一个是路由研究框架。下面是每一个的轮廓，能力已在 2026 年 6 月对照各工具自己的文档核实。请当作快照，投入前重新核对。 工具类型托管方式路由 / 回退缓存可观测性最适合 LiteLLM开源代理（OSS + 付费企业版）自托管（或托管版）有，跨 100+ 供应商的负载均衡与回退有，含基于 Redis日志、花费跟踪、集成（Langfuse、OTel）想在自己基础设施上拥有完全控制的团队 OpenRouter托管聚合器 / 市场由其代为运行（SaaS）有，供应商故障转移透传供应商侧 prompt 缓存仪表盘与用量分析用一个 key 快速接入 300+ 模型 Portkey网关 + 可观测性 + 护栏（OSS 核心 + 云）核心自托管，或云；企业版可气隙部署有，跨 1,600+ 模型的路由、回退、重试有深，日志、追踪、分析、50+ 护栏想要内建护栏与可观测性的生产团队 RouteLLM开源路由框架（研究）自托管，由你嵌入只做路由决策，不是完整网关无无在自己的栈里构建成本-质量路由器 LiteLLM 是开源主力：一个你自己部署的代理，把 100+ 供应商归一到一个 OpenAI 格式的端点后面，并把虚拟 key、预算、速率限制、回退和日志集中在一个你在自己 repo 里版本化的配置文件里。OpenRouter 是托管聚合器：一个 key、数百个模型、由其代为运行，带一个市场模式，让你在新模型上线当天就能用上，而不用在每家供应商都开账户。Portkey 是一个以可观测性和护栏为主打的网关；它在 2026 年把核心网关开源，同时也卖云版。RouteLLM 是另一类：来自 LMSYS 和伯克利的研究框架，用来训练和服务路由决策本身，而不是围绕它的网关。 \"这四个里三个是网关，一个是路由器。拿 RouteLLM 和 LiteLLM 比，就是拿大脑和身体比。多数团队两者都需要，而多数团队先去拿身体。\" 自托管还是托管：你该选哪个？ 这是第一个真正的决定，通常它就决定了工具。取舍是控制权和数据驻留，对上运维负担。 托管（OpenRouter、Portkey 云）。一个下午就拿到这层，没有基础设施要运维。代价是一个你控制不了的依赖，而在 OpenRouter，是数据经由第三方流转，欧盟团队得对照自己的数据驻留立场来权衡。OpenRouter 的目录价大体与各供应商公布的价格一致，但要查平台和信用卡手续费，小额充值时它们可能加上可观的百分比，还有每月请求量超过某个门槛后的 BYOK 费用。做预算前请重新核实当前费用。 自托管（LiteLLM、Portkey 核心、RouteLLM）。你在自己的基础设施上运行代理，所以数据路径和升级节奏都归你。LiteLLM 作为开源免费，没有用量费，但你要运维代理外加它的 Postgres 和 Redis，那份运维时间才是真正的成本。对一个有 DevOps 能力、又有合规要求的团队，这通常是对的选择。对一个赶时间的两人产品团队，这是它还不需要的额外开销。 诚实的默认：先用托管来证明这层值得它的位置，等数据驻留、规模上的成本或控制权逼出这个问题时，再转到自托管。这呼应了我们在 AI 产品项目中一以贯之的自建对外购逻辑，包括像 Twinsoft AI 这样的工作。 成本跟踪和可观测性做得怎么样？ 财务为什么这么晚才注意到账单，是因为供应商的 SDK 几乎不给你按功能或团队看花费的视角。网关就是这个视角所在的地方，而这四个工具深浅各异。 LiteLLM 按 key、用户和团队跟踪花费，强制预算和速率限制，并把日志送往 Langfuse 和 OpenTelemetry 这类工具。它很扎实，而且因为是你的部署，数据留在你手里。 Portkey 以可观测性为主打。日志、追踪和分析就是产品本身，它按记录的日志而非原始请求计费，所以价格跟着你观测多少走。如果你想开箱即用的仪表盘、护栏和审计轨迹，它是四个里最深的。 OpenRouter 给你一个用量仪表盘和你所调用模型的分析，对很多团队够用，而且零配置。 RouteLLM 这些都不给你。它是路由决策，不是围绕它的平台，所以可观测性是你自己在外面包出来的东西。 我们总会补一句提醒：花费仪表盘告诉你付了多少，不告诉你质量有没有守住。一个悄悄把更难的查询发给更便宜模型的路由器，在成本图上看着像赢，在生产里却是输。你需要在网关旁边放一个评估框架来抓住这点，而没有哪个网关自带它。这份纪律在你身上。 RouteLLM 放在哪里合适，那些数字是真的吗？ RouteLLM 是这四个里唯一纯粹围绕路由决策的：给定一个查询，把它发给强模型还是便宜模型。公布的数字确实亮眼，值得谨慎引用。LMSYS 和伯克利团队报告，在用了增强训练数据后，他们的矩阵分解路由器只把 14% 的调用发给强模型，就达到约 95% 的 GPT-4 性能，他们把这折算成比随机基线便宜约 75%，在 MT Bench 评测上降本超过 85%。 请把这些数字当作方向性的，并按来源的口径来读：它们来自 RouteLLM 的原始论文，在特定数据集（MT Bench、MMLU、GSM8K）上、对照一个 GPT-4 级强模型测得，2024 年发表，并在 ICLR 2025 上展示。你的流量不是这些基准，所以在你工作负载上的节省会有出入。诚实的要点是那个形态，而不是确切的百分比：一个学习出来的路由器能守住大部分质量，只把少数调用发给昂贵模型。在信任它之前，你仍然得在自己的评估上把它证明一遍。 在实践中，你不会用 RouteLLM 来取代网关。你可以让 RouteLLM 当路由大脑，在外面包一个网关来做回退、key、缓存和可观测性；或者你用网关自带的更简单的路由规则，省掉这个框架。当路由是你最大的单一成本杠杆、而基于规则的路由正把节省留在桌上时，RouteLLM 才挣到它的位置。 如果你正在具体评估 OmniRoute，应把产品问题与品类对比区分开。我们的 OmniRoute AI 路由配置与生产检查清单覆盖路由设计、访问强化、故障演练和上线前的评估门槛。 你该怎么选？ 把工具映射到真正约束你的那条限制上，而不是最长的功能清单： 今天就要，没有基础设施可运维。选托管方案。要模型广度、一个 key 就够，选 OpenRouter；如果还想从第一天起就有可观测性和护栏，选 Portkey 云。 数据驻留或完全控制要紧。自托管。想要一个轻量、被广泛使用的开源代理，选 LiteLLM；如果可观测性和护栏是头等要求，选 Portkey 的开源核心。 可观测性和护栏是优先项。Portkey 是围着它们建的。其他几个会记日志；Portkey 把日志做成了产品。 路由是你最大的成本杠杆。把 RouteLLM 作为路由大脑放进你选定的网关里，并在自己的评估上证明节省。 你拿不准。先用一个托管网关，给它装上仪表，让两周真实的按功能花费数据告诉你该优化什么。数据回答这个问题，比对比表更快。 只要你让应用始终说 OpenAI 的请求格式，这些里没有哪个是永久承诺。这正是整个模式安静的好处：网关是你能换掉的那个，恰恰因为它把你代码所依赖的那道接缝标准化了。 最终思考 LLM 网关是大多数团队在意识到它有名字之前，就草草重建过的那一层。早早放进去，你就在一处、在一个端点后面拿到回退、缓存、花费上限、路由和可观测性，而你的代码可以继续调用这个端点，同时你换掉它背后的东西。 这四个工具不能互换。LiteLLM 是自托管的开源主力。OpenRouter 是通往众多模型最快的托管路径。Portkey 以可观测性和护栏为主打，既给你开源也给你云。RouteLLM 是路由大脑，不是网关，数字亮眼但与基准绑定，你必须在自己的流量上重新证明。按约束你的那条限制来选，先定托管还是自托管，再装上仪表，让你自己的花费和评估数据，而不是某家供应商的图表，来决定下一步优化什么。 你可能也喜欢.. 如何在 2026 年降低 LLM Token 成本 网关所启用的成本手册：缓存、批处理、路由、把模型选对档位，按优先级排列。 Wavect vs 一家通用型开发外包 通用型卖产能，我们卖产品判断加上能交付的工程能力。 模型与基础设施继续浏览此集群从核心文章开始在欧盟自托管 LLM：开放权重模型何时才真正划算OmniRoute AI 路由：配置指南与生产检查清单Gemini Robotics 2：全身控制与试点决策pdf-inspector 评测：先本地解析 PDF，再调用 OCR本地多模态 AI 编程助手：语音、OCR 与隐私架构一台 AI PC 本地运行 DeepSeek V4 Flash 0731，现", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-07-07", "datePublished": "2026-06-27", "description": "LLM 网关把一个端点摆在多家供应商前面，将回退、缓存、花费上限、路由和可观测性收在一处。所比较的四个名字并不能互换：LiteLLM 是自托管的开源代理，OpenRouter 是托管聚合器（一个 key 接入 300+ 模型），Portkey 以可观测性和护栏为主打（开源核心加云），而 RouteLLM 是路由研究框架，不是完整网关。RouteLLM 在自己的基准上报告只用 14% 的强模型调用就达到约 95% 的 GPT-4 质量；请当作方向性数据，并在你的流量上重新证明。按约束你的那条限制来选，先定托管还是自托管，再装上仪表。数据时间为 2026 年 6 月；投入前请核对。", "headline": "2026 年 LLM 网关对比：LiteLLM vs OpenRouter vs Portkey vs RouteLLM", "image": "https://wavect.io/img/blog/headers/header_llm-gateway-router-comparison-2026.svg", "inLanguage": "zh", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/llm-gateway-router-comparison-2026/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/llm-gateway-router-comparison-2026/", "wordCount": 337 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/ai-agents/", "name": "AI 与智能体", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/models-infrastructure/", "name": "模型与基础设施", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/llm-gateway-router-comparison-2026/", "name": "2026 年 LLM 网关对比：LiteLLM、OpenRouter、Portkey、RouteLLM | ", "position": 5 } ] } ```