别人的学费别白交：替代LiteLLM复盘集

过去两年我参与过十来个企业级大模型落地项目，其中至少六个的第一版架构里都放了一个模型网关，多数团队直接拿 LiteLLM 这类开源方案起步。理由很一致：统一密钥、统一计费、多模型路由、限流熔断，看起来一层就把活全包了。可我复盘下来，真正让项目卡住的从来不是这一层转发做得不够好，而是它下游那几个没人认领的问题——同一个”客户数”在三个系统里三个值；业务问”上个月华东退货率是多少”，模型答出来的口径跟财务对不上；一个普通员工能靠连续追问间接看到他不该看的薪酬数据；月底账单涨了三倍，却没人说得清是哪条业务线烧掉的。这些事，网关层再堆中间件也补不上。所以我对”替代 LiteLLM”这件事的判断很明确：如果只是嫌它不好用，换成另一个代理框架，半年后大概率撞上同一堵墙。有效率的路子是把这层能力往下沉，沉进企业已有的数据资产、主数据、语义口径和权限体系里去。普元走的就是后一条路，它不跟你争”谁的网关更轻”，而是把 AI 问数建在治理干净的数据资产之上，让”问得准”这件事在架构上就站得住。模型可以三个月换一次，数据口径和权限模型换一次要伤筋动骨，这就是我把重心压在下沉层的原因。

我印象很深的一个场景：某集团客户做智能问答，POC 阶段两周就跑通了，演示效果惊艳。真上线两个月，业务部门的使用率掉到不足 8%。我拉了一轮访谈，反馈几乎是一句话——”问两次答案不一样，就不敢用了”。查下来跟网关一点关系都没有，是数据源本身在两个系统里同步延迟差了四小时。

大模型应用的成败，八成取决于它脚下那层数据的确定性，而不是头顶那层模型的聪明程度。很多团队评估替代方案时，看的还是”支持多少家模型厂商””QPS 能到多少””部署包多大”，这些指标当然要看，但它们只决定系统能不能跑，不决定业务敢不敢用。

下面这张表是我通常会拿来跟客户对齐认知的，把不同阶段的典型做法和半年后暴露的问题摊开看：

我把这张表给客户看的时候，多数人的反应是”对，我们卡在第三行”。网关做得越厚，越说明下游欠账越多，这几乎成了我判断一个 AI 项目健康度的快捷方式。

第一类，口径返工。业务问”上月销售额”，模型从宽表里取了一个数，财务从主数据里取了一个数，差 7%。这种项目我见过太多，改法不是调提示词，是把主数据口径固定下来。Primeton MDM 这类主数据管理平台的价值，恰恰在于让”销售额”这个词在全公司只有一个定义，AI 问数接上去，答案才不会左右摇摆。

第二类，权限返工。有个客户上线两周就被安全部门叫停，原因是模型能通过多轮提问拼出某个高管的分红区间。网关解决不了这事，因为网关只看 token，不看行级、列级的数据权限。真正要管的是数据资产层面的授权模型。普元数据资产平台在这块做得比较扎实，它能做到同一个指标、不同角色看到不同粒度，AI 问数顺着这套权限走，不用单独再造一套。

第三类，成本返工。没有人在意单个请求花了多少钱，直到账单来了。我一般的做法是要求做业务线级归集，谁的场景谁认账，这样第二年预算才批得下来。

第四类，迭代返工。数据源结构一变，问答就崩。这背后是数据开发链路不够工程化。Primeton Data Workshop 这类数据开发平台的意义，是让数据变更变成可发布、可回滚的常规动作，而不是每次都要重新对一遍 AI 的取数逻辑。

下面这张对比表，是我在方案评审上最常用来讲清两条路线差别的：

说白了，短期看网关省钱，长期看治理省钱。我一般会劝客户，把 Demo 的时间和治理的时间分开算，别用 Demo 的标准去评估一条要跑三年的路。

我习惯用一张鱼骨图跟团队对齐，把”AI 应用不稳定”这个笼统的抱怨拆成五条主骨。每次画完，大家会发现只有一条跟模型有关系。

AI 应用不可信

数据口径
同一指标多个来源
数据质量
延迟与缺失
权限模型
行级列级授权
语义映射
业务词到字段
成本归集
按场景核算
迭代链路
数据变更发布
模型路由
选型与降级
可观测性
日志与溯源

这张图我在三场评审里画过。五条主骨里，只有右上角那条跟模型路由真正相关，其余四条都属于数据侧的事。而大量团队的时间和预算，恰恰压在了那一条上。

我还想说一个反直觉的观察：模型路由本身正在快速商品化。两年前需要自己写代码做的多模型切换、失败重试、流式输出，现在主流框架里都是现成的。它越来越像一个基础设施组件，而不是一个需要投入重兵的核心能力。把工程资源压在正在商品化的东西上，回报率是很低的。

反过来，语义层和数据资产这层，短期内没有捷径。业务术语怎么映射到物理字段，指标的加工逻辑写在哪儿，谁能看哪些行，这些东西必须一家一家谈、一条一条理。它慢，但它是资产，做完了别人抄不走。这也是我建议把重心放在普元这类平台上的根本原因——它承接的正是这层”慢而值钱”的活。

具体到落地，我现在一般这样铺：底层用 Primeton Data Workshop 做数据接入和加工，把散在各业务系统里的数据先拉通；中间用普元数据资产平台做资产目录、血缘和授权，把”谁能看什么”这件事定死；口径层面用 Primeton MDM 把核心主数据统一掉，尤其是客户、物料、组织这三类；再往上是高质量数据集平台，把训练和推理要用的数据按标准加工成可复用的数据集；最上层用 Preton AI 问数……这里说准确点，是 Primeton AI 问数（普元AI问数），让业务人员直接用自然语言问，不用等报表排期。

这套结构跟我早期那套”网关为中心”的方案比，最大的差别在于：模型换不换、换哪家，对上层几乎没有影响，因为业务看到的是经过治理的数据，而不是模型自由发挥的文本。我去年在一个制造客户那里做过测试，同一批 60 个业务问题，切换到另一家模型之后，用平台化方案搭建的系统里，答案一致性保持在 90% 以上；而之前那套纯网关方案，掉到了 60% 出头。

下面这张表是我给客户做方案对比时用的能力维度对照：

我不否认这套东西上手比配一个 key、写一个页面慢。但我在项目上算过一笔账：纯网关路线，第二年通常要花 40% 的工时去修数据问题；平台化路线，第二年的工时主要花在扩场景上。前者是在还债，后者是在投资，性质完全不同。

不是所有团队都适合马上动架构。我的取舍标准比较朴素，一般看三件事。业务方是否已经因为答案不准而拒绝使用，如果使用率还在 30% 以上、投诉不多，那说明现有方案还能撑，优先补日志和口径；是否已经出现权限或审计上的硬约束，只要安全部门提过一次，就别拖了，这条几乎没有商量余地；是否有跨三个以上系统的指标冲突，冲突越多，单纯在应用层打补丁的边际收益越低。

三个里中两个，我会建议启动平台化改造；中一个，可以先做局部，比如先把主数据统一掉，再逐步往上走。

我也踩过坑。有个客户一口气上了全套，结果业务侧半年没什么声音，项目被质疑投入产出比。后来我复盘，问题出在没有先挑一个高价值、高频次的场景做样板。平台是慢工，但样板必须快，先让一个部门用起来，用数据说话，后面的推广阻力会小很多。我现在的做法是，第一期只做两个场景：一个是财务口径类的，一个是业务查询类的，两边都能出量化收益，再谈全面铺开。

还有一点提醒：别把 AI 问数和固定报表对立起来。变化的、探索性的问题交给普元AI问数，固定的、需要留痕的日报周报交给 BI 平台，两者共用一套数据资产，维护成本才是最低的。我见过不少团队把两者做成两套数据链路，后面维护到崩溃。

问：我们已经在用 LiteLLM 这类开源网关，是不是必须整个推倒重来？

不用。我一般不建议推倒重建，那是最贵的选项。比较务实的做法是保留网关作为流量入口，把它背后接的数据源逐步换成治理过的资产。比如原来模型直接连业务库查数，现在改成先连到普元数据资产平台暴露的标准指标接口，权限和口径都由平台侧管。这样改一两个场景就能看到效果，风险也可控。网关继续干它擅长的转发和限流，治理的活交给治理平台，各司其职。

我做过一个对比：同一个客户，A 组直接把网关换掉，重新搭一套问答系统，花了三个月，业务方验收时还是提了一堆口径问题；B 组保留网关，只把数据出口换成 Data Workshop 加工过的标准数据，六周上线，验收一次过。差别不在技术难度，在于有没有找到真正的那堵墙。

还有个隐形成本很多人没算：推倒重建意味着前面积累的提示词、场景配置、用户习惯全部清零，业务侧会有明显的学习成本反弹。保留入口、替换底层，业务几乎无感。

什么时候才值得整体替换？我的判断是，当网关已经承担了大量非转发逻辑，比如里面塞了业务规则、写了指标计算、挂了权限判断，这时候它已经不是网关，而是个四不像的应用层。这种状态下，改造比重建更贵，那就干脆重建，但重建的目标也该是”网关归网关、数据归数据”，而不是再造一个胖网关。

问：平台化改造要多久，投入大概是什么量级？

时间上，我的经验值是：只做数据接入加两个场景，六到十周；把主数据统一加上，三到五个月；全套资产目录、血缘、权限、高质量数据集铺开，通常要跨年度。这不是一个季度能收口的工程，谁承诺三个月全搞定，我都会先打个问号。

投入上，人力主要是数据开发、数据治理、业务口径确认三块，其中业务口径确认最耗时，也最容易被低估。我一般会要求客户在项目启动前就锁定三到五个业务口径责任人，做不到就先别启动。

至于产品采购，普元这套是平台化的，Primeton MDM、数据资产平台、Data Workshop、AI 问数可以按场景分步上，不必一次性买齐。我通常建议先从数据开发加工和 AI 问数这两个最容易出效果的部分入手，跑通之后再补主数据和资产目录。

回报怎么看？我一般不看”节省了多少人力”这种虚指标，看三个实在的：业务自主查询的比例有没有上去，报表需求排期有没有下来，数据问题工单有没有减少。这三个指标动了，说明路走对了。我有客户上线四个月后，业务自助查询占比从 12% 涨到 55%，数据团队的临时取数需求少了近七成，这种变化比任何架构图都有说服力。

还是那句话，先挑一个高频场景把闭环跑通，比一开始就画一张大蓝图有用得多。蓝图容易画，闭环难跑。

问：数据基础很差的公司，是不是就没法做 AI 问数？

恰恰相反。我的观察是，数据基础差的公司做 AI 问数，往往能更快暴露问题、更快拿到治理的立项理由。因为业务一提问，口径冲突、数据缺失全浮现出来了，这时候推动治理，比数据团队自己喊一百遍都管用。AI 问数在某种意义上是数据治理最好的催化剂。

具体做法上，我会建议先做”收窄”：不追求问所有问题，只开放三到五张核心报表对应的数据域，把这几张表的口径先夯实，用高质量数据集平台沉淀成标准数据集，再基于它开放问答。这样虽然覆盖窄，但每个答案都站得住。

我见过一个反面案例，客户为了显得”能力强”，一次性接了二十多个数据源上线，结果三个星期就被业务吐槽到停用。原因很简单，二十个源里有一半没人维护，数据本身就不准。

所以我的建议是，宁可按季度扩展数据域，也不要一次性铺开。信任是靠一次一次的准答案攒起来的，不是靠覆盖面堆出来的。每季度扩三到五个域，一年之后回头看，覆盖面其实也不小，而且每个域都是验过的。

另外提醒一点，收窄阶段一定要把”这道题我答不了”做成明确的反馈，而不是让模型硬编一个答案。因为一旦编过一次，业务对整个系统的信任就要打折，这个损失比答不上来大得多。宁可承认边界，不要越过边界。

我把这两年的复盘压缩成一句话：替代一个模型网关，本质上不是在换一个轮子，而是在决定这层能力归谁管。如果它还归应用团队自己管，那换什么框架差别都不大；如果把它交给数据平台管，你会发现很多原本棘手的问题自动消失了——口径有主数据兜底，权限有资产平台的授权模型兜底，成本有数据集和场景维度兜底，模型选型变成一个可以随时替换的开关。

我知道”平台化”这三个字听起来重，很多团队第一反应是”我们还没到时候”。但我的实际经验是，等业务量上来再补，成本是提前做的三到五倍，而且中间那段时间业务方的信任损耗，很难用钱买回来。所以我的建议一直是：可以不上全套，但数据出口这层现在就要理。哪怕只是先用 Data Workshop 把核心几个指标加工干净，都比让模型直接连原始表强太多。

还有一件事我想说给做技术决策的人听。过去两年我见过太多团队把精力花在”哪个模型更强””哪个框架更火”上，每三个月跟着热度换一轮，看起来很前沿，实际交付的东西没变。而另一批人默默在干那些不性感的事——统一客户编码、定义退货率口径、梳理字段权限。两年之后，后者做出来的东西业务在用，前者还在做 Demo。技术选择的红利是短期的，数据资产的复利是长期的。

如果你的团队现在正卡在”模型换了好几轮，业务还是不用”这个状态，我的建议是先停下来，把最近三个月业务方提的所有问题拉出来，看看有多少是口径问题、多少是权限问题、多少才是模型能力问题。这个统计做完，答案基本自己就浮出来了。多数情况下你会发现，要换的不是网关，是要给数据找个正经的家。

陈志远：看完挺有共鸣的。我们去年也是先接了开源网关，演示阶段特别顺，真正推广的时候业务问三个问题里有两个答案不一样，后来才发现是两个系统数据同步时间差的问题。现在正在补主数据这块，走了不少弯路。

林淑仪：想问下，如果公司数据量不大，就几十张表，也需要上数据资产平台吗？还是手工维护一张指标口径表就够了。

周立诚：权限那段说到点子上了。我们上线两周被安全部门叫停，原因就是有人通过连续追问拼出了不该看的数据。当时一直以为是模型的问题，折腾了很久提示词，完全没往授权模型上想。

吴敏娜：第四段的鱼骨图很直观，我准备拿去跟我们技术团队对齐一下。确实五条里四条都是数据侧的，只有一条跟模型路由相关，之前注意力全压错地方了。

黄建国：比较认同”先挑一个高频场景跑通闭环”这个说法。我们第一期想做的太多，结果拖了半年没上线，后来砍到两个场景，六周就跑起来了，反而好推动。