成本测算模板

做AI项目预算时最常卡在「不知道表格里该填什么」：只写了模型单价，漏了重试、缓存、汇率和人工，最后数字对不上账。这篇给一份可以直接照抄的模板结构，逐项说明每个字段填什么、数据从哪取、什么时候这套模板不适用，让不同角色填出来的表能对得上。

做AI项目的预算，最麻烦的不是算不出来，而是每个人算的都不一样。业务同学写个调用量，技术同学写个模型单价，财务同学再叠一层汇率，最后三张对不上。问题通常不在算术，而在表格里没写清楚每格该填什么、从哪取数。

下面这份模板结构可以直接照抄。核心思路是先定四层骨架，再往格子里填字段，每个字段都写清楚归属人和取数位置。这样不同角色填出来的表能对得上，事后复盘也知道数字是从哪来的。

模板骨架：先定四层，再填格子

很多人一上来就拉一张大表开始填，填到一半发现口径乱了。正确的顺序是先把表格横向切成四层，每层只回答一类问题，填错也容易定位。这四层从上到下分别是业务量、单价、修正系数、占位成本。

业务量层

任务次数、单次平均输入输出长度、日均调用量；这是唯一需要业务方确认的部分，别让技术同学拍脑袋填

单价层

统一按每百万token或每次调用的口径落一格，多个模型就多列，别混在同一列里

修正系数层

缓存命中比例、重试比例、批量折扣、汇率与手续费，每项单独一行，方便事后调

占位成本层

人工审核、失败返工、监控与日志存储，长期占比不低，小团队最容易漏

逐列填法：每个字段对应谁填、从哪取数

骨架定好之后就进入填格子环节。这里最容易犯的错是凭记忆写单价，或者把官方价和中转价写进同一列。下面这张表把常见字段的归属和取数位置列出来，照着填基本不会串。

如果团队同时走官方API和中转，倍率与折算规则一定要单独一列，到 /price-watch 看当时的对比再落数。把两种来源写进同一列，后面根本没法判断涨价到底来自哪边。

按场景分档：三种颗粒度别用同一张表

同一个模板不能从头用到尾。项目处在什么阶段，决定了表格该粗还是该细。用错颗粒度，要么算不准，要么维护成本比省下的钱还高。

1. 验证期用粗表只算任务次数乘以平均token再乘以单价，够判断这条路走不走得通就行，别过早引入系数
2. 成长期用中表加上缓存与重试系数，按周复核用量，避免预估越跑越偏
3. 稳定期用细表拆到每个功能模块、每个模型，配合 /usage 做月度核对，能定位到是哪一块在涨

什么情况不适用：如果业务量本身波动极大，或者还处在频繁换模型试效果的阶段，精细模板的维护成本会高于收益，这时用粗表加区间估算更实际。精细模板适合调用结构稳定、能连续观察几周的团队。

填完之后：怎么核对、多久回填一次

表格填完只是开始。预估值和真实用量之间的偏差，只有通过回填才能发现。回填的频率和方式，直接决定这张表是活文件还是摆设。

• 上线后第一周就做一次回填，预估值和真实用量并排放，偏差大的字段标出来，多数偏差出现在重试率和输入长度上
• 每月按 /monthly-billing-reconcile 的思路做一次账单与模板对账，重点看修正系数行要不要调
• 给关键行设预算告警，超阈值时先分清是调用量涨了还是单价口径变了，两者处理方式完全不同
• 模板版本要留痕，改过哪一列、什么时候改的都记下来，下次复盘才知道数字为什么变

顺带说一句，模型单价是会变的，今天核过的数字过段时间就未必准。所以模板里凡是单价类字段，最好都标注取数日期和来源页面，到期就重新到 /official-api 核对一次，别让半年前的数字一直躺在表里。

另外，如果你的项目涉及多个供应商，建议把每个供应商单独放一张子表，最后只汇总总成本。这样某一家调价或者换供应商时，只需替换子表，不用动整张主表的结构。