4000 积分在 WorkBuddy 里用 DeepSeek V4.1 Flash，到底能跑多少 token？

按我在 2026 年 10 月 17—28 日的 Magpie 使用记录，把同一批任务的 token 构成保持不变，再分别折算成全部忙时、全部闲时：4000 积分约对应 17.3 亿或 34.6 亿 token，均包含缓存读取。 如果只统计未缓存输入与输出，则分别约为 8370 万和 1.67 亿 token。

这是个人历史用量的经验换算，不是官方承诺的积分兑换比例。文章整理于 2026 年 10 月 29 日，测算沿用截至 10 月 28 日的样本。

4000 积分的使用方式总 token，含缓存读取未缓存输入＋输出，不含缓存读取其中输出，含推理
全部在忙时使用，统一构成估算约 17.3 亿约 8370 万约 801 万
全部在闲时使用，统一构成估算约 34.6 亿约 1.67 亿约 1603 万
按原样本的忙闲混合使用比例折算约 24.0 亿约 1.16 亿约 1113 万

三行都以 4000 积分为预算。前两行是统一任务构成后的情景估算，第三行是历史混合用量的直接折算；它们不是三次各花掉 4000 积分的独立实验。表中数值经过四舍五入。

“含缓存”和“不含缓存”，究竟差在哪里？

这批记录将 token 分为未缓存输入、缓存读取和输出。本文采用：

  • 含缓存总量＝未缓存输入＋缓存读取＋输出。
  • 不含缓存总量＝未缓存输入＋输出。
  • 推理 token 已包含在输出中，不再重复相加。

缓存读取通常来自重复使用的上下文，例如多轮任务里反复带入的历史消息、代码和说明。同一段上下文被多次读取，会多次计入累计 token，因此几十亿 token 不等于几十亿独立文字，更不等于模型新写出了几十亿 token。

这里还有一个容易误解的地方：“不含缓存”只是统计时去掉缓存读取这一项，并不是把缓存关闭以后重新测算。 两列仍然来自同一批有缓存复用的任务，积分也包含这些缓存读取的消耗。如果所有重复上下文都要按未缓存输入计费，4000 积分能支持多少用量，需要另算，不能直接照搬表格。

所以，看整体处理规模，可以看含缓存总量；看未缓存输入和输出的规模，可以看第二列；想知道模型生成了多少内容，应看输出列，而且其中还包含推理，不能全当成用户最终看到的正文。

闲时不只在深夜。

截至本文核对时，DeepSeek 官方的分时定价按北京时间划分：

时段时间范围
忙时周一至周五，非中国法定节假日的 09:00—12:00、14:00—18:00
闲时上述日期的 00:00—09:00、12:00—14:00、18:00—24:00，以及周末和中国法定节假日全天

官方价目表中，Flash 的缓存命中输入、未命中输入和输出三项，闲时单价均为忙时的一半。来源：DeepSeek 模型与价格

我此前对 Magpie 记录按北京时间分段，观察到 WorkBuddy 的积分扣减变化与这套忙闲时分段、闲时半价关系吻合，因此用它来归一化样本。这里需要区分证据：DeepSeek 官方页面说明的是 API 定价；本文的 WorkBuddy 积分换算依据是我的个人扣分记录。 本次查到的 WorkBuddy 积分说明没有给出这套完整的分时扣分表，不能把 API 价目表直接当作 WorkBuddy 对所有账号的积分承诺。

WorkBuddy 官方说明，积分消耗与所选模型及任务复杂度有关。具体使用时，仍应以端内显示和实际扣分为准。来源：WorkBuddy 积分说明

这笔账是怎么算出来的？

原测算只保留 Magpie 中 provider 为 WorkBuddy、模型为 deepseek-v4.1-flash、请求成功且有正数扣分记录的调用。样本共 26,599 次，未纳入另外两次带扣分的非成功请求，也没有混入其他模型。

原样本项目合计
实际消耗积分6974.26
未缓存输入183,265,379 token
输出，已含推理19,413,193 token
缓存读取3,989,966,336 token
含缓存总量4,192,644,908 token
未缓存输入＋输出202,678,572 token

直接用“样本 token ÷ 样本积分 × 4000”，得到的是忙闲混合情况下约 24 亿含缓存 token、约 1.16 亿不含缓存 token。

要比较忙时和闲时，不能把这个混合结果直接乘二。因为原来的 6974.26 积分里，已经有一部分请求享受了闲时价格。

原样本中，忙时扣分为 4258.82，闲时扣分为 2715.44。保持全部 token 构成不变，按闲时半价的关系，将其统一到忙时价格：

全部忙时的等效积分＝4258.82＋2715.44×2＝9689.70。

全部闲时的等效积分＝9689.70÷2＝4844.85。

再分别用样本 token 除以这两个等效积分、乘以 4000，就得到表格中的忙时与闲时结果。这里的两倍关系来自相同任务构成下的半价假设，并不意味着任何两批白天和夜间任务的实测 token 都一定相差两倍。

为什么含缓存的数字这么大？

这批样本的输入缓存命中率约为 95.6%，计算方式是“缓存读取 ÷（未缓存输入＋缓存读取）”。也就是说，输入中绝大部分是缓存读取，因而含缓存累计 token 很大。

如果换成频繁更换上下文、缓存复用较少的任务，或者生成更长的输出，同样 4000 积分对应的 token 量就会变化。任务类型、上下文构成和输出比例，都比一个孤立的“每积分多少 token”更值得关注。

样本窗口也会影响结果。原测算另外只取了 10 月 22—28 日的记录，用同样方法归一化，得到全部闲时约 31.1 亿含缓存 token、约 1.72 亿未缓存输入加输出。全样本的对应结果则是约 34.6 亿和 1.67 亿。含缓存总量减少而不含缓存量略增，正说明两种口径不能互相替代。

因此，按我这段时间的使用方式，4000 积分在闲时可暂按 31—35 亿含缓存 token、约 1.7 亿未缓存输入加输出理解；记一个方便的预算数，就是约 33 亿含缓存 token。这个区间来自两个历史样本窗口，不是统计置信区间，也不是最低保障额度。

对不急着完成的批量任务，午间、晚间或周末值得作为调度时间。但 token 多不自动等于完成的任务多：结果是否可用、是否需要反复返工，最终也会影响积分能做多少事。后续模型价格、平台折扣或自己的使用方式发生变化时，这笔账都应重新估算。