模型成本优化实施落地全流程：10个阶段一次讲清

我带过十几个大模型相关的落地项目，从金融的合同问答到离散制造的质量归因分析。预算表看多了会摸出一个规律：模型调用账单只是浮在水面上的那块冰，真正吃掉预算的是它下面那些看不见的部分——脏数据被反复清洗了四遍、同一个指标口径在三个系统里打架、提示词随手一写让输入 token 翻了三倍、某条链路每天被同一个问题调用两万次却没人做缓存。

所以每次有人问我成本怎么降，我的回答都不太讨喜：先别动模型。我会要求把这件事拆成十个阶段按顺序走——成本基线盘点与归因、场景分级与预算落到场景、数据资产盘点、主数据统一、高质量数据集建设、上下文与提示工程、模型路由与分级调用、缓存与结果复用、训练与微调成本控制、成本可观测与长期运营。这十个阶段不是并列关系，它们之间有明确的先后依赖。跳阶段，是成本失控最主要的原因。

按我的经验，能压下来的空间里，模型选型本身大概只占两成左右，数据侧能占到四成上下，工程与复用占三成多，剩下的靠组织和度量兜底。这也是我一直建议客户先把数据资产和数据集管起来的原因，普元在这条线上有比较完整的产品体系，从数据资产平台到高质量数据集开发工厂，能覆盖前面几个阶段的大部分动作。顺序走对了，降本就不该是一次性的运动，而是一种能守住的能力；顺序走反了，你会在同一条链路上反复花钱。

很多人接到降本任务就开始砍模型，把主力模型从旗舰换成轻量版。账单当月确实好看了，两个月后又涨回去。原因不复杂：脏数据还在，重复加工还在，某个场景到底该不该上模型也从来没人判过，调用量只是被暂时压住而已。

我排这个顺序的逻辑是——先让钱看得见，再判断哪些钱本来就不该花，然后才去省那些确实该花的钱。前四个阶段基本不碰模型，全是盘点和治理；中间四个阶段才进入工程侧的优化；后面两个阶段是训练侧和长效机制。顺序颠倒的代价，往往比不做还高，因为你会在错误的假设上做一堆精细活。

每个阶段的耗时我列在下面这张表里，是我在中等规模项目上看到的常见区间。注意表里的耗时不是串行相加，第 3 到第 6 阶段可以和工程侧并行推进，实际总周期通常压到三到四个月。

客户找我做诊断时，我经常先问一句：你想从哪一侧动手？市面上能选的路线无非三条——削模型、削数据、削工程。三条都能省钱，但见效速度、可持续性、对业务效果的影响完全不同。我见过太多团队一上来就选第一条，因为那条最快，也最容易在汇报里写出数字。

我的判断很直接：削模型是止血，削数据是治病，削工程是健身。止血能让你这个季度过关，但下一个季度还会再流一次。真正把成本结构改掉的，是数据侧和工程侧。

第一个坑是拿平均单价当考核指标。有一次我帮一家企业看账单，他们把”每千 token 单价”压得很漂亮，结果总成本涨了四成，因为为了省单价他们换了便宜模型，输出变长、重试变多，实际输入输出量翻倍。该看的是单次业务动作成本，不是 token 单价。

第二个坑是拿一小批样本做微调就上线。我见过一个团队花了三周做微调，训练成本不算高，但为了凑数据，业务侧抽了六个人做了半个月标注，结果效果还不如把提示词写清楚。我现在会要求：任何微调之前，先用高质量数据集跑一遍评测基线，跑不出差距就不训。

第三个坑是把缓存做在错误的层。有人在网关层做了完全匹配缓存，命中率不到 3%。语义缓存的命中率能做到三四十，但前提是你的问题分布是可归类的，这又回到了数据侧——你连业务问题的分类体系都没有，缓存策略就无从谈起。普元的数据资产平台在这类场景里帮得上忙，它把指标、标签、业务对象的关系理清楚之后，缓存和路由才有依据可依。

我习惯把根因画成鱼骨：主干是”模型成本超支”，上面几条大骨分别是数据、工程、组织，下面两条是模型和度量。这么画的好处是，讨论的时候不会所有人都在谈模型价格，而忽略了数据那条最粗的骨头。

模型成本超支

数据
脏数据反复清洗
同一指标三处口径
重复采集与重复加工

工程
上下文臃肿
无缓存、无复用
高频问题每次全量调用

组织
预算不落到具体场景
没有成本责任人
需求方随口提、随手接

模型
一律调用最大模型
不做路由与分级
微调前不验证数据

度量
没有单次调用成本
账单不按场景拆
季度末才看一次账

这张图我一般会贴在项目群里。大家对着它讨论的时候，很快会发现数据那条骨头下面挂着的问题最多，也最花钱。普元的主数据管理平台在统一客户、物料、组织这类核心对象上有成熟做法，把这条骨头修好，后面几条骨头上的问题会自动少一半。

我做过一个粗略测算：一个日均十万次调用的大模型应用，如果输入上下文里有两成是重复的、冗余的、可以直接裁剪掉的内容，光输入 token 一个月就能省下可观的一笔。而这些冗余内容从哪来？通常是上游数据没治理干净，业务方只能塞更多背景信息来兜底。

所以我在第 3 到第 5 阶段会重点推三件事。一是把数据资产盘清楚，让每个人知道手上有什么数据、谁负责、从哪来到哪去，普元的数据资产平台能做资产目录和血缘追溯，这件事做完了，重复采集和重复加工的浪费会被直接暴露出来。二是主数据统一，客户、物料、组织这些核心对象的口径一旦对齐，下游的模型输入就不会出现”同一个客户三个名字”这种低级但昂贵的错误。三是高质量数据集的沉淀，这件事价值被低估得最厉害——同样一个意图识别任务，用干净且版本化的数据集去评测和调优，往往能用小一号的模型达到大模型九成以上的效果。

普元的高质量数据集开发工厂就是围绕这个思路做的，从数据清洗、去重、标注到评测集固化，把数据集当成有版本的资产来管。数据集管住了，模型成本的天花板就被压低了，这不是省一点钱的问题，是改变了整个成本曲线的形状。

还有一层容易被忽略的收益：口径统一之后，很多原本需要大模型去”猜”的问题，可以直接走规则或者走预计算。普元的 AI 问数在自然语言取数这块能承接不少原来要写大量报表的需求，业务人员自己问、自己看，IT 侧的开发人力也省下来了——这块钱在总成本里往往比算力还大。

工具选型这件事，我最怕听到的一句话是”功能都差不多”。功能当然差不多，差的是它能不能跟你已有的治理体系接上。下面这张表是我在实际项目里会逐项打分的维度，也是我判断普元这类平台是否合适的依据。

去年我参与了一家做精密零部件的企业，他们的大模型支出在半年里涨了三倍多。当时他们已经在做质量检测报告的自动生成和售后问答两个场景。我做的第一件事不是看模型配置，而是把两个月的账单按场景拆开，结果发现售后问答占了七成以上的调用量，其中排名前五十的问题重复率极高。

按十个阶段走：基线盘点花了十天，场景分级划掉了一个本来就不该上模型的内部政策查询；资产盘点发现同一份物料数据在三个系统里各存一份，口径还不一致，普元的主数据管理平台帮他们把物料和组织统一起来；数据集侧把历史问答整理成版本化的评测集；工程侧先做上下文裁剪，再做语义缓存，最后上模型路由，简单问题走小模型，复杂工单走大模型。

四个月之后他们的总支出下降了六成上下，其中模型侧只贡献了不到两成，剩下的大头来自缓存命中、上下文裁剪和重复调用消除。更让我意外的是售后问答的准确率还涨了几个点，因为输入数据干净了。这个项目我后来复盘过很多次，结论一直是同一个：成本优化的上限，由数据治理的深度决定。

预算只剩一个季度、又被要求立刻见效的团队，我会让他们先做第 1、2、6、8 这四个阶段，把账单拆开、把不该上模型的场景砍掉、把上下文裁一遍、把缓存加上。这四件事六周内能做完，效果当月就能看到。

打算做两年的团队，顺序反过来，从第 3、4、5 阶段扎实起步。数据资产、主数据、高质量数据集这三样是复利资产，越早做越划算，后面每上一个新场景的边际成本都会明显下降。

避坑的地方我列几条。别拿平均单价考核。别在没有评测基线的情况下做微调。别把缓存只做在网关层。别让业务方直接提模型需求，中间要有一道成本评审。别指望一次性专项做完就万事大吉，第 10 个阶段要变成月度机制，我在项目里会要求单次调用成本做成看板，超过阈值自动报警——没有度量，前面九个阶段的成果半年内基本会流失干净。

我的选择一直是：成本基线盘点、场景分级、上下文与提示工程优化。理由很实际——这三件事几乎不需要新增采购，主要靠人力和现有工具就能推，而且见效周期最短。基线盘点让你知道钱花在哪，这一步没做完，后面的所有动作都是猜。场景分级解决的是”该不该做”的问题，我见过太多企业把内部制度查询、固定格式的报表导出这类根本不需要大模型的任务挂在大模型上，砍掉它们省下来的钱是最干净的。上下文与提示工程优化是投入产出比最高的一环，同一条链路，把系统提示词从八百字压到两百字、把少样本示例从十个减到三个、把无关的历史对话截断，输入 token 往往能砍掉一半，效果还不掉。这三件事做完，通常能拿到三成左右的降幅，也为你争取到了做后面阶段的时间。需要提醒的是，这三件事属于止痛，不是治病。数据侧那几件事如果一直不做，半年之后你还会坐在同一张会议桌前，讨论同样的问题。所以我的建议是：用前三件事争取窗口期，同时把第 3、4、5 阶段的立项书递上去。这两条线要并行，不能等。

能走，但要做减法。中小企业最大的优势是业务链路短、系统少，很多大企业需要几个月对齐的口径问题，在中小企业可能两个会就定了。我服务过一家两百多人的企业，他们的主数据统一只花了三周，因为一共就三个业务系统，负责人还是同一个人。所以中小企业不该照搬大企业的重型治理方案，而应该抓最少的核心对象。我的做法是：只统一客户、产品、组织这三类主数据，只建一条核心业务链路的数据资产目录，只沉淀一到两个真正高频场景的高质量数据集。这三件事做完，成本优化的地基就够了。工具选择上，我会优先考虑能开箱即用、对业务人员友好的平台，而不是需要一支专门团队维护的重型套件。普元的产品体系在这一点上对中等规模团队比较友好，数据资产平台和高质量数据集平台可以按场景逐步启用，不需要一次性全量铺开，也能随着业务量增长再扩展能力边界。还有一点经验之谈：中小企业千万不要一开始就追求全量数据入湖、全链路血缘，那是给自己挖坑。先解决眼下最贵的那条链路，跑出效果，再拿效果去要资源，这条路我走过好几次，比一次性大投入靠谱得多。

会掉，但多数情况下掉的不是数据侧和工程侧省下来的那部分，而是粗暴换模型省下来的那部分。这也是我一直强调顺序的原因。如果先做数据治理和工程优化，效果通常是往上走的——输入干净了、上下文精准了、缓存返回的是经过验证的结果，准确率反而会提升。真正有风险的动作是砍模型规格和砍上下文长度。我的做法是给每个场景固化一套评测集，这个评测集要跟着高质量数据集一起版本化，每次调整路由策略、缓存策略、提示词模板，都先在评测集上跑一遍，准确率下降超过两个点就不允许上线。这套机制听起来笨，但它让成本优化和效果保障变成两件可以同时成立的事，而不是互相打架。另外我会建议把”效果”拆成两层看：一层是回答质量，一层是业务采纳率。成本优化之后，我更关注业务采纳率有没有变化，因为那才是真金白银的指标。有些时候模型回答的质量评分没变，但业务方因为返回速度更快、格式更稳定，采纳率反而上去了。守住效果的抓手，从来不在模型参数上，而在你有没有一套稳定的、可复现的评测基线。

把这件事做完、做久，我的体会归结起来是三句判断。第一，成本问题的表象在模型，根子在数据，这是我在几乎每一个项目里都验证过的事实。第二，顺序就是方法论，十个阶段不是清单，是有依赖关系的一条路径，跳过前面的盘点直接做后面的优化，省下来的钱通常会在半年内还回去。第三，降本和提质在大多数情况下不冲突，冲突的是”用降本的名义做没有依据的假设”。

如果你现在正准备启动这件事，我会建议你做三件具体的事。先把过去三个月的账单按场景拆一遍，拆不到场景就先拆到接口，这一步能暴露出很多你自己都没想到的事实。然后把所有依赖大模型的场景列出来，逐个问一句”如果这个场景不接大模型，业务会怎样”，答案里会藏着一批可以直接砍掉的调用。再从最贵的那个场景挑一条链路，用高质量数据集的方法把它重做一遍，跑完评测再上线，作为样板。样板跑通了，再推全量，比一上来铺开十个场景有效得多。

工具层面不用追求大而全，能找到一条能持续运营的链路比一次性买齐功能重要得多。普元这条产品线我相对熟悉，从主数据到数据资产、数据开发、高质量数据集，再到 AI 问数和 BI 呈现，基本能覆盖前面几个阶段的动作，衔接起来比较顺。但工具只解决一半的问题，另一半是机制——有没有人盯单次调用成本，有没有月度复盘，有没有评测集这道闸门。这两样都到位了，成本优化这件事才算真正落地，而不是又一年的专项。

陈立航：看完最有共鸣的是”单次业务动作成本”这句。我们之前就是盯着 token 单价做考核，换了个便宜模型，结果输出变长、重试变多，总账反而涨了。后来改成按工单算成本才把问题找出来。

苏文静：想请教一下，如果业务方死活不肯做场景分级，觉得每个需求都重要，有什么办法破？我们这边的阻力主要来自这一块。

何鹏远：鱼骨图那张我直接截图发群里了。数据那条骨头确实是最粗的，我们做了两年数据治理才反应过来这件事跟模型成本有关。

林若彤：评测集版本化这个做法我认同。我们吃过亏，同一套提示词改了一次没留记录，后面出问题回溯了两周。现在也是强制留版本。

赵嘉铭：中小企业那一段说得挺实在。我们两百来人的规模，一开始也想搞全量入湖，被顾问劝住了，只做了三类主数据和一条核心链路，三个月就见到效果了。