让我动手的，是两条价格表
这阵子新模型是真密集。 Meta 在 9 月 2 日发了 Muse Spark 1.3，官方口径是编码能力超过 GPT-5.6 Sol、跟 Claude Fable 5.1 打平；它维持了上一代的定价，通过 Meta Model API 卖，每 100 万输入词元 1.25 美元、缓存命中输入 0.15 美元、输出 4.25 美元。
差不多同一时间，西班牙 Multiverse Computing 推了个 Quasar 438B，1M 词元上下文，价格是每 100 万输入 0.60 美元、输出 1.80 美元。
你把这两张价目表摆一块看就会发现一件事：输入输出不同价，缓存命中还有第三档价，模型之间又差着好几倍。 Meta 还特意强调 1.3 相比 1.2「工具调用次数减少约 20%、完成相同任务所需 token 减少 25%」——省 token 都成卖点了。
可问题是，当卖点是「省」的时候，说明大家都被花销这件事困住了。
我自己就属于被困住的那一类。手上几个小项目在调不同的 API，月底对账全靠翻面板，输入多少、输出多少、缓存命中占比多少，全是糊的。
换个模型省了 25% token 听着美好，但我连自己现在花在哪都说不清楚，谈何省。
面板给的数字，为什么不够用
很多平台的用量面板只给你一个总额，或者按天画根曲线。这对报销够了，对做决策不够。
我真正想回答的是这几个问题：这个月是哪个项目在烧钱？是输入 token 多还是输出 token 多？
如果输入占大头，那我该去优化 prompt 或者上缓存;如果输出占大头，那可能是让模型话太多了。再往下，同样一段业务逻辑，跑在 1.25 美元输入的模型和 0.60 美元输入的模型上，一个月差多少钱?
这些问题面板都答不了，因为它不知道你的业务分类，也不会帮你按模型价目表逐笔折算。这活儿只能自己记。
于是我决定给自己搭个最土但最实用的东西:每调一次 API,就把这次的 token 和折算成本落一条账。
表结构，我改了三版
第一版我图省事,只存了三列:时间、模型、总 token。跑了两天就后悔了——输入输出不分开,根本没法针对性优化,而且不同模型价格不一样,一个「总 token」乘不出正确的钱。
第二版拆成了输入 token、输出 token、缓存命中 token 三列。这里踩了个坑:缓存命中的输入是单独计价的(Muse Spark 1.3 是 0.15 美元,只有普通输入的零头),如果你把它混进普通输入里一起算,成本会虚高一大截。
所以缓存命中必须单独一列、单独一个价。
第三版我把价目表也存进了库,而不是写死在代码里。因为模型价格会变、会有新模型进来,把「每百万输入单价、缓存命中单价、每百万输出单价」做成一张模型价格表,记账那张表只存 token 数量,查询时再 join 折算。
这样以后 Quasar 这类新模型进来,加一行价格就行,历史账也能随时按新价重算。
最后落到 SQLite 上大概是两张表。一张 `model_price`:模型名、输入单价、缓存输入单价、输出单价、币种;一张 `usage_log`:时间、项目标签、模型名、输入 token、缓存命中 token、输出 token、备注。
成本这一列我没存死值,而是查的时候算,理由同上——价格会变,存死了就骗自己。
逻辑先在浏览器里跑通
折算逻辑本身不难,难在别把单位搞错。价目表都是「每 100 万词元多少美元」,所以每一笔的成本是 `(input/1e6)*in_price + (cache/1e6)*cache_price + (output/1e6)*out_price`。
我一开始就栽在漏了那个除以一百万,算出来的数字大得离谱,盯着看了半天才反应过来。
这种小逻辑我习惯先不碰数据库,直接用Python在线运行把折算函数敲出来,喂几组假数据进去,手算一遍对一遍,确认单价、单位、缓存分档都没错,再往下接存储。好处是改一行看一眼结果,不用来回部署,那个漏乘的 bug 就是这么当场揪出来的。
把函数验对之后,我又拿真实的价目数字试算了一把:同样一段任务,如果输入 8000、输出 2000 token,跑在 4.25 美元输出的模型上,和跑在 1.80 美元输出的模型上,单次差价立刻就出来了。这一步很治愈,因为你第一次能拿数字说话,而不是凭感觉觉得「好像有点贵」。
存进库、查出来
逻辑通了,就把数据接到 SQLite。建表、写入、按项目和模型做聚合查询,这些我都用SQLite编辑器直接把表结构和几条测试数据先铺进去,再回头写读写代码。
可视化地看着字段和样例数据调,比闷头写 SQL 猜结果踏实,尤其是核对缓存命中那一列有没有被错误地并进普通输入里,肉眼一扫就知道。
查询这块我做了三个常用视角:按项目汇总(谁在烧钱)、按模型汇总(哪个模型性价比高)、按输入/输出/缓存拆分占比(该往哪个方向省)。第三个视角其实最有用。
Meta 说 1.3 能少用 25% 的 token,但对我来说,先搞清楚自己的 token 到底花在输入还是输出上,才知道这 25% 对我值不值得为它换模型。
有个细节值得提:输出 token 通常比输入贵好几倍(Muse Spark 1.3 是 4.25 对 1.25),所以如果你发现某个项目输出占比特别高,那让模型「少废话、给结构化结果」带来的省钱效果,往往比压缩输入更明显。这个结论不是我拍脑袋,是账本自己告诉我的。
包成一个随手能查的工具
光有脚本和库还是麻烦,每次都得手动跑。我把记账写入和三张汇总查询包成了一个在线工具,记一笔就填个表单,查账就点一下看聚合结果,不用再开编辑器敲命令。
对我这种人来说,能不能「随手查」直接决定了这工具会不会被用下去——太麻烦的东西,记两天就荒废了。
如果你想再进一步,把 API 调用侧改成每次请求完自动把返回里的 token 用量回写这张表,记账就彻底不用手动了。不过要提醒一句:这类记账工具里存的是你的用量数据,如果做成对外可访问的服务,记得加上访问控制,别让自己的成本明细裸奔在公网上。
说到底,这是给决策用的
模型一周一发、价格一家一个数,这个节奏短期看不会停。你没法追着每个新模型去评测谁强,但你可以让自己的每一分钱都有账可查。
有了这张账本,再看到「省 25% token」「输入只要 0.60 美元」这类卖点时,你能立刻换算成自己项目里的真实差额,而不是被营销话术推着走。换不换模型、优化输入还是收敛输出,都变成有数字支撑的选择。
工具很土,几张表加几个查询而已,但它把「我好像花得有点多」变成了「我这个月在这个项目的输出上花了多少、换个模型能省多少」,这一步,值。