什么是 LLM 网关?
每个应用、Agent 和 IDE 都只调用的那一个端点 —— 也是你统一路由、计量、管控和审计模型流量的那个地方。
LLM 网关 · AI 网关 / LLM 代理 / LLM 路由
这个词用得比较松:厂商们把同一层叫 AI 网关、LLM 代理或 LLM 路由。本页给它一个精确的定义,把它和容易混淆的东西分开,并明确说清什么时候你不该部署它。
什么是 LLM 网关?
LLM 网关是位于应用与模型厂商之间的一层服务。应用只调用一个端点;网关把每个请求转发到你配置的模型,做协议互译、保管厂商密钥并记录用量。它不用你的流量训练,不改写你的提示词,也不替代模型本身。
- •它是基础设施,不是模型 —— 模型仍然属于你选择的那家厂商。
- •同一个端点可以服务聊天应用、编码 Agent、批处理任务、实时语音和 MCP 工具调用。
- •有用的分界线:请求路径归网关,提示词归应用。
LLM 网关到底做什么?
四件事:把每个请求路由到合适的模型;做协议归一,让任何客户端都能和任何厂商对话;集中管理密钥与访问控制;记录每一次调用以便算钱和审计。缓存、预算和内容检查都建立在这四件事之上,而不是替代它们。
- •路由与兜底:按 Agent 角色选模型,主厂商 5xx 或超时时换一家重试,上游密钥池化负载均衡。
- •协议互译:四类聊天协议双向互译,客户端可以继续用自己已经在用的 SDK。
- •治理:密钥分组、按请求头准入、按租户配额、SSO 与 SCIM、请求级审计日志。
- •可观测:按密钥、团队和模型给出分钟级 token 与成本时序。
企业为什么要在模型前面放一个网关?
因为模型访问不再是一个团队的事。当多个团队、多个厂商和多个 Agent 都在调用模型时,问题就变成了采购问题:谁能用哪个模型、每个部门花了多少、数据有没有出网、换一家厂商要花多少工程时间。网关用配置回答这些问题,而不是改代码。
- •成本归属:每次调用都带密钥和标签,花的钱能直接按团队拆开,不用再做一个对账项目。
- •数据路径:网关跑在你的网络里,请求只发往你配置的端点。
- •连续性:厂商故障和模型变化在路由层处理,不用改每一个应用。
- •采购:自托管 + BYOK 让密钥和流量留在你自己的厂商合同下。
什么时候真的需要 LLM 网关?
满足任意两条就该考虑:不止一家模型厂商、不止一个使用团队、有合规或数据驻留要求,或者花销已经大到没人能解释这张账单。在这条线以下,直接调厂商 API 更简单也更便宜 —— 网关是多一个要运维的服务。
- •为了能力、成本或容灾而用了两家以上厂商。
- •按团队或按客户的成本报表是反复出现的需求。
- •数据不能离开特定网络、区域或租户边界。
- •多个 Agent 和 IDE 现在共用一两个 API Key。
什么情况下上网关是错的选择?
当你只有一个团队、一家厂商、一个应用时。网关会多一跳、多一个部署、多一圈值班面。如果每月的模型开销可预测、合规要求也简单,直接调厂商 API,等第二家厂商、第二个团队或第一次审计要求出现时再回头看。
- •只有一个厂商上的原型或单一内部工具,不需要。
- •提示词管理和模型评测是另外的产品,网关替代不了它们。
- •任何网关都不能替你去读厂商合同。
网关和中转服务、直接调厂商 SDK 有什么区别?
中转服务替你把流量转发给厂商,通常还替你保管密钥并加收费用;你自己运行的网关把密钥和流量留在你的网络里,并加上路由、计量和策略。直接用厂商 SDK 省掉了这层间接,但重试、协议和计量逻辑会散落在每个应用里。
- •原型阶段用中转服务没问题;代价是提示词和密钥离开了你的网络。
- •只用 SDK 是最省的做法,直到第二家厂商出现 —— 那时每个应用都要写同一套胶水代码。
- •三者之中只有网关能告诉你:钱是谁花的。
| 判据 | 自托管网关 | 中转 / 聚合商 | 只用厂商 SDK |
|---|---|---|---|
| 运行位置 | 你的 VPC 或本地机房 | 厂商云 | 每个应用内部 |
| 谁保管密钥 | 你自己的密钥库;运行时在网关内存 | 中转服务商 | 每个应用各自保管 |
| 模型覆盖 | 你配置的任意厂商 | 服务商的目录 | 每个 SDK 一家厂商 |
| 路由与兜底 | 按角色、按密钥、跨厂商 | 受限于服务商目录 | 由你自己写 |
| 成本报表 | 按密钥、分组、模型,数据来自你自己的账本 | 服务商后台 | 看你自己做了什么 |
| 审计面 | 你拥有的请求级日志 | 服务商日志 | 散落在各应用里 |
网关应该自托管还是用 SaaS?
当密钥、提示词或日志不能离开你的网络,或者采购不接受再多一个子处理者时,选自托管。没有平台团队、想要零运维时,SaaS 更合适。决定性问题不是时髦,而是:谁能读到你的流量。
- •自托管的代价是容器、升级和一份 runbook;SaaS 的代价是订阅和一个子处理者评审。
- •还有混合形态:自托管的数据面加厂商控制面 —— 提示词可能留在内网,元数据未必。
- •要数据流图,不要营销页。
| 判据 | 自托管 | SaaS |
|---|---|---|
| 数据路径 | 留在你的网络内 | 经过厂商 |
| 密钥保管 | BYOK,只在网关内存 | 由厂商管理或转发 |
| 运维成本 | 你跑容器、做升级 | 厂商运行 |
| 首次可用时间 | 一个 Compose 文件 | 注册账号 |
| 合规面 | 你的 DPA、你的子处理者 | 厂商 DPA 与子处理者 |
| 故障域 | 你的基础设施 | 厂商的状态页 |
该怎么选?
按五件事给候选打分:它跑在哪里、账单锚定在什么上、原生支持哪些协议和 SDK、对密钥和租户的治理有多细、厂商明年还会不会继续做这个产品。最后再核对一件任何矩阵都看不出的事:你今天能不能复现一个月前的成本报表?
- •部署形态:自托管、SaaS 还是混合 —— 以及控制面会不会回连厂商。
- •计费锚点:按实例、按席位、按 token,还是按消费额抽成。
- •协议:OpenAI、Anthropic、Gemini、DashScope 双向互译,流式与工具调用要真的等价。
- •治理:密钥分组、请求头 ACL、预算、SSO 与 SCIM、审计导出。
- •可复现性:同样的输入,几个月后仍是同样的数。