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人民币口径具体以官方最新价为准模型档位输入单价输出单价输出/输入倍率轻量级模型约 1 元约 2 元2 倍中端模型约 4 元约 12 元3 倍高端模型约 15 元约 60 元4 倍旗舰模型约 30 元约 120 元4 倍可以看到输出单价普遍是输入的 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% 估模型档位token 占比输入成本输出成本小计轻量1/2元60%约 30 元约 38 元68 元中端4/12元35%约 52 元约 66 元118 元高端15/60元5%约 28 元约 47 元75 元合计100%——约 261 元这个数字比我预想的还低。原因在于轻量模型扛了六成流量而轻量模型的单价只有高端模型的十几分之一。分层策略的价值在这里体现得淋漓尽致——如果全部走高端同样的量要贵 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 常见问题速查表现象可能原因排查方向解决动作账单远超预期缓存命中率低检查请求前缀是否稳定把变化内容后置单次输入 token 暴涨上下文无限累积看轮次与输入量关系配滑动窗口加摘要异常任务烧钱重试无上限查失败任务调用次数限制重试次数输出 token 过多max_tokens 设太大对比实际输出与上限按任务卡死上限低频任务成本高缓存过期看任务间隔时间按无缓存估算预算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 消耗做成一张日报表每天扫一眼。数据一旦可视化异常会自己跳出来比等到月底看账单再拍大腿强得多。这个习惯我坚持了两个月再没出现过成本失控的情况。
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人民币口径具体以官方最新价为准模型档位输入单价输出单价输出/输入倍率轻量级模型约 1 元约 2 元2 倍中端模型约 4 元约 12 元3 倍高端模型约 15 元约 60 元4 倍旗舰模型约 30 元约 120 元4 倍可以看到输出单价普遍是输入的 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% 估模型档位token 占比输入成本输出成本小计轻量1/2元60%约 30 元约 38 元68 元中端4/12元35%约 52 元约 66 元118 元高端15/60元5%约 28 元约 47 元75 元合计100%——约 261 元这个数字比我预想的还低。原因在于轻量模型扛了六成流量而轻量模型的单价只有高端模型的十几分之一。分层策略的价值在这里体现得淋漓尽致——如果全部走高端同样的量要贵 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 常见问题速查表现象可能原因排查方向解决动作账单远超预期缓存命中率低检查请求前缀是否稳定把变化内容后置单次输入 token 暴涨上下文无限累积看轮次与输入量关系配滑动窗口加摘要异常任务烧钱重试无上限查失败任务调用次数限制重试次数输出 token 过多max_tokens 设太大对比实际输出与上限按任务卡死上限低频任务成本高缓存过期看任务间隔时间按无缓存估算预算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 消耗做成一张日报表每天扫一眼。数据一旦可视化异常会自己跳出来比等到月底看账单再拍大腿强得多。这个习惯我坚持了两个月再没出现过成本失控的情况。
