1. 一笔1.73亿token的账单到底该怎么算九月份我用WorkBuddy跑了一整个月的高强度任务月底看后台统计的时候愣了一下——1.73亿token。这个数字放在个人开发者身上不算小放在小团队里也算得上中等偏上的用量。当时第一反应就是如果这些token全部按官方标价走我到底要掏多少钱这个问题看起来简单乘一下单价就行但真动手算的时候你会发现坑不少。不同模型的输入输出价格不一样缓存命中与否价格差好几倍还有批量接口、上下文长度分档、推理模型的思考token计费方式等等。我前后花了两个晚上把账单逻辑彻底捋了一遍顺手把WorkBuddy里几个常用模型的计费口径也整理了出来。这篇文章就把这套算法完整拆开讲包括我实际跑出来的用量结构、缓存命中率的真实影响、以及最后算出来的那个数字。先给结论1.73亿token如果全部按官方原价、不做任何缓存优化、不分批、不挑时段按我九月份的实际模型配比算下来大约是2100到2600元人民币这个区间。但实际因为缓存命中率做到了六成以上加上一部分任务走了批量通道真实成本压到了900元出头。差距接近三倍这就是为什么值得认真算一算。这篇文章适合三类人看一是刚上手WorkBuddy、还没搞清楚token怎么计费的新用户二是用量已经上来了、想优化成本的中度用户三是单纯好奇大模型API账单结构的开发者。我会把计算过程、参数来源、缓存机制、以及我踩过的几个计费坑都写清楚你照着套自己的用量就能算出自己的账。2. 先把计费的基本盘搞清楚2.1 token到底是怎么被计费的很多人以为token就是字数其实不是。token是模型处理文本的最小单位一个中文字大约对应1到2个token一个英文单词大约1到1.3个token标点、空格、换行也都算。代码里的缩进、括号、变量名拆得更碎所以同样长度的代码和自然语言token数能差出三成。计费的核心逻辑是输入token和输出token分开算而且输出通常比输入贵。以我常用的几个模型为例输入价格大概是输出的三分之一到五分之一。这就意味着如果你让模型生成很长的内容成本会明显高于只是让它读一段长文本然后回答一个短问题。还有一个容易被忽略的点多轮对话里历史消息每一轮都会被重新计费。你和模型聊了十轮第十一轮的时候前面十轮的内容全部作为输入再算一遍。这就是为什么长对话的成本是加速上涨的不是线性增长。我在WorkBuddy里跑长任务的时候一开始没注意这个单次会话跑到后面token消耗快得吓人后来改成定期开新会话、把关键上下文用摘要方式带过去成本立刻降下来一截。2.2 输入、输出、缓存三种价格现在主流API的计费一般分三档计费类型说明相对价格输入未命中缓存全新内容首次送入模型基准价1x输入命中缓存与之前请求前缀完全一致的部分约为基准价的10%到25%输出模型生成的内容约为输入基准价的3到5倍缓存命中这一档是省钱的关键。它的原理是如果你这次请求的开头部分和之前某次请求完全一样服务端可以直接复用之前算好的中间状态不用重新计算所以价格大幅降低。前缀越长、重复次数越多省得越狠。我在WorkBuddy里跑批量任务的时候系统提示词和任务模板是固定的每次只有末尾的用户输入在变。这种情况下缓存命中率能到70%以上输入成本直接砍掉一大半。这也是为什么我最后实际账单比原价低那么多的主要原因。2.3 不同模型的单价差异有多大九月份我在WorkBuddy里主要用了三类模型一个通用对话模型、一个代码专用模型、一个推理模型。三者的价格差距相当大。通用对话模型最便宜输入大概每百万token几块钱输出十几块。代码模型稍贵输入每百万token十几块输出四五十块。推理模型最贵因为它会产生大量思考token这些思考token按输出计费输入每百万token可能二三十块输出能到上百块。我九月份的用量结构大致是通用对话模型占55%代码模型占35%推理模型占10%。但按成本算推理模型那10%的用量贡献了将近30%的费用。这个结构很典型很多人都是被推理模型的思考token悄悄吃掉预算的。提示推理模型的思考token在后台统计里有时候不单独列出会混在输出里。如果你发现某个任务输出token异常高但生成的内容并不长大概率是思考token在吃钱。3. 1.73亿token的账单逐项拆解3.1 用量结构还原先把1.73亿token拆开。根据WorkBuddy后台的统计九月份的总量分布是这样的输入token未命中缓存约5800万输入token命中缓存约9200万输出token约2300万加起来1.73亿。可以看到缓存命中的输入占了总输入的一大半这是好事。输出只占13%左右但因为输出单价高它贡献的成本比例远不止13%。按模型维度再拆一次模型类型输入token输出token占比按token通用对话约8200万约1100万54%代码专用约5300万约800万35%推理模型约1500万约400万11%推理模型的token量看着不多但它的输出里有相当一部分是思考过程实际计费输出可能比表面看到的400万更高。3.2 按官方原价逐项计算假设全部按官方标价、不考虑任何折扣我用的是以下单价单位元/百万token取常见档位模型类型输入单价缓存输入单价输出单价通用对话4116代码专用12348推理模型24696现在逐项算。通用对话模型未命中缓存输入假设其输入里60%命中缓存则未命中约3280万命中约4920万未命中输入成本3280万 × 4元/百万 131.2元命中输入成本4920万 × 1元/百万 49.2元输出成本1100万 × 16元/百万 176元小计356.4元代码专用模型同样按60%缓存命中未命中约2120万命中约3180万未命中输入成本2120万 × 12元/百万 254.4元命中输入成本3180万 × 3元/百万 95.4元输出成本800万 × 48元/百万 384元小计733.8元推理模型按50%缓存命中未命中约750万命中约750万未命中输入成本750万 × 24元/百万 180元命中输入成本750万 × 6元/百万 45元输出成本400万 × 96元/百万 384元小计609元三项加起来356.4 733.8 609 1699.2元。这是按我实际缓存命中率算出来的。如果缓存命中率为零全部按未命中输入算通用对话8200万×4 1100万×16 328 176 504元代码专用5300万×12 800万×48 636 384 1020元推理模型1500万×24 400万×96 360 384 744元合计2268元所以标题里问的“按官方价到底要花多少钱”答案取决于你怎么定义“官方价”。如果指完全不优化、不命中缓存的裸价是2268元。如果指正常使用、有缓存命中的实际价格是1699元。我实际支付的比1699还低一些因为有一部分任务走了批量接口批量通常有额外折扣。3.3 缓存命中率对账单的影响有多大缓存命中率是这里面对成本影响最大的单一变量。我做了个敏感性分析以通用对话模型为例输入8200万token输出1100万token缓存命中率输入成本输出成本总成本0%328元176元504元30%254.8元176元430.8元50%205元176元381元70%155.2元176元331.2元90%105.4元176元281.4元从0%到90%输入成本降了68%总成本降了44%。这个杠杆非常可观。而提升缓存命中率的核心方法就是保持请求前缀的稳定性系统提示词不要频繁改、任务模板固定、多轮对话里把不变的部分放前面、变的部分放后面。我在WorkBuddy里做的优化就是把这些固定内容抽出来做成模板每次调用只替换末尾的变量部分。改之前命中率大概35%改之后稳定在65%到75%之间。这一个动作九月份就省了差不多400块。4. WorkBuddy里怎么把成本压下来4.1 缓存友好的提示词结构设计缓存命中的前提是前缀完全一致。所以提示词的结构应该是“固定的在前变化的在后”。具体来说[系统角色定义] ← 固定永远不变 [任务说明和规则] ← 固定尽量不变 [输出格式要求] ← 固定 [少量示例] ← 固定 [本次具体输入] ← 变化放最后很多人习惯把具体输入放在前面或者把示例和输入混在一起这样每次请求从第一个token就开始不一样缓存完全命中不了。我一开始也犯这个毛病后来把结构调过来命中率立刻上去了。还有一个细节系统提示词里不要放时间戳、随机ID、会话编号这类每次都变的东西。哪怕只变一个字符从那个位置往后的缓存全部失效。我见过有人在系统提示词开头写“当前时间2025-09-15 14:32:11”这一行直接把整个缓存废掉了。4.2 批量任务的分批策略WorkBuddy支持批量提交任务。批量接口通常有折扣但更重要的是它能让你把相同前缀的请求集中处理进一步提高缓存命中率。我的做法是把任务按“前缀相似度”分组。比如所有需要同一套系统提示词的任务放一批所有需要另一套模板的放另一批。不要按时间顺序混着提交那样前缀来回切换缓存反复失效。分批的粒度也要注意。批太小缓存还没热起来就结束了批太大单次等待时间长而且中途如果出错重试成本高。我实测下来每批50到200个任务比较合适具体看单个任务的token量。单个任务输入在2000token以内的一批可以放到200个输入上万的一批控制在50个左右。4.3 模型选择的性价比权衡不是所有任务都需要用最贵的模型。我九月份做了一次模型降级测试把一批原本用推理模型跑的任务换成通用对话模型看效果差异。结果是对于结构化的信息提取、格式转换、简单分类这类任务通用对话模型的效果和推理模型差距很小但成本只有十分之一左右。真正需要推理模型的是多步逻辑推导、复杂代码调试、数学证明这类任务。所以我的策略是默认用便宜的模型只在确实需要的时候升级。具体判断标准任务是否需要多步推理否→通用模型输出是否需要严格正确否→通用模型是否涉及代码生成或调试是→代码模型是否需要解释复杂逻辑是→推理模型按这个标准过一遍我九月份有大概20%原本用推理模型的任务降级到了通用模型效果没有明显下降成本省了一大截。4.4 输出长度的主动控制输出token是单价最高的部分控制输出长度是最直接的省钱手段。几个实用技巧在提示词里明确要求“简洁回答”“不超过X字”“只输出结果不要解释”。很多人不写这些约束模型就会洋洋洒洒写一大堆其中大部分是你不需要的。对于结构化输出直接要求JSON格式并给出schema。这样模型不会加额外的解释文字输出token能压缩30%到50%。还有一个技巧是让模型先输出结论再按需展开。比如你问一个问题先让它给一句话答案如果这个答案够用就结束不够用再追问细节。这样避免了每次都生成一大段完整分析。注意控制输出长度不要矫枉过正。如果约束太严导致模型输出不完整你反而要重新请求总成本更高。我一般会留20%的余量。5. 那些让我多花钱的坑5.1 长对话的历史累积前面提过多轮对话每一轮都会把历史重新计费。我九月份有个任务跑了40多轮到后面每轮的输入token已经涨到几万成本曲线陡得吓人。后来我改成每10轮做一次摘要把之前的对话压缩成一段简短上下文开新会话继续。这样输入token不会无限增长成本可控。摘要本身也要花token但相比每轮重复几万token的历史划算太多。5.2 重试带来的隐性成本API调用失败重试是隐形成本大户。网络抖动、限流、超时都会触发重试而每次重试都是一次完整的计费请求。我九月份大概有3%到5%的请求是重试产生的这部分token量不大但因为是失败重试往往输入还特别长因为要重发完整上下文所以成本占比不低。减少重试的办法设置合理的超时时间不要设太短对限流错误做指数退避不要立刻重发把长请求拆成短请求降低单次失败的影响面。5.3 思考token的隐形消耗推理模型的思考token是最容易被低估的。表面上看输出只有几百字但后台计费的输出token可能是几千。我做过一次对比同一个问题推理模型表面输出300字实际计费输出2800token其中2500是思考过程。应对办法对于不需要深度推理的任务坚决不用推理模型。如果必须用在提示词里可以尝试引导“直接给出答案不需要展示推理过程”部分模型支持这种模式能减少思考token。但不是所有模型都吃这一套需要实测。5.4 上下文窗口的边界成本有些模型对超过一定长度的上下文会加价。比如前128K token是一个价超过之后单价上浮。我九月份有几个长文档处理任务输入接近200K token触发了加价档位成本比预期高了不少。处理长文档的正确姿势是分段处理而不是一次性塞进去。分段虽然请求次数多但每段都在低价档位内总成本反而更低。而且分段还能提高缓存命中率因为分段模板可以复用。6. 常见问题速查问题可能原因解决办法账单比预估高很多缓存命中率低检查提示词前缀是否稳定把变化内容后置输出token异常高推理模型思考token换通用模型或引导模型减少推理展示多轮对话成本飙升历史消息重复计费定期摘要开新会话重试次数多超时设置过短或限流调大超时指数退避重试长文档处理贵触发上下文加价档分段处理控制单次输入长度批量任务没省钱分批不合理缓存失效按前缀相似度分组每批50到200个7. 我实际支付的数字和几点体会把上面所有优化都做完之后我九月份1.73亿token的实际支付金额是912元。对比完全不优化的2268元裸价省了将近60%。这个数字里缓存命中贡献了最大的一块大概省了570元模型降级省了约300元输出控制和批量折扣省了剩下的部分。有几点体会比较深。第一缓存命中率是唯一一个你完全可控、且杠杆最大的变量值得花时间把提示词结构调好。第二不要迷信贵模型大部分日常任务用便宜模型完全够效果差异远小于价格差异。第三账单要定期看WorkBuddy后台的用量统计要养成每周扫一眼的习惯发现异常结构及时调整不要等到月底才发现超支。最后分享一个我一直在用的小技巧建一个“成本沙盒”会话专门用来测试新提示词和新任务的token消耗。任何要上量的任务先在沙盒里跑几个样本看清楚输入输出token量再决定用哪个模型、怎么分批。这个习惯让我避免了好几次潜在的预算失控。