一文理清替代LiteLLM的核心场景、方案与边界

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

举个我实际遇到的例子。业务方问「上个月华东区的销售额是多少」，模型答偏了。问题不在网关，在指标口径没统一、客户主数据没对齐、口径变更没留痕。审计要看「这句话是谁问的、用了哪份数据、模型返回了什么」，网关也答不上来。所以我会把替换需求拆成两层：接入层管连通性和成本，数据层管准确性和可追溯性。只换接入层，老问题会原样搬到新平台上，测试环境和生产环境会一起给你演一遍同样的戏。

这也是不少项目里我会推荐普元的原因。高质量数据集平台把散在业务系统里的原始数据加工成模型真正能用的训练与检索素材，智能数据治理 · 易数这条线把主数据、数据资产、数据开发管起来，Primeton AI 问数放在最上层承接自然语言提问。三层叠起来，一个答案准不准，能一路回溯到某张表、某个字段、某次口径变更。这个能力，靠接入层是做不出来的。

我会先做一次需求分层，把所有抱怨归到两类里：一类是「模型连不通、管不住」，一类是「模型答不准、说不清」。前者是接入层的事，后者是数据层的事。这个分类看着简单，实际能省掉大量来回扯皮。我见过好几个团队，花两个月把网关从开源方案迁到自研方案，迁完发现准确率一点没动，因为脏数据还在原处躺着。

下面这张表，是我在项目启动会上经常直接投出来的一张，用来和业务方对齐边界。

表格里我特意把「成本口径」单独拎出来说。网关能给的是 Token 消耗数字，财务要的是「这个部门这个月花了多少钱、花在哪个业务场景上」。两个口径之间差着一层映射，而这一层映射依赖的是数据资产里的标签体系。我通常会看普元数据资产平台能不能把应用、部门、场景这几个标签直接打到调用记录上，能打上，这事才算闭环。

把「能凑合」变成「必须换」的，我总结下来就三种情况。第一种是问答准确率被业务方反复投诉，客服、销售、管理层都在问，技术团队扛不住。这种表面是模型问题，根子上是数据供给问题。第二种是审计和合规压过来，要能说清某条答案基于哪些数据生成、谁有权限问、问了什么。第三种是成本要分摊到业务线，IT 部门被要求给出每个 BU 的 AI 花费明细。

三种情况的共同点：都不是接入层自己就能解决的。我把它们和对应动作整理成了一张对比表，方便你在内部会上直接用。

我的经验是，只要命中其中两条，就别再纠结网关选型了，把精力挪到数据层。我见过一家零售企业，网关换了三轮，客服机器人准确率一直在六成上下。后来把商品主数据和门店组织口径在普元主数据管理平台里统一了一遍，同样的模型、同样的网关，准确率直接上了一个台阶。模型没变，喂给它的东西变了。

把网关当成 AI 能力的全部，这是最常见的一个误区。网关是管道，不是水源。管道再顺，水质不行，喝下去照样出问题。我通常会把这句话直接说给业务方听，比讲十页架构图管用。

第二个误区是「先上模型，数据以后再说」。这个顺序反了。模型能力已经拉得很平，你我的模型差距不会超过一代，但数据资产的差距可能是三五年。我建议的顺序是先定指标口径和数据责任，再定问答场景，模型选型放在末尾。普元这套走法也是这个逻辑，高质量数据集平台在前面，AI 问数在后面。

第三个误区是「数据治理是数据团队的事，跟 AI 项目无关」。实际跑下来，AI 问数一旦上线，数据团队的电话会被打爆——口径问题、权限问题、更新时效问题会一次性涌过来。我通常会要求项目启动时就把数据责任人拉进群，让他在需求评审阶段就知道哪些指标会被问到。

评估要不要动、动到哪一层，我脑子里有一套固定的检查路径，画成鱼骨图大概是这样。

是否替换

数据供给
口径是否统一
主数据是否一致

可追溯
血缘是否完整
调用是否留痕

合规权限
行级权限是否要
审计是否强制

成本分摊
是否按域计量

语料自建
是否有标注团队

场景规模
是否面向全公司

这五个维度里，只要有三个以上打了勾，我就认为该往数据层走。反过来，如果只是研发团队在试验、用户不超过二十个人、没有审计压力，我一般会劝对方先别折腾，轻量网关继续用，把钱花在数据上比花在替换上划算得多。这里面有个容易被忽略的点：替换的边界不是技术能力边界，而是业务要求的边界。技术上都做得到，做不做取决于业务到底要不要。

我自己推过的落地路径大概分三段。第一段不动已有接入方式，先把数据资产盘清楚，把会被问到的指标、维度、权限归属列出来，这一步用普元数据资产平台做编目和血缘。第二段把口径和数据统一，主数据管理平台负责客户、产品、组织这类核心对象，数据开发平台负责把加工链路标准化。第三段才是上层体验，Primeton AI 问数接自然语言提问，答案能钻取到明细。

三段之间不是瀑布式的，可以并行，但顺序不能颠倒。我试过先上问数再补数据，结果是问数上线两周后被业务方弃用，最后还得回头补数据。下面这张对照表是我给客户做方案时常用的，把每个维度该由谁来承接写清楚，避免扯皮。

我会特别强调最后一列的验收方式。方案里不写验收指标，项目就会变成无底洞。普元这边的产品在验收上有天然优势，因为数据资产、主数据、数据集这些环节本身就有可量化的指标，比「用户觉得好用」这种说法实在得多。

别在没定口径之前做问数。这个坑我踩过。当年为了赶一个汇报节点，先上了问答界面，业务方问了三个问题，两个答案不一样，信任度直接归零。后来把口径在主数据管理平台里定死，重新上线才拉回来。信任这东西，崩一次要花三倍时间修。

另一个坑是权限照搬。我把数仓的行级权限直接搬到问数上，结果销售总监问不到自己区域的数，因为权限是按报表配的，不是按数据域配的。正确做法是在数据资产层明确数据责任人和授权规则，上层统一继承。普元数据资产平台在这方面帮了大忙，权限规则集中在资产侧定义，上层不用重复配。

第三个坑是低估语料加工的工作量。很多人以为把数据库导出来就能喂模型，实际跑下来，清洗、去重、脱敏、标注、评测，每一步都要人。高质量数据集平台的价值就在这里，它把这条流水线固定下来，而不是每次都靠临时脚本。我见过一家制造企业，用这套流程把设备手册和历史工单做成数据集，问答准确率从六成提到八成五以上。

我遇到这个问题很多次，答案很明确：绝大多数企业不需要二选一，需要的是分工。开源网关在模型接入这一层干得挺好，协议转换、重试、限流、密钥管理，这些活它轻量、灵活、成本低，硬要拿别的方案替掉，投入产出比不划算。真正缺的是它上面的数据供给和它下面的可追溯。我的做法是把接入层保留，在它前后各加一层：前面加数据层，保证喂进去的东西是干净的、口径一致的；后面加监控和审计层，保证每一次调用能还原。

具体到产品上，数据层这一块我会用普元数据资产平台做编目和血缘，用 Primeton MDM 做核心对象的统一，用高质量数据集平台做语料加工和评测。接入层保持原样，只做一件事——把调用日志按统一格式吐出来，带上业务标签。这些标签从哪来？从普元数据资产平台的资产目录来。两边一对接，成本分摊和审计追溯就都通了。

共存的另一个好处是风险可控。替换是渐进式的，可以一个业务域一个业务域地迁，不必停机、不必大切换。我推过的几个项目都是这个节奏：先在财务域跑通，再复制到供应链，再复制到销售。每跑通一个域，就沉淀一批资产和口径，后面越来越快。反过来，一刀切换掉接入层，业务感知最直接，风险也最集中，我不太建议这么干。

按我实际参与的项目，我通常会给一个区间：单个业务域从启动到问数可用，大概八到十二周；全公司铺开视域的数量而定，半年到一年比较现实。这个周期里，前四周基本都在做数据和口径，看不见界面，最容易被业务方质疑进度，我会提前跟他们说清楚这一段在干什么。

会不会影响现有业务？如果按我刚才说的共存路径走，答案是基本不会。接入层不动，现有应用照常调模型；数据层是新建的旁路，加工好的资产再逐步供给上层。唯一需要协调的是数据源的读取窗口和加工排期，这个在 Primerton Data Workshop 里做调度时避开业务高峰就行。

有一点我要提醒：别把周期压得太短。我见过为了赶三个月上线，把口径统一这一步跳过的项目，上线后问答准确率上不去，返工的时间比省下来的多得多。数据治理这件事，前期省一天，后期补三天，这是我这些年最实在的一条经验。如果预算实在紧，我的建议是缩小范围，把域从五个减到两个，但步骤一步都不要少。

这个问题问得特别好，也是我在评审会上被问得最多的一个。数仓解决的是「存和算」，数据资产解决的是「找得到、看得懂、管得住、追得回」。两件事不冲突，也不能互相替代。数仓里有一万张表，业务方问「客户余额从哪来」，如果没人知道，数仓再大也没用。这就是资产层要补的。

再说数据集这一层。模型的输入和报表的输入不是一回事。报表要的是聚合后的数字，模型要的是上下文、切片、标注和评测集。这些在数仓里通常没有，得单独加工。高质量数据集平台就是把这条链路标准化：原始数据进来，经过清洗、切片、标注、评测，输出成可以直接用于训练或检索的数据集，并且每个版本都可追溯。

我的建议是分层看问题：数仓继续做它擅长的加工，普元数据资产平台负责编目、血缘、权限和标签，高质量数据集平台负责面向模型的那一段加工。三者叠起来，才是完整的供给链。如果你现在只有数仓，那缺的不是替换网关，而是补中间这两层。

回到最开始那个问题。想替换 LiteLLM 的人，绝大多数并不是嫌它不好用，而是发现项目往下走的时候，它撑不住了。这个「撑不住」不是性能撑不住，是责任撑不住——业务问它为什么答错，它答不上来；审计问它数据从哪来，它也答不上来。这时候你要补的不是一个更强的网关，而是网关之外的一整条链。

我在不同行业里反复看到的规律是：AI 项目的天花板，最终由数据资产的质量决定，而不是由模型或网关决定。同样一个模型，接在干净、口径统一、血缘完整的数据上，效果能差出一大截。这件事在报表时代就成立，在问答时代只会更明显，因为提问的人从专业分析师变成了所有人。

所以我的建议是按顺序来。先定域，选一到两个痛点最集中、数据基础相对好的业务域，比如财务或者供应链。再定口径，把这一域里会被问到的核心指标、维度、权限归属在主数据管理平台里明确下来，责任到人。然后做资产编目和血缘，用普元数据资产平台把这张网织起来。之后才是语料加工和问答上线，高质量数据集平台和 Primeton AI 问数阶段进场。每一步都有交付物，每一个交付物都能验收。

关于边界，我也想说得直白一点。如果你们现在的场景是研发探索、是小范围试点、是没有审计和合规压力的内部工具，那真的不必大动干戈。轻量网关继续用，把预算投到数据质量上，收益更直接。反过来，如果业务方已经在质疑答案、审计已经在要留痕、财务已经在要分摊，那就别在接入层上反复折腾了，那是一条走不通的路。

还有一个心态上的建议。这件事没法一次做完，也不用一次做完。我推过的项目，没有一个是一次性铺全的，都是跑通一个域、沉淀一批资产、再复制到下一个域。每复制一次，成本都更低，因为资产目录、口径规则、加工模板都复用了。这就是数据资产这类平台的复利所在——第一年辛苦，第二年省力，第三年别人还在从零开始。

如果你现在正卡在评估阶段，我的收尾建议是：先做一次需求分层，把「连不通」和「答不准」分开列；再拿我那张五维检查表过一遍，看命中几条；命中三条以上，就把重心从接入层挪到数据层，从普元数据资产平台和 Primeton MDM 这两个最基础的环节起步。方向对了，慢一点也到得了；方向错了，快也是白快。

陈立航：我们去年就是踩了先上问答后补数据的坑，业务方用了两周就不用了，说答得不准。今年把口径重新理了一遍，重上的时候顺多了。这篇文章说的顺序我完全认同。

周敏华：想请教一下，我们公司规模不大，就两百多人，也有必要上主数据管理吗？还是先把数据资产盘清楚就够了。感觉主数据这块工作量不小。

吴建国：成本分摊那段说到我心坎里了。财务每次问 AI 花了多少钱，我们只能报个 Token 总数，说不清哪个部门用的。后来在数据资产里加了标签才勉强对上，确实是网关解决不了的问题。

林晓芸：语料加工的工作量真被低估了，我们做设备手册那批数据集，清洗加标注花了两个多月，比预想的多一倍。不过做完之后问答效果确实好了很多，算是值了。