1.73亿token账单拆解：Agent调用大模型API的成本计算与优化

1. 一笔1.73亿token的账到底该怎么算九月份我用WorkBuddy跑了一整个月的高强度任务月底看后台统计的时候输入加输出合计烧掉了1.73亿token。这个数字刚跳出来的时候我自己也愣了一下——平时聊token用量都是几百万、几千万的量级上亿这个单位一出来第一反应就是这要是按官方原价结算得多少钱。WorkBuddy这类工具本质上是个Agent调度层它自己不生产模型而是把用户的指令拆解成任务流再通过API转发给背后的模型去执行。所以烧token这件事烧的其实是背后模型的调用量。你看到的1.73亿是输入token和输出token的总和而这两者的计价方式完全不同缓存命中的部分又有单独的折扣价这就导致同样一个总量不同的使用结构算出来的钱能差出好几倍。这篇文章我想干的事很具体把这1.73亿token拆开按主流模型的官方定价一笔一笔算清楚到底要花多少钱。同时把缓存命中率、输入输出比例、模型选型这几个真正影响账单的变量讲透。如果你也在用WorkBuddy或者类似的Agent工具或者你正在评估自建AgentAPI和直接买订阅哪个更划算这篇的算法和思路你可以直接抄。先给个结论性的锚点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-4倍缓存命中率升高显著降低命中部分输入价打1-2.5折轻量模型分流比例升高显著降低轻量模型单价低一个数量级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元差了将近三倍。这就是结构优化的威力。下面用表格把三个场景并排对比场景缓存命中模型分流估算费用相对最坏情况场景一0%无约4152元100%场景二70%无约2989元72%场景三70%/50%60%轻量约1461元35%注意以上单价是行业代表性档位不是某一家厂商的精确报价。你自己算的时候把单价替换成你实际使用模型的官方价即可计算逻辑完全一致。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用量突然暴涨怎么排查这是我最常遇到的问题。某天发现用量比平时高了好几倍第一反应是是不是被刷了但实际排查下来通常是这几个原因现象可能原因排查方法输入token暴涨上下文累积没清理检查是否把历史对话全量带上了输出token暴涨输出约束失效检查自定义指令是否被覆盖缓存命中率骤降前缀被动态内容污染对比请求前缀是否字节一致调用次数暴涨任务陷入重试循环查看是否有失败重试逻辑我遇到过一次典型的某个任务因为返回格式不符合预期触发了Agent的自动重试结果同一个请求重试了十几次一天下来多烧了两千多万token。后来在重试逻辑里加了次数上限和失败熔断这类问题就再没出现过。5.2 缓存命中率上不去怎么办缓存命中率低八成是前缀不稳定。排查步骤抓取连续几次请求的完整payload逐字节对比前缀部分检查系统提示词里有没有混入时间戳、随机ID、动态排序的内容检查工具定义的顺序是否固定确认服务端是否真的支持前缀缓存有些模型或部署方式不支持我见过一个很隐蔽的坑系统提示词里有个工具列表代码里用了一个无序的字典去生成导致每次序列化出来的工具顺序都不一样前缀自然对不上缓存全部miss。改成固定顺序后命中率立刻上去了。5.3 怎么判断该不该上旗舰模型一个简单的判断方法把同一个任务分别用旗舰和轻量模型跑一遍对比输出质量。如果轻量模型的结果你能接受那就没必要用旗舰。很多任务其实对模型能力的要求没那么高是我们自己心理上觉得贵的就是好的。我的经验是真正需要旗舰模型的任务占比通常不超过30%。剩下70%用轻量模型完全够用质量差距在可接受范围内但成本差了一个数量级。6. 几个我实际用下来觉得值钱的技巧第一个技巧是关于缓存预热。如果你知道接下来要跑一批任务可以先用一个最小请求把系统提示词的前缀喂给服务端让缓存先建立起来后续的正式请求就能直接命中。这个操作在批量任务场景下能省不少钱。第二个技巧是输出token的预算控制。在自定义指令里明确写输出不超过X个token比事后去截断要有效得多。因为模型在生成时就会倾向于精简而不是生成一大堆再被砍掉。第三个技巧是定期审计token结构。不要只看总量要定期把输入、输出、缓存命中、各模型调用量拉出来看趋势。我每个月会做一次这样的审计经常能发现一些悄悄涨上来的异常消耗及时调整。关于WorkBuddy和CodeBuddy这类工具的选型我的看法是如果你主要是做代码相关的任务CodeBuddy的默认配置可能更贴合如果是通用的Agent工作流WorkBuddy的自定义指令和skill机制更灵活。但不管用哪个token成本的控制逻辑是一样的——管好前缀、约束输出、分流任务这三件事做到位账单就不会失控。最后分享一个我自己的账单管理习惯我会给每个工作流单独打标签月底按标签汇总token消耗。这样能清楚看到哪个工作流是吞金兽哪个是性价比之王。有一次我发现一个每天定时跑的日报生成任务因为上下文没做清理每天都在累积历史记录token消耗逐日递增。加上上下文窗口管理后这个任务的成本直接降了80%。这种问题不看结构化的账单是发现不了的。