总觉得 Token 不耐用？聊聊模型缓存背后的省钱原理

LYRouter
LYRouter

信安世纪

2026年10月13日 17:56
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

让 AI 查资料、分析文件、修改代码，任务还没做完，费用已经往上走了一截。

你看看聊天记录：自己没说几句话，AI 的回答也不算长。这些 Token，到底花到哪里去了？

一家企业客户向 LYRouter 反馈了一个很直接的感受：“Token 不耐用。” 团队里有人用 Claude Code，有人用 Trae、Codex 等工具。调用都能正常完成，消耗却让人有些疑惑。

排查这类问题，有一个经常被忽略的因素：重复发送给模型的内容，有没有用上缓存。

理解它，也就更容易看懂 AI 的使用账单。

这篇文章，从一笔账开始，讲清模型缓存的原理、影响命中的因素，以及 LYRouter 的排查与优化实践。

01 / 模型缓存

你只说了“继续” 模型却可能又收到一大包资料

假设你让 AI 助手整理一份竞品报告。它先查网页，再读文件，列出提纲后，你回复了两个字：“继续。”

屏幕上只新增了两个字，但为了接着完成任务，应用发给模型的内容，可能包括最初的任务要求、可用工具的说明、已经找到的资料、前面的讨论，以及这句“继续”。

这些帮助模型理解任务背景的内容，叫作上下文。Token 则是模型处理和生成内容时使用的计量单位，并不简单等于字数。

许多 Agent 会在后续调用中再次提供上下文。于是，一个任务里的输入可能这样增长：

机制示意｜后续调用可能带上前面的上下文，相同前缀符合条件时可复用计算。

实际应用也会压缩或裁剪历史，并非每轮都带上全部内容。但长任务中反复携带大量上下文，是很常见的情况。

你看到的是新生成的回答，账单里还有模型为完成任务而接收的输入。 缓存的价值，就藏在这些重复输入里。

02 / 模型缓存

同样多的 Token 费用可能不同

先把一次调用的用量拆开看：普通输入、命中缓存的输入，以及模型新生成的输出。

对于提供缓存优惠计费的模型服务，命中缓存的输入通常可以按更低的价格结算。

我们用一笔假设的账来说明。假设普通输入每百万 Token 收费 2 元，缓存读取每百万 Token 收费 0.2 元。同样是 100 万输入 Token：

输入量没有变，这笔输入费用却减少了 81%。

这只是计算示意，并非任何模型的实际报价，也不代表整次调用的降幅。输出仍需计费，部分服务还有缓存写入或存储费用，最终要按实际模型和渠道的规则计算。

但它说明了一件事：缓存优化不一定让 Token 数变少，却有机会让重复输入用得更便宜。

03 / 模型缓存

缓存怎样复用 刚刚处理过的内容

本文讨论的是模型服务的提示词缓存，也常被称为上下文缓存。

处理输入时，模型会产生一部分中间计算结果。符合条件的内容被缓存后，后续请求便有机会复用这些结果，减少重复处理。模型仍会结合新增内容生成本轮回答。

这里需要认识一个词：前缀，也就是从开头连续相同的一段内容。

例如，第一轮输入是“固定要求＋项目资料＋问题 A”；第二轮保留前面的历史，再追加问题 B。只要相同前缀符合服务的缓存条件，就有机会复用。

如果固定要求发生变化，能够复用的范围就可能缩小。因此，缓存关心的不只是“两次内容像不像”，还包括相同内容的位置和实际表示方式。不同模型服务的具体缓存规则有所不同。Anthropic 的提示词缓存文档也将稳定的提示词前缀作为复用的重要条件。

缓存也不是永久记忆。首次处理、内容不足缓存门槛、缓存尚未就绪或已经被清理，都可能导致未命中。DeepSeek 官方也明确说明，缓存采用尽力而为的机制，不保证百分之百命中。DeepSeek 上下文缓存说明

所以，偶尔一次缓存为 0，并不稀奇。值得追查的是：连续任务里有大量重复内容，缓存却持续偏低。

04 / 模型缓存

缓存是否命中 要看整条调用链

从点击“发送”到收到回答，一次请求可能经过客户端、网关，再到上游模型服务。每一环都可能影响复用效果。

先看客户端，重复内容是否保持稳定。

如果每轮变化的时间戳、随机标记被放进提示词前部，或者应用反复改写历史消息、调整工具定义，可复用的前缀就可能缩短。对开发者而言，减少无意义的变化、让稳定内容尽量靠前，是值得检查的方向。

再看网关，转换有没有改变内容的写法。

网关负责连接不同客户端和模型接口，有时需要转换请求格式。这里有一个容易被忽略的细节：内容含义相同，转换后的文本却可能不同。

例如，一次历史工具调用的参数是：

{\"status\":\"in_progress\",\"taskId\":\"1\"}

下一轮又变成：

{\"taskId\":\"1\",\"status\":\"in_progress\"}

任务编号和状态都没变，只是排列顺序换了。在 LYRouter 的相关排查样本中，这类表示变化影响了后续上下文的缓存复用。

问题还可能藏得更深：有些协议转换会提前把参数对象编码成一段字符串。此时，即使统一整理了外层请求，也未必处理到字符串里面的参数。要稳定这部分内容，就需要沿着实际转换过程继续检查。

最后看上游，已有缓存是否仍然可用。

部分上游的缓存复用还与请求被分配到哪个服务实例有关。同一段内容再次到达时，未必能访问到之前的缓存。对支持相应机制的上游，稳定的会话标识可以帮助后续请求保持关联，这类适配称为“会话亲和”。

它需要按具体模型和通道验证，并非给所有请求加上同一个参数就能解决。前缀本身一直在变时，会话关联再稳定，也补不回内容差异。

排查示意｜从客户端、网关到上游服务，逐段检查影响缓存复用的因素。

05 / 模型缓存

LYRouter 如何发现问题 并落实优化

回到那句“Token 不耐用”。

排查首先要把感受变成记录。LYRouter 将不同客户端的调用汇总到统一视图，团队可以从整体用量出发，按客户端、模型、API Key 等维度缩小范围，再查看具体请求。

这次排查中，一批调用虽然返回成功，缓存输入却连续为 0。

图 1｜日志原图：展示的 18 条调用，普通输入约为 60 万至 62 万 Token，缓存输入均为 0；实际模型列展示的是 DeepSeek 模型。

再看其中一条普通输入为 605,017 Token 的调用，其详情显示缓存输入为 0，输出只有 401 Token。这就解释了为什么只看回答长度，很难判断实际消耗。

图 2｜单条调用的 Token 构成。Claude Code 是客户端名称，这条记录请求的是 DeepSeek 模型。

接下来，要确认请求实际用了哪个模型、经过哪条通道，再结合连续请求的变化分析原因。LYRouter 的调用详情与路由追踪，为这一步提供线索。

图 3｜从请求进入、路由选择，到命中上游和最终结果，可以继续追查实际服务路径。

针对前文几类问题，LYRouter 的处理也落在不同位置：客户端的内容变化，需要协助用户检查请求组织方式；编码和协议转换中的不稳定表示，需要在适用链路上进行规范化，并处理工具参数内部的编码；特定上游的会话复用问题，则需要按其能力配置、验证会话亲和。

这些是相关缓存排查形成的处理方向，并不意味着每位用户都需要同时调整三处。

优化还必须守住一个前提：请求含义不能变。 工具参数里可能有长编号、精确数值；如果为了整理格式，把编号改错了，即使命中率上升，任务也可能出问题。因此，需要保留数组顺序、保护参数精度，对无法可靠处理的内容保留原有形式。

这也是平台技术工作的具体价值：从看见低命中，到分析请求变化，再把调整落实到对应链路，并检查实际结果。

06 / 模型缓存

效果如何 要回到真实用量里看

收到反馈后，LYRouter 在当天完成了排查与处理，并通过后续用量持续观察变化。把优化前后的两组业务样本放在一起看，缓存表现的改善更加直观。

两组统计中都出现的客户端，缓存表现发生了明显变化：Claude Code 的看板缓存命中率由 54.05% 提升至 91.19%，Trae 由 48.60% 提升至 85.68%。

图 4｜优化前样本的客户端统计。

图 5｜优化后样本的客户端统计。

优化后的记录还覆盖了更多工具：Hermes 的缓存命中率为 97.33%，WorkBuddy 为 96.33%，deepseek-harness 为 96.83%。

从团队整体看，缓存命中率由 52.43% 提升至 93.28%。在 Token 总量增加的同时，记录费用有所下降，每百万 Token 综合均价由约 1.98 元降至 0.29 元。

图 6｜优化前样本：Token 总量为 1,672.02M，缓存命中率为 52.43%。

图 7｜优化后样本：Token 总量为 2,470.32M，缓存命中率为 93.28%。

前后两组业务样本的汇总如下：

业务对比｜两组样本统一使用“优化前／优化后”标识，比较条件见下方数据说明。

数据说明：综合均价由各组记录费用除以 Token 总量计算，包含普通输入、缓存读取和输出。

这些记录的意义还在于，团队可以继续观察：哪些工具的缓存利用仍偏低，模型或服务通道变化后，费用表现有没有跟着变化。

对普通用户来说，不需要先学会修改底层参数。觉得消耗偏快时，可以从一段连续任务查起：看看普通输入、缓存输入和输出各占多少；如果后续多轮持续低命中，再带着调用记录进一步排查。

下次让 AI“继续”时，你就知道，它背后可能又收到了前面的整包资料。

看懂 AI 的账单，除了知道用了多少 Token，还要知道这些 Token 是怎样被处理和计费的。 LYRouter 帮助团队把这件事看清楚，将问题追到具体调用，并持续改善实际使用中的缓存表现。

从一段连续任务开始

打开 LYRouter 的「用量分析」与「日志分析」，从一段连续任务开始，看看你的缓存有没有用起来。

LYRouter · 让企业放心用 AI