这是一行正在不少公司的生产环境里悄悄运行的代码:
const response = await openai.chat.completions.create({ model: "gpt-4o", messages });
看上去没什么,但它同时锁死了供应商、模型、定价层级和一个单点故障。上个月你的 AI 账单为什么是这个数,OpenAI 下午一抽风你的应用为什么跟着崩,同一个问题被一万个用户问出来为什么要付一万次推理调用——答案全在这一行里。
大模型网关就是用来解开这个死结的,思路其实比这波 AI 热更老:代理。和你过去在数据库、微服务前面放的那层代理没两样,只不过这次它夹在你的应用和所有模型供应商之间。你的代码调网关,网关负责决定哪个模型真的接请求、模型挂了怎么办、甚至要不要调用模型。三件事:路由、回退、缓存。我们一个一个拆开看,因为每件事都有一个宣传材料不爱提的坑。
为什么非要用代理,而不是一个包装函数?
直觉可能是写个助手函数了事——function askLlm(prompt) { ... }。直到第二个供应商出现,这招就撑不住了。你得在调用点里同时处理模型名称、API 密钥,还有每家供应商特有的别扭。OpenAI 要 messages,Anthropic 把 system 拆出来,Google 又是另一套。每个调用模型的地方都知道了太多细节。
网关把这一切压成一层。你只说一种“方言”——几乎总是 OpenAI 的聊天补全格式,它已经成了大模型的“通用语”——然后网关负责把请求翻译给任何一家实际接单的供应商。这个唯一的“卡口”就是价值所在。缓存、重试、预算上限、限流、审计日志、个人身份信息脱敏,这些横切关注点不该撒得代码库到处都是,它们就该待在每一次请求都会经过的同一个地方。
┌─ 缓存?→ 路由 → 调用 → 回退?─┐你的应用 ──────►│ │ → 供应商 └── 命中:<5ms 返回,$0 ────┘ (OpenAI、Anthropic、本地...)
你可以自己搭一个(在 Node 或 Python 里对着 HTTP 客户端写几百行),也可以用开源的,比如 LiteLLM(在 OpenAI API 的形制后面跟 100 多家供应商对讲),或者 Cloudflare、Vercel 这类托管边缘网关。自建还是买,取决于你想自己兜住多少硬骨头——缓存语义、故障转移逻辑、可观测性。这个我们最后再说。先讲第一件事:路由。
路由:别再为“2+2”付前沿模型的钱
大部分应用把所有请求都发给它们最强、最贵的模型,感觉安全,但也极其浪费——因为绝大部分请求根本用不着前沿模型。给客服工单打分类、从一句话里抠出日期、判别一条评论是不是垃圾信息——一个小的、便宜的模型就够了。
热门跟贴