什么是 LLM 网关？一份白话指南
LLM 网关是位于你的应用和你所用的每家 AI 模型厂商之间的统一入口。你的代码只对接一个 API；网关负责对接 OpenAI、Anthropic、Google、DeepSeek 等厂商，一路上完成格式转换、流量路由和账单合并。
核心就这么简单。这份指南剩下的部分解释：为什么这一层已经成了生产环境 AI 应用的标配，有哪些类型，以及怎么判断你到底需不需要。
它解决的问题
团队很少一开始就用上网关，通常是撞上了下面四堵墙中的几堵之后才用。工程上的细节我们写在《多个 AI API 直接集成，背后藏着哪些复杂度》里；简单说：
- 每家厂商说的方言都不一样。主流 API 处理消息格式、系统提示词和参数的方式都略有差别，为一家写的代码到另一家就会出错。网关把这些统一到一种格式后面；实际上就是 OpenAI 格式，它已经成了事实标准，就像 S3 的 API 之于存储。
- 限流和故障不会提前通知。厂商同时按每分钟请求数*和* token 数限流，即使顶级模型也会有状态不好的时候。网关跟踪每条线路的健康状况，自动转走失败的请求，所以到达用户那里的错误更少。
- Key 和账单越来越多。四家厂商就意味着四个要轮换的密钥、四个要对账的后台、四个可能漏钱的地方。网关把这些收拢成一个 Key、一份账单。
- 换模型就要改代码。没有网关时，试一个新模型就是一个集成项目；有了网关，就是在字符串里改一个模型名。
网关的三种类型
市场上已经分化出三种形态：
- 自托管的开源方案。你在自己的基础设施上运行路由器：控制权和数据驻留都在自己手里，代价是部署、升级和追赶厂商 API 变化都得自己长期负责。知名度高的例子是 LiteLLM。
- 托管的多模型网关。由托管服务提供一个 OpenAI 兼容端点，背后是很大的模型目录；路由、换线和账单合并都在后面完成。BoostRail 属于这一类：15 家厂商的 73 款文本、图片和视频模型，用一个 Key 调用，每款的 token 单价都公开。
- 以可观测性和治理为主的平台。这类产品的重心是日志、成本分析、访问策略或护栏，附带路由功能。Helicone 和 Portkey 是这一类里的代表。
这几类在边界上有重叠，大多数产品什么都做一点；但弄清一个产品的重心在哪里，就能很快判断它在哪些方面适合你。
怎么选：七个问题
- 我是否在用、或者可能会用不止一个模型？如果确实不会，网关可有可无。
- 我的厂商出故障时，我的产品会怎样？如果答案是「跟着停掉」，那换线是你的首要需求。
- 请求数据必须留在我的基础设施里吗？是，选自托管；否，托管方案能省掉运维。
- 网关怎么收费？对照官方牌价比较 token 单价，再看充值和支付手续费，以及有没有平台费或订阅费。规模上来以后，这些差别会累积起来。
- 我能带上自己的厂商合同吗？如果你有谈好的价格，支持 BYOK（通过网关使用你自己的厂商 Key）就能保住它。看一下免费额度：BoostRail 的免费套餐每月含 1,000,000 次 BYOK 请求。
- 我需要哪些模态？文本是基本要求，图片输入很常见；图片和视频生成在各平台之间差别更大，确认目录覆盖了你的路线图需要的内容。
- 离开有多难？用 OpenAI 兼容的网关，离开就是把一个 URL 改回去。要求使用私有 SDK 的方案，离开会更难。
常见问题
网关会拖慢我的请求吗？ 它会多一跳网络。对多数负载来说，这和动辄几百到几千毫秒的生成时间相比很小；用你自己的流量测一下。
LLM 网关和 API 网关是一回事吗？ 概念相同，侧重点不同。传统的 API 网关（Kong、Cloudflare）管理通用的 HTTP 流量；LLM 网关增加了与模型相关的工作：在各家厂商的方言之间转换请求体、按 token 处理限流、模型路由与换线、按 token 追踪成本。
做原型需要网关吗？ 不需要。一家厂商、一个 SDK 是正确的起步方式。等你加入第二个模型、碰到第一次限流，或者需要把账单讲清楚时，网关才有用武之地。由于接入网关只是改一下 base_url，推迟这个决定不会有任何成本。