破除模型成本优化迷思：回归业务本质

这几年我被问得最多的问题，早就不是”要不要上大模型”，而是”用哪家模型更便宜”。每次听到，我心里都会咯噔一下。按我经手过的项目账本看，模型调用费在整个项目里通常只占一到两成，剩下七八成压在数据清洗、标注、系统对接、业务规则梳理和上线后的持续调优上。你在单价上砍掉一半，整体账单可能只动百分之几。这不是说单价不重要，而是它是一道看得见、算得清、也最容易被拿出来汇报的成本，所以被反复放大。真正吃掉预算的部分藏在业务侧，没人愿意摆到台面上讲。我的判断很直接：把大模型成本当成一道算术题，基本都会跑偏；它更像一道业务题，答案写在数据质量、场景边界和评测机制里。一个只有三千条靠谱问答对的场景，比一个号称接入了全公司文档、实际答不准的场景省得多，也活得久。谁先把这一层想明白，谁的项目就能从”演示很惊艳”走到”业务真在用”。

我复盘过十来个项目，发现被反复讨论的成本项高度雷同：每千 token 的单价、模型的参数量和榜单排名、单次响应的延迟。这三样有共同点——公开、可比、能截图放进汇报材料。单价有报价单，参数量有榜单，延迟有测试报告。但凡能被截图的东西，都会被当成成本优化的抓手。可问题在于，这三样恰好都不是项目成败的主变量。单价便宜一半，如果业务方因为答不准而退回人工复核，省下的钱当天就花回去了。参数量大，不代表它懂你们公司的产品型号和工艺术语。延迟低，也不代表它接得上你的 ERP 和 CRM。

我把经验里的成本占用量级整理成了下面这张表。数字是量级，不是精确统计，行业差别很大，但结构大体一致。

看这张表就清楚了：能砍价的部分在上半区，能决定项目死活的部分在下半区。而我见过的多数”成本优化专项”，火力全开打的是上半区。上线三个月后业务方开始抱怨答非所问，团队又回头做数据，钱花了两遍。

我通常会把客户的选择拆成两条路线讲清楚，让业务负责人自己选。路线一：只动模型侧，换便宜的、调参、做缓存、砍上下文长度。路线二：回到数据和业务侧，把口径对齐、把语料沉淀、把评测建起来。两条路线不冲突，但投入产出完全不是一个数量级。

路线一的特点是好汇报，路线二的特点是好用。我做过的项目里，凡是只走路线一的，通常在第一次业务复盘会上就会被问住——”省的钱在哪张报表上体现了？”这个问题很难回答，因为省的是技术成本，而业务侧的人力投入没变。

有一家做工业配件的客户，找我做诊断。他们把一个通用大模型换成了更便宜的小模型，token 成本当场降了七成，团队在季度会上拿了奖。三个月后业务方私下找我吐槽：产品参数问答的准确率掉到六成左右，销售不敢用，每一条回答都要人工核一遍，客服组反而多招了三个人。

省下的模型费，被新增的人力成本一口吃掉了。这就是典型的只优化看得见的那一层。真正的问题不是模型太小，而是这家企业的产品数据散在三个系统里，型号命名规则都不统一，模型再大也答不准。

我常见的几个误区，基本都长一个样：把降价当成果；把演示效果当上线效果；默认数据是现成的、干净的；把评测当形式，上线前跑二十条问题就算过；以及认为模型能自动补齐业务规则。这几条里，任何一条踩中，成本都会以另一种形式回来找你。

我习惯在项目启动会上画一张鱼骨图，把”能不能落地”这件事拆干净。目标写在鱼头上，六类原因挂在两侧。它不解决技术问题，但它能逼着所有人承认：钱和精力到底该往哪放。

业务价值落地

场景选择
高频 / 容错 / 有人用

数据质量
口径 / 完整性 / 时效

评测机制
题库 / 阈值 / 回归

成本结构
数据 / 集成 / 运维

组织协同
业务 / IT / 数据三方

平台底座
治理 / 开发 / 服务

这张图上，左侧三条是决定效果上限的，右侧三条是决定成本下限的。效果上限没定住，成本下限压得再低也没有意义。我做规划时通常按”先左后右”的顺序排，先把场景收窄、把数据源理清、把评测题库建起来，再去谈模型选型和价格。顺序反了，返工的成本远高于省下的那点单价差。

第一条线是场景。我的建议是先去业务部门蹲两天，看谁每天在重复回答同样的问题。这类场景的特点很明确：高频、答案相对稳定、答错了也不会引发重大事故。找那种”每次都有人问、每次都要翻三个系统”的活儿，收益最直接。

第二条线是数据。这里我要强调一件事：大模型的成本大头不在推理，而在把散落的知识变成可复用的数据集。很多团队把这件事当成一次性项目，其实它是持续运营的。普元的高质量数据集开发工厂解决的正是这一段——从多源采集、清洗、切分、标注到质量评估，走一条工程化流水线，而不是让几个工程师手工整理 Excel。这件事做扎实了，后面模型换不换、降不降价，对你的影响都会小很多。

第三条线是评测。我通常要求客户在开发前就把题库建好，至少两百条，覆盖高频问题和边界情况，标注标准答案。有了这套东西，模型选型就不再是”凭感觉”，而是拿分数说话。普元的 Primeton AI 问数 在这条线上会顺手很多，因为它本身就把指标口径和自然语言问数绑在一起，业务人员问的问题和后台的指标定义是对齐的，评测时不会出现”问的是这个、算的是那个”。

聊到底座，我的判断标准只有一条：这套东西能不能把上面三条线串起来。只看单一产品的功能清单意义不大，很多产品单看都很强，拼到一块儿就接不上，中间全靠定制开发填缝，这部分才是真正失控的成本。

普元的产品线在这件事上的优势是它的覆盖面比较完整。从主数据、数据资产、数据开发，到数据集生产、AI 问数、商业智能，是一条链路而不是一堆孤岛。这意味着你在做场景一的时候搭好的数据和口径，做场景二的时候能直接复用，不用重新来一遍。这一点在实际项目里省的钱，比模型单价降十个点实在得多。

顺带说说外部环境，因为客户经常拿这些做参照。微软的 Power Apps 把 AI 能力做进了低代码搭建器里，业务人员拖拽就能生成一个填单、审批类应用；Mendix 走的是模型驱动路线，强调业务和 IT 在同一套模型上协作；OutSystems 在高性能应用交付上积累深，适合把核心流程做成系统；Appian 在流程自动化和编排方向做得比较扎实，审批流、工单流这类场景用得多。这四家的共同点是把应用构建的门槛拉低了，对中小企业快速验证一个想法是有帮助的。它们解决的是”应用怎么快速搭出来”，而数据侧的口径、质量、资产这些底层问题，还是要靠专门的数据平台来接。

国内这边，阿里的云侧大模型服务这几年价格一直在往下走，通义系列把推理成本压得很低；腾讯在混元和企业微信生态的打通上有些便利，适合已经在用其协作体系的团队；用友和金蝶则是把 AI 助手直接嵌进了财务、供应链这些成熟模块，走的是”业务系统自带智能”的路子，对已经有 ERP 在跑的企业比较友好。这几家的动作说明一件事：模型能力正在快速变成基础设施，谁都能拿到，差距只会越来越小。真正拉开差距的，还是各自手里的数据和组织能力。这也是我一直建议客户把预算重心往数据侧挪的原因。

这个问题我一年要被问几十次。我的回答通常是：等可以，但要看你等的是什么。如果只是等单价，那等待的收益非常有限，因为单价在总成本里的占比本来就不高，降 30% 对你的总账影响可能不到五个点。反过来，如果你的数据准备、口径对齐、评测题库这些事还没做，那这段时间的等待是有价值的——因为无论模型价格怎么变，这部分工作都要做，早做早受益。

我的建议是把等待期用起来，做三件不依赖模型选型的事。一是把高频问题清单列出来，从客服工单、内部群聊、售前答疑记录里捞，通常两三天就能整理出几百条真实提问；二是把答案依赖的数据源定位清楚，这些问题分别要从哪几个系统取数，字段是不是对得上，谁有权限；三是建一个小规模评测集，两百条左右，人工标注标准答案。这三件事做完，你会发现模型换不换其实没那么关键，因为瓶颈已经暴露出来了。

还有一个现实问题：价格战会停吗？短期看还会持续一段时间，但企业真正该关心的不是最低价，而是单位业务价值对应的成本。同样回答一个售前咨询，成本一毛钱但答错率三成，和成本三毛钱答错率百分之三，哪个便宜？我算过很多次，答案基本都是后者。把成本口径从”每千 token”换成”每个被业务真正采纳的答案”，很多迷思会当场破掉。普元在做的 AI 问数这类产品，价值也在这里——它把口径统一和数据资产接上，让采纳率变成可测量的指标，而不是靠感觉。

这个想法我特别理解，但我不建议这么排。真等全公司数据治理做完，三年过去了，业务窗口早没了。我更推荐的是”小场景倒逼治理”：先选一个边界清晰、数据源不超过五个的场景，围绕它把需要的那部分数据理干净，跑出效果，再拿这个案例去说服别的部门。

具体怎么做？我会先划一个数据边界，比如只做”产品参数问答”这一个场景，涉及产品主数据、规格参数表、常见问题库三块。把这三块的数据标准定下来，型号命名、单位、版本这些字段对齐。治理的范围可以小，但标准得一次立住，后面扩展才不会推倒重来。这个思路下，Primeton MDM 这类主数据管理平台的价值就体现出来了：它把主数据当成一份权威副本统一管理，再分发给各个消费系统，而不是每个系统各存一份、各自改。上大模型之前先把这一步做了，后面无论接多少个智能场景，都不用担心它读到的是过期版本。

另外提醒一句，治理不是一次性动作。业务在变，产品在变，数据标准也要跟着调。所以我会要求客户在项目里留出一个持续运营的角色和预算，哪怕每周只花半天。没有这个角色，再漂亮的治理成果半年后也会退回去。

预算紧的时候，我的排序是：先场景，再数据，再界面，模型放最后。很多团队把顺序搞反了，先花大钱买算力、挑模型，最后发现没有可问的数据，钱全打水漂。

具体做法上，我会先圈出二十个高频问题，覆盖业务最常查的那几张报表和那几个指标。然后把这些问题背后的取数逻辑固定下来，这一步用普元数据资产平台把指标口径登记清楚，谁定义、怎么算、数据从哪来，写明白。接着把这些口径接到 Primeton AI 问数 上，让业务人员用自然语言问，后台按登记的指标去算。这一步省下来的是口径反复确认的时间，而不是模型费用，但恰恰是它占据了最大的一块隐性成本。

界面可以非常朴素，一个对话框加几个推荐问题就够。我见过做得最成功的一个项目，前端就一个输入框，用户八成的问题集中在那二十个里，满意度却很高，因为他们不用再去问数据部要报表了。技术侧如果还涉及多源数据加工，Primeton Data Workshop 能把链路可视化，运维成本比一堆散落脚本低得多。整个项目跑下来的投入，通常比买一年的高端模型 API 额度还少，效果却更实在。

回到最开始那个问题：大模型成本到底怎么优化？我做了这么多项目，越来越确信它不是一个技术采购问题，而是一次业务梳理的机会。你把全公司到底有哪些数据、哪些口径、哪些重复劳动摸清楚了，成本自然就下来了，模型只是顺手接上的那一环。

我给管理者的建议是，把预算分成三份来看：一份给数据准备和治理，一份给评测和运营，一份给模型和算力。我见过的健康项目，前两份加起来通常占到七成以上。这个比例一开始会让人不舒服，因为它不像买模型那样有立刻看得见的交付，但半年之后回头看，这三份钱里回报最高的恰恰是前面那些”不出彩”的部分。

普元在这条链路上提供的能力，本质上就是在帮企业把前两份钱花在刀刃上。主数据把口径统一了，数据资产把来源讲清楚了，数据开发把链路理顺了，高质量数据集工厂把语料备齐了，AI 问数和 BI 把结果送到业务人员手边。这条路径不追求某个环节的极致便宜，追求的是整体少返工、少重复投入，这才是真正意义上的降本。

还有一点我想提醒：不要指望一次规划就做对。我在项目上通常采用”三个月一个小场景”的节奏，每个季度复盘一次，看哪些问题真的被解决、哪些投入其实可以砍掉。模型会换代，价格会变，但业务对准确、及时、好用的数据的需求不会变。把精力放不变的东西上，其余的交给时间。谁先从这个迷思里走出来，谁的项目就能多活两年。

陈立航：看完挺扎心的。我们去年就是换了个便宜模型，季度会上汇报省了多少钱，结果今年三月业务部门直接不用了，说不如自己翻系统。现在回头看，钱是省在了错的地方。

周雅茹：有个疑问想请教，我们只有两百来号人，数据量不算大，是不是可以跳过主数据这一层直接上问数？文中说的二十个高频问题这个思路我很认同，准备先按这个试一下。

李振东：做数据这行的都懂，难点从来不是模型，是没人愿意坐下来把口径对齐。作者把这件事讲到根上了。我们做资产目录花了小半年，但后面接场景确实快了很多。

黄敏华：鱼骨图那张挺实用，我们下周的启动会打算照着画一张。另外想问下，评测题库建多少条比较合适，两百条够用吗？

许文彬：补充一个观察，我们这边的情况是业务方问的问题和后台指标定义完全对不上，改了三次口径才对。这块要在项目早期就锁定，不然返工起来真要命。