什么是 LLM 网关
LLM 网关(大模型网关)是 AI 网关的常见别称,指位于应用与各家大模型(LLM)之间的统一入口,负责统一路由、治理、安全、缓存与观测大模型及 AI Agent 流量。当团队从调用单一模型,发展到同时接入多家大模型、给多个应用与 AI Agent 供能时,分散的密钥、各不相同的接口、失控的 token 成本、缺失的安全与审计,都会成为难题。LLM 网关把这些统一收敛到一个入口来解决。
需要说明的是,「LLM 网关」「大模型网关」与「AI 网关」通常指同一类产品,只是叫法不同。更完整的定义与它同 API 网关的区别,可参阅 什么是 AI 网关。
LLM 网关选型看哪些维度
不同产品覆盖程度不一。选型时,可以逐条对照下面这些维度,看候选方案是否满足你的需求。
| 维度 | 看什么 | 为什么重要 |
|---|---|---|
| 部署形态 | 自托管,还是托管 SaaS;数据(提示词与响应)是否留在自有网络。 | 决定数据驻留与合规边界。对数据敏感的团队通常要求在自有 VPC 内自托管、仅保留出站连接。 |
| 开源协议 | 是否开源,以及协议类型(Apache-2.0 / MIT / AGPL-3.0 等)。 | AGPL-3.0 对「对外提供修改版需开源」有要求;宽松协议(Apache-2.0 / MIT)在商用与二次开发上约束更少。 |
| 供应商 / 模型覆盖 | 统一接入了多少家供应商与模型,是否覆盖你在用的模型。 | 覆盖越广,越能把 OpenAI、Anthropic、Google 与自托管等模型收敛到一套接口,方便切换与灰度。 |
| 路由 / 负载均衡 / 故障转移 | 能否在多模型、多密钥间做负载均衡、失败重试与故障转移。 | 避免单一供应商限流或宕机拖垮业务,是生产可用性的基础。 |
| 语义路由 | 能否按请求的语义或意图,把流量分发到最合适或最具性价比的模型。 | 让简单请求走便宜模型、复杂请求走强模型,兼顾质量与成本,而非只按固定规则转发。 |
| 缓存(精确 / 语义) | 是否支持精确缓存,乃至对相似请求的语义缓存。 | 对重复或相似问题直接命中缓存,降低延迟并节省重复调用大模型的开销。 |
| 令牌限流与成本预算 | 能否以 token 为单位做限流、配额与预算,并按模型 / 密钥 / 团队核算成本。 | 大模型按 token 计费,缺少预算与配额极易费用失控。 |
| 提示词 / 响应护栏 | 能否在入口对提示词与模型响应做校验与过滤。 | 拦截敏感信息、注入攻击与不合规内容,为 AI 流量提供统一安全基线。 |
| MCP 网关 | 能否把 MCP(Model Context Protocol)工具服务纳入同一入口治理。 | 用同一套密钥、限流与护栏治理 AI Agent 的工具调用,而非工具各自裸奔。 |
| 可观测性 | 是否统一采集模型、token 用量、延迟、成本与错误,提供日志、指标与追踪。 | 没有统一观测就无法排障与做成本分析,治理也就无从谈起。 |
| 企业身份(SSO / SCIM) | 是否支持单点登录(SSO)与用户自动同步(SCIM)等企业级身份能力。 | 面向多团队、多成员的规模化使用,需要与企业身份体系打通并可审计。 |
常见方案速览
下面按定位各用一句话概括几款常被提及的方案,更详细的横向对比见文末链接。
AISIX
Rust · 数据面 Apache-2.0 · 可自有 VPC 自托管
Rust 编写、数据面 Apache-2.0 的 AI 网关,由 Apache APISIX 原班团队打造,可在自有 VPC 内自托管(数据不出网),在同一网关上提供语义路由、模型合议(ensemble)、提示词 / 响应护栏与 MCP 网关。
LiteLLM
Python · MIT · 100+ 供应商
Python 编写、MIT 协议,既是 SDK 也是代理,统一 100+ 家供应商为 OpenAI 兼容接口;开源版即含语义缓存、虚拟密钥与预算、MCP 网关,以覆盖广度见长。
Portkey
TypeScript · 开源网关 + 托管平台 · 1,600+ 模型
TypeScript 开源网关搭配托管治理平台,覆盖 1,600+ 模型,提供原生护栏与 MCP 网关,以及较成熟的可观测与治理能力。
One API / New API
Go · Token 中转站
One API(Go / MIT)与在其基础上二次开发的 New API(Go / AGPL-3.0)属于「Token 中转站」,以中转与计费为核心:把多家模型统一到 OpenAI 兼容接口,提供令牌额度、渠道负载均衡与失败重试,自带控制台;通常不含语义路由、模型合议、护栏、MCP 网关等 AI 原生治理。
怎么做选择
维度虽多,但不必逐一并列打分。更高效的做法是先用两条主轴快速筛掉大部分选项,再对剩下的候选做横向对比。
主轴一:自托管 / 数据驻留 vs 托管
先问一个问题:提示词与响应能否离开自有网络。若对数据驻留与合规有要求,优先看能否在自有 VPC 内自托管。例如 AISIX 的数据面为 Apache-2.0,可部署在自有网络内、仅保留出站连接;若更看重开箱即用,则可接受托管 SaaS。
主轴二:是否需要治理能力
再问:你只是要「中转 + 计费」,还是需要 AI 原生治理。若只需把多家模型统一到一个接口并做计费,轻量的 Token 中转站(One API / New API) 即可;若需要语义路由、模型合议(ensemble)、提示词 / 响应护栏、成本预算、MCP 网关乃至 SSO / SCIM 等企业级治理,则应选择能力更完整的 AI 网关。
再做横向对比
用上面两条主轴缩小范围后,再针对剩下的候选逐条比对本文的选型维度。完整的横向对比可参阅 AI 网关对比;想进一步了解 AI 网关本身,可看 什么是 AI 网关 与 AISIX AI 网关。
