LLM 网关是什么，为什么每个多模型团队都绕不开它

一年前接大模型很简单：拿一个 OpenAI 的 key，写几行调用代码，上线。

现在再看这套代码，负责 AI 集成的工程师大概都眼熟：调用逻辑里塞了三个供应商的分支判断，key 直接写在各个微服务的环境变量里，成本没人算清楚，出了敏感数据也不知道拦在哪一层。想从 GPT-4o 切一半流量到 Claude，改动牵扯到七八个文件。

问题不在于谁代码写得差，而在于大模型调用早就不只是"调一个 API"了------它是一条需要治理的管道。LLM 网关（LLM Gateway）就是这条管道的治理层。看完你应该能自己画出一张网关架构图，并判断团队现在该不该上。

为什么需要一层网关：从一个 key 到一百个入口

单模型、单团队的时候，网关是多余的。真正逼出网关的，是下面这几个变化同时发生：

模型开始变多。 一个场景用 GPT-4o，另一个场景 Claude 效果更好，出于成本又想把简单请求丢给 DeepSeek，合规场景还得用国内自部署模型。每加一个供应商，SDK、认证方式、请求格式、错误码全都不一样，业务代码里的 if provider == "openai" 越堆越多。

成本开始失控。 大模型按 token 计价，而 token 消耗天生波动------一次长对话、一个 Agent 的重试死循环，都可能让账单翻倍。各团队各接各的 key，没有预算上限，月底看到账单才知道花了多少，还查不出是谁花的。

安全成了硬门槛。 用户输入可能夹带 prompt 注入，请求体里可能带着手机号、身份证、银行卡直接发给第三方模型，真实 key 散落在各个服务里随时可能泄露。

排障变成黑盒。 "为什么这次特别慢""今天超时率怎么这么高""这个月 token 涨在哪"------没有一个中心化的观测点，每个问题都得挨个供应商去查。

这四件事凑齐，就是网关该出场的时候。核心一句话：把散落在业务代码里的模型调用治理，收拢到一个统一入口。

为什么不能直接用 Kong / Nginx

这是最常被问的问题。传统 API 网关能转发 HTTP，但处理不了大模型特有的语义。传统网关只认路径和请求头，它不知道 model: gpt-4o 是什么意思，算不了流式响应扣了多少 token，也没法在请求发出前先跑一遍脱敏。LLM 网关理解"模型"这一层语义，这是它和传统网关的分水岭。

具体差别：

认证------传统网关校验 token / JWT；LLM 网关用虚拟密钥 + 团队/预算绑定
路由------传统网关看 URL 和请求头；LLM 网关解析请求体里的模型名、供应商、成本
协议------传统网关只认普通 HTTP；LLM 网关额外支持 SSE 流式响应
计费------传统网关按请求次数；LLM 网关解析 token 用量按价格精算
缓存------传统网关做响应体缓存；LLM 网关能做语义相似缓存
安全------传统网关用 WAF（SQL 注入、XSS）；LLM 网关加内容护栏（PII、prompt 注入）
降级------传统网关只能报静态 5xx；LLM 网关可以自动切到另一个供应商

网关内部长什么样：七个处理阶段

把网关拆开看，它本质是一条管道加插件的组合：一个请求进来，依次经过七个阶段，每个阶段都可以插拔替换。

复制代码

 请求进
   │
   ▼
 ①认证 ──▶ ②授权 ──▶ ③限流 ──▶ ④路由 ──▶ ⑤翻译 ──▶ ⑥调用 ──▶ ⑦后处理
   │        │         │         │         │         │          │
 虚拟      模型      预算/      选渠道     转成      对接真实    脱敏/记账/
 密钥      白名单    TPM 校验   +Fallback  目标格式   供应商 API  缓存/日志
   │                                                            │
   └──────────────────── 拿到响应，原路返回 ◀───────────────────┘

逐个说：

①认证：不校验真实的供应商 key，而是校验一层虚拟密钥（下一节展开）。
②授权：这个密钥能不能调这个模型？属于哪个团队？
③限流：除了常规的每分钟请求数，还要管每分钟 token 数，以及"这个 key 的累计花费有没有超预算"。
④路由：整条管道的核心，决定这个请求发给谁------按权重分流、失败自动降级、故障节点冷却。
⑤翻译：调用方统一用 OpenAI 兼容格式，网关负责翻译成 Claude、Bedrock 等目标供应商的格式。
⑥调用：真正发起对上游的请求，处理好流式响应的分块转发。
⑦后处理：出口护栏脱敏、按 token 精算扣费、写缓存、落审计日志。

这条管道就是网关的骨架。不同产品的差异，无非是每个阶段做得深还是浅、插件多还是少。理解了它，你在任何一款 LLM 网关上都能快速上手。

四个关键能力

七个阶段背后，真正拉开产品差距的是四个能力。

虚拟密钥：别再把真 key 发给每个人

网关最有辨识度的设计。它把密钥分成三层：

管理员密钥：用来生成和吊销其他密钥，只有平台负责人持有。
虚拟密钥：发给具体团队或服务，绑定了"能用哪些模型、预算上限多少、有效期到什么时候"。
供应商真实密钥：OpenAI、Claude 的真 key，只存在网关配置里，对外完全隐藏。

好处很直接：你可以随时吊销某个团队的虚拟密钥而不影响别人，可以给测试环境的密钥设个 10 美元上限防止误刷，真 key 从头到尾不出网关。你不该把 OpenAI 的 key 直接发给每个成员或每个微服务------虚拟密钥就是那层代理。

路由：不只是转发，是决策

好的路由引擎在做多维决策，不是简单轮询：

权重分发：同一个模型配多个渠道，按 7:3 比例分流，摊平单渠道的限速。
跨供应商降级（Fallback）：GPT-4o 报错时自动切到 GPT-4o-mini，再不行切 Claude，调用方无感知。这是传统网关做不到的------它没法跨供应商降级。
冷却机制：某个渠道连续出错就暂时踢出，过一段时间再自动试探恢复，避免持续往故障节点打请求。
条件路由：短请求走便宜模型，长对话走强模型；付费用户走 GPT-4o，免费用户走开源模型。

路由是网关从"能用"到"好用"的关键。

护栏：内容层的安全检查

护栏是在调用前后跑的安全插件，分三种时机：

调用前（pre_call）：脱敏 PII、检测 prompt 注入，把请求拦在发给模型之前。
调用中（during_call）：不阻塞请求，旁路做异步安全检查。
调用后（post_call）：检查模型输出是否合规，屏蔽敏感内容。

它和传统 WAF 不是一回事：WAF 防的是 HTTP 层攻击（SQL 注入、XSS），护栏防的是内容层风险（隐私泄露、注入、违规言论）。两者互补，不能互相替代。生产环境里最常用的一条是 PII 脱敏------把请求里的手机号、银行卡在发给第三方模型前替换成占位符，业务代码一行都不用改。

成本追踪：把账算到人头上

网关按 token 精算每次调用的花费，而不是数请求次数。它能：

按密钥 / 用户 / 团队三级归因，月底清楚知道钱花在哪。
设预算硬上限，超了直接在入口拒绝，而不是事后追责。
对接观测后端（Langfuse、OpenTelemetry 等），把延迟、token 速率、失败率都汇到一处。

这一步让"成本失控"从一个模糊的焦虑，变成一张能归因、能设限、能告警的账。

生态里有哪些选择

目前主流的几款，定位其实不完全重叠：

LiteLLM（Python）：供应商覆盖最全（100+），虚拟密钥和成本追踪体系最完备，适合已经用 Python 做 AI 基础设施的团队。
Portkey（Node.js）：极轻量，基于边缘 Worker 架构，一条命令就能起，适合小团队和快速验证。
Kong AI Gateway：在传统 Kong 网关上加的 AI 插件层，适合已经重度使用 Kong 的团队顺势演进。

选型的主线还是团队规模：小团队要的是"一条命令起来"，中大团队要的是"虚拟密钥 + 成本分摊 + 护栏"这套治理能力。安全合规要求高的行业，护栏的丰富程度是硬指标。

如果你想在 Go 技术栈里跑一套轻量、无冷启动、契合云原生的网关，我把上面这套架构用 Go 实现了一个开源版本，七阶段管道、虚拟密钥、多渠道路由和 PII 脱敏都做进了核心：github.com/warm3snow/l...。它靠一份 YAML 声明式配置就能定义多渠道权重路由和自动降级，适合拿来读代码、理解网关内部实现，或作为团队自建的起点。

LLM 网关不是锦上添花的组件。单模型阶段它是多余的，但一旦进入多供应商、多团队、要合规的阶段，没有这层网关，治理成本会随调用量非线性膨胀------而这一天，比大多数团队预想的来得早。

想清楚这四个能力里你最先需要哪个，就从那里开始接。

关注公众号「coft」，获取更多 AI 时代的深度思考。