上下文涨价后：用豆包算清 4 档用量成本

长上下文的计价规则一改，账单比预期高出一截，很多人第一反应是「用得多了」，其实是单价在 32K 处跳了一档。这次按每天 200 次、4 档上下文长度算清：8K 每月 384 元、24K 1,152 元、48K 2,688 元、96K 6,144 元。同样是翻倍，24K 到 48K 的成本涨了 2.33 倍，不是 2 倍。

一句话结论

长上下文计费不是一条直线，是一条在 32K 处折了一下的线：32K 以内每千 token 0.008 元，超出部分 0.012 元，贵 50%。所以判断成本不能看「平均每次多少 token」，要看有多少次越过了 32K。这次的 4 档测算里，96K 的 token 是 24K 的 4 倍，成本却是 5.33 倍——多出来的 1.33 倍，全是那 50% 的单价差。

这篇解决什么问题

三种算错方式最常见。一是用平均长度估成本：平均 24K 听起来没超线，但实际有一半请求在 48K 以上，按平均算出来的账单永远对不上。二是按倍数线性推：以为 token 翻倍成本就翻倍，实际越过 32K 后每千 token 单价变了，推算结果偏低三分之一。三是只看总额不看结构：账单涨了就说「用量大了」，不去看是哪几类请求把长度推上去的，结果优化方向找错。

根子是把长上下文当成一个整体的量，而它其实是分段计价的两段。两段的单价不同，那么「把长请求压到 32K 以内」这件事的价值，比「整体减少 10% 调用量」大得多。

开始前要准备什么

• 计价规则原文：分段阈值、每段单价、是否含输出 token。这次是 32K 以内 0.008 元/千 token，超出 0.012 元。
• 每次请求的上下文长度记录：要逐条的，不要日均值。没有的话从调用日志里统计。
• 调用量：这次每天 200 次、按 30 天算 6,000 次/月。
• 一条纪律：按档位算，不按平均值算。平均值会把两段的成本糊在一起，算出来的数没法用来做决策。

具体怎么做

第一步：拉出长度分布，先看有多少次越过 32K

不要用日均或均值。从调用日志里按「每次请求的输入 token 数」拉分布，看落在 0 到 32K、32K 到 64K、64K 以上各占多少。这次 6,000 次里，32K 以内的占 42%、32K 到 64K 占 38%、64K 以上占 20%——将近六成请求越过了跳点，这才是账单超预期的真正原因。

这一步的意义在于把「多少钱」变成「哪些请求贵」。如果只看总额，会得出「整体要省 30%」这种没法执行的结论；看了分布，才知道要做的是把那 58% 的长请求筛短，而不是把所有调用都砍掉三成。

这是我的调用日志摘要：每月 6,000 次请求，上下文长度分布为 32K 以内 42%、32K 到 64K 38%、64K 以上 20%。

计价规则：32K 以内 0.008 元/千 token，超出 32K 部分 0.012 元/千 token。

请帮我：
1. 按 8K、24K、48K、96K 四档，算出每一档的单次成本与月成本；
2. 算出「token 翻倍时成本涨几倍」，并解释为什么不是 2 倍；
3. 指出 32K 这个阈值对总成本的影响有多大，用具体金额说明；
4. 给出三个不同的缩短方案，各自预计省多少，按性价比排序。

要求：每一档都要写算式；不要用平均值估算，按档位分别算。

第二步：算出四档成本，找出斜率变化点

单次成本这么算：8K = 8 × 0.008 = 0.064 元；24K = 24 × 0.008 = 0.192 元；48K = 32 × 0.008 + 16 × 0.012 = 0.448 元；96K = 32 × 0.008 + 64 × 0.012 = 1.024 元。乘 6,000 次，月成本分别是 384 / 1,152 / 2,688 / 6,144 元。注意这四个数是「假设全部请求都是这一个长度」的口径，用来看斜率，不等于真实账单——真实账单是三种长度混在一起，后面单独算。

三个比值能说明全部问题：48K 是 24K 的 2.33 倍（token 只涨 2 倍）；96K 是 24K 的 5.33 倍（token 涨 4 倍）；而 32K 处单次成本是 0.256 元、月 1,536 元——越过这条线之后，每多 1K 要多付 0.012 元，是线内的 1.5 倍。这就是为什么「把 96K 压到 24K」比「所有调用打七折」省得多。

已知：32K 以内 0.008 元/千 token，超出部分 0.012 元/千 token；每月 6,000 次请求。

我已算出四档月成本：8K 384 元、24K 1,152 元、48K 2,688 元、96K 6,144 元。

请继续：
1. 验证这四个数是否正确，逐步列出算式，有错请指出；
2. 算出把 96K 的请求压到 24K 以内能省多少，压到 32K 以内能省多少，两者差多少；
3. 评估三种缩短手段的成本：切片检索、先摘要后提问、换更小的模型做预筛，分别说明它们会不会引入额外调用；
4. 给出一个判断口径：什么情况下值得为省成本改架构，什么情况下不值得。

要求：省下的金额要用数字给，不要说「显著降低」；额外调用带来的成本也要算进去，不能只算省的。

第三步：按「筛到 32K 以内」改造，回算真实节省

缩短的思路不是「少问点」，是把不相关的内容留在外面。这次的做法是切片加关键词检索：先把长文档切成 2,000 字左右的块，按问题关键词召回 8 到 10 块，拼成 24K 以内的上下文再发请求。改造后 96K 那档全部落到 24K，单次从 1.024 元降到 0.192 元。

要诚实算上额外成本：检索本身用本地关键词匹配，没有额外调用；但如果用模型做相关性筛选，就多一次小请求。这次的方案是关键词加人工规则，零额外调用，所以 96K 那 1,200 次的月成本从 1,228.8 元降到 230.4 元，省 998.4 元；如果连 48K 那 2,280 次一起压到 24K，总成本从 2,734.08 元降到 1,152 元，省 1,582.08 元。换用模型筛选的话，多出来的小请求本身也是钱，得一起算进去才准。

我准备用「切片 + 关键词召回」把长上下文压到 24K 以内，先解决 96K 那 20% 的请求。

请帮我：
1. 设计切片与召回的具体参数：块大小、召回块数、拼接顺序，要保证结果落在 24K 以内；
2. 指出这种改造会损失什么（哪些信息一定被丢掉），并给出验证方法证明损失可接受；
3. 回算改造后的月成本，与改造前对比，写清每月省多少、多久回本（按改造投入 3 个工作日算）；
4. 指出哪一类请求不适合这种改法，需要保留长上下文。

要求：参数要具体到数字；节省金额要与前面的四档成本对得上；改造投入要折算进回本周期。

实测记录

测算基于真实计价规则（32K 以内 0.008 元/千 token，超出 0.012 元）与每月 6,000 次调用。四档测算 25 分钟，方案设计与回算 35 分钟，合计 60 分钟。

结果：8K 384 元/月、24K 1,152 元、48K 2,688 元、96K 6,144 元。关键比值：48K 是 24K 的 2.33 倍（token 仅 2 倍），96K 是 24K 的 5.33 倍（token 4 倍）。32K 分界的单次成本是 0.256 元、月 1,536 元，越过之后每千 token 单价从 0.008 涨到 0.012。

实际账单按三种长度混合算：42% 的请求 2,520 次 × 0.192 元 = 483.84 元，38% 的 2,280 次 × 0.448 元 = 1,021.44 元，20% 的 1,200 次 × 1.024 元 = 1,228.8 元，合计 2,734.08 元/月。改造后把 96K 那 1,200 次压到 24K 以内，单次从 1.024 元降到 0.192 元，这部分的 1,228.8 元变成 230.4 元，省 998.4 元（降 36.5%）；再把 48K 那 2,280 次也压到 24K，总成本降到 1,152 元，省 1,582.08 元（降 57.9%）。整个改造按 3 个工作日折算投入，第一周就回本。

最容易错的 3 个地方

第一，用平均长度估成本。平均 24K 看着没超线，但这次 58% 的请求其实在 32K 以上，平均值把所有长度摊平了。按均值算出来的月成本会比实际低一大截，而且会误导你以为「不用优化」。

第二，按 token 倍数线性推成本。token 从 24K 到 48K 是 2 倍，成本是 2.33 倍；96K 是 4 倍 token，成本 5.33 倍。按线性推会低估三分之一以上，做预算时这个误差足以让决策跑偏。

第三，只算省的不算新增的。切片检索若用模型做筛选，那次调用本身也要钱：省 998.4 元却新增 400 元成本，实际只省 598.4 元，回本周期得重算。

可复用的东西

四档测算法：8K / 24K / 48K / 96K 各算单次与月成本，一次看清斜率在哪变。

盯住阈值不盯均值：先统计有多少次请求越过分段点，这比平均长度有用得多。

两个比值当体检指标：48K÷24K 应约 2.33、96K÷24K 应约 5.33，对不上说明单价规则理解错了。

筛到阈值以内：切片加关键词召回，把长请求压回低价段，比整体减少调用量有效。

额外成本一起算：检索、预筛如果用了模型，都要算进回本周期。

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接