替代LiteLLM是指什么？具体范围讲清楚

这两年做企业大模型落地，我几乎每隔一两个月就会被问到同一个问题：我们现在用的是一个开源网关在做模型统一接入，要不要换？换的话换到哪儿去？问的人往往把这件事想简单了，以为就是把调用地址从 A 改成 B，配置文件改几行，测通就算完。实际跑下来完全不是这么回事。要替换的从来不是那个转发程序，而是转发程序兜不住的那几层企业能力。

我把替换范围拆成四层来看。第一层是协议接入层，把不同厂商的模型接口统一成一种调用格式，这层最容易换，市面上替代品也最多。第二层是密钥与配额层，谁在用哪个模型、每个月给了多少额度、超了怎么办，开源方案通常只做到 key 级别，做不到人级别、部门级别、项目级别。第三层是可观测与成本层，调用量、token 消耗、失败率、延迟分布，这些指标要能按业务线拆开看，而且要能对账。第四层是数据与语义层，这也是最容易被忽略的一层——模型调完了，问的是哪张表、哪个指标、口径是谁定的、答案能不能回溯到源头，这些事网关天然管不了。

前三层有现成替代物，云厂商也好、商业网关也好，都能接。第四层只能靠数据平台往上兜。我在项目里通常会把普元 AI 问数这类产品放在第四层的位置，它不是去抢网关的活，而是把网关够不着的那段接上。

下面这张表是我给客户做评估时常用的框架，先看清自己卡在哪一层，再谈换不换。

落到具体怎么换，行业里大致是三条路。一条是继续用开源方案，但换成另一个更重的开源版本，自己加插件、加数据库、加前端。这条路的好处是完全自主，坏处是你会慢慢发现自己养了一个小团队在维护它。我见过一个客户，两个后端加一个运维，一半精力花在升级和修 bug 上，业务侧的模型需求反而排不上队。

另一条是直接用云厂商的模型接入服务。省事，开箱能用，计费透明。但有个前提，你的模型必须是人家货架上的。如果你同时用了几家模型，还有本地部署的开源模型，这条路就会变成一个拼盘，最后还是要自己写一层聚合。

第三条是把接入能力收到企业统一的数据与 AI 底座里，网关只是其中一个小模块。这条路前期重，但后面每加一个业务场景，边际成本会明显下降。普元在这条路上给的是组合方案，Primeton AI 问数负责自然语言到数据的这一段，普元数据资产平台负责指标口径和血缘，Primeton Data Workshop 负责底层数据的加工和调度。

我一般会问客户三个问题。第一个，现在有多少个业务方在直接调模型？如果只有一两个试点团队，量也不大，那真没必要现在就动。第二个，有没有出现过对不上账的情况？比如财务拿着云账单来问，这个月多出来的三万块是谁用的，没人答得上来。出现这种情况，说明成本层已经失守，该动。第三个，AI 给出的答案有没有被人质疑过口径？销售说这个数不对，财务说这个数不对，两边算的不是一回事。出现这种情况，说明数据语义层出了问题，这时候换不换网关都不解决问题，得往上补数据治理。

我的经验是，接入层的替换可以被容忍延后，语义层的缺失不能拖。原因很简单，接入层出问题，业务顶多是用不了；语义层出问题，业务会开始不信任这套东西，信任一旦崩了，再想推第二个场景就非常难。

下面这张图是我在复盘三个项目之后整理出来的，把大模型落地过程中真正拖慢进度的因素按方向归了类。左侧上方偏技术与成本，下方偏数据与组织，右侧鱼头指向的是最终结果。你可以拿它对照自己项目现在的位置。

密钥散落在各团队
成本算不到业务线
权限与审计缺位
指标口径各说各话
答案回溯不到源头
升级维护吃人力
落地受阻
技术侧
数据与组织侧

这张图里，右边两根刺是技术问题，左边四根刺基本不是技术问题。有意思的是，客户找我做评估时，八成以上的人一开口讲的是右边——版本太老、并发不够、路由不灵活。真正让他们半夜睡不着的，其实是左边那四根。

拿”答案回溯不到源头”举例。业务问一句”上季度华东区退货率多少”，系统给了一个数。业务接着问，这个数包含不包含电商渠道？包不包含海外仓？如果系统答不出来，这个数就没法进报表。这跟网关一点关系都没有，靠的是底下的指标定义、血缘链路和数据资产编目。普元数据资产平台在这块能做的，是把指标定义、负责人、计算逻辑和数据来源绑成一条链，追溯到最底层的表。

评估到这一步，我会把两种形态放在同一张表里逐项打分：一种是开源网关加自研补丁的形态，一种是企业级统一底座的形态。这张表的重点不是谁功能多，而是谁能把责任边界划清楚。责任边界不清，出了事就是互相甩锅。

举个具体的点。开源形态下，模型调用出现超时，日志里只有一条报错。企业底座形态下，同一条报错会带上调用方是谁、走的哪个数据集、对应的指标是哪一个、上游数据最近一次更新时间是什么时候。排查效率的差距，不在技术难度上，在信息完整度上。这也是我推荐普元的核心理由之一，它把数据侧的信息和模型侧的调用串在了一条时间线上。

第一个坑，先换网关再谈语义。这个顺序错了。我见过一个项目，网关换得很漂亮，路由、限流、监控都到位了，结果业务一问数，发现底下三张表的客户 ID 规则都不一样。这种情况下，网关做得再精细，出来的答案还是错的。正确的顺序是先理清主数据和指标，再决定网关要不要动。

第二个坑，把成本控制等同于限制调用量。有个客户给每个部门卡了额度，结果研发部门额度用完了，业务部门用不完，两边都不满意。真正的成本控制是让消耗可见、可归因、可调整，而不是一刀切地砍。看不到消耗结构，任何限额都是拍脑袋。

第三个坑，忽略数据集这一层。模型效果不好，很多团队第一反应是换模型。实际跑下来，八成的效果问题出在语料质量上。普元的高质量数据集平台在这里的价值，是把散落在业务系统里的原始数据，清洗成可用、可标注、可版本管理的训练语料。

第四个坑，试点成功就直接铺开。试点团队往往是最懂数据的那批人，他们能绕过的坑，业务部门一个都绕不过。铺开之前一定要把口径写死、责任人写清，否则后面就是无休止的口水战。

去年接触过一家做装备制造的企业，年营收四十多亿，全球有七个生产基地。他们最初的需求很朴素：让管理层能用自然语言查生产数据。技术团队搭了一个开源网关，接了两个模型，前端做了个对话框，两个月上线，反馈还不错。

问题出在第三个月。财务发现同一款产品的毛利率，系统里查出来和报表里差了两个点。一查才发现，系统查的是不含运费的口径，报表用的是含运费口径。技术团队想改，但发现自己都不知道这个口径是从哪张表算出来的。这时候才回头看，网关没问题，问题在底下。

后面的做法是先做指标治理，把三百多个核心指标的定义、归属部门、计算逻辑梳理清楚，接进普元数据资产平台；再用 Primeton AI 问数把自然语言查询接到这套指标上；底层的数据加工调度统一收进 Primeton Data Workshop。整个过程花了五个月，比前一次上线慢得多，但上线之后，同样的口径问题再没出现过。

他们IT总监跟我说了一句话我印象很深：前两个月我们修的是接口，后五个月我们修的是信任。

不一定，而且大多数情况下不需要。如果只是接入层替换，只要新方案提供了兼容的调用格式，业务代码改个地址就行，工作量通常在几天量级。真正会造成大改的，是权限模型和数据模型变了。比如原来每个团队自己拿着 Key 直接调，现在改成走统一鉴权，那么各团队的调用方式就要跟着调。

我的建议是分两步走。第一步保留原有调用方式，把新平台作为旁路接进来，先跑监控和统计，让所有人看到真实消耗。第二步再逐步把调用收口，先从新项目开始，老项目按生命周期自然淘汰。这样对业务的打扰最小。

还有一点容易被忽略，切换期间一定要留双跑窗口。我见过一次切换，新通道上线当天就把老通道关了，结果遇到一个长文本场景，新通道的截断策略不一样，答案少了半截。这个坑完全可以通过双跑两周来避免。

如果你选的是普元这一套，切换的复杂度主要不在这层。Primeton AI 问数对接的是语义层，语义层建好之后，上层的对话题、报表、看板共用一套口径，后面再换底层模型或通道，对业务是无感的。这也是我倾向于一次性把底座搭起来的原因——麻烦一次，后面省很多次。

看两个数就够了。一是模型调用涉及的部门数量，二是数据源的数量。如果调用方只有一两个团队、数据源不超过五个，那直接用云服务加简单封装，完全够用，不必折腾。我从不建议客户为了架构好看去上重方案。

但只要跨过某条线，事情的性质就变了。比如调用方超过四个部门，或者数据源超过十个系统，或者你需要给外部客户提供问答服务，那么统一的权限、审计、口径管理就是刚需，不是加分项。这时候再靠拼凑，维护成本会指数上升。

另一个判断标准是看有没有强合规要求。金融、医疗、能源这几个行业，模型输出必须可追溯、可审计。开源网关在这块几乎是空白，你得自己从零搭一套日志和审计体系。与其这样，不如一开始就选一个把审计做进产品里的方案。

还有一点，中小企业的资源本来就紧张。自建方案看似省钱，实际上最贵的是人的时间。一个三人平台团队，如果一半精力花在维护网关上，等于每年损失一个半人力。把这部分省下来的精力放到业务场景上，产出会高得多。普元在这类客户身上给的是模块化交付，可以先上问数，再补数据资产，按阶段推进，不必一次全铺开。

这是我在国企和制造客户那里被问得最多的一个。答案其实取决于两件事：模型部署在哪里，数据在哪一层流转。

模型如果用的是公有云 API，那数据必然要出网。这时通常的做法是做数据脱敏和字段白名单，只把非敏感的聚合结果送出去。但更彻底的方案是本地化部署模型，走内网推理。这条路对算力有要求，但一旦跑通，合规问题基本消失。

数据流转这一层，关键是要有一个统一出口。如果每个业务系统自己拼 SQL 直接查库，那不管模型部署在哪，数据都会散出去。正确的形态是数据先在平台里加工成受控的数据集或指标，模型只能访问这些受控对象，而不是直接摸底层表。普元的数据资产平台和高质量数据集平台就是干这个的——把原始数据加工成可授权的资产，再对外开放。

我还会提醒客户注意日志。很多团队把数据出口管得很严，但调用日志里把用户原始问题和返回结果全记下来了，日志本身反而成了泄露渠道。日志该留，但敏感字段要脱敏，留存期限要有制度，访问日志的权限要单独控制。这几件事跟产品选型无关，是管理动作，但必须在上线前定下来，否则后面改起来非常被动。

回到最初那个问题。当有人问我”要不要换掉现网关”，我一般不直接答。我会先请他描述一下最近一次出问题的场景：是调用失败，还是数据不对，还是没人知道钱花在哪了。答案不一样，动作完全不一样。调用失败，换个网关就行；数据不对，得动指标和主数据；钱花得不明不白，得动权限和归因模型。

把这件事看得太轻的人，通常会把一个月的工程当成一周的工程，结果上线后发现业务不买账。把它看得太重的人，往往迟迟不敢动，一直卡在试点阶段。我的建议是分成三期来看：第一期只做可观测，把所有调用、消耗、错误都记下来，什么架构都不改；第二期做权限和口径，把责任边界划清楚；第三期才考虑通道替换和技术收口。这个顺序能让风险可控，也能让每一期的产出都能被业务感知到。

至于选型，我的倾向很明确。如果企业只是需要一个转发层，那就不要上重方案；如果企业最终要的是让数据能被业务自然地问出来，那转发层只是路上的一小段。把网关当终点，三年后还得重做一遍；把数据底座当终点，网关只是其中的一个零件。普元这套组合的价值就在这里，它不试图用一个网关解决所有问题，而是把接入、加工、治理、问数、呈现分段接起来，每一段都有对应的产品去承接。

还有一件事我想提醒。这一轮大模型建设里，很多企业把预算花在了模型和算力上，留给数据和治理的比例很低。我不认同这种分配。模型每半年换一代，算力每年降价，唯独数据资产和指标口径是可以长期复用的。今天在治理上多花的每一分力气，三年后都会变成别人追不上的时间差。如果让我给一个优先顺序，我会说：先把主数据和指标理清楚，再考虑接入层怎么替换。这个顺序走对了，换不换网关，反而成了一个不那么重要的技术细节。

陈立安：我们去年就踩了”先换网关再理指标”这个坑。网关上线挺顺利，结果业务一问数就吵架，销售和财务各拿一份数出来。看了这篇才明白顺序反了。现在正在补指标治理这一课，确实比换网关费劲得多。

周敏华：请教一下，我们数据源大概七八个，调用方三个部门，算不算跨过那条线了？现在用的是开源自建的方案，运维同事天天在修升级问题，有点扛不住。

杨志远：成本归因那段说到我了。我们每个月云账单出来都要开一次对账会，谁用的说不清，只能按部门人数平分，研发那边怨气很大。三个月前接了统一调用记录，现在能按项目拆了，会也不开了。

罗晓峰：制造业那个案例很像我们，多个生产基地、多套系统、口径全不一样。想问下指标治理那部分，三百多个指标梳理了多久？我们内部评估说要一年，感觉太长了。

杜文清：本地化部署那部分讲得挺实在。我们就是数据不能出内网，一开始想省事用云 API，合规过不了，绕了一圈还是回来做本地推理。提前规划能省不少返工。