一个真实的月度 AI 账单是怎么构成的

月底登录后台，账单页只有一行字：本月消费，一个数。

这个数就是全部信息。它不告诉你钱花在了哪一步，也不告诉你哪一部分本来可以不花。于是绝大多数公司对这笔支出的管理动作只有一个——看它有没有比上个月多。多了就皱眉，少了就放心。

这一篇要做的事很窄：把这个总数拆成它本来应该有的样子。拆完之后你会发现，最容易被忽略、也最容易被省掉的那一项，既不是"用了太贵的模型"，也不是"提示词写太长"，而是同一份内容被按原价重复送了上万次。

先把口径写在最前面，免得后面被当成报价单：

本文给的是账单的构成与口径，金额是按各家官方挂牌价演算的示例，不是任何一家的实际账单。 引用的定价页与计费文档，页面本身都没有标注更新日期，我们只能如实写"该页面未标注更新日期"，不替它编一个。价格随时会变，口径不会。你要记住的是行，不是数。

一、一张月度账单该有的九行

供应商的账单通常只给你一个总数，最多再给一张按天的曲线。所以下面这张表不是"账单长什么样"，是你自己要把那个总数拆成什么样。九行，前四行是主体，后五行是漏的地方。

这九行里，第 2 行和第 3 行是本文的重点，因为它们是唯一一组"你什么都不改，只把开关拨对，账单就会掉一大截"的行。其余各行要省，多半得动业务。

先给第 1 行和第 4 行的量级感，用一家公开挂牌、且把三档价格分开印出来的供应商作例子。据 DeepSeek 官方 API 定价页（单价采集于 2026 年 8 月 18 日。本文首发于 2026 年 4 月 10 日，而这一家在 2026 年 8 月 16 日 16:00 UTC 改成了高峰 / 低谷两档计价并全线上调，所以本节的单价与后面整节演算都按新快照重算了一遍），V4-Flash 每百万 token 的高峰价格是：输入（未命中缓存）$0.44、输入（命中缓存）$0.014、输出 $1.32；V4-Pro 是输入（未命中缓存）$1.32、输入（命中缓存）$0.044、输出 $3.96。低谷价是以上各数的一半。

三个数并排放，两件事一眼可见：输出价是未命中输入价的 3 倍；而未命中输入价是命中输入价的约 31 倍。（$0.44 ÷ $0.014 ≈ 31，这一步除法是我们自己算的，分子分母就是上面那两个挂牌价。）

大多数人盯着第一个倍数，去优化"少让它说废话"。而第二个倍数比第一个大 10 倍。

二、把一个月的量真的算一遍

抽象的倍数没有说服力，下面把一个具体场景的账算完。用量是本文设定的假设值，不是任何一家企业的真实数据；单价用上面那份挂牌价。

场景：一个接待型的问答助手。每次调用送进去两段内容——一段是固定不变的产品说明与回答规则，约 3,000 token；一段是客户当次问的话，约 200 token。它回答约 300 token。每天 500 次，一个月按 30 天算。

先算量：

• →月调用次数：500 × 30 = 15,000 次
• →月输入总量：15,000 × 3,200 = 48,000,000 token = 48 百万
• →月输出总量：15,000 × 300 = 4,500,000 token = 4.5 百万

跑法 A：全部按未命中价走（也就是缓存根本没开，或者开了没命中）。

• →输入：48 × $0.44 = $21.12
• →输出：4.5 × $1.32 = $5.94
• →合计：$27.06

跑法 B：那 3,000 token 的固定部分全部命中缓存。

• →命中部分：15,000 × 3,000 = 45 百万 × $0.014 = $0.63
• →未命中部分（客户每次问的话）：15,000 × 200 = 3 百万 × $0.44 = $1.32
• →输出：$5.94
• →合计：$7.89

$27.06 变成约 $7.89。一个字的提示词没改，一次模型没换，账单降了约 71%。（$19.17 ÷ $27.06 ≈ 70.8%，除法是我们自己算的；口径不严谨的地方也说清楚：跑法 B 假设了"全部命中"，真实命中率一定低于这个数，第三节讲的就是它为什么低。）

把这两个数放进第一节那张表：跑法 A 的第 1 行是 $21.12、第 2 行是 0；跑法 B 的第 1 行是 $1.32、第 2 行是 $0.63。同一笔业务，同样的输出，第 1 行差了 16 倍。

三、为什么明明是重复内容，却没走缓存

这一节是全文的核心。上面那个 71% 是理论上限，真实世界里大多数公司拿不到，原因不是"没开缓存"这么简单——很多是开了的，只是没命中。命中失败有四个具体机制，全部写在各家官方计费与缓存文档里。

机制一：太短的内容根本不进缓存。

其中一家的官方文档写着，最小可缓存的提示长度按型号不同，分别是 1,024 token、2,048 token、4,096 token 三档。另一家的文档写着，缓存对至少 1,024 token 的前缀生效。

含义很直白：如果你的固定部分只有八百字，它可能压根不具备被缓存的资格。 你以为在省钱，其实每一次都在按第 1 行付。

机制二：缓存有寿命，而且从请求开始那一刻计时。

一家的文档写着默认缓存寿命为 5 分钟（「By default, the cache has a 5-minute lifetime.」），并且每被用一次就免费续上（「The cache is refreshed for no additional cost each time the cached content is used.」）。它还专门写了一句容易踩的：计时「is measured from the start of the request that writes or reads the cache entry, not from the end of its response」——也就是说，生成回答花掉的时间是算在寿命里的。文档给的例子是：如果一次响应流式输出了 4 分钟，那么下一次要复用同一段缓存的请求，必须在这次响应结束后约 1 分钟内发出。

另一家的文档口径是：缓存前缀在不活动 5 到 10 分钟后一般失效，最长不超过一小时。

含义：夜里那八个小时没人问问题，第二天早上第一个请求一定是未命中的。 一天里请求越稀疏，命中率越低。这就是为什么"每天只跑三五次"的场景基本吃不到缓存红利。

机制三：命中的是前缀，而且要一字不差。

一家的文档写「Cache hits are only possible for exact prefix matches within a prompt.」，并写明请求是按提示词开头的哈希路由的，「The hash typically uses the first 256 tokens.」另一家写「Modifications to cached content can invalidate some or all of the cache.」「Changes at each level invalidate that level and all subsequent levels.」

含义，也是最常见的那个坑：任何把动态内容放在开头的写法，都会让后面全部失效。 典型的三种写法，全都会毁掉命中率——

• →在系统提示词最前面插一句"当前时间是 X 年 X 月 X 日 X 时 X 分"；
• →把客户姓名、订单号拼在固定说明书的前面；
• →每次把前几轮对话的摘要塞在最上面。

这三种写法在功能上都说得通，在账单上都是灾难。正确的顺序是：不变的在前，可变的在后。 就这一句。

机制四：改工具定义会把整段缓存作废。

同一份文档写着「Modifying tool definitions (names, descriptions, parameters) invalidates the entire cache」，以及在提示词的任何位置增删图片都会影响消息块。

含义：你的技术同事在周三下午给某个工具改了一行描述，那一刻起全公司的缓存全部重建一次。这件事不会有任何告警，只会在下个月的账单上留下一个台阶。

四、五步自查：从账单侧倒查，不从业务侧猜

前面四个机制，靠猜是猜不出来的。下面这套是从账单和接口返回值倒着查，任何一个能看后台的人都能做完，不需要改代码。

第 1 步（十分钟）。找到用量明细里的三个字段。 各家名字不同，但含义一致：一次调用返回的用量里，会分开给"未命中的输入 token 数""命中缓存读取的 token 数""缓存写入的 token 数"。后台的用量导出里通常也有这三列。找不到这三列，就直接问供应商要——一份不区分这三者的用量报表，等于没有报表。

第 2 步。算一个数：缓存读取 token ÷ 总输入 token。 这个比值就是你的真实命中率。把它写在墙上。

判断线本文给一个建议值，不是任何一方的标准：低于 20%，说明缓存基本没在工作，去查第 3 步；高于 60%，说明这一块已经没什么可省的，去看账单的第 4 行和第 7 行。

第 3 步。拿一次真实请求的完整内容出来，从头往下读，找出第一个"每次都不一样"的字符在第几行。 它上面那部分是你能缓存的，它下面全都不能。把这个位置往下挪——挪的办法是把动态内容整段搬到最后。挪完重跑一天，回到第 2 步再算一次比值。

第 4 步。看缓存写入 token 有没有异常高。 如果写入量长期接近甚至超过读取量，说明你在反复写、很少读，这种情况下开缓存是亏的，理由在第五节。

第 5 步。把第 5、7、9 三行单独拉一次。 分别是：你挂了几个工具（每次请求都在为工具定义付固定的几百 token）；有没有用按次计费的服务端功能（其中一家的文档写着联网检索是 $10 每 1,000 次，在 token 费用之外单收）；上个月有多少次失败重试。这三行加起来通常不大，但它们是"账单涨了但用量没涨"时最常见的三个答案。

五、什么时候不该做这件事

第一种：请求太稀疏的场景，开缓存反而更贵。

这一条有官方原文可依。一家的定价文档写着，缓存的计价倍率是：5 分钟缓存写入按基础输入价的 1.25 倍、1 小时缓存写入按 2 倍、缓存命中读取按 0.1 倍。同一页还写了一句结论式的话：缓存命中的成本是标准输入价的 10%，因此5 分钟档在发生一次缓存读取之后才回本，1 小时档要两次读取之后才回本。

反过来读就是：如果你每次写完缓存都没等到一次读取，你付的是 1.25 倍或者 2 倍，不是 0.1 倍。 一天调用十次八次、且分散在全天的场景，很可能属于这一类。第 4 步那个"写入接近读取"的信号，查的就是它。

第二种：这笔账本来就不到值得管的量级。

上面那个例子省下的是约 19 美元。为它开一次会、拉一个人查半天日志，人力成本远超过这个数。分界线本文给一个建议值：月度调用支出连续三个月低于人民币两千元，就先别做这件事，把这半天用在别处。 这个数是按"一个人半天的时间成本"倒推的量级，你可以按自己的时薪重算。

反过来，如果这笔支出已经在四位数以上并且还在涨，那么第四节那五步的性价比会非常高——因为它省下来的比例，和用量成正比，和你花的时间无关。

第三种：把缓存当成压缩提示词的替代品。

缓存省的是"重复送同一段内容"的钱，它不省"这段内容本来就不该这么长"的钱。一份塞了六千字、其中四千字是历史遗留的说明书，命中缓存之后还是按四千字算——只是单价低了。先删该删的，再谈缓存。顺序反了，你会为一堆没人看的文字长期付 10% 的价钱。

第四种：每次内容都不同的业务，这一整套不成立。

一次性的资料翻译、每次文档都不一样的长文摘要、一人一稿的文案生成——这类业务的前缀重复度本来就低，第 2 步那个比值天然上不去。硬去优化它，只会得到一张全是零的表。这类业务该省的钱在第 4 行和第 8 行：输出能不能更短，以及不着急的任务能不能走批量接口——同一份定价文档写着批量处理对输入和输出同时打五折。

最后回到开头那一行字。账单页只给一个总数，这件事本身不会变。但你手上有一张九行的表，和一个叫命中率的比值之后，那个总数就不再是一个只能拿去和上个月比大小的数了。

这套完整的九行拆分表、命中率自查清单与配套的提示词排序规则，在《老板必修：AI时代商业模式》第 3 课。