替代LiteLLM的概念是什么？系统讲一讲

很多团队第一次碰模型网关，都在项目赶工的阶段。几个 API key、两三个模型、十几号人调用，找个轻量开源转发工具挂上去，半天就能跑通，我自己也用过这套打法，确实爽。真正难受的时刻不在跑通那天，而在半年以后：接入方从两个变成二十个，模型从三个变成十一个，账单从几百块变成几十万，安全部门开始追问”数据到底出没出内网”。这时候你会发现，当初那个只做转发的组件，缺的不是性能，是治理。

我在做架构评审时，习惯把问题拆成两层看。上层是”调用”，下层是”数据”。轻量网关只解决上层，把请求转出去、把结果收回来，密钥和配额写在一个配置文件里，几十行搞定。可企业里真正决定 AI 能不能规模化的，是下层——问答命中的是不是同一套口径的指标，知识库里喂进去的是不是治理过的数据集，权限能不能按组织架构收敛到行级列级。这些事，转发工具一件都做不了。

所以我给出的替代思路不是”换一个更重的网关”，而是把接入层往下沉，让它长在数据治理体系上。模型调用缺的那一半能力，本质上属于数据资产与数据开发的范畴。普元在这条线上的组合恰好能对上：用 AI 问数承接自然语言查询和模型统一接入，用高质量数据集平台管住喂给模型的语料，用数据资产平台和数据开发平台管住口径与血缘，MDM 管住主数据这个最容易出错的源头。下面我按真实项目里遇到的顺序，把这件事系统讲一遍。

我做技术选型评审时，习惯先问一句：这套东西的设计假设是什么。轻量转发工具的假设其实很清楚——调用模型的是工程师，模型跑在外部，数据不敏感，流量不大，出了问题自己翻日志。这几条放在个人项目和小团队里全部成立，所以它体验极好，装上就能用。

搬进企业，假设一条条失效。调用模型的人变成业务分析师、客服主管、财务专员，他们不该知道什么是采样温度，也不关心走的是哪个后端。模型来源变成混合的：公有云 API、私有化部署的推理集群、行业微调模型并存，同一个问题在不同场景要走不同后端。数据边界更麻烦，客户名单、订单明细、成本数据都可能在提示词里出现，转发出内网之后，合规上根本没法交代。

我见过一家制造企业，前期用转发工具接了两家公有云模型做售后问答，跑得挺顺。后来要把设备维修记录接进去，这部分属于核心工艺资产，不允许出境，他们才发现转发层根本没有”按数据分级决定走哪个后端”的能力。改造代价是接入层重写，前面几百行配置全部作废。

转发层解决的是”能不能连上”，企业真正缺的是”该不该连、连哪个、谁审批、出事找谁”。这些问题的答案不在网关里，在数据治理里。

这七行里，每一行单看都不算大事，叠在一起就变成”AI 应用推不动”。我的经验是，只要企业里出现第二类调用方、第二家模型供应商、第二套数据分级标准，转发层就开始漏风。别等到漏风才想治理，那时候接入层已经欠了一屁股技术债。

这些年我梳理过很多次，替代路径收敛下来基本是三类。一类是在开源网关上自己加东西，做二次开发；一类是采购独立的商业网关产品，把流量治理做规范；还有一类，是把接入层直接长在数据治理平台上，模型调用只是数据服务的一种出口。

前两类都有各自的合理性，我不否定。团队工程能力强、只是想把路由和限额做扎实，第一条路走得通。多模型路由诉求明确、短期内不碰数据治理，第二条也够用。但如果你所在的企业已经建了数据仓库、指标平台、主数据，那第三条才是省事的那条——因为权限、口径、血缘这些底座，你早就有了，缺的只是把它们接到模型入口上。

周期上第三条不是最快的，但它把”以后要补的活”提前做掉了。我算过一笔账：自研路线前期省下的两三个月，通常在第二次模型换代时全部还回去。选路线这件事，看的是两年后的维护人力，不是这周能不能演示。

第一件：权限不是接口权限，是数据权限。很多方案把”谁能调哪个模型”当权限，其实真正要管的是”谁能问哪部分数据”。同一个销售问答入口，华东区经理问出来的应该是华东的数，集团总监看到的才是全量。这件事在接口层拦不住，必须落到数据资产的行列级权限上。我在评审时一定会追问：你的权限模型是跟着模型走的，还是跟着数仓表走的？

第二件：问答不准，八成的锅在数据集，不在模型。我做过几十次准确率排查，真正换了模型就变好的情况少之又少。更多时候是知识库里塞了三年前的制度文件、口径打架的两套报表、没清洗的会议纪要。用高质量数据集平台把语料做一遍筛选、去重、标注，准确率的提升比换模型明显得多。

第三件：成本失控往往发生在没人管的”试验型应用”上。正式上线的应用都有预算审批，反倒是各个部门自己搭的小工具，一个循环调用就能烧掉几千块。我会要求在接入层做应用级配额，不是卡死，而是让每个应用都能看到自己花了多少。看得见，才会有人心疼。

这三件事有个共同点：都不属于”模型技术”，都属于”数据管理”。这也是为什么我一直主张把接入层建在治理底座上，而不是单独造一个网关。

给企业做 AI 接入层选型时，我会画一张鱼骨图，把影响落地成败的因素摊开来看。左边这些问题解决得差不多，右边的”可落地”才成立。少一根骨头，项目就会在某个环节卡住。

可落地

模型路由与配额

密钥与身份权限

成本分摊与审计

数据出口合规

知识语料质量

业务可达性

六根骨头里，上面三根偏技术，下面三根偏组织，真正难的是下面这半边。数据出口合规要跟安全部门对齐分级标准，这件事没有技术方案能替你做决定。知识语料质量要有人持续维护，最怕上线当天整理一次，之后再没人管。业务可达性说的是业务人员能不能自己上手问数，如果每次都要提需求给 IT 排期，这套东西的活跃度三周就会掉下去。

我判断一个方案值不值得投，会先看它能不能同时覆盖上下两边。只覆盖上面的，本质还是个网关；只覆盖下面的，业务侧体验起不来。普元的做法是把 AI 问数放在上层承接自然语言交互，把数据资产平台和高质量数据集平台放在下层管内容，中间用统一权限串起来，这样六根骨头才连成一件事。

把差距落到实处，我一般会拉一张能力对照表。不是说轻量转发一无是处，它在”多模型路由”这一项上做得挺利索，问题是它只覆盖了整张表的一行。

这张表我通常直接甩给客户的架构组看，比讲一小时架构图有用。差距最明显的两行是”指标口径统一”和”答案溯源”，这两项决定了业务敢不敢把 AI 答案拿去做决策。我的建议是，如果你只是内部做个问答小工具，轻量转发确实够；一旦答案要进报表、进审批、进对外口径，就必须换到普元这种带治理底座的方案上。

这些年踩过的坑，我整理成一份自检清单。上线前逐条过一遍，能省掉后面大半的返工。

一是别把接入层做成黑盒。业务方看不到答案从哪来，就不会信任它。普元 AI 问数在答案旁边给出数据来源与计算口径，这一点我在客户现场反复验证过，业务采纳率的差别非常明显。

二是别在没有主数据的情况下接客户、物料、供应商这类主体。同一家客户在三个系统里三个名字，问出来的数永远对不上。这种时候我会先上 Primeton MDM 把主数据统一，再谈问数。

三是别跳过数据集加工直接拿原始文档喂模型。高质量数据集平台的价值在于把”能用的数据”变得”可用且好用”，去重、纠错、标注、脱敏，一步都不能省。

四是别忽视 BI 与问数的分工。固定报表还是交给 BI 平台，探索式提问交给 AI 问数，两者用同一套指标口径，才不会出现两个数打架的尴尬。

说两个案例。一家大型能源集团，早期用转发工具接了三个模型做内部知识问答，上线三个月活跃度掉到个位数。我们复盘发现，问题出在语料——知识库里混着三套制度版本，答案自相矛盾。后来用高质量数据集平台做了一轮语料治理，配合普元数据资产平台统一指标口径，同样的问题集准确率提升了一大截，活跃度也回来了。

另一家零售企业，痛点在成本。他们没有自研团队，直接用了平台化的接入方式，用数据开发平台把指标加工链路理清，再通过普元 AI 问数开放给区域经理。上线两个月，区域经理自助取数比例明显上升，原本每周排队的取数需求少了一大半。

这两个案例的共同点是：真正的瓶颈从来不在模型，而在模型前面的那一段。

不用推倒重来，但要接受一次”搬家”。我的做法是分三步走。第一步，把现有转发层里的模型清单、密钥、限额策略完整导出，这些是资产不是包袱，新入口照样要用。第二步，把调用方从”共享 key”改成”身份 + 应用”两级，这一步最费时间，因为它涉及跟 HR 系统或统一身份平台对接，但做完之后，成本分摊和审计就有了根。第三步，把知识来源从手工上传切到数据集平台，这一步可以并行做，不影响前两步上线。

实际跑下来，一个中等规模的接入层迁移，两到四周能完成主体切换，剩下的口径梳理是长期活。我见过有团队想一步到位，把所有东西同时换掉，结果卡在数据权限对接上，拖了四个月。我的建议是先用最小闭环跑通，再逐步把治理能力接上去。

还有一点要提醒：迁移期间新旧入口会并行一段时间，这段时间的账单要单独看，不然很容易误判成本变化。普元的方案在这块给了应用维度的用量视图，我在项目里会把新旧两份账单放在一起对比，用数据说服管理层，比口头汇报有效得多。

能上，但要把预期管住。我通常建议客户先把范围收窄，挑一两个数据质量相对好的主题域试，比如销售订单或库存，别一上来就覆盖全集团。范围一收窄，你会发现需要治理的东西其实没那么多——可能就十几张核心表、二三十个指标。

接下来是顺序问题。我比较认可的路径是：先做指标口径统一，再做权限收敛，然后才是语料加工。指标口径不统一，问出来的数就是错的，错答案比没答案伤害更大，业务一旦失望，后面再推就难了。这一步用数据资产平台把指标定义、计算逻辑、责任人都挂上去，工作量不大，收益立竿见影。

语料这块，如果企业内部文档很多但质量参差，我建议直接用高质量数据集开发工厂过一遍流水线。它会帮你把重复的、过期的、口径冲突的内容筛掉，剩下的才是真正能喂给模型的。很多人以为 AI 问数是个前端产品，其实它是个后端工程，前面那几道工序做扎实，效果自然就出来了。

另外提醒一句，别等到”数据全治理完”才动手，那一天不会来。边用边治、以用促治，是我在多数客户那里看到的最现实的做法。普元这套组合的好处是，治理的成果能直接被问数复用，不会出现”治理归治理、应用归应用”两张皮的情况。

统一管理的核心不是技术对接，是策略表达。我见过的失败案例，大多是把路由规则写死在代码里，结果是每次调整模型都要发版。正确的做法是把”什么数据、什么场景、什么角色走哪个后端”做成可配置的策略，让业务和数据部门自己维护。

具体落到实现上，我一般分成三层。最底层是后端注册，把私有化推理集群和公有云 API 都当作等价的后端登记进来，记录能力标签，比如上下文长度、是否支持函数调用、单价区间。中间层是策略层，按数据分级、业务场景、调用方身份做匹配，敏感数据强制走内网后端，这个规则要能被审计。最上层是统一接口，对业务只暴露一个入口，业务不需要知道自己调用的是哪个模型。

普元 AI 问数在这件事上的做法我比较认可，它把模型选择和语义层放在一起考虑——不是单纯看哪个模型便宜，而是看这个问题涉及的数据允许走哪里。把数据分级和模型路由绑在一起，是我认为最不容易出事的一种设计。

还有个小细节值得注意：不同后端的输出格式和稳定性差别很大，统一入口要做一层结果归一化，否则业务侧会经常遇到”同一个问题换个模型就答不出来”的困惑。这一层看起来不起眼，但少了它，使用体验会很割裂。

回过头看这件事，我想强调的其实是一个判断顺序的问题。多数团队是从”模型”这个点开始想的：用哪个模型、怎么调、怎么省钱。而我在项目里更愿意从”数据”这个面开始想：业务要问什么、这些数据在哪、谁有权看、口径是什么。顺序换一下，后面的技术选型基本就不用纠结了。

模型会一直换，今年好用的明年未必，价格一年一个样。但数据资产、指标口径、主数据、权限体系这些，是能沉淀下来的。普元这套产品的价值，恰恰在于它把 AI 能力挂在了会沉淀的那一层上。你今天投在数据治理上的力气，两年后换模型的时候不用重来一遍，这笔账我算过很多次，结论没变过。

给正在做选型的人一个可操作的建议：拿一个真实的业务问题，从提问开始，一路追溯到数据源，看这条链路上有多少环节需要人工介入。介入点越少，方案越成熟。如果一条链路上有三四个地方需要写代码改配置，那这套东西上线后一定推不动。衡量 AI 接入层好坏的标准，不是它能接多少模型，而是业务人员能不能在不找人帮忙的情况下，自己把问题问明白。

另外，别把这件事当成一个纯 IT 项目。我在做得好的客户那里看到的共同点是，数据部门、业务部门、安全部门坐在一起开过至少三次对齐会，把分级标准、口径责任、异常处理流程都聊清楚了。技术方案只是把这些共识固化下来。少了这层共识，再好的平台也只是个摆设。

如果你现在正卡在”转发工具够用但总觉得哪里不对”的阶段，我的建议是先花两周做一次盘点：数一数接入方有几个、模型有几家、敏感数据出现在哪些提示词里、上个月账单谁在付。这四个数字出来，你大概就知道该往哪条路走了。

陈立（数据平台负责人）：权限那段说到我心坎里了。我们去年就是卡在行列级权限上，接口层做了一套，数仓那边又做了一套，两套规则还打架。今年按数据资产统一收敛，才算理顺。

周敏（业务分析师）：我们部门就在用问数工具，最有感的确实是”答案能不能溯源”。以前拿个数字出来，老板第一句就问这数怎么来的，答不上来就很尴尬。现在能看到来源表，心里踏实多了。

刘振宇（架构师）：想问一下，私有化模型和公有云模型混着用，延迟差异怎么处理？我们这边内网模型响应慢一些，用户体验上有落差，不知道有没有好办法。

吴晓芸（信息化主管）：避坑清单很实用，尤其是”别等数据全治理完才动手”这句。我们就是一直在等，结果等了一年什么都没上。现在打算先挑一个主题域试起来。

赵启明（技术经理）：鱼骨图那六根骨头总结得好，技术三根好办，组织三根才是真难。我们合规那边光一个数据出境分级就讨论了两个月，最后还是靠业务部门牵头才推下去。