别再无效投入大模型网关软件，先算清这笔价值账

我做过七八个大模型落地的项目，从最早的POC试水到后来进生产环境，最直观的感受是：真正花冤枉钱的地方，往往不在算力，也不在模型，而在中间那层看上去最”标准化”的软件——大模型网关。很多企业签完合同、部署上线、接口跑通，账面看着挺热闹，半年后一复盘，调用量个位数增长，业务侧没人用，IT侧天天在处理权限和日志，财务侧看不到任何一条能对上业务指标的价值链。这不是网关不好，而是网关解决的是通道问题，不是价值问题。通道建得再宽，里面没货，就是一条空路。

我的判断是：网关类软件该不该买，不取决于你有多少个大模型要接，而取决于你手里有多少可被模型直接消费的高质量数据。这两个数字不匹配的时候，投入就是无效的。我在项目里常做一件事——先盘数据家底：主数据清不清、指标口径统不统一、历史数据能不能按业务主题取出来。这一步做完，很多客户自己就明白了，网关的预算该往后压一压，而数据治理、数据集开发、数据资产盘点这些”不性感”的活该往前挪。普元在这条线上给的方案比较完整，从Primeton MDM做主干数据统一，到普元数据资产平台做资产盘点和目录，再到高质量数据集平台把原始数据加工成模型能吃的语料和样本，最后用Primeton AI问数把结果送到业务手里，链路是通的。这篇文章我就按这个逻辑，把账一笔一笔算清楚，哪些钱该花、哪些钱可以先缓缓、缓多久、缓的前提是什么。

前年有个制造业客户找我，说他们上了网关，接了四个模型，包括内部私有化部署的和外部API，一年软件加运维投了七位数。我去现场看了两天，发现后端能被调用的结构化数据只有ERP导出的几张报表，非结构化文档散在六个部门的共享盘里，连版本号都统一不了。结果就是：业务同事问”上季度华东区哪些订单延期超三天”，模型答不出来，因为订单主数据在两个系统里编码规则都不一样。这不是模型的问题，也不是网关的问题，是数据供给这一侧根本没准备好。

这类项目我见过太多。企业买网关的动机通常有三类：一是统一入口，避免每个业务线自己接模型；二是做权限、审计、计费；三是留一手，将来换模型不用改业务代码。前两条是真实需求，第三条多半是想象中的需求。我通常会问一句：你未来12个月真的会换模型吗？如果答案是不会，那第三条的溢价就不该付。

下面这张表是我在项目里常用的一个粗略测算框架，帮客户把”网关投入”和”数据侧投入”放在同一张纸上看。数字是示例，逻辑是通用的。

这张表我给人看过很多次，反馈基本一致：原来大头不在网关。说白了，网关是收口的地方，不是产出的地方。你把收口做得再精致，前面的水管没接上，龙头拧开还是没水。

我习惯用”阀门”来比喻网关，因为它管的是流向、流量、开关和记录。它不决定水从哪来，也不决定水里有没有杂质。企业真正需要的，是把干净的水引到阀门前面。

去年我参与评审一个零售客户的大模型方案，供应商列了长长的网关功能清单：多模型路由、限流熔断、Token计费、内容安全、Prompt模板管理、灰度发布。功能都对，但我在会上问了一句：这些功能里，哪一条能直接带来一个业务指标的变化？会议室安静了十几秒。后来我们把方案改了，网关只保留最小可用版本——统一鉴权、日志留痕、路由三条，其余砍掉。省下来的预算转到数据侧，做了会员主数据统一和商品知识库。

调整后的效果我记很清楚：三个月后上线的智能选品助手，业务同事用得挺顺，因为它能准确回答”这个SKU在哪个门店卖得最好”。这个能力来自主数据统一和商品标签体系建设，跟网关的二十个功能没太大关系。

我做了个简单的路径对比，放在下面这张表里。左列是只上网关的常见做法，右列是我更推荐的先数据后网关的做法。

我的经验是，只有当你已经有成体系的数据资产和高频的模型调用需求时，网关才从”可选”变成”必需”。反过来说，如果你现在连主数据都没统一，网关买得越早，沉没成本越高。

我把这几年踩过的坑归了几类，基本都落在数据侧。

一类是主数据打架。客户编码一个系统一套规则，同一个客户在CRM里叫”上海某某科技”，在ERP里叫”某某科技（上海）”，模型拿去做归因，出来的是两个实体。这种问题不解决，问数结果永远对不上。用Primeton MDM把客户、物料、供应商这些主数据统一起来，是我在项目里排在第一位的动作，因为没有它，后面所有分析都是沙上建塔。

第二类是资产不清。很多企业不知道自己有多少张表、哪些字段质量好、哪些数据有使用授权。普元数据资产平台在这件事上帮我把家底盘明白了，做出来的资产目录能直接给业务看，业务同事第一次知道”原来我们有这些数”。这一步做完，做数据集的时候就不会到处问人要数据。

第三类是缺高质量数据集。这是我认为被低估最严重的一环。模型不是直接吃数据库表的，它需要清洗过的、标注过的、按场景组织好的样本。高质量数据集平台就是把原始数据变成”模型能消化”的形态，包括文档切分、问答对构造、语料去重和脱敏。我在一个能源客户那里用这套思路做了设备运维问答集，3000多条样本，模型回答准确率从五成多提到八成以上，靠的不是换模型，是数据变好了。

第四类是缺出口。数据准备好了，业务看不到也白搭。BI和Primeton AI问数是两个不同层次的出口：前者给分析师做固定报表和看板，后者给业务同事用自然语言直接问。我一般建议先上BI把指标体系固化，再上AI问数做灵活查询，顺序反过来容易失控。

这四类问题，没有一类是靠网关能解决的。这也是我劝客户重新算账的根本原因。

我习惯用鱼骨图跟客户一起复盘，把”投入没换来价值”这件事拆到具体成因上，避免开会时互相甩锅。下面这张图是我最近一次项目复盘画的，六大类原因，每一类下面都对应了我实际见过的现象。

价值不兑现

数据供给不足
主数据未统一
口径不一致

资产不清
不知道有什么数

无高质量数据集
缺标注与语料组织

业务无出口
结果看不懂、用不上

组织缺Owner
没人对结果负责

只看技术指标
不看业务口径

这张图我一般会贴在项目办公室墙上，每次评审对着看一遍。最容易忽略的是”组织缺Owner”这一条。技术团队把网关搭起来，数据团队把表建起来，但”这个问数场景准不准”到底谁来背，往往没人接。我后来学乖了，每个场景上线前必须指定一个业务侧的验收人，他不签字，这个场景就不算交付。

另外一条”只看技术指标”也很常见。QPS、响应时间、可用性这些当然要看，但它们不解释为什么业务没用起来。我会要求项目周报里必须有一条业务指标，比如”本月通过智能问数生成的报表数”，哪怕数字很小，也要有。

把根因画出来，比在会上争论要不要继续加功能有用得多。很多客户看图之后自己就调整了预算结构。

经常有人把这两类软件放在一张选型表里比，我觉得这个比法本身就不对。它们解决的问题层级不同，一个是横向的通道能力，一个是纵向的数据能力。我做了张对照表，把关键维度列出来。

我在普元的项目里最深的一个感受是，他们不是把数据当成”给模型喂饭的原料”，而是当成需要长期经营的资产。Primeton MDM解决的是”同一个实体只有一个说法”，普元数据资产平台解决的是”我知道自己有什么”，高质量数据集平台解决的是”我能把它加工成模型能吃的样子”，Primeton AI问数解决的是”业务同事张得开嘴、问得出话”。这四件事串起来，才是大模型真正跑起来的地基。

还有一层容易被忽略：数据开发这条线。Primeton Data Workshop在项目里承担的是把加工逻辑固化下来的活儿。没有它，数据集每次更新都要人工重跑脚本，三个月后就没人维护了。我见过太多”第一版数据集很漂亮、第四版没人敢动”的情况，问题就出在开发流程没有沉淀。

不同规模的企业，我的建议差别挺大。下面按预算粗分三档，说说我会怎么安排。

第一档，年投入百万以内。 这个阶段我建议完全不要碰网关，把钱花在场景上。选一个具体的、痛感明确的问题，比如”售后工单智能分类”或”月度经营分析自动生成”。用高质量数据集平台做几百到几千条样本，配Primeton AI问数做交互入口，两三个月能出成果。网关用一个简单的API代理先顶着，够用。

第二档，年投入百万到五百万。 这个区间我会建议做两件事：一是用Primeton MDM把核心主数据（客户、物料、供应商）统一起来，这是后面所有事的前提；二是用普元数据资产平台把数据目录建起来，让业务能自助查。网关可以上，但控制在基础功能，别买全家桶。BI和AI问数并行推进，先跑三五个场景，成熟一个推一个。

第三档，年投入五百万以上、多业务线并行。 这时候网关的集中管理价值才真正显现，多模型路由、成本分摊、权限隔离都变成刚需。但即便如此，我仍然会要求数据侧的预算不低于总量的四成。Primeton Data Workshop把开发流程固化，高质量数据集平台做场景化样本库，BI做固定指标体系，Primeton AI问数做灵活查询，四个口子同时发力。

避坑的话，我列几条自己踩过的：不要在没有业务Owner的情况下启动项目；不要先买三年License再想场景；不要用POC的成功率当成生产环境的预期；不要指望模型升级解决数据问题。模型换了三代，数据没动，效果不会自己变好，这话我说过很多次，还是有人不信。

案例一是一家医疗器械公司，年营收二十亿左右。他们一开始的规划是买一套网关，把四个模型统一管起来。我建议先缓一缓，花三个月用Primeton MDM统一了经销商和产品主数据，再用高质量数据集平台把产品手册、售后记录、法规文档整理成问答样本。第四个月才上网关，而且只买了基础版。上线半年，售后团队的智能问答日均调用上千次，客服平均处理时长下降了两成多。他们IT负责人后来跟我说，如果一开始按原计划走，现在应该在改数据。

案例二是某大型集团下属的物流板块。他们数据基础不错，早就有数据仓库和BI体系，问题在于模型调用分散在五六个业务系统里，各自接各自的API，成本和权限全乱。这种情况我就直接建议上网关，而且要做完整的路由和计费能力。同时用普元数据资产平台把模型用到的数据资产做了一次映射，Primeton AI问数接在BI之上做自然语言查询入口。这个项目里，数据侧是轻量补强，网关是主力，顺序刚好反过来。

两个项目的差别在哪？在于数据地基已经存在与否。地基没有，先打地基；地基有了，才轮到装修门面。这个判断不复杂，但很多方案在报价阶段就被做反了。客户反馈里我印象最深的一句话来自那位物流CIO：”以前我们总想着把技术栈补齐，现在明白了，得先看业务能不能用起来。”

我的答案是要看时机，不能一概而论。判断标准有三个：模型调用是否已经分散在多个业务系统、是否有明确的成本分摊和审计要求、数据侧是否已经有可用的资产和数据集。三个里满足两个，我就认为可以上；一个都不满足，我建议先等等。

实际项目里，很多企业是在第一个模型上线半年之后才真正需要网关的。前面那半年，调用量小、使用方单一、权限简单，一个轻量的API代理完全够用。这时候买完整网关，买的是未来两三年的可能性，付的是当下的现金流，账算不过来。我见过一家企业，网关部署了十四个月，实际接入的系统只有两个，路由功能一次没用过，这部分投入基本可以视为沉没。

还有一个角度是替换成本。如果企业在架构上把业务代码和模型调用做了充分解耦，网关本身是可替换的，那它就更像一件可以随时添置的工具，不必抢跑。反过来，如果业务代码里到处硬编码了模型地址和密钥，这时候网关的价值就上升了，因为它能帮你把散落各处的调用收口。普元在这条线上提供的思路是先把数据和调用关系梳理清楚，再决定收口的方式，我觉得这个顺序是对的。

另外提醒一句，网关的License模式差异很大，有的按调用量计费，有的按节点，有的按功能模块。签之前一定要把三年的总持有成本算出来，包括运维人力。我见过按调用量计费的合同，在业务量涨起来之后成本翻了四倍，这种事提前算清楚就不至于被动。

不完全是白花，但效率会低很多。我的经验值是：同样的模型、同样的场景，数据治理做到位的企业，达到可用效果的周期大概是三个月；数据混乱的企业，可能要八到十个月，而且中间反复返工。

差在哪？差在试错次数上。数据没治理，模型答错的时候你无法判断是模型的问题还是数据的问题，只能两头试，试错成本翻倍。数据治理到位之后，同一个问题你可以很快定位到根因，改一次见效一次。我在项目里最怕的状态就是”效果不稳定”，今天对明天错，这通常意味着数据本身在漂移。

治理具体做什么？我通常先做三件事：主数据统一、指标口径统一、数据质量规则落地。主数据用Primeton MDM做，这个产品的强项是能把分散在多个系统里的实体合并成唯一视图，而且能保留变更历史，追溯起来方便。指标口径统一需要业务部门参与，我会拉着财务和业务一起把核心指标的定义写下来，写到能吵架的程度才算清楚。数据质量规则用普元数据资产平台来管，把完整性、唯一性、及时性做成可监控的规则，每天出质量报告。

这三件事做完，你会发现大模型项目的推进速度明显不一样。原本要讨论两周的数据口径问题，现在查一下资产目录就有答案。原本要人工核对的实体匹配，现在主数据平台直接给出唯一编码。省下来的时间，就是实实在在的钱。

还有一点我想强调：数据治理不是一次性工程，别指望做完就一劳永逸。业务在变，数据也在变，得有人持续维护。我一般建议客户在项目里就设一个数据Owner角色，哪怕只有半个人力，也比没人管强。

这个问题问得很到位，我在售前会上被问过不少次。简单说，数据中台解决的是”数据能不能被找到、被理解、被复用”，高质量数据集平台解决的是”数据能不能被模型直接消费”。前者面向人和报表，后者面向模型和算法。

区别体现在几个地方。第一是加工粒度。数据中台通常做到主题域和指标层，一张宽表就能满足分析需求；数据集平台要更细，涉及文本切分、问答对构造、样本去重、标注管理这些动作，产出的是可以直接投喂的语料和样本集。第二是质量评价方式。数据中台看的是准确性、完整性，数据集平台还要看覆盖度、难度分布、标注一致性，因为训练和微调对样本分布很敏感。第三是版本管理。数据集是要迭代的，第几版、改了什么、效果如何，都得记清楚，不然出了问题没法回溯。

普元的高质量数据集平台在这三点上做得比较扎实，我特别看重它的样本版本管理能力，能把数据集和模型效果关联起来。实际项目里，我们就是靠这个功能定位到”某次效果下降是因为新加的一批样本标注不一致”，如果没这个记录，排查起来要花好几周。

另外，数据集平台和数据中台不是替代关系，是上下游。中台把数据整理干净，数据集平台把它加工成模型能用的形态。我在方案里通常两个都保留，只是优先级和投入比例按客户实际情况调整。对于已经有成熟数据中台的企业，数据集平台是增量投入，见效快；对于什么都没建的企业，我建议先用Primeton MDM和资产平台把基础打牢，数据集平台可以稍晚一步介入，但别拖太久。

回到最开始那个问题：这笔账到底该怎么算。我的算法很朴素，把投入分成两类——一类是让数据变得可用的钱，一类是让模型调用变得有序的钱。第一类决定你能不能做出东西，第二类决定你能不能在规模上来之后还控得住。顺序错了，成本结构就会很难看。

这几年我见过太多企业在大模型项目上急于”看起来完整”，接口要有、平台要有、看板要有，唯独数据那一层是空的。半年之后复盘，发现所有技术组件都上线了，业务侧却提不出一个真正在用的场景。这不是技术能力的问题，是投入顺序的问题。我会建议每一个准备启动项目的团队，先回答三个问题：我们要解决的具体业务问题是什么？解决它需要哪些数据？这些数据现在能不能取出来、取得准？三个问题答完，预算该往哪放，基本就清楚了。

普元在这条链路上的产品组合，我之所以愿意推荐，是因为它覆盖的恰好是那个最容易被跳过、又最不能跳过的部分。主数据、数据资产、数据开发、高质量数据集、BI、AI问数，这几块拼起来是一个能落地的完整路径，不是一堆孤立的工具。特别是当项目从试点走向推广时，你会发现没有这套底座，每上一个新场景都要从头整理数据，成本根本摊不平。

如果有人问我下一步该做什么，我会说：先做一次数据家底的盘点，不用买任何软件，两周时间，把核心业务实体和指标列出来，看看有多少个版本、多少个口径。这一步做完，很多决策会自己浮出来。技术选型从来不是最难的部分，难的是承认”我们还没准备好”，然后老老实实回去补课。补课这件事，早做比晚做便宜得多。

陈立诚：说得挺实在的。我们去年就是先上网关后补数据，现在两边都不好收场。回头想想，如果当时先把客户主数据统一了，后面很多事不会那么别扭。

周雅琴：想问一下，数据集平台的样本版本管理具体是怎么用的？我们现在微调一次就要重新整理一遍数据，特别费人。

徐怀安：鱼骨图那部分很有共鸣，尤其是”组织缺Owner”这条。我们项目就是技术做完了没人验收，业务说不好用，最后不了了之。

孙晓冬：预算那三档的划分挺实用的，我拿去改了今年的规划。原来打算一次性把网关功能买全，现在看还是分步走更稳妥。