1. 一笔1.73亿token的账，到底该怎么算

九月份我用WorkBuddy跑了一整个月的高强度任务，月底看后台统计的时候，输入加输出合计烧掉了1.73亿token。这个数字刚跳出来的时候我自己也愣了一下——平时聊token用量都是几百万、几千万的量级，上亿这个单位一出来，第一反应就是"这要是按官方原价结算，得多少钱"。

WorkBuddy这类工具本质上是个Agent调度层，它自己不生产模型，而是把用户的指令拆解成任务流，再通过API转发给背后的模型去执行。所以"烧token"这件事，烧的其实是背后模型的调用量。你看到的1.73亿，是输入token和输出token的总和，而这两者的计价方式完全不同，缓存命中的部分又有单独的折扣价，这就导致同样一个总量，不同的使用结构算出来的钱能差出好几倍。

这篇文章我想干的事很具体：把这1.73亿token拆开，按主流模型的官方定价，一笔一笔算清楚到底要花多少钱。同时把缓存命中率、输入输出比例、模型选型这几个真正影响账单的变量讲透。如果你也在用WorkBuddy或者类似的Agent工具，或者你正在评估"自建Agent+API"和"直接买订阅"哪个更划算，这篇的算法和思路你可以直接抄。

先给个结论性的锚点：1.73亿token如果全部按某主流旗舰模型的官方标准价、零缓存命中来算，账单会落在五位数人民币的量级；但如果缓存命中率做到70%以上、并且把大量简单任务分流到轻量模型，实际成本能压到前者的三分之一甚至更低。这个差距从哪来，后面慢慢拆。

2. 先搞懂token计价的三个核心变量

2.1 输入token和输出token为什么不是一个价

几乎所有主流模型的定价表都是分开列输入价和输出价的，而且输出价通常是输入价的3到4倍。原因不复杂：输入token对模型来说是"读"，是一次前向计算里可以并行处理的；输出token是"写"，必须一个接一个自回归生成，每一步都要重新跑一遍注意力计算，算力消耗和延迟都高得多。所以模型厂商把输出定得更贵，本质是在为生成过程的算力买单。

这个差异对账单的影响极大。假设你的任务输入输出比是10:1（比如让模型读一篇长文档然后输出一段总结），那输出token只占总量的9%左右，但按4倍单价算，输出部分的费用占比会拉到接近30%。反过来，如果是开放式创作类任务，输入输出比接近1:1，那输出部分的费用占比会超过70%。所以算账之前，必须先搞清楚自己的输入输出结构，不能拿一个笼统的总量去乘单价。

2.2 缓存命中率是省钱的第一杠杆

缓存命中（cache hit）是这几年API计费里最重要的一个机制。原理是：如果你连续多次请求的前缀部分（比如系统提示词、固定的任务模板、同一份长文档）完全一致，模型服务端可以把这部分已经算过的KV缓存复用，不用重新计算。命中缓存的那部分输入token，价格通常只有标准输入价的10%到25%。

WorkBuddy这类Agent工具恰恰是缓存命中的重度受益者。因为Agent的系统提示词往往很长（工具定义、行为规范、输出格式约束），而且每次调用都带着同一套前缀，只要服务端支持前缀缓存，这部分就能反复命中。我实测下来，一个配置合理的WorkBuddy工作流，缓存命中率做到60%到80%是很正常的。这意味着光这一项，输入侧的成本就能砍掉一半以上。

2.3 模型分层决定了你的成本天花板

同一个任务，用旗舰模型和用轻量模型，单价能差10到20倍。WorkBuddy的价值之一就是它支持自定义指令和任务分流，你可以让复杂推理走旗舰模型，让格式转换、信息抽取、简单分类这类任务走轻量模型。1.73亿token里如果有60%是简单任务，把它们从旗舰模型挪到轻量模型，整体账单能直接腰斩。

下面这张表是我按常见定价结构整理的三个变量对成本的影响方向，先建立个直觉：

3. 把1.73亿token拆开算：三种典型场景的账单

3.1 场景一：全旗舰模型、零缓存的最坏情况

先算最贵的极端情况，作为成本上限的参照。假设1.73亿token全部走某旗舰模型，输入输出比按Agent任务的典型值8:2来分，也就是输入1.384亿、输出0.346亿，缓存命中率为0。

按当前主流旗舰模型的官方标准价，输入假设为每百万token 15元，输出为每百万token 60元（这是行业里比较有代表性的档位，具体数字各家不同，但比例关系接近）。计算过程：

• 输入费用：138.4 × 15 = 2076元
• 输出费用：34.6 × 60 = 2076元
• 合计：约4152元

等一下，这个数字看起来没有想象中那么吓人。原因是1.73亿token听着多，但拆到百万单位只有173个百万。真正让账单爆炸的从来不是总量，而是单价和结构。如果换成某些定价更高的旗舰模型，输入每百万30元、输出每百万120元，同样的量就是8300元。如果输出占比再拉高到50%，账单会进一步上浮。

所以"1.73亿token要花多少钱"这个问题，答案区间其实很宽，从三四千到上万都有可能，关键看你用的是哪个模型、什么结构。

3.2 场景二：缓存命中70%的现实情况

现实中的WorkBuddy工作流不可能零缓存。我把上面场景一的参数改一下：缓存命中率70%，命中部分的输入单价按标准价的20%算。

• 未命中输入：138.4 × 30% = 41.52百万，费用 41.52 × 15 = 622.8元
• 命中输入：138.4 × 70% = 96.88百万，费用 96.88 × 15 × 0.2 = 290.6元
• 输出费用不变：34.6 × 60 = 2076元
• 合计：约2989元

可以看到，缓存把输入侧从2076元压到了913元，但输出侧的2076元纹丝不动。这就是为什么我说输出token才是账单里最难啃的骨头——缓存救不了它，只能靠控制输出长度和模型分流。

3.3 场景三：叠加轻量模型分流的优化情况

再进一步，假设60%的任务分流到轻量模型，轻量模型输入每百万2元、输出每百万8元，剩下40%走旗舰。同时旗舰部分缓存命中70%，轻量部分缓存命中50%。

旗舰部分（40%的量，即输入55.36百万、输出13.84百万）：

• 未命中输入：55.36 × 30% × 15 = 249.1元
• 命中输入：55.36 × 70% × 15 × 0.2 = 116.3元
• 输出：13.84 × 60 = 830.4元
• 小计：约1195.8元

轻量部分（60%的量，即输入83.04百万、输出20.76百万）：

• 未命中输入：83.04 × 50% × 2 = 83.0元
• 命中输入：83.04 × 50% × 2 × 0.2 = 16.6元
• 输出：20.76 × 8 = 166.1元
• 小计：约265.7元

合计：约1461.5元。

从最坏情况的4152元到优化后的1461元，差了将近三倍。这就是结构优化的威力。下面用表格把三个场景并排对比：

注意：以上单价是行业代表性档位，不是某一家厂商的精确报价。你自己算的时候，把单价替换成你实际使用模型的官方价即可，计算逻辑完全一致。

4. WorkBuddy里真正影响token消耗的配置项

4.1 系统提示词的长度直接决定缓存基数

WorkBuddy的自定义指令功能很强大，你可以塞进去大量的行为规范、输出格式要求、工具使用说明。但这里有个反直觉的点：系统提示词越长，单次请求的输入token越多，听起来是坏事；可如果这套提示词是固定的、每次调用都带，那它恰恰是缓存命中的主力。长而稳定的前缀，比短而多变的前缀更省钱。

我的做法是把所有固定不变的内容——角色定义、输出格式模板、工具调用规范——全部前置到系统提示词里，确保每次请求的前缀字节级一致。任何会变的内容（用户输入、动态上下文）都放到后面。这样服务端的前缀缓存才能最大化命中。实测下来，光是保证前缀稳定这一条，缓存命中率就能从40%出头提到70%以上。

4.2 输出长度限制是最容易被忽视的省钱开关

前面算过，输出token单价高，而且缓存救不了。所以控制输出长度是省钱最直接的手段。WorkBuddy里可以在自定义指令中明确约束输出格式，比如"只输出JSON，不要任何解释性文字"、"总结控制在200字以内"、"不要重复用户的问题"。

我踩过的一个坑是：早期没做输出约束，模型特别喜欢在答案前后加一堆"好的，我来帮你分析"、"希望这个回答对你有帮助"之类的废话。这些客套话每个任务多烧几十个输出token，乘以几万次调用就是几千万token的浪费。加上严格的输出格式约束后，输出token量直接降了大概25%。

4.3 任务分流策略怎么设计才合理

不是所有任务都值得用旗舰模型。我的分流原则是这样的：

• 需要多步推理、代码生成、复杂分析的，走旗舰模型
• 信息抽取、格式转换、分类打标、简单问答，走轻量模型
• 需要长上下文理解但输出很短的，走支持长上下文的轻量模型

在WorkBuddy里可以通过不同的skill或者自定义指令来路由任务。关键是你要先统计一下自己的任务构成，看看哪些任务占了调用量的大头。很多时候你会发现，占了70%调用量的其实是那些最简单的任务，把它们分流出去，成本立刻下来。

5. 常见问题与排查技巧实录

5.1 token用量突然暴涨怎么排查

这是我最常遇到的问题。某天发现用量比平时高了好几倍，第一反应是"是不是被刷了"，但实际排查下来通常是这几个原因：

我遇到过一次典型的：某个任务因为返回格式不符合预期，触发了Agent的自动重试，结果同一个请求重试了十几次，一天下来多烧了两千多万token。后来在重试逻辑里加了次数上限和失败熔断，这类问题就再没出现过。

5.2 缓存命中率上不去怎么办

缓存命中率低，八成是前缀不稳定。排查步骤：

1. 抓取连续几次请求的完整payload，逐字节对比前缀部分
2. 检查系统提示词里有没有混入时间戳、随机ID、动态排序的内容
3. 检查工具定义的顺序是否固定
4. 确认服务端是否真的支持前缀缓存（有些模型或部署方式不支持）

我见过一个很隐蔽的坑：系统提示词里有个工具列表，代码里用了一个无序的字典去生成，导致每次序列化出来的工具顺序都不一样，前缀自然对不上，缓存全部miss。改成固定顺序后，命中率立刻上去了。

5.3 怎么判断该不该上旗舰模型

一个简单的判断方法：把同一个任务分别用旗舰和轻量模型跑一遍，对比输出质量。如果轻量模型的结果你能接受，那就没必要用旗舰。很多任务其实对模型能力的要求没那么高，是我们自己心理上觉得"贵的就是好的"。

我的经验是，真正需要旗舰模型的任务占比通常不超过30%。剩下70%用轻量模型完全够用，质量差距在可接受范围内，但成本差了一个数量级。

6. 几个我实际用下来觉得值钱的技巧

第一个技巧是关于缓存预热。如果你知道接下来要跑一批任务，可以先用一个最小请求把系统提示词的前缀"喂"给服务端，让缓存先建立起来，后续的正式请求就能直接命中。这个操作在批量任务场景下能省不少钱。

第二个技巧是输出token的"预算控制"。在自定义指令里明确写"输出不超过X个token"，比事后去截断要有效得多。因为模型在生成时就会倾向于精简，而不是生成一大堆再被砍掉。

第三个技巧是定期审计token结构。不要只看总量，要定期把输入、输出、缓存命中、各模型调用量拉出来看趋势。我每个月会做一次这样的审计，经常能发现一些悄悄涨上来的异常消耗，及时调整。

关于WorkBuddy和CodeBuddy这类工具的选型，我的看法是：如果你主要是做代码相关的任务，CodeBuddy的默认配置可能更贴合；如果是通用的Agent工作流，WorkBuddy的自定义指令和skill机制更灵活。但不管用哪个，token成本的控制逻辑是一样的——管好前缀、约束输出、分流任务，这三件事做到位，账单就不会失控。

最后分享一个我自己的账单管理习惯：我会给每个工作流单独打标签，月底按标签汇总token消耗。这样能清楚看到哪个工作流是"吞金兽"，哪个是"性价比之王"。有一次我发现一个每天定时跑的日报生成任务，因为上下文没做清理，每天都在累积历史记录，token消耗逐日递增。加上上下文窗口管理后，这个任务的成本直接降了80%。这种问题不看结构化的账单是发现不了的。