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，取常见档位）：
| 模型类型 | 输入单价 | 缓存输入单价 | 输出单价 |
|---|---|---|---|
| 通用对话 | 4 | 1 | 16 |
| 代码专用 | 12 | 3 | 48 |
| 推理模型 | 24 | 6 | 96 |
现在逐项算。
通用对话模型：
- 未命中缓存输入：假设其输入里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量再决定用哪个模型、怎么分批。这个习惯让我避免了好几次潜在的预算失控。
