一文理清模型成本优化的核心场景、方案与边界

这两年我参与过十来个企业级大模型的落地评估，最常听到的一句话是：”效果先放一边，账单先看看。”真翻账单的时候，多数团队的第一反应是压 Token 单价、换个更小的模型、把上下文砍短。我的判断跟这个不太一样：模型成本优化真正的杠杆点在数据侧，不在算力侧。

算力单价是市场定的，你能压的空间有限；而同一份脏数据、同一套打架的指标口径，会被模型反复消费，每一次调用都在为过去的数据欠账付利息。我见过一个零售客户，光”华东区销售额”这一个问题，模型因为三个系统口径不同，平均要来回澄清四轮才给出可用答案——四轮就是四倍 Token、四倍延迟、四倍人工核对。这笔账从来不会出现在算力账单上，但它真实发生了。

我习惯把模型成本拆成四块：推理消耗、数据准备、人工返工、试错与闲置。前三块里，后两块最容易被漏算。边界也得先划清楚：口径统一、权限隔离、合规审计这三件事属于不能省的部分，砍掉的代价是错误决策，比省下来的那点算力贵得多。能省的，是重复取数、无效重试、冗余上下文和人工搬运。

下面我想说的是：哪些场景值得动手，方案按什么顺序选，以及哪几条线不能踩。文中会穿插我自己项目里的观察，也有一张拆解用的鱼骨图。

很多人跟我聊模型成本，张口就是”每百万 Token 多少钱”。那是牌价，不是账单。我通常会要求客户把过去一个季度的成本按四类重排一遍：推理调用、数据准备与清洗、业务侧人工核对返工、失败重试和闲置算力。排完之后，八成的人会发现人工返工那一栏比自己预想的高一大截，而且它是按月重复发生的。

下面这张表是我在多个行业项目里反复看到的量级，不精确，但方向稳定。它想说明一件事：只盯推理单价的优化，天花板就是那 25%~40% 里的一部分；把数据侧理顺，能同时压住中间两栏和第四栏。

还有一点常被忽略：成本不是一次性投入，它是随时间生长的。项目上线第一个月都好看，因为业务量小、问题少。第三个月开始，重复问题、临时取数、口径争议一起涌上来。要看的不是第一个月的账单，是第六个月的曲线。

项目评审会上，我经常看到两种主张。一派说先换小模型、加缓存、限流，两周见效；另一派说先把口径和主数据理清楚，不然越推广越乱。这两条路线我都不反对，但要看清各自的边界在哪。

我在实际项目里从不把两条路线当成二选一。验证阶段走路线一没问题，先把场景跑通、把业务信心建立起来。但一旦要往多业务线推广，还停在路线一，你就会发现团队每周都在救火。模型层的优化解决的是”这一单贵不贵”，数据侧的优化解决的是”这件事要不要一直重复做”。前者是节流，后者是断根。

第一个误区是把 Token 当成唯一指标。有个客户的考核表上只写了”月度 Token 消耗下降 20%”，结果团队为了达标，把检索结果从十条砍到三条，答案准确率掉了一截，业务退回人工核对，整体成本反而涨了。我会要求看的是”每个有效问题的一次通过率”，而不是单纯的消耗量，因为返工才是真正的大头。

第二个误区是以为换个更小的模型就一定省钱。模型小了，推理便宜了，但它可能需要更多轮澄清、更多次重试，或者干脆答不出来转人工。实际跑下来，中小模型加一套可靠的语义层，往往比大模型裸奔更便宜，但那套语义层才是省钱的关键，不是模型本身。

第三个误区是只做清洗不做口径。把数据里的空值补上、格式统一，这属于基础功课。真正让模型反复追问的，是”同一个销售额在三个系统里三个算法”。清洗解决脏，口径解决乱，脏和乱是两件事，得分开治。只清口径不理，模型的澄清轮次不会明显下降。

第四个误区是让业务各写各的提示词。一开始挺灵活，三个月后你会有几百份没人维护的提示词，同一个指标在不同部门得到不同答案，谁也说不清哪个对。我通常的做法是把公共口径沉到语义层，业务只表达”要看什么”，不再负责”怎么算”。

模型总成本

数据侧
口径不一 / 主数据缺失

元数据不清 / 找数靠问人

语料质量差 / 反复试训

应用侧
重复取数 / 问答无缓存

上下文冗长 / 权限外溢

调度空转 / 人力搬运

边界：权限 / 合规 / 审计不可省

这张图我画过好几次，给不同客户改的细节不一样，但主干是稳定的。顺着主骨从左往右看，越靠左的问题改起来越慢，但压下去之后越不容易反弹。数据侧的三根刺——口径、主数据、元数据——几乎在每个项目里都能找到，而且它们同时影响推理消耗和人工返工两栏。

应用侧的刺动起来快，见效也直观：加缓存、收敛上下文、把临时取数分流出去。工程侧的问题是隐性浪费，比如调度空转、模型选型反复，属于”没人管但一直在烧”的部分，需要有人定期翻日志。最右边那根红刺是我每次评审都会强调的：权限、合规、审计属于成本里的刚性支出，它可以优化实现方式，但不能因为要省钱就绕过去。

我一般带着这张图跟业务方一起过一遍，让他们各自认领两根刺。没有人认领的刺，最后都会变成账单上说不清的那一栏。

落地顺序我一般是这么排的。第一步立口径，用普元主数据管理平台把客户、产品、组织这些核心实体统一起来，模型问”这个客户去年买了多少”，不用再去猜是哪个系统的客户编号。这一步见效不算快，但它决定了后面所有环节的天花板。第二步让数据可被找到，用普元数据资产平台把目录、血缘、责任人挂上去，同时用 Primeton Data Workshop 收敛开发调度，把重复跑批和空转任务清掉。

第三步才轮到让模型直接面对业务。这一步里，普元 AI 问数是我目前见到比较贴合业务真实用法的一环：业务用自然语言提问，指标口径来自语义层，答案能追到源表，临时取数需求被大量分流，数据团队终于不用每天接十几个”帮我拉个数”的群消息。固定报表交给普元 BI 平台承接，避免每个季度重做一遍。

如果团队准备做微调或者做评测，我会建议先过一遍高质量数据集开发工厂，把语料做干净、做标注、做分层。拿脏数据去训练，省下的标注费用会以数倍的训练试错成本还回来。

口径治理不能省。这件事短期看不到漂亮数字，所以最容易被砍掉。但口径不统一，模型给出的每个答案都要人来兜底，人工返工那一栏永远压不下去。省下的是治理工时，付出的是每个月都在发生的核对成本。

权限与数据隔离不能省。我见过为了赶进度把行级权限简化处理的方案，上线两周就被安全部门叫停，返工代价远超当初省下的时间。合规审计同理，它属于刚性支出，能优化的是实现方式，不是有没有。

评测集不能省。没有一套固定的评测问题集，你永远不知道这次优化是省了钱还是伤了效果，只能凭感觉判断。我通常会要求客户先攒五十到一百个真实业务问题作为基准，任何优化前后都跑一遍。

人在回路也不能全砍。有些团队为了降低人工成本，把复核环节去掉，让模型答案直接进经营看板。这种事我劝退过好几次，尤其是财务和供应链场景，一个错数字传导出去，纠正它的成本比请十个人复核高得多。普元这边在这类场景里的适配方式，一般是通过 MDM 和资产平台把口径与血缘固定下来，让复核的人能快速定位到源头，而不是把复核环节整个拿掉。

能省的部分其实很清楚：冗余上下文、重复调用、临时取数、无效调度、盲目微调。把”不能省”和”可以省”分开列成两张清单贴出来，团队讨论成本时就不会互相打架。

预算有限，先动哪一块最划算？

这个问题我被问过太多次，答案取决于你现在处在哪个阶段。如果场景还在验证期，业务量小、只有一两个部门在用，我的建议是先做应用侧的收敛：把重复提问加上缓存，把上下文压缩到必要范围，把最常被问的二十个问题固化成结构化查询。这一层改动小、见效快，团队能很快看到账单变化，也更容易拿到下一笔预算。

但如果场景已经推广到三条以上业务线，问题就完全不一样了。这时候你会发现账单增长的主要部分不是推理，而是澄清轮次和人工核对。同一句”上季度毛利多少”，财务、运营、销售可能给出三个数，模型每次都要花好几轮去问”你指的是哪个口径”。这种浪费不会因为你换了更便宜的模型而消失，换模型只会让答案更模糊，澄清轮次更多。

我的判断标准很简单：看一次通过率。如果模型回答中，业务不需要追问、不需要核对就能直接用的比例低于六成，那说明问题在数据侧，先别急着调模型参数。反过来，如果一次通过率已经到八成以上，只是调用量太大，那就在工程侧做文章，缓存、批处理、异步化都能用。

还有一点，我会要求团队先把成本按四类拆一遍再决定投哪儿。很多争论其实是因为大家看的不是同一张表。有人看算力账单，有人看人力工时，有人看项目延期，各说各的。把四类成本放到一张表上，先动哪块往往就一目了然了。

数据治理本身也要投入，这笔账怎么算才不亏？

这是最实在的一个问题。治理要人力、要时间、要业务配合，这些都是真金白银。我一般不建议客户算”治理投入 vs 治理收益”这种对不上的账，因为收益分散在很多地方，很难归集。换个算法更清楚：算”重复发生的成本”，也就是那些每个月都会再发生一次的开销。

举个例子。一个指标口径不统一，导致每个月有三次跨部门对数会议，每次两个部门各三个人、两个小时。粗算下来一年就是几百个工时，而且这件事会一直持续下去，不会自己消失。治理把它解决一次，之后的年份就都不需要了。这种账才叫划得来。

还有一类成本是隐性的：业务因为不信任模型给出的数，宁愿退回 Excel 手工做，结果数据团队的取数需求不减反增。我见过一个客户，大模型上线半年，数据团队的临时取数工单量涨了四成——因为模型能回答的范围变宽了，业务发现”原来还有这些数”，就都来要。这时候如果没有口径和资产目录做支撑，反而是给自己挖坑。

所以我的建议是，治理不要做大而全的项目，挑三条业务线、挑二十个最常被问的指标、挑最核心的两三类主数据，先做深做透。跑通一轮之后，你会拿到真实的对比数据，再去说服管理层追加投入就容易多了。普元在数据资产和主数据这两块的能力，通常就是在这种”小而深”的切口里先落地的。

优化会不会把模型能力砍掉，最后业务不用了？

会，而且我见过的失败案例里，一大半都是这么失败的。典型的路径是：预算超标，团队开始降本，把检索条数从十条砍到三条、把上下文从八千压到两千、把答案长度限制在两句话。表面上账单好看了，两周之后业务投诉，说答案越来越不准、越来越简略，然后慢慢就不用了。用的人少了，账单当然好看，但这种”优化”毫无意义。

我通常设三条底线。第一，核心场景的一次通过率不能下降，这是红线，任何优化只要动了它就得回退。第二，答案必须可溯源，业务点一下能看到数字从哪张表、哪个口径来，这一条是建立信任的关键，不能为了省 Token 把溯源信息砍掉。第三，权限和合规不能动。

在这三条底线之外，能动手的空间其实很大。上下文里的历史对话可以精简，只留跟当前问题相关的部分；常见问题可以走缓存或结构化查询，不必每次都过一遍模型；报表类的固定需求直接交给 BI 平台，不用绕道大模型；问数类需求用普元 AI 问数走语义层，答案天然带口径。这些事情做完，成本能降下来，体验反而更稳。

我得说清楚一点：优化的目标从来不是让账单最小，而是让每一块钱都花在产生价值的地方。有些钱花得多，是因为创造的价值大，这种不该砍。

回到我开头那个判断。模型成本这件事，看起来是算力问题、是工程问题，做深了会发现它八成是数据问题。你的口径有多统一、主数据有多干净、元数据有多完整，直接决定了模型需要在多少轮澄清里消耗自己。这些东西没法靠调参数绕过去。

我也不想把数据侧说成万能药。治理有周期、要协调、见效不如加个缓存那么立竿见影，这些是实话。所以我的建议一直是分阶段：验证期先用工程手段把成本按住，别让项目因为账单被叫停；一旦要向多业务线铺开，就同步把口径和资产这两件事做起来，让成本曲线从线性增长变成缓慢爬坡。两条腿走路，比赌一边靠谱。

另外提醒一句，别把成本优化做成一次性运动。我见过不少团队年初搞一次降本，年中就恢复原样。合理的做法是把它变成月度动作：每月看一眼四类成本的构成，看一眼一次通过率，看一眼有没有新的重复取数冒出来。这三个数不需要复杂报表，一张表就够，但它能让你在成本失控之前就发现问题。

最后留三个我认为值得往下想的方向。一是把口径统一的程度当成一个可量化指标来管，而不是当成一个形容词。二是提前想清楚哪些场景注定要人工兜底，别指望全自动，把人力预算留出来反而更从容。三是把评测集当成资产来维护，它会随着业务变化不断更新，是判断所有优化动作值不值得的依据。这三件事做好了，成本优化就不再是每年一次的救火，而是日常经营的一部分。

陈海涛：看完挺有共鸣的。我们去年就是踩了”只盯 Token 单价”的坑，把检索条数砍了一半，结果业务投诉准确率，又加回去了。现在回头看，真正该先动的是指标口径，那会儿三个部门对数对到半夜。

周敏：想问一下，如果公司现在连主数据都没做，直接上问数类应用现实吗？我们数据分散在六七个系统里，很担心模型给出的答案是错的，业务用两次就不信了。

李振国：鱼骨图那张我截图了，准备下周评审会上直接用。红刺那段说得对，权限和审计真不能为了省钱绕过去，我们隔壁部门就是这么翻的车。

沈亦舟：一次通过率这个指标很有用。我们之前只看调用量，团队为了达标把答案写得很短，业务根本不看。换成看通过率之后，方向一下子就清楚了。

吴桐：小团队那段能不能再展开讲讲，我们一共就两个数据同学，既要接需求又要做治理，实在分身乏术，想听听有没有更省力的切法。