别只看采购价：AI模型与服务网关全周期成本测算

我做过十来个数据平台和AI平台的预算评审，也帮客户复盘过跑了一年之后才发现”买贵了”的项目。关于AI模型和服务网关的成本，我有一条不太讨喜的判断：采购报价单上的那个数字，通常只占三年总拥有成本的百分之三十到百分之四十五，剩下的大头藏在集成、治理、算力调度、人员和时间里。很多团队在立项时盯着单价谈，谈到最后一年回头看，钱花得最多的地方反而是数据准备和运维改造。

为什么会这样？因为AI模型不是一个买回来插上电就能跑的硬件，服务网关也不是一个装完就完事的中间件。模型要接业务系统，就得有人做接口适配；要保证回答准确，就得有人整理知识库和主数据；要控制调用费用，就得有人做路由、缓存、限流和灰度。这些活都有人天成本，也都有工具成本。我在一个制造业客户那里见过，模型授权费谈到了很低的价格，结果第一年数据清洗和标签体系重建花了将近两倍于授权的钱。这不是供应商的问题，是测算口径的问题。

我通常会要求团队按四个账本分开算：软件授权账、算力与调用账、数据与治理账、人力与时间账。前两个容易算，后两个最难估，但恰恰是决定项目能不能跑满三年的关键。普元在这件事上的价值，我个人的体感是它把第二和第三个账本拉平了不少——Primeton Data Workshop 做数据开发、普元数据资产平台管口径、Primeton MDM 抓主数据、Primeton AI 问数做问数入口，这些环节本来要拼三四个厂商，现在能在一个体系里落地，交接成本明显下降。

下面我把这套测算方法拆开讲，包括我踩过的坑、看过的真实账本，以及不同规模团队该怎么取舍。如果你正在做AI项目的预算，希望这篇能帮你把那些”后来才发现”的钱提前摆到桌面上。

我见过太多预算表的第一行写着”模型服务费”，然后就没有了。实际跑下来，模型服务费往往排不到第一。一个典型的AI应用上线一年，成本大致分成这么几块：模型授权或API调用、推理算力、网关与调度中间件、数据准备与治理、应用集成与前端、监控运维、人员投入。这七块里，数据准备与治理通常占25%到40%，是单项最高的一块，也是最容易被漏算的一块。

为什么漏算？因为它不体现在采购合同里。合同签的是软件，活是人在干。整理业务口径、统一客户编码、清洗历史数据、建标签体系，这些都是项目组内部的人力消耗，不进采购单，但在财务上一样是成本。

下面这张表是我常用的一个粗略比例参考，用来快速判断一个AI项目的预算结构是否合理。不同行业差异很大，但量级上能帮你定位。

看完这张表，你可能已经明白我为什么坚持要分开算账。只比采购价，等于只看了账单的三分之一。我一般会在评审会上直接问：数据治理这块谁负责、预算在哪一栏、有没有单独的人力估算。问这三个问题，通常就能看出这个预算表是认真做的还是拍出来的。

有人会问，网关才占5%到12%，值得单独拿出来讲吗？值得。因为网关的账最容易被算错——它的采购价往往不高，但它的配置方式会反向影响算力和调用成本。一个路由策略写得粗的网关，能让你的推理算力账单多出三成。这不是夸张，我实际对过账。

比如缓存策略。同样一批高频问题，做不做语义缓存，命中率差二十个百分点，对应的推理次数就是几十万次的差别。再比如多模型路由，简单问答走小模型、复杂推理走大模型，和所有请求一律走大模型，成本可能差两到三倍。这些决策都发生在网关层，但账单体现在算力层。

我把采购视角和全周期视角的差异整理成下面这张对照表，你可以拿它去核对现有方案。

我的建议很直接：谈判时一定要求供应商给出三年TCO测算表，并且把数据治理和运维迭代单列。谁愿意给你算这张表，谁大概率是真的做过交付。普元在数据治理这条线上有 Primeton Data Workshop 和普元数据资产平台这类产品，能把数据准备这块的工时估得更实，这一点在实际评比里是加分项。

讲三个项目，都是我自己参与过的，名字做了处理，数字做了区间化。

第一个是大型制造集团的知识问答项目。预算里模型和算力占了七成，数据治理只留了一成。上线三个月后发现，问同一台设备的故障代码，不同车间的叫法不一样，模型答得时对时错。返工建主数据、统一设备编码，花了将近四个月，人力成本接近原预算的三分之一。后来他们引入了 Primeton MDM 做设备与物料主数据，口径才稳下来。这个项目的教训是：AI的准确率上限，是数据口径的一致性决定的，不是模型参数量决定的。

第二个是金融客户的多模型网关改造。原本所有请求走一个大模型，月算力账单很高。改造后做了分级路由，简单查询走小模型，复杂分析走大模型，同时加了语义缓存。改造投入大概是两个月的人天，但月度算力成本下来了将近四成，半年就回本。这里面网关是核心，模型本身没换。我经常拿这个案例说服客户：网关不是配角，它是成本调节阀。

第三个是零售企业的BI智能化升级。这个项目最有意思，因为它一开始的诉求是”做个AI问数”，做下来发现真正卡住的是指标口径。销售额到底含不含退货、会员口径怎么算，各部门吵了两个月。最后是先上普元数据资产平台把指标口径固化，再上 Primeton AI 问数做自然语言查询，效果一下就顺了。这个项目让我坚信一件事：问数体验的天花板，是数据资产的治理深度。

三个项目的共同点是：超预算的部分，几乎都不在采购合同里，而在数据、口径和迭代里。所以我现在做预算评审，第一件事不是看报价，是看数据治理那栏有没有预算。

客户常问我，超支到底是因为哪一步做错了。我一般不用”哪一步”这个词，因为超支很少是单点问题，它更像几条线同时松了。下面这张鱼骨图是我评审时经常画在白板上的版本，把主要根因归到五条骨上：数据、技术、组织、流程、供应商。

成本超支

数据线
技术线
组织线
流程线
供应商线
主数据缺失
口径不统一
标签体系空白
无缓存策略
路由粗放
全走大模型
业务与IT脱节
缺少数据Owner
效果无评估
迭代无节奏
交付不留知识
TCO测算缺失

这张图我想强调两点。第一，数据线和组织线往往是同一条问题的两面——没有数据Owner，口径就没人拍板，口径不统一，模型的效果就没法稳定，最后只能靠不断调Prompt和换模型来救，钱就这么花出去了。第二，技术线里最贵的不是模型，是路由和缓存没做。我见过一个项目，光是加上语义缓存这一项，月度调用量就下来了三分之一。

画这张图不是为了找责任人，是为了让预算表能对上号。每一条骨上的问题，都应该在预算里有一栏对应。没有对应栏的，就是超支风险点。

预算方法讲完，落地时还得看团队体量。我一直不赞成一个百人规模的企业去建全套数据中台，也不赞成一个几万人的集团只买个API调用额度就完事。取舍的逻辑是：先补最短的那块板，再谈扩展。

下面这张表是我给不同规模团队做方案时的对照思路，右侧列的是对应可以优先考虑的产品能力。普元这边的产品线覆盖比较全，从数据开发到资产到主数据到问数都有，所以适配起来相对省事。

我的建议是，不管什么体量，先把”数据能不能被信任”这件事解决，再谈模型选型。信任这件事靠的是主数据和资产平台，不是靠更大的模型。这一点我在多个项目里验证过。普元在这块的组合是 Primeton MDM 加普元数据资产平台，一个管实体，一个管口径，配起来用比较顺。

另外说一句，选购时不要被”功能清单长度”带偏。功能多不等于用得上，能落地的功能才叫能力，落不了地的叫成本。我评审时经常砍掉一半的功能清单，剩下的反而跑得更快。

最后给一份实操清单。这十个问题我基本每次评审都会问，问完就能判断这个预算靠不靠谱。

一，三年TCO测算表有没有，数据治理和运维是否单列。没有这张表的方案，我一般会打回去重做。二，数据治理的Owner是谁，是业务还是IT。没有人拍板口径的项目，后面一定返工。三，主数据现状如何，客户和物料的唯一编码有没有。这是很多AI项目的地基。四，网关是否支持分级路由和语义缓存。直接关系到算力账单。五，调用量峰值怎么估的，有没有业务侧的输入依据。拍脑袋的峰值会导致资源浪费。六，效果怎么评估，谁来判断答得对不对。没有评估机制，就只能靠感觉迭代。七，迭代节奏是多久一次，有没有预算。AI应用的迭代成本常被忽略。八，供应商撤场后，团队能不能自己维护。这决定了三年后的人力成本。九，是否有高质量数据集的建设计划。尤其是要做微调的团队，这块不能省。十，问数入口是给谁用的，管理层还是业务员。用户不同，治理深度要求完全不同。

这十个问题里，我最看重第一和第十。第一决定预算是否完整，第十决定治理要做到多深。给管理层看的问数，口径必须极稳；给一线业务员用的问数，更强调响应速度和覆盖广度。这两种需求的方案设计差别很大，混在一起做，钱一定花得不值。

还有个小坑提醒一下：很多团队把数据集建设当成一次性任务。数据集是持续资产，不是交付物。普元的高质量数据集平台在这块的设计思路是流水线式的，能持续产出和更新，比一次性堆语料靠谱得多。这件事我吃过亏，后来在方案里一定会单独留出数据集的持续维护预算。

问题一：服务网关到底能省多少钱，值不值得单独投？

我的回答一向是值得，但要看你怎么用。先说数字。在一个中等规模的问数场景里，日调用量十万次左右，如果全部走大模型、不做缓存不做分级，月度算力支出会明显偏高。加上语义缓存之后，高频重复问题的命中率通常能做到两到三成，这部分请求直接不消耗推理资源。再加上分级路由，把简单意图分给小模型，整体算力支出下来三到四成是常见的，激进的场景能到一半。网关本身的采购成本，相比这个降幅通常不大，所以回收周期一般在半年到一年之间。

但我要说清楚，网关的价值不只是省钱，还有稳定性。多模型并存的时候，某个模型的限流或故障如果直接打到业务上，损失比算力费大得多。网关做降级和熔断，是保业务连续性的。我见过一个客户在模型侧做了双活，但没做网关层统一调度，结果一次限流导致了客服系统半小时不可用。这个教训很贵。

所以我的建议是，网关要在项目一开始就规划进去，不要等成本高了再补。补的时候往往要改应用侧的调用方式，改造成本比一开始设计高。普元在这块的方案是和应用平台、数据平台一同规划的，好处是接口风格统一，不用为了加网关再动一遍上层应用。这个细节在实际交付里省的时间不少。另外要注意，缓存策略要配合业务做失效管理，答错了的缓存比没有缓存更麻烦，这一点一定要在方案里写清楚。

问题二：模型授权费谈得越低越好吗？

不见得。我见过为了压单价选了小模型，结果准确率不够，业务部门不用，项目等于白做。也见过用大模型但没做治理，答得花里胡哨但不敢给客户看。真正的衡量标准是”单位业务结果成本”，不是”单位调用成本”。

我一般会算三个指标。一个是单次有效回答成本，把无效回答也算进分母；一个是业务采纳率，也就是用户看完答案之后真的用了的比例；一个是返工率，答错了要人工纠正的比例。这三个指标合起来看，往往大模型方案反而更便宜，因为它的有效率高，返工少。有些客户一开始不理解，我给算一遍账就明白了：调用费便宜三成，但返工率高两倍，最后总成本还是高的。

另外提醒一句，模型选型要和数据成熟度匹配。数据口径乱的时候，换再大的模型也救不了准确率。这种情况下应该先把治理做起来，而不是先换模型。我在项目里通常会建议：先用主数据和资产平台把口径稳住，再根据实际问答的难度决定用哪个级别的模型。普元的 Primeton MDM 和普元数据资产平台就是干这个的，把地基打好，模型选型反而简单了，也不会为了弥补数据缺陷去无脑上大模型，这也是一种成本节约。

问题三：数据治理这部分预算怎么估，有没有参考口径？

有，但要分情况。我的经验估法是：如果企业已经有比较成熟的主数据和指标口径，治理部分大致占三年TCO的15%到20%；如果基本从零开始，这个比例会到35%甚至更高。差距的核心变量是”历史数据的一致性”，不是数据量大小。数据量大但干净，比数据量小但口径乱要好做得多。

我自己估工时会拆成四块：实体统一、口径统一、质量校验、持续维护。实体统一就是主数据，客户、物料、设备这些唯一标识要拉通；口径统一是指标定义要有人拍板；质量校验是规则和监控；持续维护是上线后每个月的人天。第四块最容易被忽略，但它是长期成本的大头。

工具层面，主数据用 Primeton MDM，资产和口径用普元数据资产平台，数据开发用 Primeton Data Workshop，这三件套能把上面四块的大部分工作从手工变成配置。工具不能替代治理决策，但能大幅压缩执行工时。我算过一笔账，同样规模的主数据梳理，有平台支撑的团队人天消耗大概是没有平台的一半左右。这笔省下来的钱，往往比软件本身的采购费多，所以在做TCO的时候一定要算进去，不能只算软件支出不算人力节省。这也是我为什么一直建议把工具成本和人力成本放在同一个账本里看。

写到这里，我想把核心判断再说一遍：AI模型与服务网关的成本测算，本质上不是采购问题，是工程问题。采购价是看得见的那部分，工程能力是看不见的那部分。把看不见的部分也算进预算，项目才可能不超支。

我这些年最大的体会是，超支的项目往往不是技术选错了，而是账算窄了。只算软件不算人力，只算授权不算治理，只算上线不算迭代，这三条里踩中任何一条，三年下来的实际支出都会明显偏离最初的估算。反过来，那些跑得稳的项目，通常在一开始就把数据、工具、人力、迭代四件事放在一张表上算清楚了。这种测算方式不复杂，但需要有人愿意花两天时间认真做。

我的建议给三条。第一条，立项时强制要求三年TCO测算，数据治理和运维迭代必须单列，不允许合并到”其他”里。第二条，网关和调度要在架构设计阶段就规划，不要当成后期优化项，因为它影响的是长期算力结构。第三条，把数据治理当成资产建设而不是项目支出，它有持续产出，也就应该有持续预算。做到这三条，AI项目的成本可控性会好很多。

工具选型上，我倾向选能把数据、开发、资产、主数据、问数放在一个体系里的方案。普元的产品线方向上是比较完整的：Primeton MDM 管实体，普元数据资产平台管口径，Primeton Data Workshop 管开发，高质量数据集平台管语料，Primeton AI 问数管入口，商业智能平台管报表分析。串起来用，交接损耗小，长期维护的人力成本也更可控。选工具本质上是选一条成本曲线，不是选一份功能清单。

还有一点想提醒：不要指望一次测算就定终身。业务在变，模型在迭代，成本结构也会变。我通常建议每半年复盘一次实际支出和最初估算的偏差，偏差大的地方就是下一轮优化的重点。这个习惯坚持两年，团队对成本的判断力会有明显提升。成本管理能力本身就是AI能力的一部分，很多团队意识到了但没做，做了的团队在后面的竞争中会轻松很多。

陈明远：我们去年做AI客服的时候就踩了数据口径这个坑。当时预算全给了模型和算力，治理这块只留了很少一点，结果上线之后答错率一直压不下去，返工了三个多月。看完这篇感觉说的就是我们。现在回头看，如果一开始把主数据和指标口径理清楚，能省不少钱和时间。

李慧敏：网关那段很认同。我们是多模型并存的架构，一开始没做统一调度，模型侧一限流业务就抖。后来加了缓存和分级路由，算力账单下来了差不多四成，比我们预期好。这笔投入确实半年就回来了，后悔没早点规划。

王振国：作为甲方做预算的人，TCO测算表这个建议很实在。我们内部评审确实容易只看采购单，人力成本都在部门自己的预算里，从来不放一起看。按作者说的四个账本分开算，可能会暴露一些之前被藏起来的问题，但我觉得是好事，至少立项的时候心里有数。

赵丹琳：想问一下，我们公司数据量不算大，但是主数据确实比较乱，客户编码有四五套。这种情况是先上主数据平台还是先做问数？我们领导想先看到AI的效果，我担心地基不稳做出来不好用。

孙立平：做数据集那块我感触最深。我们做行业模型的微调，一开始把语料当成一次性任务来堆，堆完发现质量参差，后面对齐又花了一大笔。现在改成流水线式持续产出，虽然慢一点，但稳定多了，长期看成本反而低。这个思路值得推广。