What is the difference between an LLM router and an LLM gateway?

所谓“路由器与网关的区别”，一句话说清就是：路由是一种功能，网关是一个产品边界。路由器决定把请求发给哪个模型，网关则在路由之外，还管认证、计费、协议转换、缓存与回退、可观测性这些事。把“有路由”当成“就是网关”，会在选型时漏掉一半工作：路由能帮你挑模型，但挑完之后的账单、密钥、故障处理，仍然需要有人负责。本文先界定两个词，再按同一口径比较它们各自负责什么，最后说清托管网关自身的边界。

路由器到底只负责什么？

路由器的核心工作是选择：根据模型名、成本、延迟、可用性这些规则，把一次请求发给合适的模型或厂商。它可以很简单，比如按固定顺序试几个模型；也可以很复杂，比如按实时状态动态打分。但无论多复杂，路由器本身不回答另外几个问题：谁有权调用、这次调用记在谁的账上、请求失败了由谁重试、调用记录存在哪里。把路由器单独拿出来用，适合已经有自己的认证和计费体系、只想补一块模型选择逻辑的团队。对其他人来说，光有路由是不够的，缺掉的部分迟早要自己补上。还有一个判断点：路由规则本身也要可测试，如果规则写死了、改一次要重新部署，故障时的调整速度就会受限，选型时要看规则是配置还是代码。

网关在路由之外还管什么？

网关把路由包进一个完整的服务边界里。认证上，网关发密钥、管权限、按密钥或按服务隔离用量；计费上，网关合并跨厂商的账单、统计每次请求的成本；协议上，网关把一种请求格式转成厂商需要的格式，客户端不用为每个厂商写一套集成；可观测性上，网关记录每次请求实际 served 的模型、延迟和费用，出了问题有据可查。缓存与回退也是网关层的事：相同请求是否复用结果、首选模型失败时走哪条备选路，都在网关的职责里。换句话说，网关是你和厂商之间的一个完整中介，而路由器只是这个中介里负责“发给谁”的那一块。完整中介的代价也要看到：多一层服务就多一处可能故障的环节，网关本身的可用性会直接影响后面所有模型调用，这一点在选型时要和它带来的省事一起权衡。

认证与密钥的归属怎么分？

用纯路由器时，厂商密钥通常还掌握在你自己手里，路由器只是帮你选路，账单关系仍在你和厂商之间。用网关时，认证关系变了：托管网关是一把密钥对应多个厂商，你不再直接持有厂商密钥，网关替你认证和结算；自托管网关则是在应用侧统一入口，但背后你仍然持有厂商密钥。带自有密钥的网关是中间形态：厂商直接向你收费，网关不加价，只提供路由和统计。选型时先问清密钥归属：密钥泄露时影响范围多大、能不能按服务单独吊销、权限能不能只读模型列表，这些问题在路由器层面根本不存在，到了网关层面才成为必答题。

协议转换与缓存回退属于谁？

协议转换是网关的典型职责，不是路由器的。客户端讲一种标准请求格式，网关把它转成不同厂商的格式，工具调用、流式返回这些细节由网关处理；纯路由器通常假设调用方已经处理好了格式，只负责选路。缓存与回退的分工也类似：路由器可以决定回退顺序，但回退的触发条件、重试次数、回退后的告知，往往要网关层才有完整的实现。缓存更是如此：要不要缓存、缓存多久、缓存命中后计不计费，这些规则需要一个有状态的服务边界来承载，单块路由逻辑很难独自承担。分不清这条线，就会把网关才有的能力误以为是路由器的标配。

部署归属与适用场景怎么选？

路由器可以是一段库代码、一个函数、也可以是网关里的一个模块，部署形式灵活；网关则是一个服务，有部署位置、有运维责任、有状态要维护。托管网关部署在服务方，适合想要零运维的团队；自托管网关部署在自己的基础设施里，适合数据不能出内网、或者已有运维能力的团队。适用场景的判断标准是：你缺的是“选模型”这一块，还是“认证、计费、观测、故障处理”整套？只缺前者，补路由就够了；缺的是整套，找网关更划算。反过来，已经有完整中台的团队再套一个托管网关，可能会多一层不必要的中间环节，数据路径和账单都会变复杂。判断时还有一个简单测试：把网关拿掉，你的系统还能不能跑起来，能跑起来的说明缺的只是路由，不能跑的说明缺的是整套服务。这个测试做一次，就能省掉很多选型争论。

“有路由”为什么不等于“就是网关”？

因为路由解决的是单次请求发给谁，网关解决的是长期运行谁负责。一次调用成功，不代表账单可查、密钥可管、故障可溯源；一串调用都成功，也不代表换厂商时不用重写代码。把两者混为一谈的常见后果是：上线时觉得够用了，跑一段时间才发现账单对不上、故障时不知道走了哪个模型、想换厂商时发现模型名和厂商字段散落在代码各处。这些都不是路由器的错，是选型时把功能清单当成了产品边界。界定清楚词，再谈选型，才能把缺掉的部分提前补上，而不是在故障里补。

托管网关自身的边界在哪里？

FreeModel 是托管网关而非单纯的路由函数，它的边界要说清：路由层面的能力不等于网关层面的账单、认证与可观测承诺，请求要经过第三方再到厂商，路由只是在合适的模型里挑选，并不能把弱模型变强，免费额度是先试不是无限承诺。网关不改变底层模型的质量，也不替你解决提示词本身的问题。一个直说自己边界的网关，比只罗列功能的网关更容易信任，选型时先读它对“它不是什么”的表述，再看它支持多少模型、多少功能。

选型时先分清再比较，具体怎么做？

分清的办法很简单：问一句“除了选模型，它还替我管什么”。只管选模型的，是路由器；还管认证、计费、协议转换、缓存回退、可观测性的，是网关。缺整套的找网关，只缺选模型的补路由，已经有中台的先看会不会多一层中间环节。词分清了，比较才有同一口径：比较路由器就比选路规则和可测试性，比较网关就比账单透明度、数据路径、故障告知和退出成本，两个层面的标准不要混着用。

一句话收尾：词分清了，比较才不会拿路由的标准去要求网关，也不会拿网关的标准去要求路由。分清之后再动手，缺什么补什么，不多套一层，也不漏一层。这一句先想清楚，后面的比较就不会跑偏。

来源与延伸阅读：FreeModel 关于页：它是什么、不是什么、FreeModel、OpenAI 定价（openai.com/api/pricing）、Anthropic 定价（anthropic.com/pricing）、实测免费网关对比、十四家网关公开模型清单实读、网关对比、网关排名指南。

用一组数字看清差别

把同一份用量分别放到两种结构里算，差别就很具体。假设一个月 1,500 万输入 token、300 万输出 token：按 Claude Sonnet 5.5 的 $2 / $10 每百万 token 算，是 15 × $2 + 3 × $10 = $60/月；同样用量换成 GPT-5.5 的 $5 / $30，是 15 × $5 + 3 × $30 = $165/月。路由器能帮你把请求导向更便宜的模型，但谁来发密钥、谁来合并这两笔账单、失败时谁负责回退，仍然要由网关这一层回答。

• 只补路由：适合已有认证、计费和观测体系的团队，改动最小。
• 上网关：适合想把密钥、账单、协议转换、回退一次配齐的团队。
• 两个都要：已有中台但缺模型选择逻辑，可以在中台里加路由，不必再套一层托管网关。

价格对照：路由能省多少

路由的价值就在这张表里：同一份用量，选错档位一个月差 $100 以上。但谁来记账、谁来保证失败回退，仍然是网关的职责。

四步判断你需要哪一个

1. 列出缺口：现在的系统缺的是「选哪个模型」，还是「密钥、账单、故障处理」整套。
2. 做摘除测试：把网关拿掉，系统还能不能跑。能跑，缺的只是路由；不能跑，缺的是整套服务。
3. 算多一层的成本：网关会多一个故障点和一段数据路径，把它带来的省事和风险放在一起看。
4. 看退出成本：模型名、厂商字段、账单口径是否散落在代码里，换方案时要改多少处。

常见问题

Key numbers

• 2 layers: routing is a function; the gateway is the product boundary.
• 5 duties beyond routing: authentication, billing, protocol translation, failover, observability.
• 3 price points for the same 15M input / 3M output workload: $60 on Sonnet 5.5, $165 on GPT-5.5, $3 on Haiku 5.5.

Sources

• OpenAI API pricing: https://openai.com/api/pricing/
• Anthropic pricing: https://www.anthropic.com/pricing
• OpenRouter documentation (hosted gateway reference): https://openrouter.ai/docs
• LiteLLM documentation (open-source proxy reference): https://docs.litellm.ai/

One worked example

Take a team sending 15M input and 3M output tokens a month. A bare router still needs keys, billing, and failover built around it, so the real comparison is router plus glue versus gateway. Price the glue in engineer-days, not dollars; one week of maintenance usually costs more than the gateway fee for a small team.

What changes when traffic grows

At low volume the router and the gateway look the same: both send a request to a model. At higher volume the difference is failure handling. A router without a retry budget turns one provider limit into a user-visible error; a gateway absorbs it. Budget for the failure path before you budget for model prices.

Decision checklist

• Does the thing you are buying own the keys, or just forward them?
• Does it retry on a rate limit, and does it tell you which model answered?
• Can you see one bill per request, with input and output separated?
• What is the exit cost if you switch next quarter?

Four questions, one page of answers. If a vendor cannot answer all four in writing, the feature list is not the deciding factor.

At a glance

Sources for the provider-side facts: Microsoft Learn AI architecture, DeepSeek API docs.