应用只接一家模型 API 的时候，没人觉得需要网关。等到第三家接进来——主用一家、备用一家、便宜任务走一家——密钥散在配置里，限流逻辑复制了三份，某家限流了没人知道该切谁。LLM 网关就是为这个时刻准备的。

一、网关到底管什么

它不负责让模型更聪明，负责的是把模型当成一种「会抖动的依赖」来运维：

• 统一接入：密钥集中托管、按调用方发虚拟 key，换供应商不改业务代码；
• 路由与分流：按任务类型、成本预算、延迟目标把请求分到不同模型，同一类任务甚至可以按比例灰度；
• 限流与配额：供应商的限流是按 key 算的，网关把多账号池化，同时在出口给内部各团队记账；
• 降级与重试：超时换模型、限流退避、错误分类后决定重试还是直接降级。

这些能力每一条都不新鲜，都是微服务时代 API 网关的旧活。新的不是技术，是把「模型」第一次当成需要治理的生产依赖。

二、容易低估的三个坑

1. 可观测性的粒度。只记成功失败不够，token 数、首字延迟、每条请求的模型版本都得落库，否则成本归因和事故复盘都做不了。
2. 响应的可比性。不同供应商的错误码、限流语义、流式行为都不一样，降级切过去以后，业务拿到的结果结构要有人负责对齐——这层适配比路由本身费工。
3. 缓存不是免费的。响应缓存和前缀缓存能省大钱，但对话类请求几乎不可缓存，盲目开缓存命中率惨淡还占内存。

三、自建还是用现成的

开源网关和商业方案都不少，判断标准其实就三条：你要接的供应商覆盖全不全、路由策略是不是够灵活（尤其基于成本和延迟的动态路由）、以及敏感数据出不出得去你的边界。团队规模小、模型只有两三家时，一层薄封装可能就够；模型数量和调用方数量一起涨，网关才会回本。

小结

LLM 网关的本质，是把模型供应商的不可靠性翻译成业务可用的可靠性。它不性感，但多模型架构里，这层早建晚建都得建——晚建的代价通常是一次线上事故。

说明：本文为公开资料的整理与评述，信息来源包括主流开源网关项目文档与各模型供应商的公开 API 文档，数据以各官方原文为准。本文由 AI 辅助整理，不构成技术选型或投资建议。