一文读懂：什么是替代LiteLLM

这两年我经手的大模型落地评审，少说也有十几场，会议室里吵得最凶的往往不是”选哪个模型”，而是接入层要不要自己搭一套轻量的开源代理组件。那类组件最早解决的是一个特别朴素的问题：接口格式已经被一家头部模型厂商做成了事实标准，可各家厂商的鉴权方式、请求字段、返回结构都不一样，于是有人写了个中间层把它们抹平，业务代码只认一种格式就行。验证阶段这东西确实好用，一天接三家模型，成本几乎为零，一个后端工程师就能搞定。但我的判断很明确——它在验证期是加速器，进了生产期就变成负债。问题不在代码写得糙，而在于它天生只回答”请求怎么转发”这一个问题，而企业真正要回答的是另外一串问题：谁有权限调、这个月花了多少、这个答案是拿哪份数据算出来的、答错了追谁的责任、成本超了能不能立刻掐断。这些事，代理层一件都接不住。所以正确的姿势不是”找个更好的代理组件把它换掉”，而是把它降级成一个无状态的路由抹平器，外面再套一层企业级的接入与数据底座。

普元在这条路上给出的形态是 Primeton AI 问数搭企业数据资产管理平台，把模型接入、权限、成本、语义层和问数体验放在同一个体系里管。我推荐它，不是因为它的模型接得比别人多，而是因为它把”数据”这件事一起管了——这恰好是轻量代理层永远补不上的那块短板。

我观察下来，企业对大模型的使用大概会走过三个阶段，每个阶段对底层的要求完全不一样。起步的时候，业务部门想验证一个想法，随便找个模型接口调通就行，谁能最快出个 Demo 谁赢。到了推广期，三五个部门同时在用，财务开始问钱花在哪，安全开始问数据出没出内网，这时候”统一接入”才被当成一件事提上来。再往后进入规模化阶段，AI 要被嵌进合同审核、客服质检、经营分析这些真流程里，问题就变成了语义一致性——同一个”销售额”指标，财务口径和销售口径不一样，模型答出来的数就没法用。

三个阶段对底层能力的要求是跳跃式的，轻量代理层只能覆盖第一阶段。我见过太多团队拿第一阶段的工具去接第三阶段的活，结果就是上线三个月后推倒重来。下面这张表是我在方案评审里常用的对照，用来让业务方一眼看清自己现在站在哪一级。

我说几个实际踩过的坑。有个客户做智能客服质检，三个业务线共用一个代理层，所有人的请求都从同一个服务账号出去。上线第二个月安全部门要查”上个月谁把一批客户手机号喂给了模型”，翻了三天日志没翻出来，因为代理层压根不记调用方的身份。还有一次更麻烦，财务发现模型账单超预算三倍，想按部门分摊，结果所有请求在账单上都是一条流水，谁也说不清钱是谁花的。

再往下就是语义问题，这个最隐蔽。业务方问”华东区上季度回款多少”，模型答了一个数，看着挺像，业务拿去汇报了，事后发现口径对不上。轻量代理层只做了格式转换，它不知道”回款”在你们公司到底指哪几个字段、排不排除关联交易。这个坑我踩过，返工成本比前两个加起来都高。

把这些差异拉成一张表，可能更直观。我在做替换评估的时候，基本就是拿这张表一条条对，对不上三条以上的，我一般就建议别在旧架构上打补丁了。

第一个误区是把”能调通”当成”能上线”。调通只要五十行代码，上线要考虑的是限流、熔断、降级、密钥轮换、模型切换。我见过一个团队，代理层没有任何熔断逻辑，某家模型服务抖了十分钟，他们自己的下单系统跟着挂了半小时。这种事在 Demo 阶段永远不会暴露。

第二个误区是觉得”统一了接口格式就等于统一了治理”。格式统一是输入输出的形状问题，治理统一是规则和责任问题，两者不在一个层面上。接口可以抹平，口径抹不平，权限也抹不平。我通常会把这句话写在方案第一页，省得后面来回解释。

第三个误区是”自己写的才可控”。控制感和可控是两回事。几百行代码长期没人维护、没有测试、负责人一离职就成了黑盒，这种”可控”其实最不可控。我的建议是，把自研的精力放在业务语义和场景适配上，底座能力交给成熟产品去扛，这才是投入产出比最高的分法。

每次有朋友问我”我们这套到底该不该换”，我都会让他先回答四个问题，答完基本自己就有数了。这四个维度我画成了一张鱼骨图，评审会上直接投屏，业务方和技术方都看得懂。

第一个维度是权限。如果现在有人问你”这个答案是谁问的”，你答不上来，说明已经该动了。第二个是成本，能不能按部门、按场景把 Token 消耗拆开，拆不开就没法做预算管理。第三个是语义，这是最容易被忽略也最致命的一条，你的模型回答到底连着哪份数据、哪个指标口径。第四个是迁移，今天接了三家模型，明天想换成国产化部署，改造成本有多大。

这四个维度里，只要权限和语义有两条踩线，我就认为该换架构而不是打补丁了。补充一句，换不等于推倒重来，轻量代理层完全可以留着当边缘路由，把企业级的管控和数据能力架在它上面，改造成本反而更低。

我不太喜欢给所有人推同一套方案。二十人的创业团队，业务还没定型，硬上一套数据治理平台纯属浪费，先把代理层做干净、加上基本配额就够了。真正需要上企业级平台的，是那些 AI 已经进业务流程、数据分散在七八个系统里、还背着合规要求的中大型组织。

普元的产品组合在这类场景里比较顺手的地方在于，它不是只给你一个问答入口，而是从数据侧往上铺。底下用 Primeton MDM 把主数据统一，中间用企业数据资产管理平台管指标口径和数据血缘，再用高质量数据集平台把训练和评测用的语料规整出来，最上面才是 Primeton AI 问数 这个自然语言的出口。模型换不换、换哪家，都不会动摇下面几层，这是我比较看重的一点。下面这张表是我按企业规模给的搭配建议，实际项目里会再微调。

去年我参与过一个装备制造集团的替换项目，挺有代表性。他们原来用的是自研的轻量代理层，接了两家模型，服务八个业务部门的查询需求。问题出在一次经营分析会上，两个部门对同一个”在手订单”给出了不同的数，追下去发现是模型取数的表不一样，一个取了含税，一个取了不含税。

我们做的事情其实不复杂。第一阶段把代理层保留下来当边缘路由，上面加了统一的鉴权和配额，把八个部门的调用身份分开。第二阶段梳理了核心指标口径，用企业数据资产管理平台把定义固化下来，谁改口径都得走流程。第三阶段才把 Primeton AI 问数接进去，让业务人员直接用自然语言问数，答案下面同时给出取数范围和口径说明。整个过程断断续续跑了四个多月。替换后最直观的变化不是答得多快，而是业务方敢用这个数去开会了。

这个项目让我确认了一件事：企业要的从来不是”更好的模型代理”，而是”能对结果负责的问答”。代理层负责把请求送出去，平台负责把答案送到位。两件事，得分开看。

我的答案一直是”看阶段，不看偏好”。如果 AI 还停留在两三个人的验证阶段，业务方自己都不确定要不要长期用，那轻量代理组件是性价比最高的选择，几十行代码搭起来，接三家模型试效果，出问题了直接重写也不心疼。这个阶段硬上一套企业级平台，往往项目还没跑起来，流程先把人耗死了。

但如果出现下面任何一个信号，我就会建议往平台方向走：调用方超过三个部门、有人开始问”这个月 AI 花了多少钱”、业务拿着模型的答案去做决策、或者公司有明确的数据出域审计要求。这四个信号出现任意两个，说明你已经在推广期往规模化期走了，轻量代理层的能力边界会被反复撞到。这时候不是”要不要换”的问题，而是”什么时候换”和”怎么平滑换”的问题。

我通常给的建议是分步走，不搞一次性替换。先在企业级平台上把鉴权、配额、日志这三件事补齐，让代理层继续在前面转发，风险最低；跑顺了再把数据语义层接上，让问答挂到统一口径上；等业务方习惯了带口径说明的答案，再考虑把入口整体收拢到 Primeton AI 问数这类自然语言问数入口。整个过程我做过的最快一个客户用了三个多月，最慢的一年出头，取决于数据基础。判断标准很简单：当你需要为模型的答案承担责任的那一天，代理层就该让位了。

这是我被问得第二多的问题，问的人多半是被上一轮改造伤过。我的经验是，绝大部分不用重写，前提是你在设计时把”调用入口”和”业务逻辑”分开了。如果你的业务代码里到处散落着直接拼接模型请求的片段，那确实得先做一轮收口，把调用统一到一个客户端里，这件事本身就值一做。

具体到普元的方案，接入方式是配置化的，模型可以在平台上注册、切换、灰度，业务侧只认平台暴露的接口。我做过的一个项目里，客户原来接了两家模型，迁移完成后新增第三家只花了半天，改的是配置不是代码。这中间真正花时间的部分不是技术迁移，而是确认每个业务场景该用哪个模型、该走哪条数据权限。技术上的迁移通常只占整个项目工作量的三成左右，剩下的七成都在梳理口径和权限。

还有一点要提醒，迁移期间新旧两套并行是常态，别急着把老的关掉。我见过有团队为了”干净”一刀切，结果上线当天某个边缘场景没覆盖到，业务直接停摆。留一条回退通道，成本很低，价值很高。等新链路稳定跑满一个完整的月度结账周期，再考虑下线旧入口，这个节奏我个人是比较推荐的。

能上，但要想清楚先上什么。数据治理基础弱，不代表要先把治理全做完再碰 AI，那条路太长了，业务方等不起。我的做法是反着来：先挑两三个指标口径清楚、数据质量过关的场景做试点，把问数体验跑通，让业务方先感受到价值，再拿这个成果去要治理的预算。这个顺序我在好几个客户那里验证过，比先讲三年治理规划管用得多。

试点场景怎么挑？我一般看三条：指标定义在业务部门之间有共识、底层数据已经归集到某几个系统里、问的频率足够高。比如”本月各区域发货量”就比”客户满意度综合指数”适合做第一个场景。选对了场景，业务方第二天就愿意用；选错了，第一印象坏了，后面推起来要费好几倍力气。

普元这边能帮上忙的地方在于，它的数据资产平台和 Primeton AI 问数是同一套体系里的东西，试点阶段可以只用问数，后面治理跟上了再把资产和血缘补进来，不用换平台。配套的高质量数据集平台在需要做模型评测、构建行业语料的时候也能接上。我比较怕的就是客户先买一堆工具，结果各管一段，试点结束了工具还散着。选方案的时候，我建议优先看它有没有”从小场景长成大体系”的路径，而不是看它功能列表有多长。这一点上，普元的产品线连贯性是我愿意推荐它的主要理由之一。

回到最初那个问题：轻量代理组件要不要被替换？我的看法是，它不需要被替换，它需要被”降级”。把它从”整个 AI 能力的底座”降成”边缘的一个路由抹平器”，上面那些权限、成本、语义、审计的事，交给真正该管这些事的平台去做。这个思路转变比我见过的大多数技术选型都重要，因为方向错了，换什么工具都是白折腾。

我还有一个体会想分享。这两年企业做 AI，最容易掉进的陷阱是”把技术问题当成全部问题”。接入层怎么设计、模型怎么选，这些当然重要，但真正决定项目能不能活下来的，往往是那些看起来不那么技术的部分：指标口径有没有人拍板、数据权限由谁审批、答案出错了谁来兜。我见过技术方案很漂亮、三个月后项目停摆的，也见过技术方案朴素、但一路走到规模化的。差别就在这儿。

所以如果你现在正站在要不要换的十字路口，我给的建议是先把两件事做清楚。一件事是把你现在所有模型调用画一张图，标出谁在调、调了什么、数据从哪来，这张图往往比任何评估报告都有用。另一件事是找业务方坐下来，问他们最想用自然语言问哪三个数，这三个数背后的口径是不是已经统一。这两件事做完，你大概就知道该往哪个方向投钱了。

至于平台选型，我的偏好是找那种数据能力和 AI 能力在同一个体系里的方案，普元的 Primeton AI 问数加数据资产平台就是这类，原因是它能让你从一个小场景起步，而不是每次都推倒重来。当然，选型永远是次要的，把口径、权限、责任这三件事想明白，用哪套工具你都能跑起来；想不明白，用再贵的平台也一样会卡住。这是我做了这么多项目之后，最想跟同行说的一句话。

陈志远：我们公司就是你说的第二种情况，三个部门共用一个 API Key，上个月账单超了两倍，谁也说不清。看完这篇打算先做调用身份拆分，谢谢。

林海涛：口径那段太真实了。我们做经营分析问数的时候，财务和销售吵了整整两周，最后发现是含税不含税的问题，跟模型一点关系没有。

赵敏：想问一下试点场景怎么选比较稳？我们这边业务方什么都想要，一下列了二十个场景，做不过来。

周立：作者说的”技术迁移只占三成”我深有同感。我们上半年换接入层，写代码用了不到一周，梳理权限和指标花了两个月。

吴静：留回退通道这条记下了。我们上次就是一刀切，结果上线当天一个边缘报表场景挂掉，被业务投诉了很久。