我想给一份长文档做缓存，开之前顺手去核了一下单价，在模型详情页上看到这么一行：缓存存储 0.017 元/百万 tokens/小时。前头的输入、输出、缓存命中都写着「元/百万 tokens」，唯独这一项后头多挂了个「/小时」。我盯着那个斜杠愣了一下——省下来的钱是一次性的，存着的钱是按钟点走的。数字取自火山方舟控制台 Doubao-Seed-2.1-pro 模型详情页与豆包大模型定价页，2026-09-27 抓取，具体以页面和账单为准。
我把计费单位抄下来，才看清它是租的不是买的
页面上这一组数是这么摆的：Doubao-Seed-2.1-pro 推理输入 6 元每百万 tokens，输出 30 元，缓存命中 1.2 元，缓存存储 0.017 元每百万 tokens 每小时。Turbo 那一行是输入 3 元、输出 15 元、命中 0.6 元，存储照样是 0.017。
前三项都得等到一次请求进来才记账，最后一项不一样，它认的是时间。计费方式在文档里写得很直白：按每个自然小时里用缓存的最大量乘单价累加，不足一小时按一小时算；费用在创建缓存那一刻就产生，一直到这份缓存被删掉才停。
这两句话合起来，意思是：我只跑十分钟的任务，也按一小时付；任务跑完我忘了删，它就一直收到我删为止。以前我只盯着命中价是输入价的两折这一层，压根没往「放着也要钱」上想。
我把两笔账拉到同一把尺子上，算出来一个不太舒服的结果
同一份缓存，一边在省钱一边在花钱。我把两边的数都折成「每百万 token」来比。
命中一次省下多少：pro 是 6 减 1.2，得 4.8 元；turbo 是 3 减 0.6，得 2.4 元。
存着要花多少：一小时 0.017 元，一天 0.408 元，七天一百六十八小时，是 2.856 元。
两列并排放：
存一天 0.408 元，turbo 命中一次省 2.4 元，租金占收益的百分之十七，还有得赚。
存七天 2.856 元，turbo 命中一次省 2.4 元，租金是收益的 1.19 倍，倒贴 0.456 元。
存七天 2.856 元，pro 命中一次省 4.8 元，租金占收益的百分之五十九点五，净剩 1.944 元。
也就是说，在便宜那档模型上，把一份缓存存到文档写的上限七天，光租金就比它命中一次省下的钱还多出一成九。想回本，至少得在这七天里命中两次。
换算成时间更好记：turbo 上的回本线是 141.2 小时，差不多 5.9 天；pro 上是 282.4 小时，差不多 11.8 天。过了这个点还没人来问第二个问题，这份缓存从省钱变成了花钱。
还有一层是我算完才反应过来的：这笔账跟缓存多大没关系。租金和收益都按每百万 token 走，两边一约，倍数就消掉了。我拿 pro 新版那一款的一百零二万四千满窗验算了一遍——存七天 2.925 元，命中一次省 4.915 元；换成 turbo，存七天还是 2.925 元，命中一次只省 2.458 元。比例跟一百万那组分毫不差。所以别去纠结「我的文档太长了，缓存会不会不划算」，长不长短不了这个比值，真正管事的是多久复用一次。
还有一层是我算之前完全没想到的：缓存只动输入那一半。输出那 30 元一点没降。拿一轮一千 token 进、一千 token 出的对话算，不用缓存是 0.006 加 0.03，一共 0.036 元；输入全命中之后变成 0.0012 加 0.03，是 0.0312 元。命中率给到百分之百，整轮也就省下百分之十三点三。钱的大头压在输出上，这就是很多人开了缓存、账单却没怎么动的原因。
还有个上限我顺手记了下来：文档里写，一次能缓存的最大长度是上下文窗口减去最大输出长度。pro 的新版窗口一百零二万四、最大输出二十五万六，减完是七十六万八——能租出去的地方比窗口本身小四分之一。按这个数存七天是 2.193 元，turbo 上命中一次省 1.843 元，照样是倒贴。
一句话先记住：缓存划不划算，跟文档多长无关，只跟多久再问一次有关。
我又翻到批量那一栏，缓存折扣当场缩水
同一个页面往下就是批量推理的价格：批量输入 3 元、输出 15 元、批量缓存命中 1.2 元。
我拿计算器对了两遍：在线那组里，命中 1.2 是输入 6 的两成；批量这组里，命中 1.2 成了输入 3 的四成。命中这一项的价格没动，动的是它旁边那个参照物——批量先把输入砍了一半，缓存再打的那道折就只剩一半了。
落到省下的钱上：在线命中一次省 4.8 元，批量命中一次只省 1.8 元，剩下百分之三十七点五。回本线也跟着从 282.4 小时压到 105.9 小时，不到 4.4 天。
这里头有个容易想岔的地方：批量五折和缓存两折不是相乘的，它们是叠在同一段 token 上的两道折。同一段内容不可能既算批量的便宜输入、又算缓存的深度折扣，你只能吃其中更狠的那道。所以真跑批量的时候，我不再把成本模型押在缓存命中率上了，能走批量本身就是更大的那道折。
照这张表，我给自己定了四条
第一，保留时长按复用频率定，不按「拉满更保险」定。文档里两种模式的到期方式还不一样：一种是配一个保存时长，计时用当前时刻减最近使用时刻，用一次就重置一次，等于能续命；另一种是配一个固定的到期时刻，最大到当前时间加 604800 秒，也就是七天，用多少次都不重置，到点就没。打算一周才问一次的长期活儿，我选能续命的那种；打算七天里集中跑完一批，后者够用了。
顺带补一条免租的出路：那张对比表里，自动生效、不用我动手的隐式缓存，存储这一栏写的是不计费——它只在命中的时候收钱，代价是命中不由我说了算，内容太短也不会被缓存。真不想操心租金，就拿它兜底，别去碰要交租的那两种。
第二，短任务跑完就删。不足一小时按一小时，创建即计费，删掉才停。这条对一次性脚本特别重要，跑完就扔的缓存留着纯属给账单添数。
第三，命中没命中别靠猜。返回的 usage 里有个 prompt_tokens_details.cached_tokens，那就是这一轮真正吃到折扣的 token 数。我以后调缓存先看这个数，再决定是继续存还是删掉。
第四，一周才问一次的长文档，老实重发比存着便宜。按上面的表，turbo 上第五点九天就是分界线，过了这条线，缓存从省钱翻成花钱。
需要说清楚：上面这些全是我按页面单价乘出来的算术，不是真跑出来的账单，实际还受命中率、请求路由这些变量影响。我核的是规则，不是结果。
你手上那份要反复问的长文档，一般隔多久会再问第二次？
本文含 AI 辅助创作内容：资料检索与初稿由 AI 完成，观点梳理、数据核验与编校由人工完成。