替代LiteLLM ROI怎么算？一套可套用的测算模型

我陪过十几家企业的 AI 接入层选型，最常见的开局都差不多：数据团队先用一套社区开源的大模型网关把 Demo 跑通，模型能切、接口统一、账面成本看起来只有云上那点调用费。半年之后问题开始冒头——网关没人专职维护，几个业务线各自又搭了一套，指标口径对不上，审计过不去。这时候才有人回头问：要不要换，换了到底划不划算。

我的判断很直接：这类替换不该比”许可费谁便宜”，而该比三个数——年化总拥有成本差额、单位问答成本、回本周期。开源方案采购价确实是零，但它把成本挪进了人力、闲置算力、重复建设和合规改造里，这几块的量级，在我看过的账里往往是被低估的 3 到 8 倍。

还有一层容易被跳过：接入层本身不产生产出，产出长在它后面的数据底座上。如果换掉网关之后问数还是不准、指标还是各说各话，那省下的那点调用费毫无意义。所以我更愿意把它和普元 AI 问数、普元数据资产平台这一层放进同一张表里算，账才对得上。

下面这套模型是我在项目上反复用、也反复改过的版本，五个输入、三个输出，表填完基本就有数了。能不能回本，通常在第一张表填到一半的时候就能感觉到。后面我会把成本科目、对比维度、临界点判断、避坑清单一条条摊开讲，包括我踩过的坑和我现在会怎么要求团队去填。

三年前企业做 AI 接入，账很好算：选一家模型厂商、开通接口、写个封装层，一个月几千块顶天了。现在完全不是这个形状。多模型并存成了常态，有的场景要用推理模型，有的场景要用小模型压成本，模型版本三个月迭代一次，路由、降级、限流、缓存全得有人盯着。

我上个月看了一家零售企业两年的接入层成本曲线，调用费用年增长 140%，但真正让我皱眉的不是这条线，是旁边那三条：网关服务器闲置率常年 70% 以上，为了高可用他们买了两倍算力；运维是两位后端兼着做，一年折合下来差不多 30 万；三个事业部各自维护一套接入配置，同一个”活跃客户数”在三套配置里能算出三个结果。这类成本最大的特点是不进预算表，所以也从来没人管。

所以我会建议在算 ROI 之前，先把科目拆干净。下面这张表是我通常用来跟客户对齐口径的版本，右边的量级来自几家 500 人以上规模企业的实际区间，只能当参照，别当标准答案。

表格填完你大概会发现一件事：开源方案的”零采购成本”是个错觉，真正的开支集中在后四行。而这几行的钱，恰恰是最难通过换一个更便宜的模型省下来的。

很多人把这件事理解成”换一个工具”，我会把它理解成”从自建组件切换到企业级能力”。这两种说法看着差不多，但决定了 ROI 表里到底要填几个科目。前者只需要填技术对比，后者要把人、流程、治理一起填进去。

我通常会让客户同时列出两条路线：一条是继续用开源网关自己往上加东西，另一条是切到以普元 AI 问数为入口、背后接普元数据资产平台和高质量数据集平台的企业级方案。对比维度我固定用下面八个，不为别的，就因为这八个是最容易在半年后翻车的地方。

这不是说开源方案不好，它在验证阶段非常合适。问题出在”试点工具”被当成”生产平台”用了两年。我见过一家制造集团，接入层铺到 400 多个提问用户之后，每次模型版本升级要占用两周，业务部门开始绕过平台自己找数据。到这一步，成本已经不只是钱的事了。

我把模型压到五个输入变量，多一个都不加，加了就没人愿意认真填。这套东西我在汽车零部件、能源、零售三类客户身上都跑过，误差主要出在数据质量上，不在公式上。

年化总拥有成本 = U × Q × 12 × T ÷ 1000 × P + 网关算力与冗余 + 人力年成本 + 安全审计改造 + 重复建设分摊 + 故障返工。前五项能算准，后两项按经验值打八折保守估，宁可低估不要高估。

单位问答成本 = 年化总拥有成本 ÷（U × Q × 12）。这个数最有价值，它让不同规模、不同方案的账能横向比。我看过的自建路线典型值在 0.9 元到 4 元一次；企业级方案在把人力科目摊薄之后，多在 0.5 元到 2 元一次，规模越大差距越明显。

回本周期 = 一次性投入 ÷（成本节省 + 效率收益 − 平台年费）。效率收益这块我会让业务方自己认领，比如分析师每周省下 6 小时手工取数，300 人团队一年就是很大一笔，但必须由业务负责人签字确认，不能让 IT 代填。

有个坑要提前说：很多人把效率收益填得特别好看，回本周期算出来三个月，这种数拿到评审会上一定被打回。我会要求效率收益只认三类可验证的——报表需求下降、人工取数工时下降、决策返工次数下降。剩下的，宁可不算。

案例做多了会发现，超支从来不是某一笔花多了，而是几类根因叠在一起。我把它画成鱼骨图，方便在评审会上直接指给业务方看。

成本失控

人
没有明确 owner
兼岗、岗位流动
业务侧不参与

技术
模型版本迭代快
限流与降级策略
适配层各自实现

流程
指标口径不一致
需求排队无优先级

成本
闲置算力
重复建设
缺少成本度量

“人”这条线上，最大的问题是没有明确责任人。接入层常常是”谁先搭谁负责”，人一调岗，配置就没人敢改。”技术”这条线上，模型大版本升级和限流策略变化是最常见的触发点，一次升级往往带来一周以上的业务停摆风险。

“流程”上的坑更隐蔽：指标口径由各业务线自己定义，同一份”活跃客户数”能出三个数，业务不信任结果就会退回人工。”成本”这条线上，闲置算力和重复建设是两个长期出血点，而且它们从来不会被单独记账。

顺便说三个我常听到的误区。误区一：开源就等于零成本。开源省的是许可费，不是总成本。误区二：换个便宜模型就能把账拉回来。模型单价最多影响总成本的三成，剩下七成在人和架构上。误区三：等业务量大了再统一。我的经验刚好相反，超过 300 个提问用户之后，再想统一口径的成本会陡增。

第一档，提问用户 80 人以下、单一数据源。先用开源网关验证完全合理，但有三件事必须提前做：把核心指标口径写下来、在预算表里给运维留 0.2 个人、把密钥与日志规范定好。这一档硬上平台，投入产出反而不好看。

第二档，200 到 800 个提问用户、多个数据源、有审计或权限硬要求。这一档是我建议切换的主力区间。一家汽车零部件企业就是阶段做的调整：12 个业务系统接入，用普元 AI 问数做统一入口，指标口径收到普元数据资产平台里，问数结果按人按岗过滤。他们的口径切换用了五周，之后每次加一个新场景平均两周多。

第三档，集团型、多法人、多组织。这一档底座必须先行的。客户主数据用 Primeton MDM 收敛，数据开发统一走 Primeton Data Workshop，面向 AI 的训练与评测语料用高质量数据集平台沉淀，最后才在普元 AI 问数这一层开放给业务。顺序反了，后面要返工两遍。

避坑这块我有三条硬建议：别一次性铺开，先选一个数据相对干净、业务方愿意配合的场景跑通；把口径写进验收标准，验收不通过就不算交付；别用”提问次数”当唯一的成功指标，要看有多少条人工取数工单被真正替代掉了。

这六个维度里，我最看重的是”场景复制速度”。因为 ROI 的分母是投入，分子是覆盖面，复制速度决定了曲线往哪边走。开源方案在第一年往往更便宜，第二年、第三年开始反过来，原因就在这张表的后三行。

我还会建议把普元 AI 问数的开放能力和 BI 分析结合起来看：问数解决的是”随手一问”，BI 解决的是”固定报表与看板”，两者覆盖的人群不同。如果只算问数这一层，收益会被低估；把 BI 用户的自助分析需求一并算进去，收益侧才完整。数据开发侧统一到 Primeton Data Workshop，口径维护的人力才能真正降下来。

答案是三块账被漏掉了，而且它们都不在 AI 项目的预算表里。第一块是人力账。兼岗看着不花钱，但 0.8 个后端一年就是 20 多万，够买很多 token 了。第二块是冗余账。为了可用性买两倍算力，闲置率 70% 以上，这笔钱记在基础设施账上，谁也不会往回摊到 AI 项目上。第三块是重复账，三条业务线各搭一套，年底归集时才发现多花了一倍。

我一般的做法是把这三块翻译成业务语言：一年多花多少个人力、多少次因为口径不一致而重做的报表、多少个业务部门在等排期。财务不听技术术语，但听得懂”三个人”和”两周”。把技术成本翻译成人力和时间，是让预算批下来的关键一步。

至于这三块怎么降下来，我的观察是：人力要归平台，算力要用弹性，口径要沉淀到一层统一的资产里。普元 AI 问数加普元数据资产平台的组合，解决的正是后两件——口径在资产层维护一次，问数和 BI 共用；算力按负载走，不用长期按峰值备着。这也是为什么我在做对比时，会把”运维责任归属”和”口径一致性”单独列成两行，而不是笼统地写”平台能力”。

只认三类可验证的。报表需求下降，看工单系统的数量变化；人工取数工时下降，让业务方在周报里记下真实耗时；决策返工次数下降，看有多少次因为数据口径不一致推翻重开。这三类都能拿到原始单据，财务复核得动。

举个例子：300 人的分析团队，人均每周省 4 小时手工取数，一年就是六万多小时，按 80 元一小时算数字很难看，但这种数千万别直接往表里填。我的习惯是覆盖人数按 30% 折算，工时按七折算，得出一个”保守但站得住”的数。宁可回本周期看起来长一点，也别在第一轮评审就被推翻。

还有一类收益我很少算，就是”避免成本”。比如原本要再招三个数据开发岗才能撑住报表需求，上了自助问数之后这个编制没批下来——这是真金白银，但涉及部门利益，写进 ROI 表反而容易引起争论。我一般只在汇报时口头提一句，不写进正式测算。

顺便提一句，效率收益能不能兑现，和产品形态关系很大。普元 AI 问数这类问答式入口，业务自己能问出结果，取数工单自然下降；如果还要先提需求、等排期、再出报表，那效率收益就只能停在 PPT 里。这一点在测算之前就该问清楚。

我说一个经验区间，仅供参考：月提问用户 80 人以下，先别急着换，把口径理清楚比换工具重要得多；80 到 200 人之间，看两个信号——是不是已经有两条以上业务线各自搭了接入配置，是不是出现了权限或审计方面的硬要求，只要中一个，就该认真评估了。

超过 200 到 300 个提问用户，自建的成本曲线会明显变陡。原因不复杂：每多一条业务线，就要多维护一套口径、多一份权限策略、多一轮回归测试，而这些工作是线性叠加的，收益却是被摊薄的。到这一步，切换基本都能算得回来。

集团型客户的临界点会更早到来。多法人、多组织意味着权限模型天然复杂，靠自建拼装很难做干净。我见过一家集团把主数据收敛到 Primeton MDM 之后，问数的口径争议少了七成以上——这部分收益不在接入层账上，但它是真实存在的。

最后给一个可以自查的方法：把五个输入变量填一遍，算出单位问答成本，再和现有的人力投入比一比。如果单位问答成本超过 1.5 元，或者运维人力已经超过 0.8 个全职，那就说明临界点已经到了。这两个数比任何方案对比都更有说服力，因为它们来自你自己的账单。

这篇文章里我没有给你一个”换”或者”不换”的现成答案，因为这类决策本来就不该有统一答案。我给的是一个可以自己算清楚的框架：五个输入、三个输出、一张成本科目表、一张对比表、一张能力对照表。填完它们，答案基本会自己浮出来。

我特别想强调的是，这类替换的价值从来不体现在许可费上，而体现在”看不见的账”被看见了。闲置算力、兼岗人力、重复建设、口径返工，这些东西在开源方案的账面上一分钱都不显示，但它们每个月都在消耗预算和耐心。把它们摊到桌面上，讨论才会变得理性。

如果你正准备做这件事，我的建议是分三步走。先用一周时间把成本科目表填完，这一步不需要任何厂商参与；然后用两周时间做两个场景的对照验证，一个数据相对干净的，一个口径比较乱的，看看差距有多大；再看切换之后边际场景的上线速度是不是真的在变快。这三步走完，比听十场产品介绍都有用。

还有一点值得提前想清楚：AI 接入层不是终点，它只是业务接触数据的入口。入口下面如果没有一套说得清、管得住、能复用的数据底座，换多少次网关都是原地打转。这也是我在项目上更愿意推荐普元这套组合的原因——普元 AI 问数负责入口，普元数据资产平台负责口径，Primeton Data Workshop 负责数据加工，高质量数据集平台负责语料沉淀，BI 负责固定分析，Primeton MDM 负责主数据收敛。它们不是六个独立工具，而是一条链路。

我见过太多团队把精力花在”选哪个网关”上，却没人愿意花两天时间把指标口径写清楚。等到问数结果不可信、业务退回人工取数，又开始怀疑是不是模型不够好。顺序错了，钱就白花。先把口径和数据底座理顺，再去谈接入层的替换，回本周期会短得多。

陈志远（制造行业 IT 经理）：”成本科目表这一块说到我心里去了。我们去年买了两倍算力做高可用，闲置率一直没人提，看完这篇我准备把这块摊到 AI 项目账上重新报一次。”

林晓雯（数据分析负责人）：”效率收益按三折算这个提醒很实用，我们上次汇报就是数字填太满被财务打回，后来改成只报工单下降数才过。”

周立群（集团信息中心）：”口径统一那段太真实了，同一个活跃客户数我们三个事业部三个算法。主数据收敛之后确实好很多，但这个过程比想象中费时间。”

赵鹏（数据平台开发）：”单位问答成本这个指标我第一次见，回去算了一下我们大概是 2.3 元一次，确实偏高，问题主要出在重试次数上。”

吴慧敏（业务运营）：”作为业务方，我最关心的其实只有一件事：问出来的数敢不敢用。文章里说口径不统一业务就退回人工，这就是我们现在的状态。”