1. 一笔1.73亿token的账，到底该怎么算

九月份的时候，我拿 WorkBuddy 跑了一整个月的自动化任务，月底看后台统计，消耗了 1.73 亿 token。这个数字第一次跳出来的时候我自己都愣了一下——不是心疼，是好奇：如果这些 token 全部按官方标价走，一分钱折扣都不打，到底要掏多少钱？

这个问题看起来简单，乘一下单价就完了，但真动手算你会发现坑不少。因为 token 分输入和输出，输出通常比输入贵好几倍；缓存命中的部分又有单独的折扣价；不同模型的单价差着数量级；再加上 WorkBuddy 这类工具在后台会自动做上下文压缩、历史裁剪、缓存复用，实际计费口径和你在对话框里看到的字数完全不是一回事。

所以这篇东西我打算把这件事彻底拆开讲。适合谁看？三类人：一是正在用或者准备用 WorkBuddy 做自动化、想知道成本天花板的；二是自己搭 API 调用、想搞明白 token 账单结构的；三是单纯好奇“1.73 亿 token”这个量级在真实世界里意味着什么钱的。我会把计算过程、参数选择、缓存机制、模型差异、以及我自己踩过的几个计费坑全部摊开讲，你照着抄就能算出自己的账。

先把结论的方向给出来：1.73 亿 token 按官方价算，落在几百到几万块人民币这个区间里，具体数字取决于你的输入输出比例、缓存命中率和用的什么模型。差距为什么这么大，往下看。

2. 先把 token 这件事说透，不然账算不明白

2.1 token 不是字，中文里一个 token 约等于 1.5 到 2 个汉字

很多人第一次接触 token 会下意识把它当成“字数”，这是算账出错的头号原因。token 是模型处理文本的最小单位，英文里大概 4 个字符算 1 个 token，中文里因为编码方式不同，通常 1 个汉字会被切成 1 到 2 个 token，平均下来 1 个 token 对应 1.5 到 2 个汉字。

我实测过一段 1000 字左右的中文技术文档，用常见的分词工具跑出来是 620 个 token 左右，比例大概是 1.6。这个比例会随文本内容浮动：代码、标点密集的文本 token 会偏多，纯口语化的中文偏少。所以当你看到“1.73 亿 token”，换算成汉字大概是 2.6 亿到 3.4 亿字，这个体量相当于把一套几十本的技术丛书来回读了几十遍。

为什么这个换算重要？因为你在估算成本时，如果拿“字数”去乘单价，结果会差出将近一倍。我见过有人按字数算完觉得“才几十块”，实际账单出来三百多，就是栽在这个换算上。

2.2 输入 token 和输出 token，价格能差 4 到 8 倍

这是第二个必须搞清楚的点。几乎所有主流模型的计费都分两档：输入（input / prompt）和输出（output / completion）。输入是你喂给模型的内容，输出是模型生成的内容。输出之所以贵，是因为生成过程需要逐 token 解码，算力消耗远大于读取。

拿几个常见模型的官方价举例（单位：每百万 token，人民币口径，具体以官方最新价为准）：

可以看到，输出单价普遍是输入的 2 到 4 倍，部分场景能到 8 倍。这意味着同样 1 亿 token，如果全是输出，成本可能是全是输入的 4 倍以上。所以算账时绝对不能拿一个平均单价去乘总量，必须把输入输出拆开。

WorkBuddy 这类自动化工具的特点是：输入侧会塞大量上下文（历史对话、工具返回结果、文件内容），输出侧相对精简（主要是决策和最终结果）。所以它的输入输出比例通常很悬殊，我自己的统计大概是 8:1 到 15:1 之间，也就是每产生 1 个输出 token，背后有 8 到 15 个输入 token 在支撑。

2.3 缓存命中：能把输入成本打到一折的隐藏开关

这是最容易被忽略、但对总账影响最大的一个机制。所谓缓存命中（cache hit），指的是你这次请求的输入内容，和之前某次请求的前缀高度重合，服务端直接把之前算好的中间状态复用，不用重新计算。命中缓存的那部分输入 token，价格通常只有正常输入价的 10% 到 25%。

为什么 WorkBuddy 这种工具特别吃缓存？因为它跑自动化任务时，系统提示词、工具定义、历史上下文这些内容在连续多轮里是高度重复的。一个设计良好的自动化流程，缓存命中率能到 70% 甚至 90% 以上。反过来，如果你的任务每次都是全新的、无关联的输入，缓存命中率可能只有个位数。

我九月份那 1.73 亿 token 里，根据后台的缓存统计，输入侧大约有 78% 是命中缓存的。这个比例直接决定了最终账单是“几千块”还是“几万块”。后面算账时我会把这个变量单独拎出来做敏感性分析。

3. 1.73 亿 token 的账单，我按三种口径算给你看

3.1 口径一：最贵的情况，全按旗舰模型无缓存算

先算最坏情况，让你知道成本天花板在哪。假设这 1.73 亿 token 全部走旗舰模型，输入输出按 10:1 拆分，且缓存命中率为 0。

拆分一下：输入约 1.573 亿 token，输出约 0.157 亿 token。

按旗舰模型输入 30 元/百万、输出 120 元/百万算：

• 输入成本：157.3 × 30 = 4719 元
• 输出成本：15.7 × 120 = 1884 元
• 合计：约 6603 元

如果输出比例更高，比如 5:1，输出变成 0.288 亿 token，输出成本涨到 3456 元，合计约 8175 元。如果全按最贵的档位且输出占比夸张，破万是很轻松的。这就是为什么有人听说“1.73 亿 token”会觉得要花好几万——他们默认了最贵口径。

3.2 口径二：中端模型加真实缓存命中率

现在换成更贴近实际的口径。我九月份的主力模型是中端档位，输入 4 元/百万、输出 12 元/百万，输入输出比 10:1，缓存命中率 78%。

关键来了：命中缓存的输入 token 按 10% 计价，也就是 0.4 元/百万。没命中的输入按 4 元/百万。

• 命中缓存的输入：1.573 亿 × 78% = 1.227 亿 token，成本 122.7 × 0.4 = 49 元
• 未命中的输入：1.573 亿 × 22% = 0.346 亿 token，成本 34.6 × 4 = 138 元
• 输出：0.157 亿 token，成本 15.7 × 12 = 188 元
• 合计：约 375 元

看到差距了吗？同样 1.73 亿 token，从 6603 元直接掉到 375 元，差了 17 倍。这里面缓存贡献了绝大部分降幅。这也是为什么我一直强调：算 token 账不算缓存，等于白算。

3.3 口径三：混合模型策略下的真实账单

实际生产中没人会全程用一个模型。我的策略是分层：简单任务（格式化、分类、提取）走轻量模型，复杂任务（推理、规划、代码生成）走中端或高端模型。九月份的大致分布是轻量 60%、中端 35%、高端 5%。

按这个分布重新算，输入输出比 10:1，缓存命中率统一按 75% 估：

这个数字比我预想的还低。原因在于轻量模型扛了六成流量，而轻量模型的单价只有高端模型的十几分之一。分层策略的价值在这里体现得淋漓尽致——如果全部走高端，同样的量要贵 20 倍以上。

所以回到标题那个问题：1.73 亿 token 按官方价到底多少钱？答案是：全旗舰无缓存约 6600 元，中端加真实缓存约 375 元，混合分层策略约 260 元。三个数字都是“按官方价”，差别全在口径上。你报哪个数，取决于你想表达什么。

4. 缓存命中率是怎么被 WorkBuddy 拉上去的

4.1 系统提示词和工具定义是缓存的主力

WorkBuddy 每次调用模型，都会带上一大坨固定内容：系统提示词、可用工具列表、工具的参数 schema、当前工作目录结构、历史对话摘要。这些内容在同一个会话的连续多轮里几乎不变，天然就是缓存的最佳素材。

我抓过一次实际请求，单次调用的输入里，固定部分占了大约 65%，动态部分（用户新指令、工具返回结果）只占 35%。也就是说，只要缓存机制正常工作，这 65% 就能按一折计价。这是自动化工具相比手动对话的巨大优势——手动对话每轮输入差异大，缓存命中率上不去。

4.2 前缀稳定性决定缓存能不能命中

缓存不是自动生效的，它要求请求的前缀完全一致。什么意思？如果两次请求的开头部分逐 token 相同，从第一个不同的 token 开始，后面的内容才需要重新计算。所以缓存命中的关键不是“内容相似”，而是“前缀相同”。

这就带来一个实操要点：把变化的内容尽量往后放。比如系统提示词、工具定义这些固定内容放最前面，用户指令、动态数据放后面。如果你把时间戳、随机 ID 这种每次都变的东西塞在开头，缓存直接全废。

我踩过这个坑。早期我的一个任务模板里，开头带了个当前时间戳，结果缓存命中率只有 12%，账单比预期高了四倍。把时间戳挪到末尾之后，命中率飙到 80% 以上。这个改动花了我五分钟，省下的钱够吃好几顿火锅。

4.3 缓存有有效期，别指望隔天还能命中

缓存不是永久的，各家服务商的缓存存活时间不一样，短的几分钟，长的几小时，很少有超过一天的。这意味着如果你的自动化任务是低频的、间隔很久才跑一次，缓存基本帮不上忙。

WorkBuddy 跑批量任务时，连续调用之间的间隔通常很短（秒级到分钟级），正好落在缓存有效期内，所以命中率能维持在高位。但如果你的任务是每天定时跑一次，每次跑之前缓存早就过期了，那就要按无缓存来估算成本。这一点在做预算时特别重要，别拿高频场景的命中率去套低频场景。

5. 模型选型：省钱的真正杠杆在这里

5.1 不是所有任务都配得上旗舰模型

我见过太多人上来就全量走旗舰模型，理由是“效果最好”。效果确实好，但成本也是真的高。问题在于，很多任务根本用不上旗舰模型的推理能力。

举个例子：从一段文本里提取人名和公司名，这种任务轻量模型做得又快又准，成本只有旗舰的几十分之一。你拿旗舰模型去做，纯属浪费。反过来，涉及多步推理、代码调试、复杂规划的任务，轻量模型会频繁出错，重试几次的成本反而超过直接用旗舰。

我的判断标准很简单：任务能不能用一句话描述清楚规则。能，就走轻量；不能，需要模型自己“想”，才上高端。按这个标准，我九月份六成流量走了轻量模型，效果没打折扣，账单直接砍半。

5.2 分层路由的实操配置

具体怎么落地？我在 WorkBuddy 里配了一套路由规则，核心逻辑是根据任务类型打标签，再映射到模型档位。大致长这样：

routing_rules: - task_type: "extract" # 信息提取、格式化 model: "light" max_tokens: 1024 - task_type: "classify" # 分类、打标 model: "light" max_tokens: 256 - task_type: "summarize" # 摘要、改写 model: "mid" max_tokens: 2048 - task_type: "reason" # 推理、规划 model: "mid" max_tokens: 4096 - task_type: "code" # 代码生成、调试 model: "high" max_tokens: 8192

这套规则跑下来，最贵的 code 类任务只占 5% 左右，但它贡献了大部分价值。轻量任务占了六成，成本几乎可以忽略。这就是分层的意义：把好钢用在刀刃上。

5.3 max_tokens 设太大是隐形浪费

还有一个细节：max_tokens参数。它限制的是输出长度上限，但很多人习惯性设成 4096 甚至 8192，觉得“留足空间”。问题是，模型有时候会“话痨”，明明一句话能说完，非要展开写一大段。输出 token 单价高，这一浪费就是真金白银。

我的做法是按任务类型卡死上限：分类任务 256 足够，提取任务 1024，摘要 2048，只有代码和长文生成才给到 4096 以上。实测下来，输出 token 量降了大约 30%，效果没有任何损失。这个参数调整是零成本的，改个数字就行，性价比极高。

6. 那些让我多花钱的坑，一个个说

6.1 上下文无限累积，token 悄悄翻倍

自动化任务最容易犯的错，是把历史对话无脑全塞进上下文。跑个十几轮之后，输入 token 量会指数级膨胀。我早期有个任务，跑到第 20 轮时单次输入已经涨到 8 万 token，而其中真正有用的信息不到 5%。

解决办法是滑动窗口加摘要。只保留最近 N 轮完整对话，更早的内容压缩成一段摘要。WorkBuddy 支持配置窗口大小，我一般设 6 到 10 轮，再往前就摘要。这样输入 token 能稳定在一个可控范围，不会随轮次无限增长。

提示：窗口大小不是越大越好。窗口越大，单次成本越高，但能减少摘要带来的信息损失。我的经验值是 8 轮左右，兼顾成本和连贯性。

6.2 重试机制没设上限，失败任务烧钱

网络抖动、服务限流、模型偶发报错，这些都会触发重试。如果重试没有上限，一个卡住的任务可能反复调用几十次，每次都烧 token。我遇到过一次，某个任务因为返回格式解析失败，自动重试了 47 次，白白烧掉几百万 token。

现在的做法是：重试最多 3 次，且每次重试前先检查错误类型。如果是格式问题，先修正解析逻辑再重试；如果是限流，退避等待；如果是输入本身有问题，直接标记失败，不重试。这个改动之后，异常任务的 token 消耗降了 90% 以上。

6.3 把大文件整个塞进去，不如先切片

处理文档类任务时，很多人图省事，把整个文件内容一次性喂给模型。一个 5 万字的文档就是 3 万多 token，如果任务只需要其中一段，剩下的全是浪费。

正确做法是先做检索或切片，只把相关片段送进模型。WorkBuddy 可以配合本地检索工具，先定位相关段落，再喂给模型。这样单次输入能从几万 token 降到几千，成本差一个数量级。我处理长文档任务时，基本都会先过一遍切片逻辑，这一步省下的钱非常可观。

6.4 常见问题速查表

7. 把账算准的几个实操建议

7.1 先跑一周采样，再推全月

别一上来就按理论值估全月成本，误差会很大。我的做法是先跑一周，记录真实的输入输出比、缓存命中率、各模型占比，然后按这一周的数据外推。九月份我就是这么干的：第一周采样显示日均 580 万 token，缓存命中率 76%，外推全月约 1.74 亿，和最终实际的 1.73 亿几乎吻合。采样一周的成本很低，但能让你的预算准确度提升一个档次。

7.2 给账单设个告警线

再好的估算也架不住意外。我给自己设了日消耗告警线，超过阈值就暂停任务排查。这个阈值怎么定？按你的预算除以 30，再上浮 50%。比如月预算 500 元，日告警线设 25 元。触发告警不一定是出问题，但至少让你有机会在账单失控前介入。我靠这个机制抓到过两次异常，一次是重试风暴，一次是某个任务死循环，都在烧掉几十块的时候就掐断了。

7.3 定期复盘模型占比，别让高端模型悄悄膨胀

分层策略配好之后不是一劳永逸的。随着任务迭代，可能会有越来越多任务被归到高端模型，成本悄悄爬升。我每两周复盘一次各模型的 token 占比，如果高端模型占比超过 10%，就回头看看有没有任务可以降级。这个习惯让我把高端占比长期压在 5% 左右，省下的都是纯利润。

7.4 缓存命中率要当成核心指标盯

如果只能盯一个指标，我选缓存命中率。它直接决定输入成本是打一折还是全价，杠杆效应最大。低于 50% 就要查原因，低于 30% 基本说明请求结构有问题。我现在的日常命中率稳定在 75% 到 85% 之间，偶尔掉下来就立刻排查，通常都是某个新任务的前缀不稳定导致的。

8. 回到那个问题：到底多少钱

把前面所有变量收拢一下。1.73 亿 token 按官方价，成本区间大致是：

• 全旗舰、无缓存、输出占比高：8000 到 12000 元
• 全旗舰、无缓存、常规比例：6000 到 7000 元
• 中端模型、真实缓存命中率：350 到 450 元
• 混合分层、优化到位：250 到 350 元

这四个数字都是“按官方价”算出来的，没有用任何折扣或赠送额度。差别全在口径：模型档位、输入输出比、缓存命中率、分层策略。所以下次有人问你“1.73 亿 token 多少钱”，你可以反问他：你说的哪种口径？

我自己九月份的实际支出落在最后一档，两百多块。这个数字背后是三个月的持续优化：从最初的全量旗舰、缓存命中率 12%、月账单逼近五千，一路调到分层路由、命中率 80%、月账单两百多。省下的钱是次要的，更重要的是这套方法论可以复用到任何 token 计费场景——不管你是用 WorkBuddy、自己调 API，还是接别的工具，算账的逻辑是相通的。

最后分享一个我最近在试的小技巧：把缓存命中率和 token 消耗做成一张日报表，每天扫一眼。数据一旦可视化，异常会自己跳出来，比等到月底看账单再拍大腿强得多。这个习惯我坚持了两个月，再没出现过成本失控的情况。