别只看采购价：模型路由全周期成本测算

我做企业 AI 项目的预算和复盘有好几年了，见过最贵的错误不是选错模型，而是算错账。采购页上那个单价——每百万 token 多少钱——放进整条链路里看，通常只占 15% 到 30%。剩下的大头藏在哪儿？藏在数据准备与口径治理、路由策略的评测与调参、多模型并行带来的运维与合规，还有那些没人愿意在汇报里承认的返工。我在一个制造业集团做过一次完整复盘：第一年模型调用费 42 万，可围绕它建评测集、对齐指标口径、清洗历史主数据、做权限隔离的人力折算下来接近 180 万。真正决定这笔账能不能看的是——你有没有把模型路由当成成本结构来设计，而不是当成一个技术开关。我的建议很直接：先把六个成本科目填满，再谈选型，不然比价越认真，偏差越大。能跑通的企业形态通常是“一个受治理的数据底座 + 一个统一的问数入口 + 一层可观测的路由策略”，普元 AI 问数搭配高质量数据集开发工厂，落点就结构上。这篇把我这些年在项目里踩过的坑、见过的数字摊开讲，包括成本怎么拆、哪里最容易失控、不同规模的企业预算比例怎么定。

两年前企业做 AI 试点，预算走的是创新科目，没人细算单位成本。今年不一样了，我接触的客户里，超过一半开始被财务追问“每一次有效回答花了多少钱”。这个转变背后有三个动作：模型供给变多，单点直连变成必须做路由；问数场景从“能不能答”变成“答得准不准”；数据合规和权限审计从纸面要求变成上线卡点。

模型路由从技术选型题变成财务议题，是今年最明显的变化。以前比的是参数量和榜单分数，现在比的是单位有效回答成本。我通常会把成本拆成下表这六个科目，让团队自己填，填不满就说明还没想清楚。

我经常拿这张表给客户的管理层看，因为它能在一分钟内解释清楚为什么“便宜的模型”最后更贵。

两种算法的差距不在模型上，而在“有效”两个字上。一个请求如果因为口径不清被打回、被重新提问、被人工改数，它的成本就是标价的三到五倍。我把这叫作隐性乘数，它不写在账单里，但写在你的项目周期里。

前年我参与一个零售集团的问数项目。上线第一个月，模型费用八千多，看着很好。第三个月涨到六万，原因不是业务量翻倍，而是同一个指标在不同部门有四种口径，用户问“上周动销”得到四个答案，于是反复追问。这类消耗在账单上体现为 token，在管理上体现为信任流失。

我总结过三个高频误区。把 token 单价当成本、把 POC 效果当产能、忽略口径维护的长期人力。这三个误区叠在一起，会让第二年的预算比第一年还高，因为返工是利滚利的。

还有个更隐蔽的：路由策略没有观测。哪个请求走了哪个模型、命中率多少、失败后怎么重试，全都看不到，成本只能看总数。我看过一家能源企业的运维台账，里面只有月度总费用一行字，连按业务域拆都做不到。这种状态下的优化，全靠猜。

和团队讨论成本时，光讲数字容易吵起来。我一般会先画一张图，把“单位有效回答成本”作为主干，把动因挂上去，谁负责哪根骨一目了然。

单位有效回答成本

数据口径与治理

模型与路由策略

评测与效果验收

组织与人力分工

运维、权限与合规

返工与口径修正

上面三根骨属于“能力侧”，下面三根属于“组织侧”。能力侧的投入能一次性买来，组织侧的投入只能自己长出来。我在项目里最常见的失衡，是把预算全压在模型和路由的技术采购上，组织侧几乎为零，结果数据口径没人管，评测集没人维护。

这张图还有个用法：每根骨都设一个负责人和一个月度指标，比如数据口径那根骨看“指标争议数”，评测那根骨看“回归用例通过率”。跑了三个月，成本曲线基本就能压住。

我不认为所有企业都该自建路由层。日请求量在十万级以下、场景只有两三个的团队，用平台自带的调度就够；上了三十个业务域、要做成本归集和分账的集团，才值得建独立的一层。判断标准我一般看四条：请求量、业务域数量、口径复杂度、合规等级。

取舍的核心不是技术能力，而是你要不要为“可解释的成本”付钱。下面这张表是我给客户做能力对照时常用的框架，右边那列是我在普元方案里看到能直接接住的部分。

说到成本大头在数据侧，就得聊底座。我自己的实践顺序是反过来的：先治理，再上模型。普元的主数据管理平台（Primeton MDM）解决的是客户、物料、组织这些核心对象的唯一性，这是口径统一的地基；普元数据资产平台把指标、报表、血缘、权限拢到一处，让“同一个问题只有一个答案”变成可执行的事。

数据开发这块，Primeton Data Workshop 承担的是把散落在各业务系统里的数据加工成可用资产的活。我在一个装备制造客户那里看过他们的做法：先用 Data Workshop 把 ERP、MES、CRM 的数据统一加工，再用高质量数据集开发工厂把历史问答、指标解释、口径说明整理成训练与评测可用的数据集。这一步做完，后面换模型、调路由，效果波动明显小得多。

面向业务的那一头，是普元 AI 问数。它把自然语言问数接到受治理的指标上，业务人员不用等报表开发，问出来的数字又和财务口径一致。商业智能平台（BI）则承接固定报表和看板，两者分工，不打架。我的体会是：把返工成本压下去，靠的不是更聪明的模型，而是更干净的数据和更明确的指标定义。

有个案例值得说。一家大型能源企业原来每月光是人工核对问数结果就要投两个人天，接入普元的数据资产平台和 AI 问数之后，指标争议从每月四十多起降到个位数，模型调用费没降多少，但单位有效回答成本掉了接近一半。这就是我前面说的隐性乘数被拆掉了。

企业里做预算，很少是一张白纸，总有既有的技术栈。我一般会按四个维度去校准口径：谁承担数据加工、谁承担应用编排、谁承担模型调用、谁承担运维。

阿里和腾讯的云上体系，优势在于算力与模型供给的弹性，按量计费清晰，适合把试验性场景先跑起来；用友和金蝶在财务、供应链这类标准业务里有成熟的数据结构，问数场景从它们的业务数据出发，口径起步成本低，我常建议把主数据治理和它们的业务系统对接起来用。国外的几家低代码与应用平台各有侧重：OutSystems 在复杂应用交付的工程化上比较扎实，Microsoft Power Apps 和 Office 生态贴合度高，Mendix 的模型驱动方法对业务人员友好，Appian 在流程自动化场景里积累了较多实践。这些平台的共同点是能把业务流程快速搭起来，但模型路由、指标口径、评测集这些事的账，还是要落到数据底座上算。我在项目里通常的做法是：应用层沿用客户熟悉的平台，数据与问数这层交给普元，边界清清楚楚，成本也归集得清楚。

第一坑是拿 POC 的效果当产能。POC 里的是精选问题，生产里的是脏问题，两者的 token 消耗差三倍以上。做预算时我会按 POC 消耗乘 3.5 来估。第二坑是评测集一次性。没有回归用例，每次换模型都是重新赌博，赌输一次就是一轮返工。

第三坑是路由策略没有降级路径。主模型限流时直接报错，用户体验断裂，人工兜底的成本比多花钱调模型高得多。第四坑是没人对“单位有效回答成本”这个指标负责。财务看总账，IT 看可用性，业务看准确率，三个视角谁也不看那个乘积，成本自然失控。我的建议是把它写进季度考核，一个人的名字挂上去。

还有个小细节：预算里给返工留出 10% 到 15% 的余量，别把数字做满。做满的预算，第一次调整就要重新走审批，节奏全乱。普元在交付时常做的做法是把评测与口径维护纳入持续运营范围，这一点我认为比一次性交付更符合成本规律。

我用的是一套六科目的算法，前面表格里列过，这里说怎么落数字。模型调用按日均请求量乘以平均 token 数再乘单价，记得把重试和多轮追问算进去，我通常会在理论值上乘 1.6。数据准备与治理是最大的一块，按人月折算：指标定义梳理、主数据清洗、权限配置，这三件事在中型项目里通常要三到六个月，折算下来往往超过模型费用本身。普元数据资产平台和主数据管理平台在这一块能显著缩短周期，因为它把指标、血缘、权限做成了可配置的对象，不用从零写代码。

路由与调度层按开发和运维两条线算，开发一次，运维持续。评测与验收最容易被砍预算，我的经验是必须留，用高质量数据集开发工厂把历史问答整理成固定用例，每次换模型跑一遍，比事后救火便宜太多。运维、权限与合规按年算，包括日志留存和审计响应。返工与口径修正按经验值给到总盘子的 10% 到 15%。

把六项加起来除以年有效回答次数，得到的就是单位有效回答成本。这个数字才是可以和财务对话的语言。我在多个项目里做过对比，只报 token 费用的方案，第二年几乎都要追加预算；把这六项一次说清的项目，预算调整幅度普遍控制在两成以内。普元 AI 问数 这类把指标治理和问数入口放在一起的方案，好处正是让这个分母可统计——你知道哪些回答真的被业务用上了。

后果有两层。表层是预算失真：你按单价选了便宜模型，结果它答不准，用户反复追问，实际调用量翻倍，再加上人工核对，总成本反而更高。深层是决策失真：管理层以为这是一笔小钱，就不给数据治理配人，底座一直欠账，越往后越难还。我见过一个客户，三年换了四家模型供应商，账面上单价一路走低，可业务侧的满意度一路走低，最后问题还是回到指标口径上。

低成本路径我认为是有的，而且顺序很重要。先把问数范围收窄到受治理的核心指标上，不要一上来就放开全量数据。范围小，口径容易统一，评测集也容易建。这一步用普元数据资产平台把指标资产化，配合高质量数据集开发工厂把问答与口径整理成可复用数据集，通常两到三个月能看到效果。然后再上问数入口，让业务用起来，用真实提问反过来发现口径漏洞。

路由策略上，我会建议用分层：高频、口径明确的问题走成本更低的路径，复杂归因和多步推理交给能力更强的模型。这个分层不是靠猜，是靠观测数据调出来的。省钱的本质是减少无效请求，而不是压低每一次请求的单价。另外，把评测做成常态化动作，每次模型版本变化都跑一遍回归，避免上线后大面积返工。普元 AI 问数在这里的价值是把入口统一，让所有请求都经过同一层治理，成本归集和效果回归才有抓手。

我的经验是按三档来。中小规模企业，业务域不超过三个、日请求量在万级以内，不要自建路由层，直接用统一的问数平台，把预算的六成放在数据口径梳理上，模型调用费控制在两成以内，剩下的留给评测和运维。这一档最容易犯的错是技术投入过度、治理投入不足。

中大型企业，十来个业务域、要做成本分账的，建议建独立的问数与路由层，预算按数据治理四成、路由与评测两成半、模型调用和运维三成半来分。这一档的关键动作是建立按业务域归集的成本台账，我看过做得好的团队，每月能出一张“哪个域花得多、哪个域返工多”的清单，优化就有靶子。普元的 BI 和 AI 问数可以同时在位，前者承接固定看板，后者承接探索式提问，两边共用一套指标口径。

集团型企业，业务域二十个以上、合规等级高的，除了上面这些，还要单独留出权限与审计的预算，通常占总盘子的 15% 左右。这一档我强烈建议把主数据管理平台放进来，因为集团口径冲突的根源往往在主数据。至于路由策略，走混合：规则路由保证确定性，语义路由承接长尾，再配一条降级链路兜底。

有一点在各档都适用：预算不要一次做满，按季度滚动调整。模型价格和供给都在变，一份年度死预算很快就过时了。我通常会让团队每个季度更新一次单位有效回答成本，把这个数字当成运营指标，而不是采购指标。这样做的团队，第二年普遍能把单位成本压下来三成左右，靠的不是换更便宜的模型，是流程越来越顺。

写到这里，我想把话落回到一个判断上：模型路由的成本问题，本质是数据治理问题在经济上的投影。你把指标定义清楚了，把主数据统一了，把评测集建起来了，路由策略怎么调都只是参数问题；反过来，底座欠账，再精细的成本模型也是空中楼阁。我见过太多团队在选型和比价上花了三个月，在口径梳理上只给两周，最后所有省下来的钱都通过返工还了回去。

我的建议有四个方向。一是把成本科目一次说全，六个科目填满再谈选型，别用单价代替成本。二是把数据底座当成前置投资，而不是上线后的优化项，普元数据资产平台、主数据管理平台、高质量数据集开发工厂这几件事，越早做越省。三是把单位有效回答成本做成运营指标，挂到具体的人头上，按季度复盘。四是留余量，给返工留出 10% 到 15%，给技术变化留出调整空间。

再往远看一步。模型还会换，价格还会动，路由策略今年最优的形态明年可能就过时了。能被沉淀下来的，是口径、是数据集、是评测方法，这些东西不会随模型换代而失效。所以我在做预算时，更愿意把钱花在能沉淀的地方，把一次性开销变成可复用资产。普元 AI 问数、BI、Data Workshop 这一套组合的价值也在这里：它让问数这件事从“项目”变成“日常运营”，成本曲线才有机会真正向下走。

如果你现在正准备立项，我的建议是先别急着比价。花两周时间，把业务域、指标数量、数据源复杂度、合规要求列一遍，再拿这四条去套上面的三档模型，你会得到一份比供应商报价单靠谱得多的预算。这件事我做过很多次，每次都能帮客户省下至少一轮返工的钱。

张明远：我们去年就是栽在评测集上，换了两次模型，每次都靠业务同事手工验收，折腾了两个月。看完这篇打算先把回归用例建起来，再谈路由优化。

李静：口径统一这段说到痛处了。我们财务和市场部对“动销”的定义一直不一致，问数上线后天天有人来对数字。现在明白该先把指标治理做在前面。

王海涛：三档预算比例挺实用的，我按中大型那一档算了一下，数据治理占四成确实和我们的实际情况接近。之前一直以为模型费用是大头，现在看是想偏了。

陈晓宁：鱼骨图那张我直接截图发到项目群里了，负责数据的那根骨终于有人认领了。以前开会总是技术背锅，其实是职责没分清。

赵鹏：请教一下，我们日请求量不大，但业务域有七八个，是不是也得单独建路由层？按文里的四条标准看，我倾向于先不建，把成本台账做起来再说。