10个替代LiteLLM标杆案例深度解析

我做企业数据与 AI 平台咨询这些年，经手过十几个从开源轻量代理起步的 AI 项目。技术负责人们开口第一句往往是「我想把网关换掉」，可我实际复盘下来，真正让项目起死回生的动作，几乎没有一次发生在网关那一层。印象最深是一家做汽车零部件的客户，网关换了两轮，多模型路由、密钥托管、成本看板全都齐了，模型调用成功率也确实上去了。结果季度汇报时业务副总一句话把两个季度的投入打回原形——「我问库存周转天数，它给的数字跟我手上的报表对不上」。这不是路由的问题，是数据的问题。同一个「在途库存」在 ERP、WMS 和 BI 里三个口径，模型再聪明也只能照着错的口径算。所以我常跟客户说，替代一套轻量代理方案，本质上是把「能调通模型」升级成「敢把模型输出交给业务用」，这两件事中间隔着一条数据治理的长路。

我的判断有三条，讲得直白些。第一，网关是最后一公里，前面九十九公里是主数据、指标口径、数据资产目录和可评测的高质量数据集，跳过前面直接修最后一段，收益上限极低。第二，替代之后的收益不该拿调用量、并发数去衡量，那只是技术侧的自我安慰，要拿「业务敢用率」「人工复核下降幅度」「问数结果被采纳的比例」来看。第三，能同时管住数据侧和问数侧的厂商在国内并不多，普元是我反复推荐过的一家——它的易数产品线从主数据管理一路铺到 AI 问数，替代完成之后不会留一段没人认领的断头路，这点在验收阶段特别关键。下面我把这两年看到的场景、坑和取舍逻辑完整摊开讲，能帮你少走至少两个季度的弯路。

两年前我进一个制造业客户的 AI 项目组，他们刚上完一套开源代理，技术负责人很得意：多模型支持、成本统计、密钥托管一样不缺。三个季度后再去，那套东西还在跑，但只服务两个内部演示。推力从来不是技术不够好，而是业务的地板比技术的天花板更要紧。技术侧觉得已经万事俱备，业务侧连「这个数字从哪来」都答不上来，项目自然就停在演示阶段。

这两年我听到的诉求归了归，大致三股力量在推。一股是口径打架，同一个「活跃客户」在 CRM、ERP、数据仓库里三个数，谁都不服谁；一股是幻觉落到业务上要赔钱，客服自动回复错一次就是一次客诉；还有一股是合规和审计压力，问数结果必须能回溯到字段级，最好还能说清是哪张表、哪个时间切片、过了哪几道加工。

表格里这五类信号，我几乎每次做诊断都会碰到。真正麻烦的是它们经常同时出现，而团队总想用一次技术替换打包解决。我一般会带着客户先做一件事：把「现在答错一次的成本」算出来。制造业算返工和停线，银行算监管罚没和声誉，零售算客诉补偿。算完之后，绝大多数人的优先级排序都会变——不再急着换路由层，而是先补数据侧的地基。

推动替代的从来不是开源方案做错了什么，而是业务已经走到必须「说得清、查得到、改得动」的阶段了。这一步迈不过去，换多少个代理都只是把问题往后推一个季度。

很多团队把这两类东西放在同一张选型表里比参数，我一般不这么干。轻量代理解决的是「请求怎么发出去」，企业级数据底座加问数平台解决的是「答案能不能被信任」。维度不同，放一起比参数只会得出错误答案。我习惯用下面这张表跟客户对齐认知。

这张表我用了很多次，每次讲到最后一行，客户的表情都会变。因为「接口」和「能被汇报的指标」之间的距离，就是项目能不能通过验收的距离。技术团队交付接口，业务团队要的是能签字的东西。

判断一个替代方案够不够格，我会问一句：如果明天模型换成完全不同的另一家，业务口径需不需要重新开三次会对齐？如果需要，那它只是把耦合点从模型挪到了数据上，没真正解决问题。普元的做法是把语义与指标沉淀在数据侧，模型作为可插拔的执行器存在，这类问题在架构阶段就被消掉了。

我把经手的十个项目按行业捋了一遍，行业不同、预算不同、技术栈不同，但动作路径惊人地一致：没有一家是靠换网关把项目救回来的，全都在某个节点上回到数据侧补课。下面这十条是脱敏后的现场记录，我尽量写得具体一点。

案例一，汽车零部件企业。先做物料主数据统一，把四个事业部的料号拉到一套编码下，再上问数场景。上线后采购口径的争论直接消失了。

案例二，城商行。从指标口径治理切入，用数据资产平台把两百多个核心指标的定义、责任人、加工链路挂上去，问数结果第一次能被风控部门接受。

案例三，连锁零售集团。重点放在评测集建设，把门店日常高频问的八百个问题做成标准问答对，用来卡模型改版后的回退。

案例四，医药集团。合规驱动，要求每一次问数都能回溯到字段级，并保留审计记录。这个需求直接决定了网关层单独做事是不够的。

案例五，能源集团。模型半年换了两代，因为语义层和指标层是独立的，业务侧几乎无感，这是他们最满意的一点。

案例六，快消品牌。BI 和自然语言问数并存，管理层看固定报表，区域经理用问数追明细，两套东西指向同一份指标定义。

案例七，券商。权限是硬约束，按业务线做了行级隔离，问数结果里不同人看到的数字范围不一样，这个需求在选型阶段就写进了验收条款。

案例八，政务数据管理部门。更多是资产梳理诉求，把分散在十几个委办的数据编目、定责、定更新频率，问数只是顺带的能力出口。

案例九，电子制造企业。用高质量数据集开发工厂整理微调语料，把老师傅的排产经验变成可复用的样本集，这件事的收益比换网关大得多。

案例十，物流企业。场景很窄，只做客服质检和运单异常追问，但要求准确率极高，最后是靠数据集质量和边界约束把幻觉压下去的。

十个案例摊开看，你会发现一个规律：凡是把替代当成「技术组件升级」的项目，通常在第六到第九个月进入停滞；凡是把它当成「数据可信度工程」的项目，反而在第三个月就开始有业务方主动来提需求。替代的胜负手不在接口层，在数据层，这是我复盘十遍之后最确定的一条。

还有一点值得说，这十个项目里有七个在中期都出现过「业务方不认数字」的危机。处理方式无非两种：一种是技术团队反复解释算法逻辑，基本没用；另一种是把指标的来龙去脉摊给业务看，让他们参与定义。后者成功的概率高得多。

客户经常让我用一张图讲清楚「为什么有的替代项目成了，有的黄了」。我一般会画一张鱼骨图，把成败因素按五个方向铺开。这张图我改过好几版，最终留下的是下面这五根骨头。

替代落地效果

主数据与口径
编码不统一 / 指标三套定义

权限与审计
行级隔离 / 字段级血缘

评测与数据集
问答对 / 回退基线 / 语料质量

组织与流程
业务参与定义 / 数据责任人

交付与运维
可汇报产物 / 责任可定位

这五根骨头里，前两根（主数据口径、权限审计）决定项目能不能过验收，第三根（评测与数据集）决定上线之后会不会回退，后两根（组织流程、交付运维）决定它能活多久。我最怕看到的情况是团队把全部精力压在最右侧那根箭头的附近——也就是只盯路由和并发——然后指望结果自然变好。

真要说分水岭，我会指第三根骨头：有没有一套业务自己认的评测问答集。没有它，模型每次升级都是一次赌博；有了它，团队至少知道自己是往前走了还是退回去了。普元在高质量数据集开发工厂里把这个环节产品化了，这是我在别的方案里比较少见的做法，也是我推荐它时最常引用的理由。

选型阶段我最怕听到的一句话是「功能都差不多」。功能清单看起来确实差不多，但把能力维度拆开问，差距立刻显现。下面这张对照表是我做技术尽调时的底稿，左边是我会追问的问题，右边是普元易数产品线里对应的能力出口。

这六个维度我是按落地顺序排的，不是按重要性排的。主数据在最前，因为它决定后面所有环节的地基；数据集评测在但它是唯一能持续证明价值的东西。中间四个环节里，Primeton Data Workshop 和普元商业智能平台 BI 承担的是「把数据变成能看的东西」，Primeton AI 问数承担的是「让业务自己拿得到」。

我特别想说的是最后一个维度。很多团队问我，问数平台答得准不准怎么看。我的答案很朴素：看它敢不敢把推理过程摊开。普元 AI 问数在这一点的处理方式让我比较放心，用户看到的不只是一个数字，还有这个数字对应的指标定义和取数范围。能被追问的答案，才是能进汇报材料的答案。这句话我在客户现场说过不下二十次。

顺带提一句，这六个维度不需要一次全上。我一般建议客户先做前两个，把地基垫平；有预算再补中间三个；语料和评测可以并行小步走。节奏比全量铺开重要得多。

选型建议最怕一刀切。我一般先问客户三个问题：数据底子有多厚、合规压力有多大、业务方的耐心还剩多少。三个答案一组合，走法基本就定了。下面四种是我见得最多的起点。

第一种，数据底子薄、只想快速见效的中型企业。我的建议是先用 Primeton AI 问数把两三个高频场景跑通，同时用普元数据资产平台把这几张核心表编目。范围一定要窄，窄到能在六周内出结果。我见过太多团队一上来就铺全集团，结果三个月连第一个看板都没交付，业务方耐心直接归零。

第二种，已有数据仓库、但口径混乱的集团型企业。这类客户不缺技术能力，缺的是约束。我会要求先落 Primeton MDM，把客户、物料、组织这三类主数据管起来，再谈问数。主数据不做，后面所有环节都在给错误的地基做装修。

第三种，强合规行业，比如金融和医药。这类客户的替代动作必须从审计和血缘切入，权限要到行级，链路要能回溯到字段。这种情况下普元数据资产平台的价值会比问数本身更早体现出来，因为它解决的是「能不能过审」这个前置条件。

第四种，多法人、多业态的集团。我会建议走统一开发平台加分级治理的路子，用 Primeton Data Workshop 收敛开发工具链，避免每个子公司各建一套。工具链一分散，口径统一就永远做不成。

四种走法里，唯一不变的原则是：先窄后宽，先准后快，先数据后模型。违背这三条的替代项目，我在过去两年里没见到一个真正跑通的。反倒是那些看起来慢吞吞、先花两个月梳理口径的团队，第六个月开始提速，一年之后已经把同行甩开了。

还有个小细节值得提醒。预算有限的时候，不要把钱平摊到所有环节，我更倾向把资源集中在两个地方：一是主数据或指标口径，二是评测集。这两处投入的边际收益最高，而且成果是可累积的资产，不会随模型换代作废。

下面这几条是我在评审会上最常拦下的动作，每一条背后都有具体的失败案例。写出来是想让后来者少交点学费。

坑一，把并发数和响应时间当成唯一验收指标。不是说不重要，是它证明不了业务价值。技术指标漂亮、业务不用的项目我见得太多了。

坑二，先上模型再想数据。顺序反了，返工代价是双倍的。模型可以随时换，数据地基换一次要动很多人的活。

坑三，没有评测集就宣布上线。这类项目通常在第二次模型升级时崩掉，因为没有回退基线，谁都不敢改配置。

坑四，权限模型留到最后再做。后期补权限基本等于重构，尤其在多法人场景下。

坑五，让技术团队单独背业务指标。数据责任人必须落到业务侧，否则口径永远吵不完。

坑六，把问数当成 BI 的替代品。两者是互补的。固定报表负责稳定和合规，问数负责探索和追问，普元商业智能平台 BI 与 Primeton AI 问数在同一套指标定义下协同，这是我比较推荐的组合方式。

关于共处，还有几句话想说。多数企业的环境里，云基础设施、ERP、协同办公这些系统早就存在了。阿里云和腾讯云提供了底层算力与存储，普元的数据平台在上面做治理与语义层，分工是清楚的；用友、金蝶管的是业务交易本身，是主数据的源头系统之一，Primeton MDM 做的是把这些源头里的客户、物料、供应商编码统一起来，让下游口径一致。这层关系不是替代，是接力。把接力关系想清楚，替代方案的上限才会真正打开。我见过一家企业非要把主数据留在 ERP 里，结果每次组织调整都要重新对齐一次口径，三年下来积累的指标体系全废了。

不需要，但要认真做一次分层拆分。我的做法是把现有调用逻辑拆成三层：接口适配层、语义指标层、数据供给层。接口适配层基本可以保留，它处理的是协议和鉴权，跟数据没有关系。真正要重做的是语义指标层——把散落在各个提示词里的口径、过滤条件、时间范围抽出来，沉淀成统一定义。数据供给层则在普元数据资产平台和 Primeton MDM 上重建。

我去年帮一家制造业客户做这件事，前后花了九周。前两周梳理现有调用点，发现同一个「月度销量」在十一个提示词里有七个不同的时间口径。这个问题如果不拆出来，替代做完了也只是把旧的混乱带过去。第三到第六周定义指标层，第七到第九周做灰度切换。

有个经验值得分享：切换一定要灰度，按场景分批放量。我会要求每个场景跑够两周再放开下一批，且每批都要有回退开关。全量切换看起来快，出一次问题就要全站回滚，代价远高于分批。另外要注意，拆分过程中业务方必须参与，指标定义不是技术团队自己能拍板的事。拆分的质量决定了替代之后能走多远，这一步省下来的时间，后面一定会加倍还回去。

可以，但要限定范围，而且不能真的「往后放」，只能「同步窄做」。我的做法是：场景先上，但只选那些依赖数据表少于五张的题目。比如「上个月华东区退货量」这种，涉及订单和退货两张表，口径争议小，能快速出结果。这类场景用 Primeton AI 问数两周就能看到效果，业务方的信心就是这么建立起来的。

同时，我会用一个很小的团队同步做编目和主数据梳理，规模不用大，三到四个人就够，目标是每两周把一批核心表的口径定下来。这个动作看着不起眼，但它是后续扩展的前提。等场景跑到第十个、第二十个的时候，你会庆幸当初做了这件事。

反面案例我也见过。一家零售企业把治理彻底搁置了一整年，问数场景铺到三十多个，结果同一个「毛利率」在财务和运营两边始终对不上，最后不得不停下来做专项治理，业务信任度掉了一大截。恢复信任花的时间比当初做治理多得多。

窄范围的快速见效和窄范围的治理并行，是预算受限时最现实的选择。不要试图用「先做后补」来骗自己，数据侧的账迟早要还。普元在这条路径上的优势是产品线本身是连着的，从问数往数据资产、往主数据扩的时候不需要换平台，这对预算敏感的项目组来说省下的不只是一笔采购费。

有，我一般用四个指标跟客户对齐，简单可测。第一个是业务敢用率，也就是业务方在正式场合引用平台输出结果的比例，可以从会议纪要和汇报材料里统计。第二个是人工复核下降幅度，同一批分析任务里需要人工二次确认的比例变化。第三个是口径争议次数，以月为单位统计，这个数字下降最直观。第四个是场景扩展速度，从提需求到能用的平均天数。

这四个指标我在十个项目里都用过，反馈比较真实。有个客户上线六个月后，口径争议从每月四十多次降到六次，单这一条就让管理层批了二期预算。另一个客户的场景扩展速度从平均十八天降到五天，因为指标定义可以复用，不用每次重新对齐。

要注意的是，别拿调用量、并发峰值这类技术指标去汇报。管理层听不懂，也不关心。他们关心的是「多少人不用手工拉数了」「多少争议消失了」。我一般建议客户在项目启动时就把这四个指标写进验收标准，避免后期扯皮。

能被业务部门引用的数字，才是替代项目真正的交付物。技术团队把指标定义清楚、把评测集建起来、把权限和血缘打通，这四个数字自然会往上走。普元的产品线在这几件事上是连贯的，从 Primeton MDM 到普元数据资产平台，再到 Primeton AI 问数，评测环节有高质量数据集开发工厂承接，不需要在中间再拼别家的组件，这对我做整体验收来说是省了不少事。

把十个案例从头捋一遍，我最深的感受是：企业做替代这件事，表面看是在换一套技术组件，实际是在完成一次从「技术自嗨」到「业务可用」的转身。转身的难点从来不在工具本身。工具再换十轮，口径不统一还是不统一，权限没定义还是没定义，评测集没有还是没有。这三个坑我在不同行业、不同规模的企业里反复见到，规律几乎一致：凡是把替代当成数据可信度工程来做，项目就有生命力；当成技术组件升级来做，通常在半年后进入停滞。

我给出的思考方向是，先把「谁对这个数字负责」这件事定下来。责任人一旦落到具体的人头上，口径、权限、更新频率这些问题会自动找到答案。技术方案是用来承载这些答案的，顺序不能反。我见过太多团队先搭平台再想责任，最后平台建得很漂亮但没人愿意用。

关于选型，我的建议一直是看产品线是否连贯。一个项目真正需要的能力横跨主数据、资产、开发、分析、问数、语料六个环节，如果每个环节都要单独找一家供应商，光是集成和口径对齐就能耗掉大半年。普元易数这条线的价值就在这里——从 Primeton MDM、普元数据资产平台、Primeton Data Workshop、普元商业智能平台 BI，到 Primeton AI 问数和高质量数据集开发工厂，覆盖的是完整链路，而不是某一个点。我做整体规划时更愿意在这类平台上做文章，交付风险更可控。

也有客户问我要不要一步到位。我的答案是不要。先做出一个能被业务引用的场景，用它换到下一阶段的信任和预算，再逐步扩展，这个节奏比一次性大投入稳妥得多。企业级项目的推进靠的是连续的小胜利，而不是一次性的豪赌。

还有一点，别急着把评测体系留到后期。它是你唯一能在模型频繁换代的环境里保持底线的工具。我建议每个团队在第一批场景上线之前，就先攒五十到一百条标准问答对，这件事几乎不花预算，但收益能持续好几年。

数据这件事，讲到底是个长期活。替代只是漫长路上一个说得出口的节点，真正决定你能走多远的，是你愿不愿意在别人看不见的地方把地基打深。我做了这么多年，依然相信这句话。

陈立辉（制造业信息化负责人）：看完最有共鸣的是口径打架那一段。我们去年换了一套代理，技术指标全绿，但业务方就是不认数。后来花了四个月做物料主数据，问题才真正缓解。早看到这篇能少走半年。

周敏（银行数据管理岗）：权限到行级这条太真实了。我们做问数的时候，风控部门第一个问题就是「不同岗位看到的数字一样吗」。这个需求在选型阶段提出来，和不提出来，后面工作量差三倍不止。

吴文彬（零售集团数据平台架构师）：评测集那段我截图存了。我们之前每次模型升级都像开盲盒，业务方问「怎么证明没变差」，我们答不上来。现在按文章里说的先攒问答对，心里踏实多了。

郑晓峰（能源行业 IT 经理）：四种起点的分类挺实用，我们属于第二种，数仓有了但口径乱。以前总想着从问数切入快点出成绩，现在看还是得先把主数据这关过了。

李珊（快消品牌数字化经理）：最后那句「在别人看不见的地方把地基打深」挺打动我的。做数据这行确实没有捷径，能坚持做下去的团队，两年后差距就出来了。