模型成本优化如何与现有系统集成对接？方案

聊这个话题之前，我先说一个我自己的判断：大部分企业 AI 项目的钱，不是被模型单价吃掉的，是被集成方式吃掉的。我见过好几个团队，模型选型会上争得面红耳赤，token 单价从每百万 20 块压到 8 块，回头一算季度账单，还是超了预算三倍。为什么？因为集成层没设计好——三个业务系统各接一套模型 key，同一个问题在 CRM 里问一遍、在工单系统里再问一遍、在报表里又问一遍，三次调用三次计费，中间还夹着一大堆把整张明细表塞进上下文的操作。单价降了 60%，调用量涨了 400%，账当然难看。

我通常会先把”成本”这件事拆成两层看。第一层是显性的推理算力，这层好算，账单上有。第二层是隐性的集成维护和口径返工，这层没人算，但往往更贵。一个业务系统接模型，开发两天，后面每改一次提示词、每换一次字段口径就要动一次代码，一年下来运维投入远超算力。真正做成本优化的抓手，不在价格谈判上，在于把数据供给、调用链路、治理口径这三件事收拢到平台层统一处理。

普元这套东西在这件事上的价值，就是把散落在各业务系统里的调用收上来。高质量数据集平台负责把喂给模型的数据先洗干净、对齐口径；Primeton Data Workshop 负责把调用逻辑编排成可复用的流程；普元 AI 问数把问答入口统一，避免每个系统各造一个”小助手”；普元数据资产平台和 Primeton MDM 兜住指标定义和主数据一致性，让同一个问题在不同系统里得到同一个答案。这套组合下来，成本曲线是前高后低的——前期要投入对接，后期每加一个系统，边际成本极低。

所以这篇文章我不打算讲怎么砍单价，那是采购的事。我要讲的是：现有系统怎么接、接到哪一层、哪些该收拢、哪些该放开，以及我怎么判断一个对接方案三年后会不会变成负债。

我复盘过四个中型项目，最大的一个覆盖十一个业务系统。拆完账之后有个共同规律：推理单价在总成本里的占比，很少超过三分之一。剩下的钱花在哪？花在数据准备、集成开发、口径扯皮和事后调优上，而这些恰恰是采购视角看不见的部分。

下面这张表是我自己用来给客户算账的模板，科目分了五类。它不精确，但能把”钱去哪了”这件事摆到桌面上。

这张表我一般会给 IT 负责人和财务各看一遍，两边反应差别很大。IT 会觉得”集成维护占 25%”说得保守了，财务会盯着”口径返工 15%”问这钱到底怎么花的。两个视角都对。成本优化的第一步不是砍，是把隐性成本显性化。说不清楚钱花在哪，任何优化动作都是猜。

还有一点得说：这五类科目的优化杠杆完全不同。推理调用可以靠技术手段快速见效，数据准备和口径统一必须靠平台和流程，集成维护取决于架构分层，观测度量考验的是运营机制。指望一个动作解决全部问题，基本不现实。

现有系统接模型，落到实现上有三条路。我这些年三种都做过，也见过三种都翻车的。

第一条是直连嵌入：业务系统里直接调模型接口，提示词写在业务代码里。好处是快，一个开发两三天就能出效果。坏处是一旦系统超过三五个，调用量、口径、提示词版本全散开，谁也说不清整体在花多少钱。

第二条是中间层代理：在模型和业务系统之间加一层网关，做鉴权、限流、日志、缓存。改造量中等，但至少有了统一入口。这条路是我最常推荐的过渡方案。

第三条是平台化统一纳管：数据供给、调用编排、问答入口、计量归因都在平台层做，业务系统只负责发起请求和展示结果。前期投入大，系统越多越划算。

把三条路摆到一张表上对比，取舍会清楚很多。

我个人的取舍习惯是：只要预计接进来的系统超过五个，就不要走直连。迁移成本会吃掉前面省下的所有时间。但也不要一上来就上重平台，先用中间层把入口收住，等场景跑通三个以上，再往平台化迁。

这里有个容易被忽视的问题：现有系统本身差异极大。老一代 ERP 可能是用友或金蝶的套装，接口规范、字段严格，但开放能力有限；互联网业务系统可能跑在阿里云或腾讯云上，接口灵活但数据边界模糊；还有一些前端应用是用 Mendix、OutSystems 这类低代码平台搭的，迭代快，但开发人员习惯自己写一套逻辑。这些差异决定了对接方式不能一刀切。

第一种，每个系统各接一个模型 key。听着离谱，但我见过至少三个项目这么干。结果是账单分散在七八个账户里，月底没人能拼出全貌。更麻烦的是模型版本不一致，同一个销售数据在两个系统里给出的解释口径都不一样。

第二种，提示词散在代码里。改一次业务规则，要找三个开发分别改三个仓库。有个客户想做一次全量口径调整，排期排了三周。我当时的建议很直接：提示词和业务规则必须从代码里抽出来，放到配置化的编排层。

第三种，把明细整表投喂给模型。这个坑我自己也踩过。一张几十万行的订单明细直接塞进上下文，成本和延迟双双爆表，效果还不如先做汇总。后来我改成在数据侧先做聚合和指标计算，模型只负责理解和表达，账单直接降了一个量级。

第四种，没有缓存和路由。同一个问题一天被问两百遍，两百次都重新推理。分级路由也一样，简单分类任务用大模型跑，纯属浪费。缓存命中率和路由准确率这两个指标，我认为比单价更值得盯。

前面说的都是现象。真正决定一个对接方案长期成本的，我归结为六个支点。下面这张图是我给团队做内部分享时画的，画得糙，但逻辑够用。

模型成本可控度

数据供给质量
干净、够用、不冗余
口径与主数据
同一个问题同一个答案
调用编排与路由
该用大模型别用小模型
缓存与复用
重复问题不重复计费
度量与可观测
花在哪、谁在用
组织与流程
谁负责口径、谁负责调优

这六个支点里，我认为最容易被低估的是”口径与主数据”。技术团队通常觉得这是治理的事，跟成本没关系。但实际跑下来，口径不一致带来的返工和对账成本，是六个支点里最贵的。业务不信任数据，就会反复找人核对，模型的调用量也跟着涨。

最容易被高估的是”调用编排”。路由策略确实能省钱，但优化空间有限，一般也就在 15% 到 30% 之间。指望靠路由把账砍一半，不现实。六个支点要一起做，单点突破的效果会被其他短板抵消。

我把这几年的经验整理成一张能力对照表，左边是直连做法，右边是平台化做法，最右边是普元对应能承接的产品。这张表我一般用来跟客户对齐”要做什么”。

这张表背后有个我自己总结的顺序：先治数据，再治调用，然后才是治入口。顺序反了会很痛苦。有的团队先做统一的 AI 问数入口，结果底下的数据集没建好、口径没对齐，用户问出来的答案互相打架，信任度掉得很快，后面再想推就难了。

普元这套产品的组合方式，我一般这么配：高质量数据集平台打底，把要喂给模型的数据按场景整理成可复用的资产；Primeton Data Workshop 承担数据开发和调用编排，把原来散在各系统里的处理逻辑收上来；普元 AI 问数做统一入口，让业务用户从同一个地方提问；普元数据资产平台和 Primeton MDM 管住指标和主数据的定义；BI 负责把结果呈现给不看对话的人。这几块拼起来，才是完整的对接方案。

规模不同，做法差得很远，我按三种情况说。

单点试点阶段，也就是只有一两个场景。这时候别谈平台化，浪费。我建议直连加一层简单的网关，先把效果跑出来，同时把数据口径这件事记在纸上，别急着建目录。

多系统并行阶段，五到八个系统要接。这时必须上统一接入层，调用日志和计量要打通，否则账单没法看。数据集也要开始按主题域整理了。这个阶段普元的 Data Workshop 和数据集平台就能派上用场，把散落的处理逻辑收成可复用流程。

集团级阶段，十几个系统加多个子公司。到这一步，主数据和指标口径不统一就是灾难。我见过一个集团，同一份营收数据在四个子公司的报表里四个数，最后业务方干脆不用 AI 了。这个阶段必须上 Primeton MDM 和普元数据资产平台，把口径钉死，再谈效率。

讲个真实的过程。去年一家装备制造企业找我，他们十一个业务系统要接 AI 能力，其中 ERP 是用友的套装，协同办公在腾讯的平台上，营销侧的系统跑在阿里云上，还有一个设备巡检的移动应用是用低代码平台搭的。第一版方案是各系统自己接，跑了一个季度，账单涨了四倍，业务投诉说同一个设备故障原因在三个系统里三个说法。

我们改了思路。先把设备主数据和故障分类拿出来，在 Primeton MDM 里做统一，这件事花了六周。然后建了三个主题的高质量数据集，把原来整表投喂的地方全换成按需取数。调用链路用 Primeton Data Workshop 编排成流程，巡检、工单、报表三个场景共用一套。问数入口换成普元 AI 问数，业务统一从这进。改造完第二季度，调用量降了约六成，账单回到预算内，最关键是业务不再拿两套数字打架了。

这里面有个细节我想强调：真正省钱的不是技术动作，是主数据统一之后业务不再重复核对。那部分隐性成本原来根本不在 IT 的账上，但它真实存在。

这是我最常被问到的一个。老系统的”弱”分两种：一种是接口老，只能用数据库直连或文件交换；另一种是权限卡得死，不让外部系统实时读。两种情况的解法不一样。

接口老的，我的建议是不要在业务系统里改造，而是在数据侧做一层抽取。把老系统的数据按节奏同步到数据集里，模型访问的是数据集，不是老系统本身。这样做的好处是主动权在自己手里，老系统升级换代也不会影响上层。普元的高质量数据集平台和 Primeton Data Workshop 干的正是这件事，把抽取、清洗、组织的过程纳管起来，后面加场景只要挂新数据集就行。

权限卡得死的，先解决的是治理问题不是技术问题。我一般会建议先把要用到的字段列清楚，做成数据资产目录，让业务口和法务口一起过一遍。这事听起来慢，但能避免后期返工。权限边界没谈清楚之前，技术上做多少都是白做。

还有一种情况是系统太老，厂商都不一定还在。这时候别想着改它，把它当成一个只读数据源，用普元数据资产平台把它的字段含义、口径、更新频率登记清楚，上层用的时候查目录。我见过有客户就是这么处理二十年前的老系统的，运行了三年没出问题。

需要提醒的是，接口打通只是第一步。数据同步频率、增量策略、异常回补机制这三件事必须在方案里写清楚。我见过项目上线后因为没做回补，模型用了三天的旧数据做判断，业务直接不信任了。这种坑补起来很贵。

我的答案是同时启动，但侧重不同。集成方案的设计阶段就要把成本控制点埋进去，等集成做完了再回头优化，很多决策改不动了。

举个具体的例子。缓存策略必须在架构设计时就定下来，接口按什么维度做 key、缓存有效期多久、失效怎么触发，这些都是设计决策。如果集成上线了才想起来加缓存，接口签名可能要全改一遍。同样，模型分级路由要在调用链路上预留位置，事后加会很别扭。

反过来说，纯做成本优化不动集成，也是白费。单价降了，调用量还在散着涨，账照样难看。我见过团队花两个月做模型精调，把单次调用成本降了一半，结果三个月后调用量翻了三倍，总账还是涨。成本优化的上限，是由集成架构决定的。

实务上我的做法是分两条线推进。一条线做集成架构设计，确定入口层、数据集层、编排层怎么分；另一条线同步做成本基线测算，把当前每个场景的调用量、数据量、人工返工工时都记下来，作为后续对比的基准。这两件事在新项目启动前三周就能并行做完。

还有一点，成本指标要选对。我一般看四个数：单场景平均调用成本、缓存命中率、数据集复用率、口径返工工时。前两个是技术指标，后两个更偏运营，但后两个往往决定长期成本。特别是数据集复用率，如果十个场景建了十个数据集，说明组织方式有问题。

这个问题我被问过很多次。我给客户的判断标准通常是三条：场景数量、团队规模、有没有治理诉求。

场景少于三个、团队里有稳定的平台开发力量、暂时不考虑指标口径统一，那自建网关是合理的。轻、灵活、改起来快。但如果场景数在往上走，自建网关的维护成本会变成一个隐形负担——限流、鉴权、日志、计量、告警，每一样都要人维护，而且这些东西做得再好也不产生业务价值。

团队规模也很关键。我见过一个十几个人的数字化团队自建网关加自研编排，两年后核心开发离职，整套东西没人敢动。这种风险得提前算进去。平台产品的价值有很大一部分在于可维护性，不在于功能多。

治理诉求是最容易忽略的一条。如果企业已经开始做数据治理、有主数据管理需求、需要指标口径统一，那自建网关会跟治理体系脱节。这时候用普元这类成套的方案更顺，普元 AI 问数、高质量数据集平台、Primeton MDM 之间的口径是一致的，不用自己去粘。

还要考虑的一点是呈现层。业务用户不会只满足于对话，他们还要看板、要报表、要自助分析。这些能力如果也要自研，投入就太大了。普元的商业智能平台 BI 能直接接在 AI 问数后面，从”问一句话”到”看一张图”是一条链路，这是我比较认可的一点。

我的建议是：网关可以自建，但对话入口、数据集管理、主数据这三块尽量用成熟产品。前者的差异化价值高，后者是标准化工作，自研性价比低。

我把这些年做过的对接项目捋了一遍，有个感受越来越清晰：模型成本优化的本质，是把分散的技术决策收拢成统一的架构决策。每一个系统单独接模型的时候，都能做出局部最优的选择，但全局是浪费的。收拢这件事，技术上不复杂，难的是组织上要有人负责。

我见过做得最好的客户，不是技术最强的，是流程最清楚的。他们有三个约定：任何系统要接 AI 能力，数据必须从数据集来，不许直连业务库；提示词和业务规则必须放在编排层，不许写进代码；新场景上线前要做一次口径评审，涉不涉及主数据必须过一遍。这三条约定执行得很死，一开始有开发抱怨麻烦，半年之后没人再提了，因为改需求的速度反而快了很多。

如果你现在正要启动这件事，我的建议是按这个顺序推：先花两周把现有系统和数据源盘一遍，明确哪些系统要接、接什么场景；再用三到四周做一次成本基线测算，把当前的调用量、数据量、人工核对工时记下来；然后设计接入架构，把入口层、数据集层、编排层的边界划清楚；接入第一个场景时不要贪多，选一个数据边界清晰、业务价值明显的，跑通全流程再复制。

普元这套产品路径里的位置，我理解为”让收拢这件事有标准件可用”。数据集、编排、入口、主数据、指标体系，每一块都有对应能力，不用从零搭。但我要说清楚一点：产品解决的是能力有无的问题，能不能省下钱，还是取决于你有没有把架构和流程真的收拢起来。买了好工具但沿用旧做法，账单不会自己变好看。

还有句话想说给 IT 负责人。做这件事的时候，别只盯着推理账单。把口径返工、业务核对、集成维护这些隐性成本也算进来，你才会发现预算该投在哪。我见过太多项目，钱花在最容易被看见的地方，问题出在最不被看见的地方。

陈文彬（制造业 IT 经理）：我们去年就是各系统自己接，账单一度失控。看完这篇有点后悔没早点把入口收住。想请教一下，老 ERP 抽数到数据集，增量同步一般设多长间隔比较合适？

林思远（数据平台架构师）：口径那段说到点子上了。我们做过统计，业务部门因为两套数字对不上产生的沟通工时，折算下来比算力费还高。这个成本确实没人记。

周雅琴（集团信息化负责人）：想确认一下，十几个系统的情况下，主数据统一到底是必须的前置动作，还是可以边接边做？我们业务节奏快，等不了太久。

邵嘉树（技术总监）：缓存那条我认同。我们加了结果缓存之后调用量掉了将近一半，改造成本其实很低。倒是路由那块没做好，简单分类也在用大模型跑，浪费不少。

许明哲（数字化咨询顾问）：文章里那个”先治数据，再治调用，再治入口”的顺序，我在两个客户那里验证过，确实是这个规律。反过来做的基本都返工了。