北京
这是一行正在不少公司的生产环境里悄悄运行的代码：
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”付前沿模型的钱
大部分应用把所有请求都发给它们最强、最贵的模型，感觉安全，但也极其浪费——因为绝大部分请求根本用不着前沿模型。给客服工单打分类、从一句话里抠出日期、判别一条评论是不是垃圾信息——一个小的、便宜的模型就够了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
