一、真正的变化不是"接了个模型"
近一年看各家技术公开分享，有个规律越来越清楚：业务系统里调用大模型的那段代码，正在从业务里剥出来，沉到一层独立的网关里。无论是官方框架的 AI 接入模块，还是内部自建的 LLM Gateway、Model Router，名字不同，干的是一件事------把"调用模型"从一次性脚本变成有 SLA 的基础设施。
以前大家关心"用哪个模型"，现在基础设施团队关心的是：能不能灰度、能不能限流、能不能记账、能不能在模型抽风的时候一键降级。
二、为什么一定要有一层网关
我自己踩过的坑，基本能对上网关解决的四个问题：
- 成本可见性。没有统一入口，没人知道这个月 AI 到底花了多少、花在哪个业务上。网关天然是一个计量点，token 用量按业务线打标签，月底账单终于能拆开看。
- 供应商可替换。今天用 A 家，明天 B 家降价 60%，没有网关你就要改二十个调用点，有网关就是改一份路由配置。
- 稳定性兜底。模型超时、限流、返回畸形 JSON，这些错误以前在每个业务里各写一遍异常处理，现在统一在网关做重试、熔断和降级到小模型。
- 合规与审计。Prompt 和输出留痕、敏感词拦截、日志脱敏，这些不该让每个业务团队重新发明一次。
代价也真实存在：多一跳延迟，多一个需要 7×24 值班的东西，多一次和模型能力赛跑的适配成本。网关团队永远在追赶新模型的 API 变化，这是个体力活。
三、我的三个判断
第一，模型层的护城河很浅，接入层和数据层的护城河才深。模型三个月换代一次，谁都能调；但你的历史调用日志、自建评测集、人工标注的好坏样本，是别人拄不走的。
第二，中小团队不必自建网关，用现成的就行。工程量不在于转发请求，而在于把十几家模型的差异抹平并长期维护，这笔账对小团队不划算。
第三，别把业务逻辑写进网关。一旦路由层开始懂"订单业务该怎么答"，它就不再是基础设施，而是一个没人敢动的巨型 if-else。
工具会换，模型会换代，唯一沉淀下来的是你把不确定性收敛成可运维系统的那套工程判断。