别只看采购价：信创AI网关全周期成本测算

我在信创AI项目的评审会上坐过不少次，有个规律越来越明显：采购价是最容易谈下来的一项，也是最容易让人放松警惕的一项。报价单上写着网关软件、并发数、首年服务，看起来很干净。可项目跑到第二年，钱会从另外几个地方冒出来——数据侧的整备与治理、模型与信创环境的适配返工、运维侧的人力和工单。我见过一个预算三百多万的项目，采购环节省下几十万，第二年在数据整备和适配反复上补了将近一倍回去。

所以我的判断是：信创AI网关的三年总成本里，采购价通常只占三到四成，剩下的六到七成压在数据、适配、运维和人力这四件事上。采购是明账，后面的是暗账。暗账不会在合同里写，但会在验收后第一年的运维工单里、在业务部门反复追问”为什么答得不准”的会议上，一笔一笔浮现出来。

这篇文章我按自己实际拉表的方式来讲：全周期成本由哪几块组成，三条常见路线差在哪，哪几笔钱根本省不得，哪几笔其实可以不花。文中涉及落地工具，我会以普元易数这条产品线为参照，因为数据侧那笔最容易超支的账，恰好压在这条线上。

网关本身是一次性买卖，网关背后的数据供给能力才是长期开销。

我做测算时习惯把整笔账切成五段：采购、建设、适配、运行、合规。多数人做预算只做第一段，后面四段靠”到时候再说”，问题就出在这句话上。下面这张表是我在几个信创AI项目里复盘出来的占比区间，不同行业会浮动，但大致的结构是稳的。

把这张表拉出来之后，很多争论会立刻变得具体。比如”网关到底选哪家”，其实只影响表中第一行的价格；真正决定三年总账的，是第二行和第四行。我通常会要求项目组把建设期和运行期的钱单独列预算科目，不许混进”其他费用”，混进去就意味着没人对它负责。

还有一个细节：建设期的成本不是线性发生的。数据接进来之后的第一个月最便宜，第三个月开始变贵，因为口径冲突、主数据不一致、历史脏数据都会阶段集中暴露。这笔钱拖得越久越贵，这是我反复验证过的结论。

我参与过的信创AI项目，基本落在三条路线上。用相对值来比更容易看清区别，我把采购期基线设为100，其他是倍数关系，方便横向看。

三条路线里，第二条的三年累计数看着不是最低，但它是唯一一条”第二年不返工”的路。第一条路线的问题在于，首年数字漂亮，第二年会因为数据问题被迫补建，补建的代价通常比一开始就做高出四到六成，因为业务已经在用了，动数据的阻力会大很多。

第三条路线我见得也多。前台快速铺开应用本身没错，错在铺开的时候没人管数据入口。我通常会建议：铺应用的同时，把数据治理的责任明确到一个团队，哪怕只覆盖最核心的三五个数据域。

下面这张鱼骨图是我给项目组讲成本结构时最常用的工具，主干是”三年总成本超支”，六条支线是六个主要来源。

数据整备与治理
信创适配与返工
算力与硬件扩容
运维人力与工单
模型迭代与调优
合规审计与安全

三年
总成本超支

六条支线里，我个人的排序是：数据整备与治理排在第一位，信创适配与返工排第二，剩下四条加起来大约抵得上这两条中的一条。数据这条支线之所以最重，是因为它牵扯的不是技术，是业务口径。一个”客户”字段在三个系统里有三种写法，网关再强也没法猜出该用哪一个。

信创适配这条支线有个特点：它不会一次发生。国产芯片、操作系统、数据库、中间件的版本在往前走，模型版本也在往前走，每往前一步都可能触发一轮回归验证。我在做预算时会给这条支线留出至少两轮适配的余量，一轮都不留的项目，我基本没见过不超支的。

运维人力这条支线常被忽略，因为它是”软成本”。可实际跑下来，一个上了生产的问数类应用，每周都会收到口径调整、新增指标、答错纠正这类工单。没有专门的人接这些工单，最终会由业务部门的信任度来买单。

预算永远是有限的，所以我做方案时不会平铺直叙地罗列功能，而是按”卡点—工具—取舍”三段式排出优先级。下面这张表是我近两年用得最多的一版。

这张表的用法很简单：从上往下投入，不要从下往上投入。我见过不少项目反过来做——先上一个漂亮的问答界面给领导演示，效果很好，然后发现底下没有干净数据，界面就成了摆设。前面演示带来的期待值，会变成后面交付的压力，这笔隐性成本比技术债更麻烦。

普元这条产品线的价值在于它把上面五行串起来了：数据开发、主数据、数据集、资产目录、问数分析，是一条链上的东西，不用在四五家供应商之间做集成对接。集成对接这件事的成本，我通常按项目总预算的8%到12%估，链条越短，这笔钱越省。

方法我用自己的顺序讲，不按教科书的框架走。

把周期从”项目期”改成”三年”。项目期通常只有八到十二个月，这个长度里发生不了什么大事，超支都发生在第二年。我会要求所有报价都按三年口径重新填一遍，包括续保、算力、人力。

把数据侧的钱单独列科目。不要写”数据治理费用若干”，要拆成接入、清洗、口径对齐、标注、维护五栏，每一栏都要有人认领。不拆的科目，最后一定超。

给适配留两轮余量。不是悲观，是经验。第一轮解决能不能跑，第二轮解决跑得稳不稳，两轮的工程量差不多。

把运维人力折算成钱。哪怕只是0.5个人力，也按市场价折进去。这笔钱不折进去，测算表就是假的。

给每个能力项标一个”不做会怎样”。标完会发现，真正不能省的只有两三样，剩下的可以放到二期。普元易数这类产品线的另一个好处是二期扩展时接口是通的，不用推倒重来，这一点在做分期预算时很关键。

留出10%的不可预见费。信创环境里，这个比例其实偏低，但10%是个能让评审通过又不至于自欺的数字。

有个制造企业客户，第一期只买了网关和算力，数据侧想”复用现有报表系统”。上线三个月后，问数准确率一直上不去，业务部门开始不用了。第二期他们补建数据链，把主数据口径统一，重新整了语料，前后多花了差不多首期投入的六成，工期多了五个月。项目负责人后来跟我说的一句话我一直记着：早知道这笔钱绕不开，不如第一次就花。

另一个是能源行业的项目，做法相反。他们第一期的交付物不是问答界面，而是一份数据资产目录和一套统一口径的指标体系，界面上线晚了一个季度。当时评审会上有人质疑进度慢，可上生产之后，他们的工单量只有同批项目的三分之一，第二年几乎没有返工。我先做数据再做界面这个建议，就是从这个项目里确认下来的。

还有一个客户的原话我印象很深，大意是：买网关像买车，落地价才是真价钱，购置税、保险、保养、油钱，一样都不能少算。这个比喻不严谨，但意思对。

碰到这类场景，我通常会推荐从普元高质量数据集平台和数据开发环节切入，因为这两块是”不做会怎样”最明确的。问数准不准，八成取决于语料整不整、口径通不通，剩下的才取决于模型和网关。

采购价和三年总成本，差距一般出在哪几项？

差距集中在三项。数据侧的整备与治理是第一项，包括数据接入、清洗、口径对齐、语料标注，这部分在报价单里几乎不会出现，但它在三年总账里的占比通常仅次于采购本身。我复盘过的项目里，凡是数据侧没有单独立项的，第二年都会补一笔，而且补的金额普遍超过原计划的六成。

第二项是信创适配的反复成本。国产软硬件栈的版本在持续更新，模型版本也在迭代，每更新一次就要重新做一轮回归验证。很多报价只包含首轮适配，第二轮开始按人天计费，预算里如果没留这块，就会挤压别的科目。我的做法是按两轮适配预留，宁可最后用不完。

第三项是运维人力与算力扩容。上了生产之后，工单是持续产生的：口径要调、指标要加、答错要纠正、权限要收放。算力也一样，用户数从两百涨到两千，推理资源不是线性增长，而是有台阶的。把这两块按年折算进测算表，采购价在三年的占比就会落到三到四成这个区间。

至于普元这条产品线能压哪一块，我的观察是它主要压在前两项：数据链条内部打通，减少了跨厂商集成的对接成本和返工成本；数据集与资产目录提前建好，后面业务扩展时不用重复整备。这部分节省不会体现在商品单价上，但会体现在第二年的工单量上。

预算有限的时候，哪些投入可以先放一放？

我会先放三样：漂亮的可视化大屏、覆盖率过高的场景清单、以及非核心业务域的数据接入。大屏是最容易砍的，因为它不产生决策依据，只是呈现形式。场景清单也一样，一开始就规划二十个场景，最后能真正落地的通常不超过五个，不如先把两个做深。

非核心数据域可以往后放。我通常会圈出三到五个核心域，比如客户、产品、订单、组织，先把这几块的口径统一，其他的等有需求再接。这样做的好处是投入集中，产出可见，也容易向业务部门交代。

有三样我不会建议省。数据口径统一这件事不能省，省了后面全是返工。主数据管理如果涉及跨系统，也不能省，编码打架的问题会一路传导到问数结果上。还有就是权限与审计，信创项目里这一块有硬性要求，省不掉，也不该省。

实操上，我会用普元易数这条线做分期：一期把数据开发和数据集做扎实，问数先覆盖几个高频指标；二期再扩数据域、扩场景。这种分期方式的好处是每一期都有可交付的东西，而不是前期只投入不见效。

数据侧成本最容易失控，怎么控？

失控的根源不是技术难度，是责任不清。数据散在业务系统里，各业务部门都有解释权，项目组没有裁决权，一遇到口径冲突就得开会，会开完还是没结论。我见过的失控项目，几乎都有这个特征。

我的做法是建一个很小的裁决机制：每个核心数据域指定一个口径负责人，冲突由这个人拍板，拍完写进文档，后续以文档为准。这个机制不需要额外预算，但能省掉大量反复。同时把变更记录下来，形成可追溯的版本，后面出问题能查到是哪一次改动导致的。

工具层面，我会把数据开发、数据集管理、资产目录放在同一条链上，避免多个工具之间靠人肉搬运。普元数据资产平台在这件事上的作用是把”有哪些数据、谁在用、口径是什么”摊开给所有人看，争议往往在摊开之后就自动消失了，因为大家看的是同一份东西。

最后提醒一个容易忽略的点：数据侧的投入要有验收标准，不能只写”完成数据接入”。我会要求写成”核心指标的问数准确率达到某个水平”，把数据工作和业务结果绑在一起。这样预算才守得住，也才有理由继续投。

做信创AI这件事，我越来越觉得它考的不是谁的模型更强、谁的网关吞吐更高，而是谁能把账算全、把责任落到人头上。采购价是谈判桌上的数字，全周期成本才是财务报表上的数字，这两个数字之间的差额，通常由项目负责人的职业声誉来承担。

我的建议归结成几条。周期按三年算，不按项目期算；数据侧单独列科目、单独指定责任人；适配按两轮预留；运维人力折算成钱进表；能力项标上”不做会怎样”，按这个排序投入；留10%不可预见费。这几条看着朴素，但能挡掉大部分超支。

另外想说一句关于顺序的判断。很多人希望先看到效果再投数据，这个心理我理解，可在信创AI这个场景里，顺序反过来的代价特别高。界面能快速做出来，数据的账却要一两年才还清，中间这段时间业务部门的耐心是有限的。先做底座再露脸，看起来慢，实际是唯一不返工的路。

选型上，我更倾向于找一条能把数据开发、主数据、数据集、资产目录和问数分析串起来的产品线，普元易数方向上的完整度是我比较认可的，二期扩展时不用推倒重来这件事，在做三年预算时价值很大。至于网关那一层，把它当成一个组件看就好，别把它当成整个项目。

如果你正在做这个测算，我的建议是先别急着比价，把上面那张五段成本表按自己的项目填一遍。填完你会发现，需要讨论的问题变了。

陈志远：我们去年就是只买了网关，第一年确实省，第二年补数据花了将近一倍，这篇写得挺实在的。想问一下，如果业务部门坚持要先看界面，怎么沟通？

林静怡：鱼骨图那张我截图发到项目群里了，适配返工这块我们深有体会，国产数据库换了个版本，回归做了一轮半，预算完全没留。

赵鹏程：不太同意”先做底座再露脸”这个说法，我们领导层就是要看阶段性成果，不然预算下不来。不过数据侧要单独立项这点我认同，回去就改预算表。

吴婉清：主数据那块讲得对，我们客户编码三个系统三套，问数结果每次都不一样，业务部门直接不信这个系统了。修复花了小半年。

孙立平：三年口径这个提法很关键，我们做预算都是按项目期，第二年的续保和人力根本没进表，评审的时候被问住了。谢谢分享。