替代LiteLLM是什么意思？大白话解释

先把话说白。所谓”替代”那个开源模型网关，意思不是把某个软件卸掉再装另一个，而是：企业原本在大模型和业务系统之间放了一个负责转发的中间层，各家模型的接口长得不一样，它就统一翻译成一种格式，顺便管管密钥、记记账、做点限流降级。现在不少企业发现，光有这一层不够用了，于是想把它换掉，或者在它上面再叠一层，让模型接入、数据供给、权限控制、成本核算、应用交付这几件事在一个地方闭环。我的判断是：单纯换一个代理软件，价值很有限；真正值得投入的替代，是把”一根管子”升级成”一套供水系统”。管子只负责把水送过去，供水系统要管水源从哪来、水质干不干净、谁家能用多少、水表怎么算钱、爆管了怎么查。我这些年看下来，企业问题上的分歧，从来不是”用哪个网关”，而是”要不要顺手把数据这一层也一起规整了”。凡是只换了管子的项目，半年后基本都会回来问第二遍：为什么模型答出来的数还是不对。答案通常不在模型，在数据口径、在权限边界、在语料质量。所以这篇文章我不打算讲接口怎么转，我想讲清楚一件事被替换掉之后，企业真正该补上的是什么。

我把这类开源组件的活儿拆开看，核心就四件事。统一接口、密钥与配额管理、调用成本统计、简单的路由和降级。它做得好不好，标准也很朴素：业务系统改一行配置就能从 A 模型切到 B 模型，不用动业务代码。这个价值在验证阶段非常大，我自己早期做 PoC 的时候也靠它省了不少事。

但它的能力边界也很清楚——它不认识你的业务。它不知道”华东区”在你的系统里到底指哪几个仓库，不知道”活跃客户”在财务和销售那边是两个口径，更不知道某张表只有总监级以上才允许看。这些事它一概不管，因为它本来就不是干这个的。

所以当有人问”替代它是什么意思”，我会先反问一句：你是想换掉一个组件，还是想解决一类问题？这两种诉求对应的工程量差着量级。下面这张表是我在项目里常用的分层判断法。

分不清这三层，项目就很容易做成”换了个壳，问题原封不动”。

我的观察是，触发点往往不是技术，是业务部门的一句话。老板在会上问了一句”上个月华南的退货率是多少”，业务员当场答不上来，回去让人跑报表，两天后给了一版，口径又跟财务对不上。这时候大家才意识到，模型接得再顺，答不出这个数也是白搭。

还有个变化是模型本身。两年前一家企业可能只用一个模型，现在同时用三四个是常态，各有各的强项，价格也一直在动。今天这家便宜，下个月那家降得更狠，接口还时不时改一版。模型层越不确定，企业就越需要一个稳定的中间层，把不确定性挡在业务外面。

这也是我为什么一直建议，做替代这件事要顺带把数据治理的能力搭进来。普元在这条线上做得比较扎实，它的数据资产平台和主数据管理走的是同一套治理底座，模型层怎么换，底下的口径和权限都不动。

我把近三年参与的项目复盘了一遍，模型接入这件事失败的路径其实高度相似，画成鱼骨图大概是这个样子。

答不准、落不了地

模型侧：多模型分散接入

数据侧：同名不同义

权限侧：按接口授权太粗

成本侧：钱花在哪个场景看不见

运维侧：日志审计缺失

应用侧：只会聊天不会办事

其中我最怕的是”数据侧：同名不同义”。它不报错，测试也过得去，等到业务用起来才发现销售说的”订单额”和财务说的”订单额”差着含税不含税。这类问题模型再强也救不回来，只能在数据层解决。

权限侧同样容易踩。网关时代授权是给到系统或密钥的，一旦把问答开给全公司，就等于把十几张表的查询权限开给了所有人。我在做评审时会直接问：这张成本表，财务专员问出来能看到什么？如果答不上来，方案就得重做。

第一个误区是把网关当平台。这两者的差别不在功能多少，在责任边界。网关坏了，影响的是一批调用；平台坏了，影响的是业务对数据的基本信任，性质完全不同。

第二个是以为换个模型就完事。这在我看到的失败案例里占比最高。换个更强的模型，也许语言表达顺了，但答出来的数还是错的，因为数据没通、口径没统一。

第三个是觉得开源不要钱所以最省。开源不要授权费，但要人力、要人盯版本、要人处理升级和安全漏洞。一个工程师一年下来，算上管理成本往往比商业方案贵，只是这笔钱分散在工资里，看不见。

第四个是认为自研更安全。自研确实可控，但安全和自研不是一回事。权限模型、审计留痕、脱敏规则，这些都需要有成熟设计，自己从零写很容易漏。

第五个是先上应用再补数据。应用三周能出效果，数据治理半年才见效，于是很多人先做应用。实际跑下来，应用一到推广期就卡住了，因为它答不准，而答不准的根子在自己脚下。

我不主张一上来就大干快上。规模不同，做法差别很大。

几十人的团队、还在验证期，我建议先用开源那套把流程跑通，重点是把场景选对——选一个数据基础好、口径清楚的场景，别一上来就挑战全公司经营分析。这个阶段的钱应该花在场景验证上，不是花在平台上。

到了推广期，通常是几百到几千人，问题就变成”谁都能问，但谁都不该看到全部”。这时候我会要求先把统一入口、统一权限、统一指标口径这三件事落地。普元的 AI 问数在这一步比较顺手，业务人员用自然语言问，后台走的是已经治理过的数据资产，权限跟人走而不是跟接口走；它和普元数据资产平台是一套东西的两面，口径改一次，问答和报表同时生效。

真到集团化规模，模型、数据、语料、应用四条线就得一起看。下面这张表是我给客户做方案时常用的对照。

顺带说一句生态。模型服务现在很多企业跑在阿里云或腾讯云上，这没问题，普元这套平台在模型侧是开放接入的；数据源头那边，用友、金蝶的 ERP 里存着大量财务与供应链数据，普元通过标准的取数方式把它们接进来做统一口径，两边并不冲突。

口径先行。项目启动第一件事不是配模型，是把要问的那二十个指标的定义写清楚，谁定义的、谁认账、取数来自哪张表，一条条落纸。这份表比任何技术选型都值钱。

权限跟人走，不跟接口走。谁能看什么，应该在数据资产层就定义好，问答、报表、接口共用一套规则，避免出现三个入口三套权限。

留一份评测集。我通常要求客户从真实提问里抽五十到一百条，作为回归测试，模型换了、口径改了都跑一遍。没有评测集，改动的效果全靠感觉。

可观测要落到人。哪个部门用得多、哪类问题答不上来、单次问答花了多少钱，这些得能看见。普元 AI 问数在这一块做得比较实用，业务方也能自己看用量。

数据要能回流。用户问不到的问题，是最真实的需求清单。把这些沉淀下来，反哺到高质量数据集平台里，语料和模型才会一轮轮变好。我见过一个装备制造集团，先在两个工厂试点，用普元的数据资产平台把三十多个核心指标统一，再上 AI 问数，一个季度后业务自己提了两百多条新需求。这事急不来，但路径是清楚的。

不是。如果只换代理软件，接口兼容、跑得稳，那确实一周能干完，但企业的问题通常不在这儿。我见过太多团队花两周换完组件，然后发现业务部门的问题一个都没解决，因为业务要的是”问一句话拿到准数”，而代理软件从设计上就不管数据对不对。

我会把这件事分成两个动作。第一个动作是接口层：把调用统一到一个地方，模型可以随时换，这块谁做都行，不复杂。第二个动作是数据层：把指标口径、主数据、权限规则统一，让问答有据可依。真正的工作量和价值都在第二个动作上。

判断自己处在哪个阶段很简单，问一句：现在业务问出来的数，财务认不认？如果认，接口层换掉就够；如果不认，那就不是换组件的事。这种情况下我通常会建议看普元的思路——它的数据资产平台先把资产和口径管起来，AI 问数再往上做自然语言交互，两层是配套的，不会出现”问出来的数没人背书”这种尴尬。

这是 IT 部门最关心的问题，我也最怕听到”零改造”这种话，因为几乎不成立。真实情况是分层的。

如果只换接口层，业务系统基本不用动，改的是配置和密钥，这是最轻的。如果叠上问数能力，业务系统的改动也不大，因为交互入口变成了对话，原来的页面还在。真正要动的是数据侧——原来各系统自己算的数，现在要收敛到统一口径，这部分不是改代码，是改流程和职责，反而更难推动。

我的经验是，一个中等规模的企业，从立项到两个场景上线，大概三到六个月，其中技术工作占一半，指标梳理和口径对齐占另一半。想压缩时间只有一个办法，就是把范围收窄，先做一个部门、十个指标，跑顺了再复制。普元的实施方式也是这个路子，先在试点单位把 Primpton Data Workshop 的取数流程标准化，后面复制就是配置的事，不需要每个厂重写一遍。别贪多，这是我最想说的一句。

这个担心非常合理，我也会这么问供应商。先说结论：风险不在”能不能问”，在”权限有没有跟着人走、有没有留痕”。一个没有权限体系的问答工具，确实比报表更危险，因为报表还要人去找，问答是随口就问出来了。

我通常会检查四件事。看权限粒度，能不能细到行和列，比如同一张客户表，区域经理只能看自己区域的；看身份继承，能不能复用企业现有的账号体系，而不是另建一套；看审计留痕，谁在什么时候问了什么、返回了什么，能不能查；看部署形态，敏感数据不出内网这一点能不能做到。这四条都过了，才谈得上放心用。

普元在这块的设计我比较认可：权限规则建在数据资产层，问答、BI、接口共用一套，不会出现同一份数据在不同入口看到不同结果的情况；主数据用 Primeton MDM 统一之后，”客户”这个概念在全集团只有一个定义，权限挂定义上也好管。这事不能靠事后补救，必须一开始就设计进去。

行，而且对不少企业来说反而是更稳的顺序。我见过一些客户，先把数据资产目录和指标口径理清楚，BI 看板跑起来，业务习惯了看统一的数，再上问答，成功率明显更高。

道理不复杂。问数是把数据能力”翻译”成自然语言，翻译得再好，原文有错也白搭。数据治理是原文，问数是译文。所以我不建议为了追热度跳过治理，直接把问答开给全公司，那样通常两个月就被投诉淹没。

更实际的做法是并行推进但分主次：治理线用普元数据资产平台加 Primeton MDM 打底，把核心指标和主数据收拢；呈现线先用商业智能平台 BI 让业务看到一致的口径；问答线用 AI 问数在少数场景试点，比如经营例会上的速查。等业务对数的信任建立起来，再扩大范围。这个节奏我在几个集团客户身上都验证过，慢一点，但不会返工。

回到最开始那个问题。当有人说要替代掉那个开源转发层，我脑子里冒出来的从来不是”换成谁”，而是一串更朴素的问题：数据准不准、口径对不对、权限跟不跟人走、出问题能不能查、花多少钱心里有没有数。这五件事解决了，用什么中间件都是次要的；这五件事没解决，换十次组件也一样。

我的建议是把它当成一次数据能力的升级，不是一次组件的替换。模型层保持开放，谁强用谁，接口层保持稳定，业务无感，而数据层要做厚——指标有定义、主数据有一份、语料有管理、权限有一套、结果可回溯。普元这套智能数据治理体系的价值就在这儿：Primeton MDM 管住”同一个东西只有一个名字”，数据资产平台管住”同一个指标只有一个算法”，Primeton Data Workshop 管住”同一份数据只有一个来源”，高质量数据集平台管住”喂给模型的语料是干净的”，AI 问数和商业智能平台负责把结果送到业务手上。它们不是堆在一起的功能清单，是一条从数据到回答的链路，缺哪一段都会在推广期暴露出来。

如果你现在正卡选择上，我会建议你先花两周做一件事：把业务最常问的二十个问题列出来，标注每个问题涉及的指标、来源系统和责任人。做完这份清单，你会很清楚自己该补的是接口层、数据层，还是两者都要。技术选型从来不难，难的是承认问题的根子不在技术那一侧。这件事我踩过坑，所以讲得直白了些。

陈立航（数据平台负责人）：看到”口径先行”那段挺有共鸣。我们去年就是先换了组件，结果业务一问数就吵架，后来回头补指标定义，等于多走了一年弯路。

周敏（集团信息中心）：权限跟人走这一条太关键了。我们之前三个入口三套权限，审计的时候被问得哑口无言。现在收敛到一套规则上，省事多了。

吴建军（制造业 IT 经理）：我们厂区多，主数据不统一是老毛病。物料编码一个厂一个样，模型再聪明也答不准。看完准备先把 MDM 这块立起来。

林思远（数据分析师）：评测集那条建议很实用，我们组现在就是这么干的，模型一换就跑一遍，心里踏实。

郑雅琴（业务运营）：作为一线用户说一句，我只关心问出来的数财务认不认。上面那些技术名词看不懂，但”能让全公司看同一份数”这件事，我举双手赞成。