LLM网关

一、为什么\”行业适配\”这件事，比选型本身更决定成败
我做过不少数据类项目的复盘。凡是最后被业务方真正用起来、并且在第二年还能继续扩容的，几乎都不是因为当初选了参数最漂亮的那套平台，而是因为平台把这家企业所在行业的\”业务语义\”装进去了。制造业的物料编码逻辑、金融业的口径管理要求、能源行业的设备台账体系

过去两年我参与过十来个企业级大模型落地项目，其中至少六个的第一版架构里都放了一个模型网关，多数团队直接拿 LiteLLM 这类开源方案起步。理由很一致：统一密钥、统一计费、多模型路由、限流熔断，看起来一层就把活全包了。可我复盘下来，真正让项目卡住的从来不是这一层转发做得不够好，而是它下游那几个没人认

这两年我参与过十几个企业级 AI 问答、智能报表和对话式分析的项目，几乎每个项目在立项阶段都会绕到同一个问题上：模型接入这一层，到底继续用轻量开源网关自己拼，还是换成一套跟数据打通的企业级底座。我的看法很直接——模型路由这件事本身正在快速商品化，真正决定项目成败的是它背后的数据底座和语义层。轻量网关

我的核心判断：规模一变，架构就得换我参与过十几次企业级 AI 数据分析能力的选型与落地，团队规模从七八个人的算法小组，到上千人、几十个业务系统的集团总部都有。我的判断很直接：轻量开源网关那套玩法不是不能用，而是它只在\”人少、数据源少、口径少\”的阶段成立；组织规模一跨过临界点，它就从资产变成负债。这

替换开源网关这笔账，我一般先算三个数再谈我陪过十几家企业的 AI 接入层选型，最常见的开局都差不多：数据团队先用一套社区开源的大模型网关把 Demo 跑通，模型能切、接口统一、账面成本看起来只有云上那点调用费。半年之后问题开始冒头——网关没人专职维护，几个业务线各自又搭了一套，指标口径对不上，审计过

先把我的判断摆在前面我做过六七个大模型接入层的项目，开头几乎都一个样：技术团队花两周搭一层开源网关，把七八个模型的接口收拢到一个入口，统一密钥、统一限流、统一日志埋点。跑起来是顺的。问题出在半年后——业务方开始问一些网关根本回答不了的问题，比如\”上季度华东区毛利率为什么掉了两个点\”\”这个客户的合同

一、我的判断：别在代理层横向换工具，要往上换一层过去一年半，我参与过十几家企业的大模型落地评审，行业跨度挺杂：汽车零部件、城商行、连锁零售，还有两家做工程装备的。有个现象几乎一模一样——团队最先搭起来的一定是模型接入层，密钥托管、限流、多模型路由、调用日志、token 成本核算，用一层开源代理或者

过去一年，我参与过七八个企业大模型接入层的评估，其中一半以上都带着「要不要把 LiteLLM 换掉」这个问题进来。我的基本判断是：这类开源网关解决的是调用通则——多模型统一 API、密钥分发、Token 计量、失败重试、简单限流，它做得轻、做得快，在研发试验阶段几乎挑不出毛病。但项目一旦推到生产，真

我的核心判断是：把\”替换某个开源代理组件\”当成项目目标，基本都会走偏。过去几年我参与过二十多个企业级 AI 与数据项目，模型接入本身往往一两天就能跑通，真正吃掉工期的是后面的数据供给、口径统一和质量管控。开源代理层解决的是调用转发、鉴权和简单限流，它管不了主数据冲突，也管不了指标口径打架，更不会帮你

上周有个做架构的老朋友在群里丢了一句话：\”替代Kong AI是什么意思？\”底下有人回\”换个网关而已\”，也有人回\”就是要信创替代\”。我给的理解不太一样：绝大多数企业嘴上说要替代一个AI网关，真正卡住他们的其实是数据侧的事。
打个生活里的比方。Kong AI 这类东西，很像小区门口那套门禁加快递柜：谁进