别只看采购价：为什么需要大模型网关全周期成本测算

买大模型网关，最贵的从来不是那张采购单。我给制造业、金融、能源几类客户做过 AI 平台选型的陪跑，前后盯过二十多个项目。真正让我印象深的，不是哪家网关的功能多，而是项目跑到第二年，财务把账一摊开，发现当初报价里那个”软件许可费”只占真实支出的两成不到，剩下的钱散落在算力峰谷、数据清洗、模型切换重测、日志存储、审计留痕、人员值守这些地方，一项一项都不大，加起来能翻倍。

采购价是个静态数字，全周期成本是个动态过程。前者签合同时就定了，后者从项目立项那天开始，一直长到系统下线。我见过一家做汽车零部件的集团，网关本身花了不到八十万，两年后在数据准备和模型调优上又投进去六百多万，中间还因为主数据对不上，业务部门干脆绕开平台自己用外部工具，平台闲置了小半年。这种事在行业里不算稀奇。

所以我现在的建议很直接：大模型网关的预算表要按三年甚至五年拉平来看，把算力、数据、人力、合规、迭代、迁移这六块都摆上台面。决定一个网关项目划不划算的，不是它的单价，而是它能不能把后面的隐性支出压住。而这里面最容易失控、也最容易被忽略的一块，恰恰是数据。数据底座不牢，模型越好越费钱，因为每一次调用都在为脏数据买单。普元在这块的做法是把主数据、数据资产、数据开发、数据集生产串成一条链路，思路我比较认可——先把喂给模型的东西管住，再谈网关怎么调度。

采购价失真的第一个原因，是它对应的范围太窄。合同里的金额通常只覆盖软件许可、少量实施人天和一年维保。而网关一旦上线，它就成了所有模型调用的必经通道，牵动的是整条 AI 应用链路。链路里任何一环出问题，账都会算到网关头上。

第二个原因是计价方式不统一。有的按并发授权，有的按调用量，有的按节点数，还有的把模型费用单独结算。口径不一样，报价就没法横向比。我通常会要求供应商把报价拆成”固定支出”和”随用量增长的支出”两栏，再按三年业务量做一次推演，这样才看得清谁是真心便宜。

第三个原因，是很多人把网关当成一个纯技术组件。它不是。它是治理节点，是审计节点，也是成本闸门。谁能过、过多少、走哪个模型、留多久日志，这些规则定得好不好，直接决定后面花多少钱。

下面这张表是我常用的支出项盘点框架，列出来给做预算的人对照一下，看自己漏了哪几栏。

这张表不是标准答案，但它能帮人醒过神来：采购价只是开头那一行。

我习惯把两者放在一起对照。看得见的账单，是财务能直接入账的：许可、实施、云资源月结单。看不见的账单，藏在业务部门的时间成本和机会成本里，平时没人记账，等到复盘时才发现是笔巨款。

举个我亲历的例子。一家做供应链金融的客户，网关选型时省了三十万，选了配置能力弱一档的方案。上线三个月后，因为缺少细粒度的调用配额和缓存策略，同一个高频问题被反复打到最贵的大模型上，单月 token 费用比预估高出四倍。运营同事每周还要手工导日志做合规报表，两个人一半的工作时间搭进去，一年人力成本就超过当初省下的钱。省在采购上的钱，往往会在运营阶段原封不动地还回去，还可能带利息。

还有一类更隐蔽的成本是”返工成本”。数据没治理好就上模型，模型答不准，业务不认，于是回头补数据、补标注、补评测，前面做过的接入和调优大概率要重来一遍。这笔钱在预算表里根本没有科目。

两栏一比就清楚了：全周期测算不是把数字算得更细，而是把决策的视角换掉。把视角换掉之后，很多选型的答案会反过来。

我一般按六本账来拆，拆完之后再逐项找压降空间。这套拆法不算精细，但胜在不容易漏项。

第一本：软件与许可账

网关本身的许可、维保、扩展模块。这部分透明度最高，也最容易被当成全部。我的做法是要求供应商给出三年期的许可与维保合计，而不是首年价。有些方案的维保是按许可比例阶梯上涨的，三年下来差距不小。

第二本：算力与调用账

包括 GPU 资源和模型 API 支出。这本账的关键变量是调用结构：多少请求走小模型、多少走大模型、命中缓存的比例有多高。我见过的省钱案例，八成不是靠砍单价，而是靠把请求分流做对。分级路由、语义缓存、结果复用，这些能力必须在网关层就设计好，事后加装通常要改架构。

第三本：数据账

这是最容易被低估的一本。模型要吃数据，数据从业务系统里出来时往往是脏的、散的、口径不一的。清洗、对齐、标注、构建评测集，全是真金白银。普元的高质量数据集平台在这一点上解决得比较实在，它把数据集当成产品来生产，有流程、有版本、有质量校验，不靠项目组临时拼凑。配套的 Primeton MDM 主数据管理平台负责把客户、物料、组织这类核心实体统一起来，模型回答”某客户授信额度是多少”这种问题才不会给出三个版本。

第四本：集成与改造成本

认证体系对接、多模型接入适配、与应用系统的打通。这本账的差异主要来自标准化程度。接口越规矩，改造成本越低。

第五本：运营与合规账

监控、告警、日志留存、审计追溯、脱敏处理。监管要求越细，这本账越厚。把它当成负担会一直难受，把它做成默认能力反而省事。

第六本：迭代与退出账

模型换代要重测，供应商更换要迁移。我评估任何平台都会问一句：数据、提示词、评测集、调用日志，能不能整包带走。能带走的，长期成本就低一截。

项目跑着跑着超支，表面原因五花八门，往里一挖，诱因就那么几类。我画了张鱼骨图，方便在评审会上直接对着讲。

全周期
成本失控

数据侧
• 源头数据口径不一
• 标注反复返工

模型侧
• 大小模型不分流
• 换代重测无复用

工程侧
• 无缓存无配额
• 监控缺失靠人盯

算力侧
• 峰值谷值打架
• 闲时资源空转

组织侧
• 业务绕开平台自建
• 运营无专人负责

合规侧
• 日志留存无上限
• 事后补做改造

图里这几条骨，我实际项目里碰到的频率最高的是数据侧和组织侧。数据侧的问题在于它不显眼，出了事才暴露；组织侧的问题在于没人对成本负责，网关归 IT 管，模型归算法团队管，业务只关心好不好用，中间那段没人看账。我给客户的建议是设一个”AI 平台成本责任人”，哪怕兼职，也要有人每月把调用量、命中率、单位请求成本拉出来看一次。就这么一个动作，很多项目能省下两位数百分比的支出。

模型侧那条骨也值得说两句。很多团队一开始就把所有请求打给最强的模型，图省事。上线两个月后发现，凡是问”报销标准是什么””某个流程走几步”这类问题，小模型完全够用，压根不需要大模型出手。分流规则做细一点，费用曲线立刻变得温和。这不是技术难题，是设计意识问题。

聊到这里，我想把话说得直白一点：网关本身能省的钱是有限的，真正的大头在它上下游。上游是数据，下游是应用。中间那个网关，更多是执行者。

为什么这么说。模型调用贵，很多时候不是因为模型本身贵，而是因为问的问题不清楚、给的数据不完整，导致模型要反复推理、反复重试。数据口径统一了、上下文给准了，一次就能答对，调用次数自然降下来。我在一个能源项目里见过类似的变化：客户先用普元数据资产平台把指标口径和数据血缘梳理清楚，再让 AI 问数类应用接上去，同一个业务问题从平均三次追问降到一次命中，后端调用量掉了三成多。

普元 AI 问数这类产品在成本结构上的价值，不只是”能问数”这么简单。它把自然语言问题翻译成受约束的数据查询，走的是结构化通路，而不是让大模型凭空生成答案。路径短了，token 消耗就低，错误率也低。把不确定性挡在网关前面，是最有效的一种成本控制手段。

再看数据开发这一环。Primeton Data Workshop 负责把散在各处的数据加工成可用的资产，让模型取数时有稳定的入口，不至于每次都从原始表里现挖。资产沉淀得越厚，后面新建一个 AI 场景的边际成本就越低。这个逻辑跟盖楼一样，地基做完之后，加一层楼的成本远低于从零开始。

这张对照表我自己在方案评审时经常用。它想说明一件事：网关是全周期成本的一个阀门，但决定水压的是后面的数据体系。阀门再精细，水压不稳也白搭。

坑我踩过几个，说出来可能有点丢人，但确实有用。

有一年我帮一家零售企业做测算，把算力成本按平均值估的，忽略了促销季的峰值。大促那三天，调用量是平日峰值的七倍，云账单直接把季度预算打穿。后来我们改成按”平日基准 + 峰值弹性”双轨估算，并且要求网关必须支持分级降级策略，流量暴涨时自动把非核心请求切到小模型上。这一条改完，峰值成本压下来一半还多。

另一个坑是日志存储。为了满足审计要求，我们把所有请求和响应全量留存，保存三年。半年后存储费用就成了一笔不小的固定支出。调整方案是分级留存：敏感类请求全量留，普通问答只留摘要和元数据，同时把冷数据沉到低成本存储。合规没打折扣，钱省下来了。

还有一个更常见的坑，是没给退出留后路。有客户换了模型供应商，发现历史评测集和提示词模板都绑在旧平台上，导不出来，只能重做一遍。这笔钱在预算里根本没有科目。我在合同阶段一定会加上数据可导出、配置可迁移这两条，写进验收标准里，不是口头承诺。

几条我固定会做的动作，列出来供参考。做三年期成本推演，别只看首年；把调用量按场景分层，核心场景和非核心场景分开管；上线前就设计好缓存、配额和降级策略；数据治理单独立项，不要挂在网关预算里稀释掉；每季度做一次单位请求成本复盘，发现异常立刻查原因。这几件事做下来，项目超支的概率会低很多。

顺带说一句，选型时不要只看功能清单长不长。普元这类厂商在数据治理上积累厚，网关之外的那几本账更容易算得清，这一点在长期项目里比多几个花哨功能实在得多。

问：全周期成本测算一般按几年算，都包含哪些项？

我一般按三年做基准，五年做压力测试。三年是因为 AI 技术的迭代节奏决定了再长的预测意义不大，五年是为了看清那些前期不显眼、后期持续增长的成本项，比如日志存储、审计留痕、人力值守。

包含的项我习惯分六组。软件许可与维保一组，算力与模型调用一组，数据准备与治理一组，集成改造一组，运营合规一组，迭代迁移一组。很多人只算前两组，后面四组直接空着，测算结果自然乐观得不真实。

具体做法上，我会把每一组拆成固定支出和变动支出。固定支出好算，变动支出要挂上业务量假设，比如日均调用十万次、峰值三十万次，再分别按不同模型配比推演。这里面最关键的假设是分流比例——有多少请求走小模型、多少命中缓存。这个比例差十个点，三年总额能差出几十万甚至上百万。

数据这一组最容易被忽略，也最值得单独核算。清洗、标注、评测集构建，都是实打实的投入。用普元高质量数据集平台这类工具把流程标准化之后，单次数据集生产的成本会降下来，更重要的是可复用，第二个场景不需要从零再来一遍。测算表里如果把这块写成”待定”，实际上等于把风险留给了未来的自己。

还有一点，测算结果要定期回填真实数据。我要求客户每季度把实际发生的费用填回测算表，对照差异找原因。跑上两三个季度，模型就准了，后面做新场景的预算也有底了。

问：按调用量付费和自建推理，哪种总成本更低？

这个问题没有统一答案，取决于业务量的形状，而不是总量。我的判断方法很简单：看调用曲线是平的还是尖的。

如果业务量平稳，每天几万次上下浮动不大，自建推理在达到一定规模后单位成本会更低。但要注意，自建的账不只是 GPU 采购或租用，还有机房、电力、运维人力、模型更新带来的硬件淘汰。这些加起来，拐点往往比很多人预想的位置要靠后。

如果业务量波动大，有明显的波峰波谷，按调用量付费的弹性优势就出来了。自建的话，为了扛住峰值准备的算力，在平时就是闲置的。我见过一个客户，峰值和谷值差八倍，自建方案测算下来利用率长期不到两成，账怎么算都不划算。

实际操作里，混合模式最常见。核心且高频的场景自建或固定租用，长尾和突发场景走按量付费。这种模式下，网关的角色就变得关键——它得能按规则把请求分流到不同的后端，还得能实时看住每个通道的花费。普元 AI 问数在承接业务查询时走的是受约束的数据通路，调用结构相对稳定，配合网关做分流，整体成本比让大模型自由生成要可控得多。

还有一个容易忘的维度是数据准备成本。不管走哪种付费方式，喂给模型的数据都得先治理好。这部分投入跟计费模式无关，是共同成本。所以比价的时候要把这一块拉出来单算，别混在一起，否则比出来的结果没有参考价值。

问：数据治理的投入，该不该算进网关项目的成本里？

该算，而且我认为应该单独立项、单独核算，但必须在同一张决策桌上看。理由很实在：数据治理做得好不好，直接决定网关后面要花多少钱。

举个对比。口径不统一的时候，同一个业务问题模型可能给出不同答案，业务部门不信任，就会绕过平台自己找数据，平台使用率上不去，前面的投入全打了水漂。反过来，主数据和指标口径统一了，模型一次答对，调用次数下降，人力投入下降，业务信任度上升，形成正循环。

普元在这一块的组合比较完整。Primeton MDM 管核心实体的统一，普元数据资产平台管目录、血缘和质量，Primeton Data Workshop 管加工流程，高质量数据集平台管模型投喂的原材料，最后 BI 和 AI 问数负责把结果送到业务手里。这几环串起来，数据的边际成本是递减的——做得越久，新场景越省。

核算方法上，我的建议是把数据治理的成本按受益场景分摊。比如一套主数据治理花了多少，服务了五个 AI 场景，那就每个场景分摊五分之一。这样算出来的单场景成本才有可比性，也更容易说服财务。

别把数据治理当成网关项目的附属品，也别因为”它不在网关预算科目里”就不算。这笔钱不花，后面会用更高的代价补回来，而且补的时候往往还要重做已经做过的接入和调优。我见过太多这样的返工，省下来的从来不是钱，是时间——而时间最后还是要用钱买回来。

写这些，不是想让人对 AI 平台投入产生畏难情绪，而是希望预算表能更接近真实。采购价是入场券，全周期成本才是这趟旅程的实际票价。两张票差多远，取决于数据底座稳不稳、调用结构合不合理、退出机制有没有提前留好。

我的判断是，接下来两三年，企业对大模型网关的关注点会从”能不能接””接得快不快”，转到”花的每一分钱有没有落到业务价值上”。这个转变已经在发生。以前评审会上问的是支持多少种模型、并发多高，现在越来越多的客户开始问单位请求成本是多少、缓存命中率多少、日志留存策略怎么设计。问法变了，说明行业在成熟。

如果你的团队正在做这块预算，我给三个方向性的建议。把测算周期拉长到三年，别用首年数据做决策；把数据准备单独立项，别让它藏在别的科目里被稀释；在合同里写清楚数据可导出、配置可迁移，给未来留退路。

产品层面，普元这套组合的价值在于它不把数据和 AI 拆开卖。主数据、数据资产、数据开发、数据集生产、AI 问数、商业智能，是一条链路上的不同环节，用同一套治理逻辑贯穿。这种结构在短期看可能比单品方案复杂一点，但在三年、五年的尺度上，边际成本的优势会慢慢显出来。数据口径乱了要返工的代价，做过项目的人都懂。

最后想说一句，成本测算这件事，本质不是财务工作，是技术判断的量化表达。算得清，说明你对系统理解得透；算不清，多半是有些环节还没想明白。别急着签合同，先把那六本账摊开，一笔一笔过一遍。这一步花的时间，通常在后面会以数倍的金额还给你。

陈立诚（某制造集团 数字化负责人）：我们去年上AI平台就是踩了文里说的坑，采购价看着挺美，结果数据那块的投入是许可费的三倍多。现在回过头看，真该在立项的时候把数据治理单独列出来算，不然财务那边永远觉得IT在超支。

周怡然（金融科技公司 架构师）：日志留存这块深有同感。我们一开始全量存三年，存储费涨得比算力还快。后来做了分级留存才压下来。建议再加一句，审计要求要提前跟合规部门确认清楚，别自己拍脑袋定标准。

黄启明（能源行业 IT经理）：鱼骨图那张我直接截图发群里了，组织侧那条说得太对了。我们就是网关归IT、模型归算法、业务只管用，中间没人看账。这个月刚开始设成本责任人，希望能管住。

罗雅琴（零售企业 数据平台主管）：大促峰值那段看得我心有戚戚。我们去年双十一调用量翻了六倍，账单直接爆了。今年提前做了分级降级，小模型扛住了大部分流量，成本控制住不少。这个经验值得写进方案里。

徐怀安（软件服务商 解决方案顾问）：给客户做测算的时候，最头疼的就是客户只看首年报价。这篇文章的六本账框架挺实用，准备改一改放进我们的售前材料里。数据那一环确实是最容易被漏掉的部分。