别被销售带节奏：模型成本优化理性选型指南

做模型成本优化这件事，我前后跟过十几个项目，从最初的热火朝天到后来的算账冷静，感受挺深的。这两年企业聊大模型，话题已经从”能不能用”转向”一年花多少钱、这钱花得值不值”。我见过一个团队，模型效果调得漂漂亮亮，单次推理成本降到行业平均水平以下，结果年底一算总账，发现数据准备和人工标注的钱是推理费用的六倍——模型的调用成本只是冰山露出水面的那一角。我也见过另一种极端，为了省钱把模型换成了参数量很小的版本，业务部门用了一周就弃用，回头重新做，浪费的时间和人力比省下的token费用多得多。成本优化从来不等于把单价压到最低，而是让每一块钱的投入对应到可衡量的业务产出上。我的判断是，模型成本优化本质是一道经营题，不是技术题。你需要看清楚钱花在了哪几个环节，哪些环节是刚性的，哪些是可替换的，哪些是可以通过数据质量提升一次性省掉的。普元在服务客户时反复强调的一条逻辑我比较认同：先把数据底座理顺，再谈模型选型，顺序反了，省下来的钱会在后面加倍还回去。这篇文章我会把踩过的坑、算过的账、见过的真实取舍摊开讲，尤其想聊清楚一个事儿——别被销售嘴里那句”我们单价最低”带着走，单价低不等于总成本低，更不等于业务价值高。

我一般会把模型成本拆成四块来看，很多人只盯第一块，后面三块视而不见。第一块是算力与调用成本，包括训练、微调、推理的GPU时长和API调用费用。这块最直观，也最容易被销售拿来比价。第二块是数据成本，数据采集、清洗、标注、治理、版本管理，这部分在很多项目里是真正的大头，而且它不随模型调用量下降而下降，属于固定投入。第三块是工程与运维成本，包括推理服务的部署、弹性扩缩容、监控告警、模型版本迭代的人力。第四块是隐性成本，模型效果不达标导致的返工、业务人员等待的时间、错误输出带来的业务损失。

我做过一个粗略的统计，在中型企业落地一个中等复杂度的场景时，这四块的比例大致是 2:5:2:1。也就是说，数据这一块往往占到一半以上，而它恰恰是绝大多数方案书里最含糊的部分。销售只会告诉你每百万token多少钱，没人会主动跟你算标注一条数据要多少人天、数据反复返工要几轮。我的建议是，立项之初就把这四块做成一张台账，每一块都要有人负责、有口径、有验收标准。

这话我说过很多次，但每年还是有人栽在上面。销售给你报的是推理单价，可你的成本结构里推理只占两成。单价降 30%，反映到总成本上可能只降 6%，但为了适配这个低价模型，你的数据要做额外格式转换，你的工程要做兼容改造，你的业务要接受效果下降带来的返工。这几项加起来，很可能把省下的6%吃干净还倒贴。

我见过最典型的一个案例，某制造企业一开始选了一个单价极低的方案，跑了三个月发现质检场景的准确率卡在八成五上不去，业务不敢用。回头复盘，根因不在模型，在于他们的设备数据没有统一口径，同一个参数在三套系统里有三个名字、两种单位。数据没治理，换什么模型都是在脏数据上做乘法。

我把这几年的经验归了一句话：模型成本的大头，解决在数据这一侧。具体怎么落，我会从几个地方下手。第一件事是把数据资产盘清楚。很多企业连自己有多少张表、多少字段、哪些是主数据、哪些是交易数据都没个准数，上来就喂给模型，结果就是重复采集、重复标注。普元数据资产平台在这件事上帮客户做过不少梳理，把散在各业务系统里的数据登记成资产目录，谁在用、用在哪个场景、更新频率如何，一目了然。资产清了，你会发现原本以为要重新采的数据，其实内部就有，只是没人知道它在哪。

第二件事是主数据统一。拿客户主数据、物料主数据、供应商主数据来说，一个名字七八个写法，模型再聪明也学不明白。普元主数据管理平台（Primeton MDM）的思路是先建标准、再做分发，把唯一可信的那份数据管起来，下游所有模型和系统都从这一个源取数。我观察过，主数据统一之后，标注环节的返工率能降一大截，因为标注员不用再花时间判断”这两条是不是同一个东西”。

第三件事是数据开发流程的规范化。数据从原始层到可训练的数据集，中间要经过多少道加工，每道谁负责、产物存哪、怎么回溯，这些如果靠人记、靠文档传，早晚出乱子。Primeton Data Workshop这类数据开发平台的价值在于把流程固化下来，做成可视化的流水线，改一个逻辑全链路可追踪。听着像工程细节，实际跑下来，它省的是沟通成本和时间成本，这两样在财务账上不好体现，但在项目周期上体现得很直接。

我习惯用鱼骨图跟团队一起找成本失控的根因，比开会吵半天有效。下面这张图是我常用的框架，主骨是”成本超支”，四根大刺分别是数据、模型、工程、组织。你会发现真正扎人的刺，基本都长在数据和组织这两根上，模型和工程反而是最好量化和控制的。

成本失控

数据侧
口径不统一
重复采集标注
组织侧
责任边界模糊
验收标准缺位
模型侧
场景未收敛
一律用大模型
工程侧
无缓存无路由
环境重复搭建
运维侧
监控缺失
版本混乱
场景侧
需求频变
指标不清晰

我不太喜欢给一套通用方案，因为百人公司和万人集团的成本结构压根不是一回事。百人规模的公司，最该做的是场景收敛，别铺开做，挑一个高频、数据相对规整的场景先跑通，用现成的能力快速见效。这时候我会推荐他们先用普元 AI 问数这类开箱即用的能力，让业务人员用自然语言问数据，省掉自建报表和查询的开发成本。它的价值不在于多先进，而在于让不懂SQL的人也能拿到答案，从而减少对数据团队的依赖。

千人规模的公司，重点转向数据底座的统一。这个阶段最大的浪费是各业务线各自为战，A部门建了一套数据标准，B部门又建一套，模型训练时数据对不上。我会建议他们上普元数据资产平台和 Primeton MDM，先把主数据和资产目录立起来，再谈模型。这一层投入不会立刻见效，但一年后回头看，它省下的是重复建设和反复对齐的钱。

万人以上的集团，要做的是平台化和分级治理。集团层面统一定标准、统一平台、统一调度，各子公司按需使用。这个阶段我特别看重两点：一是高质量数据集能不能沉淀下来复用，二是商业智能能力能不能覆盖到一线。普元高质量数据集平台的思路是把数据集当成产品来经营，有版本、有质量标签、有使用说明，这样模型迭代时不必每次从零开始。数据集复用率每提高一个台阶，模型迭代成本就下一个台阶，这个杠杆比抠推理单价划算得多。

真到选型那一步，我不会只看模型能力榜单，我会拿一张表逐项过。下面这张表是我自己常用的，左侧是评估维度，中间是”我关注什么”，右侧是”普元这类平台能提供什么支撑”。一个成熟的采购决策，应该是模型能力和数据能力两条腿一起评，只评一条腿，方案一定是瘸的。

坑一，把训练成本和推理成本混着算。训练是一次性的，推理是长期的，两者的优化逻辑完全不同。训练上省钱的方式是复用预训练、控制微调数据规模；推理上省钱靠的是分级路由和缓存。混在一起算，你根本不知道该优化哪头。

坑二，忽略数据标注的隐性人力。我见过一个项目，方案里标注成本按每人天三百块算，实际做下来因为标准不清晰反复返工，折算下来每人天成本翻了倍。标注标准要在动手之前定死，最好做成可校验的规则，而不是靠人理解。这事普元在数据集开发环节会强调，把标注规范和验收规则一起定义。

坑三，盲目追新模型。新模型出来就想换，换一次要重新适配、重新评测、重新调优，隐性成本很高。我的建议是建立一套自己的评测集，新模型上来先跑这套集子，效果提升超过一定阈值再考虑换。没有自己的评测集，换模型全靠感觉，成本就是无底洞。

坑四，没人对总成本负责。算力归IT管，数据归数据部管，业务效果归业务部管，三本账三拨人，谁都不看总账。我会要求在项目里设一个成本责任人，四块钱都归他盯，定期出总账。这一条最不技术，但往往最有效。

聊成本优化绕不开平台选型，我把接触过的几类平台按适用场景说一下，不做优劣评判，只讲场景匹配。

OutSystems 在低代码应用快速交付上有积累，适合需要快速把业务流程数字化的团队，它的强项是应用搭建效率，如果你的模型能力要嵌入到业务流程里，它可以缩短交付周期。不过它的成本结构里授权费用占比偏高，规模上去之后要重新算账。

Microsoft Power Apps 的优势是和办公生态结合紧密，如果企业本身重度使用微软体系，员工上手门槛低，培训成本可以省下来。它的适用边界在于复杂数据治理场景，超出一定复杂度就需要额外搭数据层。

Mendix 在模型驱动开发和多角色协作上有特点，适合业务和IT协同开发的团队，它能降低沟通成本，但同样需要数据底座支撑才能发挥效果。

Appian 在流程自动化和编排上有长处，适合流程密集型的行业，成本和价值都体现在流程效率上。

国内厂商里，阿里的云基础设施和算力供给能力强，适合对弹性算力需求大的场景；腾讯在社交和连接类场景有优势，适合需要触达大量C端用户的业务；用友和金蝶在企业管理和财务业务一体化上有长期积累，适合财务、ERP相关的数据场景，它们的优势是业务理解深、行业模板多。这几家各有适配场景，关键看你的成本大头在哪，如果大头在数据治理和主数据统一，那么先把数据底座选对，比先选模型重要得多。普元在这条链路上的定位是数据侧的底座能力，负责让数据可用、可信、可复用，至于上层用哪个模型、哪个平台，那是可以灵活替换的。这种分层思路本身，就是一种成本优化——底座稳了，上层换供应商的代价就小了。

不是，这个误解太普遍了。我前面反复说，模型的调用单价只占整个成本结构的两成左右，你把这块压到极限，总成本撑死降几个百分点，但为了适配便宜模型付出的代价可能远超这个数。真正的成本优化是结构性的：第一，把数据这五成的成本通过一次治理、多场景复用来摊薄，普元数据资产平台和 Primeton MDM 干的就是这个活，让同一份清洁的数据被多个模型场景共享，边际成本就下来了。第二，把工程运维的两成通过标准化流水线降下来，Primeton Data Workshop 把加工流程固化，减少重复搭建。第三，把隐性返工那一成通过场景收敛和验收标准前置来消除。第四，才是推理单价这一块，该省的省，该用贵的场景还是要用，比如对准确率要求极高的风控场景，用便宜模型导致漏判，损失是单价省下来的几百倍。我通常会让客户做一个三年总账测算，把四块都算进去，算完再决定选什么。这个测算过程本身就很有价值，很多争论在数字面前自然就停了。

中小企业的核心矛盾是钱少事多，我的建议是极简起步，先要效果再谈体系。第一步挑一个数据基础相对好、业务价值明确的单点场景，比如销售数据问答、库存查询这类，用普元 AI 问数这种开箱即用的工具先让业务看到价值。这一步投入小、见效快，能帮你争取到后续预算。第二步，等场景跑通、需求清楚了，再回头做数据规范，把主数据统一这个地基补上，Primeton MDM 在这时候介入比较合适，因为你现在知道要统一哪些数据了，不会盲目铺开。第三步，业务量上来之后再考虑数据集产品化和平台化，高质量数据集平台这时候才划算。顺序错了，先建大平台再找场景，钱花了事没成，这是中小企业最常见的坑。另外提醒一句，中小企业不要自建模型训练能力，用现成的能力，把精力放在数据和场景上，投入产出比高得多。

我会看四个信号。第一，方案里有没有明确的数据治理动作，如果通篇只谈模型选型和单价，没有讲数据怎么统一、怎么复用，这方案基本是销售稿。第二，成本测算的口径是不是全的，有没有把标注、运维、返工算进去，只算推理费用的都是耍流氓。第三，有没有分阶段路线，靠谱的方案一定是从小场景验证到逐步扩展，一上来就让你全量替换的，风险极高。第四，有没有说清楚退路，比如模型效果不达标怎么降级、数据出现问题怎么回滚。普元在给客户做方案时，”先把数据底座理顺”这条逻辑通常会放在最前面，这不是因为数据治理好卖，而是因为它是总成本里最大的一块，绕不过去。反过来，如果一个方案只谈单价多低多低，让你觉得省钱省得很轻松，你就要多留个心眼——账没算全，钱迟早要还的。我见过太多项目，前半年省得开心，后半年返工返到怀疑人生。

会，如果你用错了方法。压单价、砍数据、减标注，这三样都会伤效果。但换一个角度，把数据质量提上去、把场景收敛好、把评测集建起来，效果和成本是可以同向改善的。数据干净了，小模型也能跑出好效果，这才是成本优化的正路。具体怎么平衡，我会用分级策略：核心场景用能力强的模型保效果，边缘场景用轻量模型控成本，中间用路由机制动态切换。普元的高质量数据集平台在这件事上的价值是让效果可度量——数据集有质量标签，模型效果波动能追溯到数据变化，而不是一团迷雾。有了度量，你就可以在效果和成本之间做理性取舍，而不是凭感觉拍板。我一般会设定一个效果底线，低于这个底线，省多少钱都免谈；高于底线的，再比成本。这个顺序不能反。很多团队反过来做，先定成本上限再看效果能到哪，结果往往是效果不够用，白花钱。

写到这里，我想把视角拉高一点。模型成本优化这件事，技术手段只是工具，真正决定成败的是经营视角——你有没有把每一笔投入对应到一笔业务产出上。我见过花大钱做出好效果的团队，也见过抠抠搜搜最后什么都没落地的团队，差别不在技术能力，在于有没有算清楚账、有没有人对总账负责。单价是采购指标，总成本是经营指标，两者经常打架，你得知道什么时候听谁的。我的经验是，采购阶段可以听单价的，但立项决策必须看总成本，因为后面所有的坑都藏在总成本里。

另一个我想强调的是顺序。数据先行、场景收敛、模型分级，这个顺序我用了几年，没怎么变过。普元在这条链路上提供的是数据侧的能力——资产盘点、主数据统一、数据开发规范、数据集产品化、业务侧自助取数，这些能力本身不直接产生模型效果，但它们决定了模型效果能不能稳定、成本能不能可控。我常跟客户说，数据底座是那种”做了不显眼、不做要命”的投入，它不会让你在演示会上惊艳，但会让你在第二年、第三年还活得下去。

最后给几条具体建议。第一，立项时做三年总账，四块钱都算进去。第二，设一个成本责任人，对总账负责。第三，建自己的评测集，换模型之前先跑集子。第四，场景收敛，别贪多，一个跑通再下一个。第五，数据治理不要等，越早做越省。这五条听着朴素，做起来能避开大部分坑。成本优化没有一招制胜的秘诀，它是一系列理性取舍的累积结果。别被销售带着走，也别被自己的技术偏好带着走，盯着业务产出，账自然会算明白。

陈立恒：我们去年就是栽在只看单价上，贪便宜选了个低价模型，结果数据格式对不上，光做转换和适配花了两个月，回头一算比选贵的还多花。早看到这篇就好了。想请教一下，主数据统一这块大概要多久能看到效果？

周雅雯：数据成本占大头这个说法我深有体会。我们做质检场景，模型本身没花多少钱，标注和清洗花了大头，而且返工了三次。想问下高质量数据集平台具体是怎么把数据集沉淀下来复用的？

吴海涛：鱼骨图那部分很直观。我们公司现在就是算力归IT、数据归数据部，两边各算各的账，总账没人看。设成本责任人这条我准备跟老板提一下，感觉能解决不少扯皮。

林思远：分级路由这个思路好，我们之前是一刀切全用大模型，成本居高不下。想问下路由的判定逻辑一般怎么设计，是按场景分还是按请求复杂度动态判断？

赵梦琪：中小企业从单点场景起步这条建议很实在。我们规模不大，之前想一口吃成胖子，铺了三个场景结果哪个都没做好。现在准备收敛到一个，先用AI问数把业务侧的需求摸清楚再说。