1. 1.73 亿 token 这个数字先拆开看它到底意味着什么9 月一个月烧掉 1.73 亿 token这个量级放在个人开发者或者小团队里已经算是相当激进的用法了。很多人看到这个数字第一反应是这得花多少钱但真正值得先搞清楚的是这 1.73 亿 token 是怎么构成的。因为 token 的计费从来不是一个统一单价输入和输出不一样缓存命中和缓存未命中不一样不同模型之间更是差出好几倍。你如果不先把用量结构拆开后面算出来的钱基本就是拍脑袋。我自己在统计用量的时候习惯把 token 分成四块来看输入 token未命中缓存、输入 token命中缓存、输出 token、以及推理类模型的思考 token如果有。这四块在账单上的单价完全不同。尤其是缓存命中这一项很多平台的缓存命中价格只有未命中价格的十分之一甚至更低1.73 亿里如果有很大一部分是命中缓存的重复上下文那实际花费可能比1.73 亿乘以标准输入价低一个数量级。所以这篇文章我不打算直接甩一个总数给你而是带着你把 1.73 亿 token 按真实使用场景拆解再按官方价一项一项算清楚。算完之后你会发现决定账单高低的从来不是总 token 数而是缓存命中率和输入输出比例这两个隐藏变量。这也是为什么同样烧 1.73 亿 token有人花几百块有人花几千块。先给一个直觉性的结论垫底如果这 1.73 亿里绝大部分是输入、且缓存命中率做得不错那按主流模型的官方价总花费大概率落在几百到一千多元人民币这个区间如果输出占比高、缓存命中率又低那冲到三五千甚至更高也很正常。具体怎么算出来的往下看。2. 把 1.73 亿 token 拆成输入、输出和缓存三本账2.1 为什么不能拿一个单价乘总数很多人算账的方式是打开官网价目表看到某个模型输入 X 元/百万 token输出 Y 元/百万 token然后拿 1.73 亿直接乘。这个算法错在两个地方。第一1.73 亿是输入加输出的总和你根本不知道里面多少是输入多少是输出第二它完全忽略了缓存命中这个变量。举个具体的例子。假设某模型官方价是输入 4 元/百万 token、输出 16 元/百万 token、缓存命中输入 0.4 元/百万 token。现在你有 1.73 亿 token如果全是输入且全部未命中缓存那是 692 元如果全是输出那是 2768 元如果 90% 是命中缓存的输入、10% 是输出那只有 0.9×173×0.4 0.1×173×16 ≈ 62 277 339 元。你看同样是 1.73 亿差距能到八倍以上。所以第一步永远是把总量拆成结构。WorkBuddy 这类工具通常会在用量面板里给出输入、输出、缓存的分项统计如果没有你就得从自己的使用日志里估算。我一般会看两个比例输入输出比和缓存命中率。2.2 输入输出比决定账单量级的第一杠杆在典型的对话式或 Agent 式使用场景里输入 token 通常是输出的 5 到 20 倍。原因很简单每一轮对话你都要把历史上下文重新发一遍而模型只吐一小段回复。如果你在做代码补全、文档问答、长文本总结这类任务输入占比会更高输入输出比冲到 30:1 都不稀奇。反过来如果是纯生成任务比如让模型写长文、批量产出内容输出占比就会明显上升输入输出比可能只有 2:1 到 5:1。这种情况下账单会明显更贵因为输出单价通常是输入的 3 到 5 倍。我拿一个常见的 Agent 工作流来估假设 9 月这 1.73 亿 token 里输入占 85%、输出占 15%。那就是输入 1.47 亿、输出 2600 万。这个比例对于 WorkBuddy 这种偏工具调用、任务编排的场景是比较合理的因为它大量时间在读取上下文、调用工具、拼接 prompt真正生成的内容占比不高。2.3 缓存命中率被大多数人忽略的省钱开关缓存命中是这里最容易被低估的一项。所谓缓存命中就是你的请求里有一段内容和之前发过的完全一致通常是系统提示词、固定的工具定义、重复的文档前缀平台识别出来后按极低价格计费通常是标准输入价的 10% 到 25%。对于 WorkBuddy 这种会反复携带同一套系统提示和工具 schema 的工具缓存命中率做得好可以到 60% 到 90%。我实测过一个类似场景把系统提示和工具定义固定下来、放在 prompt 最前面缓存命中率能稳定在 75% 以上。这意味着那 1.47 亿输入里可能有 1.1 亿是按缓存价算的只有 3700 万按全价算。这一项对最终账单的影响比换一个便宜模型还大。所以下面算账的时候我会分**乐观高缓存命中和保守低缓存命中**两种情形给你算你对照自己的实际情况取。3. 按官方价实算三种模型档位下的真实花费3.1 先设定计算口径为了让数字有意义我先把口径固定下来你可以按自己实际用的模型替换单价总 token173,000,0001.73 亿输入占比85%即 147,050,000 token输出占比15%即 25,950,000 token缓存命中率分 75%乐观和 30%保守两档计价单位统一换算成元/百万 token然后我选三个档位的模型来算旗舰档对标顶级模型输入 4 元、输出 16 元、缓存 0.4 元、主力档对标中端模型输入 1 元、输出 4 元、缓存 0.1 元、经济档对标轻量模型输入 0.5 元、输出 2 元、缓存 0.05 元。这三档基本覆盖了市面上主流 API 的价格区间。3.2 旗舰档模型高缓存命中 vs 低缓存命中先算乐观情形缓存命中率 75%命中缓存的输入147,050,000 × 75% 110,287,500 token按 0.4 元/百万算 44.1 元未命中缓存的输入147,050,000 × 25% 36,762,500 token按 4 元/百万算 147.1 元输出25,950,000 token按 16 元/百万算 415.2 元合计约 606 元再算保守情形缓存命中率 30%命中缓存输入147,050,000 × 30% 44,115,000按 0.4 元 17.6 元未命中缓存输入147,050,000 × 70% 102,935,000按 4 元 411.7 元输出25,950,000按 16 元 415.2 元合计约 844 元可以看到旗舰档下缓存命中率从 75% 掉到 30%账单从 606 涨到 844多花了近 240 元涨幅接近 40%。而这还只是输入部分的变化输出那 415 元是雷打不动的。3.3 主力档和经济档差距被压缩但依然明显主力档输入 1 元、输出 4 元、缓存 0.1 元缓存命中 75%命中缓存输入110,287,500 × 0.1 元/百万 11.0 元未命中输入36,762,500 × 1 元/百万 36.8 元输出25,950,000 × 4 元/百万 103.8 元合计约 152 元主力档缓存命中 30%命中缓存输入44,115,000 × 0.1 4.4 元未命中输入102,935,000 × 1 102.9 元输出103.8 元合计约 211 元经济档输入 0.5 元、输出 2 元、缓存 0.05 元缓存命中 75%命中缓存输入110,287,500 × 0.05 5.5 元未命中输入36,762,500 × 0.5 18.4 元输出25,950,000 × 2 51.9 元合计约 76 元经济档缓存命中 30%命中缓存输入44,115,000 × 0.05 2.2 元未命中输入102,935,000 × 0.5 51.5 元输出51.9 元合计约 106 元把这几组数字整理成一张表看起来更直观模型档位缓存命中 75%缓存命中 30%差额旗舰档约 606 元约 844 元238 元主力档约 152 元约 211 元59 元经济档约 76 元约 106 元30 元3.4 从这张表里能读出什么第一输出 token 是账单的硬骨头。在旗舰档里输出只占 15% 的量却贡献了 68% 的费用。这就是为什么少让模型说废话不只是体验问题更是成本问题。第二缓存命中率的价值随模型档位放大。旗舰档下缓存优化能省 238 元经济档下只省 30 元。所以如果你用的是贵模型缓存优化是必修课用便宜模型优化收益相对有限但蚊子腿也是肉。第三1.73 亿 token 的真实花费区间大概在 76 元到 844 元之间取决于你用什么模型、缓存做得好不好。如果混合使用多个模型贵的做复杂推理、便宜的做日常任务实际花费大概率落在 200 到 400 元这个中间地带。4. 缓存命中率是怎么被拉高的以及为什么很多人做不好4.1 缓存命中的底层逻辑前缀匹配要理解缓存命中得先知道它的机制。主流平台的缓存基本都是前缀缓存平台把你这次请求的 token 序列和之前某次请求的开头部分做比对如果前面一大段完全一致这段就按缓存价算直到出现第一个不一致的地方为止。这个机制决定了缓存优化的核心原则把稳定不变的内容放在 prompt 最前面把每次都变的内容放在最后面。系统提示词、角色设定、工具定义、固定的知识库前缀这些都应该放在最前面且保持字节级一致。用户的实时输入、当前时间戳、随机 ID 这些必须放在最后。我见过太多人把时间戳或者随机 session id 塞在系统提示词里结果每次请求前缀都不一样缓存命中率直接归零。这种坑非常隐蔽因为功能上完全正常只有看账单的时候才会发现钱花多了。4.2 一个真实的前缀优化案例我之前帮一个团队看他们的用量发现缓存命中率只有 12%账单高得离谱。排查下来发现三个问题一是系统提示词里带了当前日期每天变一次二是工具定义列表的顺序每次调用时被代码随机打乱三是他们在 prompt 中间插了一段动态检索到的文档把后面的固定内容全冲掉了。改法很直接把日期从系统提示里拿掉改成在用户消息里传工具定义按固定顺序序列化加个排序保证稳定动态文档挪到 prompt 末尾。改完之后缓存命中率从 12% 涨到 68%同样的任务量月账单直接砍掉一半多。这个案例说明一件事缓存优化不是玄学是工程规范问题。只要你保证前缀稳定命中率自然就上去了。4.3 缓存也有失效边界别指望 100%需要提醒的是缓存不是永久的。平台通常会给缓存设一个存活时间几分钟到几小时不等超过时间没被再次命中就失效了。所以如果你的请求间隔很长缓存命中率会天然偏低。WorkBuddy 这种连续执行任务的工具请求密集缓存命中率通常比较好但如果是那种一天跑几次的批处理脚本缓存基本帮不上忙。另外缓存是按模型隔离的。你换了模型之前的缓存就用不上了。所以频繁切换模型会牺牲缓存收益这也是为什么混合使用多模型虽然能省钱但要在缓存和单价之间做权衡。5. 除了单价还有哪些隐藏成本在悄悄吃掉预算5.1 重试和失败请求也是要计费的这一点很多人没意识到请求失败不代表不计费。如果模型已经开始生成、中途因为超时或错误中断已经产生的 token 通常照样算钱。WorkBuddy 这类工具在调用外部 API、执行工具时容易遇到超时如果重试逻辑写得粗暴一次任务失败重试三次token 消耗就是三倍。我在统计用量时专门看过失败请求的占比健康的情况下应该在 5% 以内。如果超过 10%说明你的重试策略或者超时设置有问题这部分钱是纯浪费。建议给重试加个上限并且对幂等的工具调用做去重别让同一个失败请求反复烧钱。5.2 上下文膨胀越聊越贵的隐形杀手对话式使用有个天然问题上下文会越来越长。每一轮都把历史全带上到第十轮的时候输入 token 可能是第一轮的十倍。如果不做上下文管理一个长会话的后期成本会指数级上升。常见的做法有三种一是滑动窗口只保留最近 N 轮对话二是摘要压缩把早期对话总结成一段短文本三是关键信息抽取只保留结构化的要点。WorkBuddy 这种任务型工具更适合后两种因为任务状态比对话历史更重要没必要把每句闲聊都带着。我实测下来一个原本会膨胀到 5 万 token 上下文的长任务用摘要压缩后能控制在 8000 token 以内单次成本降到六分之一。这个优化对 1.73 亿这种量级的用量来说省下的钱非常可观。5.3 思考 token推理模型的额外账单如果你用的是带推理能力的模型还要注意思考 token。这类模型在给出最终答案前会先生成一段内部推理这段推理通常按输出价计费而且量不小有时候能占到总输出的 50% 以上。也就是说同样一个问题推理模型的实际输出 token 可能是普通模型的三到五倍。如果你的任务不需要复杂推理用推理模型就是纯浪费。反过来需要推理的任务用普通模型可能因为答案质量差而反复重试算下来也不便宜。选模型的核心是匹配任务复杂度不是越贵越好也不是越便宜越好。6. 把 1.73 亿 token 的账算明白之后我总结的几条实操经验6.1 先测结构再谈优化不要一上来就想着换便宜模型。先花半天时间把用量结构摸清楚输入输出比是多少、缓存命中率是多少、失败请求占多少、有没有上下文膨胀。这四个数字拿到手你才知道钱到底花在哪优化才有方向。我见过太多人盲目换模型结果因为新模型缓存机制不同账单反而涨了。6.2 缓存优化是投入产出比最高的一件事在所有优化手段里缓存优化的性价比是最高的。它不需要你改业务逻辑只需要规范 prompt 的拼接顺序把稳定内容前置、动态内容后置。改一次长期受益。对于 1.73 亿这种量级缓存命中率每提升 10 个百分点旗舰档下能省几十块一年下来就是几百上千。6.3 输出要克制但别牺牲质量控制输出 token 不等于让模型少说话。正确的做法是在系统提示里明确要求简洁回答、不要复述问题、不要输出无关解释同时把格式约束写清楚。这样既省 token又不影响答案质量。粗暴地限制长度反而会导致答案不完整引发重试得不偿失。6.4 给用量设个预警线1.73 亿 token 不是小数目如果没有监控很容易在月底看到账单时吓一跳。建议按天统计用量设一个日消耗预警线超过就排查是不是有异常请求或者死循环。WorkBuddy 这类自动化工具尤其要注意一个写错的循环可能一晚上烧掉几千万 token。6.5 混合模型策略要算总账用便宜模型做简单任务、贵模型做复杂任务这个思路没错但要算总账。因为切换模型会牺牲缓存而且便宜模型如果搞不定任务导致重试省下的单价可能又赔进去了。我的经验是同一类任务尽量固定用同一个模型让缓存充分发挥作用跨类任务再考虑分模型并且给每类任务单独统计成本。回到最开始那个问题9 月用 WorkBuddy 烧了 1.73 亿 token按官方价到底要花多少钱答案不是一个数字而是一个区间——76 元到 844 元中位数大概在 200 到 400 元。决定你落在区间哪个位置的不是运气而是你对输入输出比和缓存命中率这两个变量的掌控程度。把这两个变量管好1.73 亿 token 也能花得很体面管不好同样的量能让你多掏好几倍的钱。 1. 1.73 亿 token 这个数字先拆开看它到底意味着什么9 月一个月烧掉 1.73 亿 token这个量级放在个人开发者或者小团队里已经算是相当激进的用法了。很多人看到这个数字第一反应是这得花多少钱但真正值得先搞清楚的是这 1.73 亿 token 是怎么构成的。因为 token 的计费从来不是一个统一单价输入和输出不一样缓存命中和缓存未命中不一样不同模型之间更是差出好几倍。你如果不先把用量结构拆开后面算出来的钱基本就是拍脑袋。我自己在统计用量的时候习惯把 token 分成四块来看输入 token未命中缓存、输入 token命中缓存、输出 token、以及推理类模型的思考 token如果有。这四块在账单上的单价完全不同。尤其是缓存命中这一项很多平台的缓存命中价格只有未命中价格的十分之一甚至更低1.73 亿里如果有很大一部分是命中缓存的重复上下文那实际花费可能比1.73 亿乘以标准输入价低一个数量级。所以这篇文章我不打算直接甩一个总数给你而是带着你把 1.73 亿 token 按真实使用场景拆解再按官方价一项一项算清楚。算完之后你会发现决定账单高低的从来不是总 token 数而是缓存命中率和输入输出比例这两个隐藏变量。这也是为什么同样烧 1.73 亿 token有人花几百块有人花几千块。先给一个直觉性的结论垫底如果这 1.73 亿里绝大部分是输入、且缓存命中率做得不错那按主流模型的官方价总花费大概率落在几百到一千多元人民币这个区间如果输出占比高、缓存命中率又低那冲到三五千甚至更高也很正常。具体怎么算出来的往下看。2. 把 1.73 亿 token 拆成输入、输出和缓存三本账2.1 为什么不能拿一个单价乘总数很多人算账的方式是打开官网价目表看到某个模型输入 X 元/百万 token输出 Y 元/百万 token然后拿 1.73 亿直接乘。这个算法错在两个地方。第一1.73 亿是输入加输出的总和你根本不知道里面多少是输入多少是输出第二它完全忽略了缓存命中这个变量。举个具体的例子。假设某模型官方价是输入 4 元/百万 token、输出 16 元/百万 token、缓存命中输入 0.4 元/百万 token。现在你有 1.73 亿 token如果全是输入且全部未命中缓存那是 692 元如果全是输出那是 2768 元如果 90% 是命中缓存的输入、10% 是输出那只有 0.9×173×0.4 0.1×173×16 ≈ 62 277 339 元。你看同样是 1.73 亿差距能到八倍以上。所以第一步永远是把总量拆成结构。WorkBuddy 这类工具通常会在用量面板里给出输入、输出、缓存的分项统计如果没有你就得从自己的使用日志里估算。我一般会看两个比例输入输出比和缓存命中率。2.2 输入输出比决定账单量级的第一杠杆在典型的对话式或 Agent 式使用场景里输入 token 通常是输出的 5 到 20 倍。原因很简单每一轮对话你都要把历史上下文重新发一遍而模型只吐一小段回复。如果你在做代码补全、文档问答、长文本总结这类任务输入占比会更高输入输出比冲到 30:1 都不稀奇。反过来如果是纯生成任务比如让模型写长文、批量产出内容输出占比就会明显上升输入输出比可能只有 2:1 到 5:1。这种情况下账单会明显更贵因为输出单价通常是输入的 3 到 5 倍。我拿一个常见的 Agent 工作流来估假设 9 月这 1.73 亿 token 里输入占 85%、输出占 15%。那就是输入 1.47 亿、输出 2600 万。这个比例对于 WorkBuddy 这种偏工具调用、任务编排的场景是比较合理的因为它大量时间在读取上下文、调用工具、拼接 prompt真正生成的内容占比不高。2.3 缓存命中率被大多数人忽略的省钱开关缓存命中是这里最容易被低估的一项。所谓缓存命中就是你的请求里有一段内容和之前发过的完全一致通常是系统提示词、固定的工具定义、重复的文档前缀平台识别出来后按极低价格计费通常是标准输入价的 10% 到 25%。对于 WorkBuddy 这种会反复携带同一套系统提示和工具 schema 的工具缓存命中率做得好可以到 60% 到 90%。我实测过一个类似场景把系统提示和工具定义固定下来、放在 prompt 最前面缓存命中率能稳定在 75% 以上。这意味着那 1.47 亿输入里可能有 1.1 亿是按缓存价算的只有 3700 万按全价算。这一项对最终账单的影响比换一个便宜模型还大。所以下面算账的时候我会分**乐观高缓存命中和保守低缓存命中**两种情形给你算你对照自己的实际情况取。3. 按官方价实算三种模型档位下的真实花费3.1 先设定计算口径为了让数字有意义我先把口径固定下来你可以按自己实际用的模型替换单价总 token173,000,0001.73 亿输入占比85%即 147,050,000 token输出占比15%即 25,950,000 token缓存命中率分 75%乐观和 30%保守两档计价单位统一换算成元/百万 token然后我选三个档位的模型来算旗舰档对标顶级模型输入 4 元、输出 16 元、缓存 0.4 元、主力档对标中端模型输入 1 元、输出 4 元、缓存 0.1 元、经济档对标轻量模型输入 0.5 元、输出 2 元、缓存 0.05 元。这三档基本覆盖了市面上主流 API 的价格区间。3.2 旗舰档模型高缓存命中 vs 低缓存命中先算乐观情形缓存命中率 75%命中缓存的输入147,050,000 × 75% 110,287,500 token按 0.4 元/百万算 44.1 元未命中缓存的输入147,050,000 × 25% 36,762,500 token按 4 元/百万算 147.1 元输出25,950,000 token按 16 元/百万算 415.2 元合计约 606 元再算保守情形缓存命中率 30%命中缓存输入147,050,000 × 30% 44,115,000按 0.4 元 17.6 元未命中缓存输入147,050,000 × 70% 102,935,000按 4 元 411.7 元输出25,950,000按 16 元 415.2 元合计约 844 元可以看到旗舰档下缓存命中率从 75% 掉到 30%账单从 606 涨到 844多花了近 240 元涨幅接近 40%。而这还只是输入部分的变化输出那 415 元是雷打不动的。3.3 主力档和经济档差距被压缩但依然明显主力档输入 1 元、输出 4 元、缓存 0.1 元缓存命中 75%命中缓存输入110,287,500 × 0.1 元/百万 11.0 元未命中输入36,762,500 × 1 元/百万 36.8 元输出25,950,000 × 4 元/百万 103.8 元合计约 152 元主力档缓存命中 30%命中缓存输入44,115,000 × 0.1 4.4 元未命中输入102,935,000 × 1 102.9 元输出103.8 元合计约 211 元经济档输入 0.5 元、输出 2 元、缓存 0.05 元缓存命中 75%命中缓存输入110,287,500 × 0.05 5.5 元未命中输入36,762,500 × 0.5 18.4 元输出25,950,000 × 2 51.9 元合计约 76 元经济档缓存命中 30%命中缓存输入44,115,000 × 0.05 2.2 元未命中输入102,935,000 × 0.5 51.5 元输出51.9 元合计约 106 元把这几组数字整理成一张表看起来更直观模型档位缓存命中 75%缓存命中 30%差额旗舰档约 606 元约 844 元238 元主力档约 152 元约 211 元59 元经济档约 76 元约 106 元30 元3.4 从这张表里能读出什么第一输出 token 是账单的硬骨头。在旗舰档里输出只占 15% 的量却贡献了 68% 的费用。这就是为什么少让模型说废话不只是体验问题更是成本问题。第二缓存命中率的价值随模型档位放大。旗舰档下缓存优化能省 238 元经济档下只省 30 元。所以如果你用的是贵模型缓存优化是必修课用便宜模型优化收益相对有限但蚊子腿也是肉。第三1.73 亿 token 的真实花费区间大概在 76 元到 844 元之间取决于你用什么模型、缓存做得好不好。如果混合使用多个模型贵的做复杂推理、便宜的做日常任务实际花费大概率落在 200 到 400 元这个中间地带。4. 缓存命中率是怎么被拉高的以及为什么很多人做不好4.1 缓存命中的底层逻辑前缀匹配要理解缓存命中得先知道它的机制。主流平台的缓存基本都是前缀缓存平台把你这次请求的 token 序列和之前某次请求的开头部分做比对如果前面一大段完全一致这段就按缓存价算直到出现第一个不一致的地方为止。这个机制决定了缓存优化的核心原则把稳定不变的内容放在 prompt 最前面把每次都变的内容放在最后面。系统提示词、角色设定、工具定义、固定的知识库前缀这些都应该放在最前面且保持字节级一致。用户的实时输入、当前时间戳、随机 ID 这些必须放在最后。我见过太多人把时间戳或者随机 session id 塞在系统提示词里结果每次请求前缀都不一样缓存命中率直接归零。这种坑非常隐蔽因为功能上完全正常只有看账单的时候才会发现钱花多了。4.2 一个真实的前缀优化案例我之前帮一个团队看他们的用量发现缓存命中率只有 12%账单高得离谱。排查下来发现三个问题一是系统提示词里带了当前日期每天变一次二是工具定义列表的顺序每次调用时被代码随机打乱三是他们在 prompt 中间插了一段动态检索到的文档把后面的固定内容全冲掉了。改法很直接把日期从系统提示里拿掉改成在用户消息里传工具定义按固定顺序序列化加个排序保证稳定动态文档挪到 prompt 末尾。改完之后缓存命中率从 12% 涨到 68%同样的任务量月账单直接砍掉一半多。这个案例说明一件事缓存优化不是玄学是工程规范问题。只要你保证前缀稳定命中率自然就上去了。4.3 缓存也有失效边界别指望 100%需要提醒的是缓存不是永久的。平台通常会给缓存设一个存活时间几分钟到几小时不等超过时间没被再次命中就失效了。所以如果你的请求间隔很长缓存命中率会天然偏低。WorkBuddy 这种连续执行任务的工具请求密集缓存命中率通常比较好但如果是那种一天跑几次的批处理脚本缓存基本帮不上忙。另外缓存是按模型隔离的。你换了模型之前的缓存就用不上了。所以频繁切换模型会牺牲缓存收益这也是为什么混合使用多模型虽然能省钱但要在缓存和单价之间做权衡。5. 除了单价还有哪些隐藏成本在悄悄吃掉预算5.1 重试和失败请求也是要计费的这一点很多人没意识到请求失败不代表不计费。如果模型已经开始生成、中途因为超时或错误中断已经产生的 token 通常照样算钱。WorkBuddy 这类工具在调用外部 API、执行工具时容易遇到超时如果重试逻辑写得粗暴一次任务失败重试三次token 消耗就是三倍。我在统计用量时专门看过失败请求的占比健康的情况下应该在 5% 以内。如果超过 10%说明你的重试策略或者超时设置有问题这部分钱是纯浪费。建议给重试加个上限并且对幂等的工具调用做去重别让同一个失败请求反复烧钱。5.2 上下文膨胀越聊越贵的隐形杀手对话式使用有个天然问题上下文会越来越长。每一轮都把历史全带上到第十轮的时候输入 token 可能是第一轮的十倍。如果不做上下文管理一个长会话的后期成本会指数级上升。常见的做法有三种一是滑动窗口只保留最近 N 轮对话二是摘要压缩把早期对话总结成一段短文本三是关键信息抽取只保留结构化的要点。WorkBuddy 这种任务型工具更适合后两种因为任务状态比对话历史更重要没必要把每句闲聊都带着。我实测下来一个原本会膨胀到 5 万 token 上下文的长任务用摘要压缩后能控制在 8000 token 以内单次成本降到六分之一。这个优化对 1.73 亿这种量级的用量来说省下的钱非常可观。5.3 思考 token推理模型的额外账单如果你用的是带推理能力的模型还要注意思考 token。这类模型在给出最终答案前会先生成一段内部推理这段推理通常按输出价计费而且量不小有时候能占到总输出的 50% 以上。也就是说同样一个问题推理模型的实际输出 token 可能是普通模型的三到五倍。如果你的任务不需要复杂推理用推理模型就是纯浪费。反过来需要推理的任务用普通模型可能因为答案质量差而反复重试算下来也不便宜。选模型的核心是匹配任务复杂度不是越贵越好也不是越便宜越好。6. 把 1.73 亿 token 的账算明白之后我总结的几条实操经验6.1 先测结构再谈优化不要一上来就想着换便宜模型。先花半天时间把用量结构摸清楚输入输出比是多少、缓存命中率是多少、失败请求占多少、有没有上下文膨胀。这四个数字拿到手你才知道钱到底花在哪优化才有方向。我见过太多人盲目换模型结果因为新模型缓存机制不同账单反而涨了。6.2 缓存优化是投入产出比最高的一件事在所有优化手段里缓存优化的性价比是最高的。它不需要你改业务逻辑只需要规范 prompt 的拼接顺序把稳定内容前置、动态内容后置。改一次长期受益。对于 1.73 亿这种量级缓存命中率每提升 10 个百分点旗舰档下能省几十块一年下来就是几百上千。6.3 输出要克制但别牺牲质量控制输出 token 不等于让模型少说话。正确的做法是在系统提示里明确要求简洁回答、不要复述问题、不要输出无关解释同时把格式约束写清楚。这样既省 token又不影响答案质量。粗暴地限制长度反而会导致答案不完整引发重试得不偿失。6.4 给用量设个预警线1.73 亿 token 不是小数目如果没有监控很容易在月底看到账单时吓一跳。建议按天统计用量设一个日消耗预警线超过就排查是不是有异常请求或者死循环。WorkBuddy 这类自动化工具尤其要注意一个写错的循环可能一晚上烧掉几千万 token。6.5 混合模型策略要算总账用便宜模型做简单任务、贵模型做复杂任务这个思路没错但要算总账。因为切换模型会牺牲缓存而且便宜模型如果搞不定任务导致重试省下的单价可能又赔进去了。我的经验是同一类任务尽量固定用同一个模型让缓存充分发挥作用跨类任务再考虑分模型并且给每类任务单独统计成本。回到最开始那个问题9 月用 WorkBuddy 烧了 1.73 亿 token按官方价到底要花多少钱答案不是一个数字而是一个区间——76 元到 844 元中位数大概在 200 到 400 元。决定你落在区间哪个位置的不是运气而是你对输入输出比和缓存命中率这两个变量的掌控程度。把这两个变量管好1.73 亿 token 也能花得很体面管不好同样的量能让你多掏好几倍的钱。