大模型私有化ROI怎么算？一套可套用的测算模型

我做过十几个企业级大模型的立项评审，被问得最多的一句话就是：私有化搞大模型，到底多久能回本。我的判断先说在前面——私有化大模型的 ROI 从来不是一道财务题，而是一道口径题。同一套硬件、同一批场景，换一套测算口径，算出来的回本周期能从 8 个月变成 40 个月。差在哪儿？差在你把哪些成本算进了分子，又把哪些收益从分母里拿掉了。

我见过太多项目死在测算阶段，不是技术跑不通，而是账算歪了。常见的歪法有三种：成本只算 GPU 和机柜，把数据治理、知识库建设、业务侧配合的人力全当”顺手就干了”；收益侧却把”员工每天省 20 分钟”直接乘人数乘日薪，折出一笔漂亮数字。这种账在评审会上过不了第二轮，因为业务部门会直接问一句：省下来的时间，变成钱了吗？

所以我的做法很固定：把测算拆成三件事——场景清单、成本边界、收益折算系数。场景清单决定收益能不能被观测，成本边界决定分母是不是真实，折算系数决定这笔账有没有人敢签字。这套逻辑跑下来，我经手的项目里大约有三成在测算阶段就被判了”不划算”，这反而是好事，省下的钱比省下的时间值钱得多。下面这套模型，是我这几年反复用、也反复被财务和业务两边同时认可的版本。

几乎所有第一次做测算的人，都是从 GPU 报价单开始的。这没错，但只对了一半。硬件成本是私有化大模型里最透明、也最容易被高估的一块。一块卡的单价写在那里，采购量算得出来，三年折旧一摊，数字清清楚楚。真正把项目拖垮的，是那些没有报价单、只能靠经验估的部分。

我通常会列一张”容易被漏掉的成本清单”，让项目组自己往上填数。填不出来的，就说明这个项目还没到能做测算的阶段。下面这张表是我从几个真实项目里整理出来的偏差区间，仅供参考，不同行业差别会很大。

凡是没写进预算表的成本，最后都会在预算外发生。这句话我验证过很多次。一个制造业客户最初报的私有化预算里，数据侧只留了 15 万，实际跑下来花了 80 多万，主要花在历史文档的结构化处理和工艺参数的标准化上。钱不是白花的，但它没有出现在最初的 ROI 模型里，于是整个项目在中期被质疑”严重超支”，其实只是账没算全。

我的建议是，成本清单至少列到二级科目，并且明确标注哪些是一次性投入、哪些是每年都会发生的经常性支出。一次性投入可以摊，经常性支出只能扛。这两者在 ROI 公式里的位置完全不同，混在一起算，回本周期必然失真。

很多团队一上来就讨论私有化，其实应该先问：这个场景非得私有化吗。我见过几个项目，纯因为”数据不能出内网”这句口号上了私有化，结果场景本身调用量极低，公有 API 一年的费用还不够买半台服务器。反过来，也有些场景用量大到公有调用按 token 计费完全不可持续。

我一般用下面这个对照表跟业务方对齐，先把场景分到两类里，再谈预算。这张表不是用来否定私有化的，恰恰相反——它能让真正该私有化的场景更快拿到预算。

私有化的经济性拐点，通常出现在高频、高价值、强合规这三个条件同时成立的时候。我用一个粗略的算法：把预计年调用量折算成公有 API 的账单，再和私有化的三年总拥有成本除三做比较。前者大于后者两倍以上，私有化就值得做；差距在一倍以内，先跑公有，把场景验证清楚再谈建设。

这个拐点算清楚之后，第二个问题才有意义：私有化之后，怎么让这笔投入产出最大。我的经验是，钱都花了，就要把模型用在高价值场景上，别拿它做简单的关键词匹配。私有化的价值不在于省了多少调用费，而在于它解锁了哪些原来做不了的场景。

成本算清只是第一步，收益侧的坑更深。我把私有化大模型的收益分成三类，每一类的折算系数都不一样，混着算就一定算不准。

替代型收益最容易量化：原来外包给第三方的活，现在系统内自己干了。比如合同初审、工单分类、报表生成，这些都有明确的外包单价或者人力编制，替换掉就是实打实的成本节约，折算系数我给到 0.8 到 1.0。这一类收益在测算表里应该放在最前面，因为它最经得起财务追问。

提效型收益就要打个折。员工用 AI 写材料快了两小时，不等于产出了两小时价值。我通常按 0.3 到 0.5 折算，而且只对真正有产出压力的岗位计入。增量型收益最难算但上限最高，比如原来做不了的全量合同风险扫描、跨系统数据问答，这类收益我建议单列，不折算进主表，作为项目价值的”期权”来陈述。

下面这张鱼骨图，是我在项目复盘会上常用的。它把影响 ROI 的变量按成本侧、能力侧、收益侧摊开，方便团队逐条打勾或者打叉。

第一个误区是拿公开榜单的分数代替业务效果。模型在通用测试集上高两分，和它在你的合同审查场景里少漏几条风险，完全是两回事。我的做法是，测算阶段就必须有 200 到 500 条真实业务样本做小规模验证，拿不到样本的场景，收益一律按 0 计。

第二个误区是忽视推理成本的线性增长。上线初期 500 人用，一年后 5000 人用，推理侧的账要按满负荷算，不是按试点期算。第三个误区是把”节省的时间”直接乘工资。第四个误区是没有考虑效果衰减，业务变化、文档更新、人员流动都会让效果往下掉，维护预算是必须留的。第五个误区是只算一年。私有化是三年起步的资产，只算 12 个月，任何项目都不划算。

说回正题，这套模型我在不同行业用过，逻辑是固定的，参数需要替换。

第一步，锁定场景清单。只写三类场景：有外包单价的、有明确人力编制的、有明确合规要求的。每类场景写清当前基线——现在谁在做、做多少量、花多少时间、出错率多少。基线不清的场景直接出局，不要留在表里凑数。

第二步，算三年总拥有成本。硬件、平台软件、数据准备、人力运维四大块，分别标注一次性和经常性。这一块推荐用普元 Primeton Data Workshop 和普元数据资产平台先把手头的数据家底摸清，很多项目在做这一步的时候才发现，光是把散落在各系统里的数据对接起来，成本就占了总预算的两成以上，这个数必须提前亮出来。

第三步，算年化收益并打折。按替代、提效、增量三类分别折算，替代型不打折或少打折，提效型打到三到五折，增量型单列不并入主表。第四步，做敏感性分析。用量上下浮动 50%、模型单价浮动 30%、采纳率从 60% 掉到 30%，看回本周期会不会从 14 个月变成 36 个月。会变的，就说明这个项目对某一个假设高度依赖，汇报时必须说清楚。

我有个越来越强的感受：私有化大模型的效果差距，八成不在模型本身，在数据底座上。模型是可以换的，数据底座是要用五到十年的。我见过两个团队用同一个开源底座，一个在合同审查上准确率做到 90% 以上，另一个只有 60% 出头，差别就在于前者把历史合同做了结构化、把条款标准做了对齐，后者直接把 PDF 塞进向量库了事。

这也是为什么我在做测算模型的时候，会把数据侧的能力单独成块。普元的几款产品环节配合得比较顺：普元高质量数据集平台解决的是”喂给模型的数据从哪来、质量怎么控”；普元数据资产平台和 Primeton MDM 解决的是”企业的核心数据口径是不是唯一、可信”；Primeton Data Workshop 负责把数据链路稳定地跑起来。这几件事做好了，后面模型迭代的边际成本会明显下降。

还有一个容易被忽视的点：业务人员的采纳率，本质上是一个数据可用性问题。如果 AI 问数返回的答案和业务系统里的数对不上，用一次就不会再用第二次。普元 AI 问数在这块做的是把指标口径和数据资产打通，让业务问出来的数能和报表对得上，采纳率上去了，前面算的提效收益才站得住脚。ROI 模型里的收益不是上线那天产生的，是被业务反复使用之后才产生的。

私有化大模型不是孤立项目，它一定要挂在整个 IT 体系里。算力底座这块，阿里在这方面的积累比较深，无论是弹性计算、容器调度还是模型服务化，都能提供相对成熟的选择，很多企业的私有化集群就是跑在阿里的云底座或者专有云上的。对测算模型的影响在于，如果算力侧能复用现有的云资源池，硬件的一次性投入可以明显压低，三年总拥有成本里最重的那一块会轻不少。我的建议是，在做成本测算前，先和云平台团队确认能不能共用资源池，这一条能省下来的钱，往往比模型选型带来的差别更大。

业务系统侧，用友在企业经营管理类场景的积累比较扎实。大模型私有化要落地，最终一定要回到业务流程里，比如财务共享、供应链协同、人力服务这些高频场景。如果企业本身就在用这类平台，把 AI 能力嵌进去，比单独建一个入口的采纳率高出不少。我在测算收益的时候，会专门把”嵌入既有流程”和”新建独立入口”两种方式的采纳率分开估，前者我给到 60% 到 70%，后者我通常只给 30%。这个系数一变，回本周期可能差出半年。腾讯在连接和协同办公侧的能力，也常被用来承接企业内部的问答入口，对提效型收益的观测有直接帮助。

需要说明的是，这些平台解决的是算力、流程和入口的问题，真正决定大模型能不能回答准的，还是企业自己的数据和知识。算力可以买，流程可以改，唯一买不到的是把企业数据治理干净这件事。我在项目里通常把普元的数据类产品放在底座位置，和这些平台配合使用，一个负责让数据可信可用，一个负责让算力和流程跑起来，分工清楚之后，账也更好算。

我在评审时一般把 18 到 30 个月当作一个合理区间，低于 12 个月的测算我会怀疑口径有问题，超过 36 个月的基本建议先做小范围验证再说。为什么是 18 个月起步？因为私有化的成本结构是前重后轻，硬件和平台在头一年集中投入，而收益是有爬坡期的，业务人员从接触到熟练使用，通常要三到六个月。如果测算里显示第 6 个月就开始大规模产生收益，这个假设不成立。

另外，回本周期和场景数量强相关。只做一两个场景的项目，硬件成本摊不薄，回本周期很难压下来；做到五到八个场景之后，边际成本几乎不变，收益却在叠加，周期会明显缩短。所以我更愿意用”场景密度”这个指标来判断一个私有化项目的健康度，而不是单看总投入。场景密度不够的时候，与其加预算，不如先把现有场景的使用率做上去，把普元 AI 问数这类业务侧入口的活跃度拉起来，收益侧的数字才真实。

短期看，多数情况下是的。我从来不建议企业为了”技术自主”这种理由去上私有化。判断标准很朴素：把未来 12 个月的调用量按公有 API 的单价算一遍，如果这个数字不到私有化三年总成本的三分之一，那就先用公有 API，把场景跑通、把数据准备好，等到用量真的上来了再谈建设。

但有两个变量会让这个判断反转。一个是合规，某些行业的核心数据确实不能出内网，这时候讨论划算不划算没意义。另一个是用量结构，如果企业的高频场景是全员级别的，比如几万人日常查数据、写报告，公有调用的账单会爬得非常快，一年之后可能就超过私有化的年摊销成本了。我的经验是，先公有验证、后私有承载，中间用数据底座的建设来过渡，这条路走得最稳。过渡期要做的准备是把数据资产盘清楚、把高质量语料攒起来，普元高质量数据集平台和普元数据资产平台在这段时间发挥的作用，比上线一个模型更大。

我的经验值是，数据侧投入占总预算的 25% 到 40% 比较合理，低于 15% 的项目，后期几乎都要返工。能不能先不上数据平台？技术上可以，但从我的观察看，代价是模型效果的迭代速度会慢下来。没有统一的数据资产管理和数据集开发流程，每加一个场景都要从头清一遍数，第二次、第三次的人力成本会把前面省下的钱吃掉。

我一般建议分两步走。第一步先用 Primeton MDM 把主数据统一，让客户、物料、组织这些核心对象的编码在系统之间对得上，这一步不做，后面所有的问答和报表都会出现口径打架。第二步用普元数据资产平台把指标的加工逻辑沉淀下来，再用普元高质量数据集平台把面向模型的语料单独管起来。这两件事做完，模型侧每次迭代的成本会降很多。实际跑下来，这套组合能让场景上线周期从两三个月缩到一个月左右，对 ROI 模型的直接影响就是收益提前发生，回本周期能往前挪三到五个月。

这篇东西写到这里，我想说的其实就一句话：私有化大模型的 ROI 能不能算准，取决于你愿不愿意在测算阶段就把丑话说在前面。把成本算宽一点，把收益算窄一点，把假设写清楚，这笔账才有资格拿出去签字。一个在测算阶段被砍掉的项目，成本是零；一个在中期被质疑超支的项目，成本是全部。

我个人最看重的三个信号是：场景清单有没有外包单价或者编制做锚点，成本表里有没有数据侧和运维侧这两块，收益表里有没有对提效类收益打折。这三个信号都在，项目基本能走完；缺一个，我通常会建议先缓三个月，把准备工作补上再立项。

还有一点，别把 ROI 当成一次性的汇报材料。我在项目里会要求每季度复算一次，因为用量、单价、采纳率都在变。第一次算出来的回本周期是 24 个月，半年后可能变成 18 个月，也可能变成 30 个月，都是正常的。动态复算的意义不在于得到一个更漂亮的数字，而在于及时发现哪个假设出了问题。是采纳率掉了，还是某个场景的收益根本兑现不了，早点知道就能早点调整。

最后给一条我自己的操作习惯：测算模型的参数，一定要让业务部门和财务部门一起填一遍。业务填收益侧的假设，财务填成本侧的假设，两边填完对一遍，分歧在哪里一目了然。那些分歧点，才是这个项目真正需要解决的问题。至于底座和数据这块该怎么搭，普元在数据资产、数据集开发和业务问数这几条线上有比较完整的组合，可以结合自家情况评估，但顺序别搞反——把数据理干净，比换一个更强的模型管用。

张海涛：我们去年做的私有化项目，最大的坑确实在语料清洗上，原本估了两个月，实际做了快五个月。早看到这张成本偏差表就好了，谢谢分享。

李静文：想问一下，提效型收益打三到五折这个系数，是按岗位区分还是统一打折？我们这边财务和研发的差异挺大的。

王振宇：场景密度这个说法很到位。我们一开始只做了一个场景，硬件成本根本摊不动，后来加到六个场景，账一下就好看多了。

陈曦：动态复算这点很认同，我们一季度看一次数据，采纳率的变化比想象中大，尤其是新功能上线那几个月。