9 月过完我打开 WorkBuddy 的用量面板看到那个数字的时候愣了几秒1.73 亿 token。不是 173 万是 1.73 亿。当时第一反应不是我到底问了它什么而是这要是按官方 API 价格结算得掏多少钱。这个问题其实挺有意思的。绝大多数人用这类 AI 助手的时候对 token 是没有体感的——你问一句话它回一段话中间烧了多少 token、这些 token 分别走了输入还是输出、有没有命中缓存全是黑盒。等到月底看账单或者看用量统计才发现数字大得离谱。所以这篇东西我打算把 1.73 亿 token 这个数字彻底拆开算清楚它在不同计费口径下到底值多少钱顺便把 token 计费里那些容易被忽略的坑讲透。不管你是刚接触 API 计费的新手还是已经在跑自己工作流的老手应该都能从这套算法里拿到点能直接用的东西。1. 先把 1.73 亿 token 这个数字拆成能算账的零件1.1 为什么1.73 亿 token本身不是一个能直接报价的数很多人看到用量统计里的总数第一反应是拿这个总数去乘一个单价。这个做法从根上就错了因为 token 计费从来不是单一价格而是分层的。一个 AI 助手的调用过程token 至少分成三类输入 tokeninput/prompt tokens、输出 tokenoutput/completion tokens、以及缓存命中的输入 tokencached input tokens。这三类的单价可以差出十倍甚至更多。输出 token 通常是最贵的缓存命中的输入 token 往往只有正常输入价格的十分之一左右。所以 1.73 亿这个总数如果不知道它的构成比例算出来的钱可能差好几倍。我见过有人拿总 token 乘输出单价算出来一个天文数字把自己吓一跳也有人拿总 token 乘最便宜的缓存单价得出一个才这么点钱的结论。两种都不对。要算准第一步是把 1.73 亿拆成输入多少、输出多少、其中缓存命中多少。WorkBuddy 这类工具的用量面板一般会给到分项如果没有分项就得靠经验比例去估。1.2 一个 AI 助手类工具的典型 token 构成比例我拿自己 9 月的实际使用情况做了个统计也参考了几个同样重度使用这类工具的朋友的数据得到一个比较有代表性的比例区间。注意这是助手类工具的比例不是纯 API 调用的比例两者差别很大。token 类型占比区间说明输入 token未命中缓存15% ~ 30%每次对话新带入的上下文输入 token命中缓存45% ~ 65%重复的系统提示、历史上下文、固定指令输出 token15% ~ 25%模型实际生成的内容为什么缓存命中占比这么高因为助手类工具每次调用都会带上大量固定内容系统提示词、工具定义、技能描述、历史对话。这些东西在连续对话里高度重复只要服务端支持上下文缓存绝大部分都会被命中。这也是为什么按官方价算和按实际账单算经常对不上——缓存把成本压下去了。按这个比例1.73 亿 token 可以拆成大概未命中缓存的输入约 0.35 亿按 20% 估命中缓存的输入约 0.95 亿按 55% 估输出约 0.43 亿按 25% 估这三个数字就是后面所有计算的基石。比例一变结果就变所以我会在每一档计算里都说明假设。1.3 单价从哪来不同模型的价差能到几十倍按官方价这句话本身就有歧义因为官方价取决于你用哪个模型。同一个厂商旗舰模型和轻量模型的价差可以到十几倍不同厂商之间同档次模型的价差也能到几倍。我整理了一张常见档位的价格对照表单位统一成美元 / 百万 token方便横向比。这些是公开的官方标价区间具体以各家最新公告为准我这里给的是量级参考。模型档位输入单价$/M输出单价$/M缓存输入单价$/M旗舰级最强推理3 ~ 1515 ~ 750.3 ~ 1.5主力级均衡0.5 ~ 31.5 ~ 150.05 ~ 0.3轻量级高性价比0.05 ~ 0.50.2 ~ 20.01 ~ 0.05看到没光官方价这三个字旗舰和轻量之间就能差出两个数量级。所以下面我会分档算而不是给一个笼统的数。2. 按官方价硬算三档模型下的真实花费2.1 旗舰档如果 1.73 亿全走最强模型先算最贵的情况也就是假设这 1.73 亿 token 全部由旗舰级模型处理。取一组中间偏上的价格输入 $10/M、输出 $50/M、缓存输入 $1/M。代入前面的拆分未命中输入0.35 亿 35M35 × 10 $350缓存输入0.95 亿 95M95 × 1 $95输出0.43 亿 43M43 × 50 $2150合计约$2595按 7.2 的汇率换算大概1.87 万元人民币。这个数字一出来很多人会倒吸一口气。但要注意这是全部走旗舰的极端假设。实际使用中助手类工具会根据任务复杂度路由到不同模型简单任务根本不会调用旗舰模型。所以这个数字是理论上限不是真实账单。2.2 主力档更接近真实使用结构的算法主力级模型是这类工具的主力价格取输入 $2/M、输出 $8/M、缓存输入 $0.2/M。同样代入未命中输入35M × 2 $70缓存输入95M × 0.2 $19输出43M × 8 $344合计约$433折合人民币约3118 元。这个数字就现实多了。一个月重度使用三千块左右的 API 成本对于高频使用者来说是合理区间。而且这还是没算任何折扣、批量优惠、免费额度的情况。2.3 轻量档如果大量任务被路由到小模型轻量级模型价格取输入 $0.15/M、输出 $0.6/M、缓存输入 $0.015/M未命中输入35M × 0.15 $5.25缓存输入95M × 0.015 $1.43输出43M × 0.6 $25.8合计约$32.5折合人民币约234 元。三档算下来从 234 元到 1.87 万元差了将近 80 倍。这就是为什么我一直强调脱离模型档位谈 token 花费等于没谈。2.4 把三档结果放在一起看档位输入成本缓存成本输出成本合计美元合计人民币旗舰档$350$95$2150$2595≈ 1.87 万主力档$70$19$344$433≈ 3118 元轻量档$5.25$1.43$25.8$32.5≈ 234 元真实情况几乎肯定是三者的混合。一个合理的估计是60% 的 token 走主力档30% 走轻量档10% 走旗舰档。加权算下来大概在$600 ~ $900之间也就是人民币4300 ~ 6500 元。这个区间我觉得是最接近按官方价到底要花多少钱这个问题的答案。3. 缓存命中率才是决定账单的那只手3.1 缓存命中率从 50% 提到 80%能省多少钱前面所有计算里缓存输入单价都是正常输入单价的十分之一。这意味着缓存命中率每提高一点成本就往下掉一截。我拿主力档做了一组敏感性测试固定总 token 1.73 亿、输出占比 25%只改缓存命中率缓存命中率未命中输入缓存输入输出合计美元30%0.91 亿0.39 亿0.43 亿$182 $7.8 $344 $53450%0.65 亿0.65 亿0.43 亿$130 $13 $344 $48765%0.455 亿0.845 亿0.43 亿$91 $16.9 $344 $45280%0.26 亿1.04 亿0.43 亿$52 $20.8 $344 $417从 30% 到 80%省了大约 $117降幅 22%。看起来不多那是因为输出成本占了大头把总盘子撑住了。如果只看输入侧的成本从 $190 降到 $73降了 62%。所以缓存优化的收益在输入密集的场景里才最明显。3.2 为什么助手类工具的缓存命中率天然偏高这里要讲一个很多人没意识到的机制。助手类工具和裸调 API 最大的区别在于它每次请求都会附带一大坨固定内容。系统提示词通常几千 token每次必带工具/技能定义如果开了很多技能这部分能到上万 token历史对话连续对话里前面的内容会被反复带入用户自定义指令固定不变的部分这些内容在连续会话中高度重复。只要服务端实现了前缀缓存prefix caching重复部分就会命中缓存按缓存价计费。所以一个设计良好的助手缓存命中率做到 60% 以上是常态做得好的能到 80%。反过来说如果你的助手缓存命中率很低那大概率是这几个原因系统提示词每次都在变比如带了时间戳、历史对话被频繁截断重组、或者服务端压根没开缓存。这些都是可以优化的点。3.3 一个反直觉的结论上下文越长单位成本可能越低新手容易有一个直觉上下文越长token 越多肯定越贵。这话对但不完整。因为长上下文里重复的部分占比更高缓存命中率也更高。假设你有一段 5 万 token 的固定背景资料第一次带入是全额输入价之后每次带入都是缓存价。用得越多这段资料的摊薄成本就越低。我实测过一个场景把一份 3 万 token 的规范文档作为固定上下文连续问 50 个问题。第一个问题输入成本是 3 万 token 全额后面 49 个问题里这 3 万 token 全部命中缓存。平均下来每个问题的背景成本只有原来的几十分之一。所以固定上下文 高频复用是压成本最有效的手段之一。4. 那些让账单悄悄膨胀的隐藏项4.1 输出 token 为什么是成本黑洞看前面的表就知道输出单价通常是输入单价的 4 到 5 倍是缓存输入单价的 40 到 50 倍。也就是说生成 1 个 token 的成本抵得上读 40 到 50 个缓存 token。这意味着什么意味着让模型少说废话比少读资料重要得多。我见过有人为了省输入 token把上下文砍得七零八落结果模型因为信息不足反复追问、反复解释输出 token 反而暴涨总成本更高。一个实用的经验输出 token 的优化优先级永远高于输入 token。具体做法包括在提示词里明确要求简洁回答、限制回答长度、避免让模型复述已知信息、关闭不必要的解释过程输出。这些动作对账单的影响比抠输入 token 大得多。4.2 重试和失败请求也在烧钱这是一个特别容易被忽略的点。API 调用失败、超时、被限流这些请求如果已经产生了输入 token 的处理很多情况下是照样计费的。尤其是流式输出中途断掉的情况已经生成的部分输出 token 也是要算钱的。我 9 月有一次批量任务因为网络抖动重试了大概 200 次每次重试都带着完整的上下文。事后估算光是这些重试就多烧了将近 800 万 token。按主力档算差不多 $20 出头。单看不多但如果你的任务本身失败率高这个数字会很难看。所以做批量任务的时候一定要做幂等设计和失败去重别让同一个请求反复重试。另外重试前先判断错误类型如果是限流退避重试如果是参数错误重试一万次也没用纯烧钱。4.3 上下文窗口的隐形浪费还有一个坑很多工具在组装请求时会把整个历史对话原封不动带上哪怕前面 90% 的内容和当前问题无关。这就导致每次请求的输入 token 里有大量僵尸上下文。我做过一个对比测试。同一个任务一种做法是全程保留完整历史另一种做法是每轮只保留最近 5 轮对话加一个摘要。结果后者的总 token 消耗只有前者的 40% 左右而回答质量几乎没有差别。原因很简单模型真正需要的上下文远比我们以为的少。提示定期清理对话历史、用摘要替代全文、把固定资料放进系统提示而不是每轮对话这三个动作能显著降低输入 token。5. 把 1.73 亿 token 换算成人话5.1 1.73 亿 token 大概是多少内容量光看数字没感觉我换算一下。一个中文 token 大约对应 1.5 到 2 个汉字不同分词器有差异英文一个 token 大约对应 0.75 个单词。按中文算1.73 亿 token 大约对应2.6 亿到 3.5 亿个汉字。一本 30 万字的长篇小说大概是 15 万到 20 万 token。1.73 亿 token 相当于读了800 到 1000 本这样的书。当然助手类工具的 token 大部分不是读进来的内容而是系统提示、工具定义、历史对话这些结构性开销。但即便打个对折这个量级也相当惊人了。这也解释了为什么重度使用者的账单会那么高——不是问了多复杂的问题而是调用次数多、每次调用都带着一堆固定开销。5.2 单次对话的平均成本是多少假设 9 月我进行了大约 3000 次有效对话这个数字对重度使用者来说不算夸张1.73 亿 token 平摊下来每次对话约 5.8 万 token。按主力档算每次对话成本约 $433 / 3000 ≈$0.14折合人民币约1 块钱。按旗舰档算每次约6 毛到 6 块不等。这个数字挺有意思单次对话一块钱左右感觉不贵但乘以 3000 次就是三千块。这就是订阅制和按量付费的核心差异——订阅制赌的是你用得少按量付费赌的是你用得多。对于重度使用者按量付费几乎一定更贵。5.3 和订阅制比到底哪个划算这是很多人真正关心的问题。我拉了一张对比表假设某订阅制服务月费 $20约 144 元提供一定的用量额度使用强度月 token 量按量付费主力档订阅制更划算的轻度500 万≈ $12$20按量中度3000 万≈ $75$20订阅重度1.73 亿≈ $433$20可能超额度订阅若额度够结论很清晰用得越多订阅制越划算。但前提是订阅制的额度能覆盖你的用量且不限制模型档位。很多订阅制服务在重度使用时会限流、降级模型或者干脆不给用旗舰模型。这时候划算就要打折扣了。所以真正的选择逻辑不是哪个便宜而是你的使用模式匹配哪种计费。间歇性、爆发式使用按量付费更灵活持续、高频、稳定使用订阅制更省。6. 我实际压成本用过的几个手段6.1 把固定内容全部前置到系统提示这是收益最直接的一招。原理很简单系统提示在整个会话里是不变的服务端缓存能完整命中。而如果你把同样的内容放在每轮用户消息里虽然也能命中缓存但一旦中间插入其他内容缓存前缀就断了后面的全部失效。具体做法把所有固定不变的指令、背景资料、格式要求全部写进系统提示或自定义指令里不要放在对话消息里。我这么改完之后缓存命中率从 55% 左右提到了 75% 以上。6.2 用摘要代替完整历史连续对话里历史越长输入 token 越多。但模型真正需要的往往只是最近几轮的上下文加上一个整体摘要。我的做法是每 10 轮对话让模型生成一次对话摘要然后把摘要 最近 3 轮原文作为新的上下文。这样既保留了关键信息又把输入 token 压到了原来的三分之一左右。实测回答质量没有明显下降偶尔在需要精确回忆细节的场景会差一点但可以通过需要时再调取原文来弥补。6.3 按任务复杂度分流模型不是所有任务都值得用旗舰模型。我给自己定了个简单的分流规则格式转换、简单问答、信息提取轻量模型代码生成、逻辑推理、长文写作主力模型复杂架构设计、多步推理、难题攻坚旗舰模型这个规则执行下来旗舰模型的调用占比从原来的 40% 降到了 10% 左右总成本直接砍掉一半多而实际体验几乎没变。因为大部分日常任务轻量和主力模型完全够用。6.4 监控和告警不能少最后一条也是最重要的一定要有用量监控。我给自己设了日用量阈值超过就告警。有一次某个自动化脚本出了 bug陷入了循环调用两小时烧了 2000 万 token。要不是有告警这个数字可能会翻好几倍。监控的粒度建议做到按天看总量、按模型看分布、按任务类型看消耗。这样一旦某个维度异常能立刻定位到具体是哪个环节在烧钱。7. 回到那个问题1.73 亿 token 到底值多少钱把前面所有分析收拢一下。1.73 亿 token 按官方价算答案是一个区间而不是一个数如果全部走旗舰模型约1.87 万元人民币如果全部走主力模型约3118 元人民币如果全部走轻量模型约234 元人民币按真实混合使用结构估算约4300 到 6500 元人民币这个区间跨度很大但每一个数字都是有依据的取决于模型档位、缓存命中率、输入输出比例这三个核心变量。任何脱离这三个变量给出的单一报价都是耍流氓。我自己 9 月的实际感受是token 花费这件事算清楚比省下来更重要。你只有先知道钱花在哪才知道该从哪里省。盲目砍上下文、盲目换小模型往往省了小钱亏了大钱——回答质量下降导致的返工消耗的 token 可能比省下来的还多。最后分享一个我踩过的坑早期我为了省 token把系统提示写得很短结果模型经常误解任务反复澄清输出 token 暴涨。后来把系统提示写详细了输入 token 是多了点但一次就能答对总成本反而降了。在提示词上花的 token是最值得花的 token这个道理我用了两个月才真正想明白。