搞懂缓存机制，从Gemma4到Claude Code省80%Token ✍ 实践哥MinLi🕐 2026-04-07📦 11.3 KB 🟢 已读 𝕏 文章列表 文章通过本地 Gemma4 实验发现大模型对话中存在 100 倍加速的现象，深入剖析了 Transformer 的 KV 缓存原理，并逆向分析了 Claude Code 的精密缓存工程。文章解释了为何连续对话比频繁开启新 Session 更省钱，指出破坏缓存的关键行为（如切换模型、修改 System Prompt），并提供了保护缓存以节省 80% Token 的具体使用姿势。 Claude Code缓存机制Token优化KV Cache成本优化Transformer源码解析ClaudeGemma提效 # 搞懂缓存机制，从Gemma4到Claude Code省80%Token **作者**: 实践哥MinLi **日期**: 2026-04-06T13:53:54.000Z **来源**: [https://x.com/MinLiBuilds/status/2041178722230030384](https://x.com/MinLiBuilds/status/2041178722230030384) ---  > 早上打开 Claude Code，敲第一句话，2%～10% 的套餐额度没了。午休回来继续干活，又一句话，10% 的额度蒸发。你有没有想过，这 token 到底花在哪了？我带着这个疑问，在本地用 Gemma4 跑小模型做实验——发现同一段对话，有些轮次要等 30 秒，有些只要 0.2 秒。为了搞清楚为什么，我会从 Transformer 的注意力机制开始讲，再到 Claude Code 的代码实现， Anthropic 在缓存上做了一整套精密工程。理解了这套机制，你就知道怎么让同样的套餐多撑 3-5 倍。 导读 本文比较长，按兴趣挑着看，只想了解省钱的直接翻到第六章： - 一~二：本地实验 + 原理揭秘（核心故事线，所有人） - 三 ： 缓存的细节追问（想深入理解的人） - 四~五 ： 逆向 Claude Code 源码（开发者 / Claude Code 用户） - 六~七 ：使用姿势 + 省钱技巧（Claude Code 用户，没时间的直接看这里） ## 一、实验：同一段对话，为什么有时 30 秒有时 0.2 秒？ 起因很简单：我想在本地体验一下大模型的 context caching，看看到底能快多少。 先拿 Ollama 在 Mac (Apple Silicon, 16GB) 上跑 Gemma 4（8B 总参数，9.6GB 模型），写了个测试脚本做多轮对话：先喂一篇 670 token 的文章，然后连续追问 5 个问题。 每轮 API 返回两个关键指标：prompt 处理时间（消化输入）和生成时间（吐出回答）。我把 prompt 处理时间单独拎出来，结果不出所料： Turn 2 到 Turn 3，prompt 处理从 31 秒直降到 0.25 秒——100 倍加速。 而生成速度始终稳定在 13-20 tok/s，丝毫不受影响。  这说明加速只发生在"消化输入"阶段，和"吐出回答"无关。 Gemma 4 有 9.6GB，16GB 内存跑起来比较吃力。我又换了个小模型 Qwen3.5（0.8B，~1GB）做同样的测试，想看看模型大小是否会影响这个现象： 小模型全程 200ms 上下，波澜不惊。没有 Gemma 4 那种"突然快 100 倍"的戏剧性变化。 两个问题浮出水面： 那个 100x 加速到底是什么？ 为什么大模型受益巨大，小模型却无感？ ## 二、答案：KV 缓存——注意力的 QKV 中的 KV 大模型生成文本时，用的是 Transformer 注意力机制。核心公式： Attention(Q, K, V) = softmax(Q · Kᵀ / √d) · V Q、K、V 三个角色： - Q (Query) — 当前新 token 的，"我要找什么？" → 每次不同，不能缓存 - K (Key) — 历史 token 的，"我这有什么？"（索引） → 算完就固定，可以缓存 - V (Value) — 历史 token 的，"具体内容是什么？" → 算完就固定，可以缓存 KV 缓存就是把历史 token 的 Key 和 Value 存起来，新 token 只需要算自己的 Q，然后查已有的 KV。  这之所以可行，是因为当前所有主流大模型（Claude、GPT、Gemini、Llama、Gemma、Qwen）都是 Decoder-only 架构——单向注意力，每个 token 只看前面的 token。前面 token 的 KV 算完就固定了，后面怎么追加都不影响。 因果掩码（causal mask）： T₁ T₂ T₃ T₄ T₁ ✅ ❌ ❌ ❌ T₂ ✅ ✅ ❌ ❌ T₃ ✅ ✅ ✅ ❌ ← T₃ 的 KV 永远不变 T₄ ✅ ✅ ✅ ✅ ← 新增 T₄ 不影响 T₁₂₃ 如果是双向注意力（BERT），加一个新 token 会改变所有 token 的表示，缓存全废。这也是为什么 BERT 做不了生成式 AI。 回到实验数据 Turn 1-2 慢（24-31 秒）：模型在逐层计算 670+ 个 token 的 KV 张量，60 层 × 670 token × 2(K+V) = 巨量计算。 Turn 3 突然快（0.25 秒）：之前算好的 KV 全部缓存住了！只需从内存加载，不用重算。瓶颈从GPU 计算变成了内存读取。 小模型无感：Qwen3.5 只有 0.8B 参数，算 KV 本来就只要 200ms，缓存省不了多少。 模型越大，KV 计算越昂贵，缓存收益越大： 注意命中时两个模型速度几乎一样，都是从内存读取。 ## 三、缓存是无损的吗？生成结果会进缓存吗？ 无损。 Transformer 的计算是确定性的，KV 从缓存加载和现场计算的结果完全一致。 生成结果不进 prompt 缓存。 模型吐出的 output token 的 KV 在请求结束后丢弃——因为每次生成内容不同（temperature > 0），存了也没法复用。 但有个精妙之处：在下一轮对话中，上轮的生成结果被拼回 prompt，变成了"输入"的一部分，自然被缓存覆盖。 对话越长，缓存覆盖比例越高，每轮新增计算量越小。这就是为什么多轮对话是缓存的最佳场景，也是为何 Opus 现在拿 1m 当默认项。 多轮对话的上下文累计：有缓存 vs 没缓存 很多人以为每轮对话都要"重新读一遍"所有历史，token 消耗是 N(N+1)/2 的二次增长。如果没有缓存，确实如此。但有了缓存，情况完全不同： 对比：255K vs 60K，缓存省了 76%。 可视化上下文累计： 这就是为什么"一个 session 持续对话"比"频繁开新 session"省钱的根本原因。 新 session 每次从 Turn 1 开始，永远在付全价写入缓存的钱。老 session 继续对话，前面的全是缓存，只有末尾新增的一点点是全价。  不过实验中也发现，Ollama 的缓存是概率性的——同样的 prompt 跑两次，缓存命中的轮次不同，而且连续命中几次后可能突然失效（内存压力导致 KV 被淘汰）。效果惊人，但不可靠。 那 Claude API 的缓存呢？有没有更确定性的方案？我翻了 Claude Code 的源码。 ## 四、 Claude Code：一套精密的缓存工程 用Claude Code 翻了它自己的源码后发现，Anthropic 在缓存上做了大量精细工程——远不是"自动缓存"这么简单。 Prompt 不是一整块发出去的 每次 API 调用，Claude Code 发送的是一个精心拼接的多层结构： 关键函数（源码位置）： - getSystemPrompt() (prompts.ts:444) — 组装系统提示词 - splitSysPromptPrefix() (api.ts:321) — 按 DYNAMIC_BOUNDARY 切分 - buildSystemPromptBlocks() (claude.ts:3214) — 添加 cache_control 标记 - addCacheBreakpoints() (claude.ts:3064) — 在最后一条消息上标记缓存断点 缓存是前缀匹配的：只要从头开始的 token 序列一致，就能复用。这就是为什么系统提示词放最前面、保持不变如此重要。 两档 TTL - 默认 5 分钟 — 所有用户 - 扩展 1 小时 — Pro/Max 订阅用户（未超额）、Anthropic 员工 claude.ts:源码 408-413： 缓存断裂检测 Claude Code 会监控每次调用的 cache_read_input_tokens，如果比上次下降 >5% 且绝对值 >2000 tokens，判定为断裂，并分析原因：系统提示词变了？工具增减了？TTL 过期了？模型切了？ Claude Code 的缓存设计还是很清晰的，和 Ollama "缓存没了你自己猜" 形成鲜明对比。 ## 五、缓存像链条：断在哪里，后面全废 缓存是前缀匹配。理解这个就理解了一切： 切换模型也是完全失效——Opus 和 Sonnet 的权重不同，KV 张量不能互用。切一次模型，50K tokens 的上下文要全价重算。在 TTL 内切回可能还能命中旧缓存（promptCacheBreakDetection.ts 追踪了 modelChanged）。所以这点也要注意，下班前的最后半小时，不要切模型。 Sub-agent 能复用主线程的缓存吗？ Claude Code 在处理复杂任务时会启动 sub-agent（比如 Explore agent 搜代码、Plan agent 做规划）。每个 sub-agent 是一次独立的 API 调用，它能复用主线程的缓存吗？ 答案：几乎不能。 源码里，缓存状态是按 querySource + agentId 分开追踪的——每个 agent 有自己独立的缓存链。而且 sub-agent 和主线程有三个关键不同： 工具集不同 — 主线程有全套工具（Read, Write, Edit, Bash, Agent...），Explore agent 只有子集（Read, Grep, Glob, Bash）。工具 schema 不同 → 缓存前缀不同 → tools 之后的部分全部无法复用。 消息历史完全独立 — sub-agent 有自己的对话上下文，和主线程的历史没有交集。 可能用不同模型 — sub-agent 可能用 Haiku 或 Sonnet（更便宜），而主线程用 Opus。不同模型 = 不同权重 = KV 张量完全不同 = 零复用。 所以每启动一个 sub-agent，基本等于一次"迷你冷启动"。这也是为什么 Claude Code 不会滥用 sub-agent——简单的文件搜索直接用 Grep/Glob 工具就行，不必每次都启动 Explore agent。如果你在 CLAUDE.md 里写了 "多用 agent 并行处理"，要意识到每个 agent 都有独立的缓存开销。 ## 六、保护你的缓存：Claude Code 使用姿势 理解了缓存机制，就知道什么习惯省钱、什么烧钱。 核心原则：别碰前缀，只在末尾追加 保护缓存的（绿灯）： - 连续对话 — 前缀不变，增量缓存，一个 session 持续对话 - btw — 使用 btw 共享 session，可共享缓存 - Claude.md — 定期整理这个文件，但不要在工作到一半的时候整理 破坏缓存的（红灯）： - 开新 session — 冷缓存，~20K tokens 全价重算 - 改 CLAUDE.md — Block 4 起全部失效，配好就别动 - 加减 MCP 工具 — 工具 schema 变化 = 缓存断裂，session 前配好，禁用不用的MCP - 切换模型 — 完全失效，按阶段切，别频繁切 - /compact — 消息历史变了 = 断裂，对话 >100K 时再用 - 发呆超过 TTL — 缓存过期，1h 内说句话 @IceBearMiner 也写了一篇节省80%token的宝典，大家可以验证看看： 缓存差异有多大？ 假设系统提示词 20K tokens，对话 10 轮： - 一个 session 持续对话：1 次全价 + 9 次 1/10 = 1.9 份 - 每次开新 session：10 次全价 = 10 份 差了 5 倍。对 Pro/Max 订阅用户，这意味着同样的套餐能多干 3-5 倍的活。 ## 七、进阶想法：Cache Keep-Alive 续命 Pro/Max 用户的 TTL 是 1 小时。午饭吃 1.5 小时回来，缓存就过期了，开个冗长的会议，缓存就过期了。 原理：缓存 TTL 在每次读取时刷新。所以只要在过期前发一次匹配前缀的请求，缓存就能无限续命。 方案设想：用 tmux 或 iTerm2 AppleScript，每 55 分钟往 Claude Code 终端自动发一条prompt： ## 相关链接 - [实践哥MinLi](https://x.com/MinLiBuilds) - [@MinLiBuilds](https://x.com/MinLiBuilds) - [1.9K](https://x.com/MinLiBuilds/status/2041178722230030384/analytics) - [@IceBearMiner](https://x.com/@IceBearMiner) - [4.4K](https://x.com/IceBearMiner/status/2041152419032101247/analytics) - [升级至高级版](https://x.com/i/premium_sign_up) - [11:38 PM · Apr 6, 2026](https://x.com/MinLiBuilds/status/2041178722230030384) - [1,964 Views](https://x.com/MinLiBuilds/status/2041178722230030384/analytics) --- *导出时间: 2026/4/7 00:54:52*
搞 搞懂缓存机制，从Gemma4到Claude Code省80%Token 本文通过本地实验与源码分析，深入解析了大模型的 KV 缓存机制。作者从 Transformer 注意力机制讲起，解释了为何多轮对话会出现 100 倍的加速差异。通过逆向 Claude Code，揭示了 Anthropic 精密的缓存工程策略（前缀匹配、TTL 机制）。最后，给出了具体的 Claude Code 使用姿势（如保护缓存前缀、避免切换模型），帮助用户将 Token 消耗降低 80%，实现同样的套餐多干 3-5 倍的活。 技术 › Claude ✍ 实践哥MinLi🕐 2026-04-20 Claude CodeKV CacheToken优化缓存机制Transformer成本优化大模型原理AI开发源码分析效率提升
L LLM 中的 Prompt Caching 技术详解：以 Claude 为例的高效缓存策略 本文深入探讨了 LLM 中的 Prompt Caching 技术，解释了其背后的 KV Cache 机制及静态/动态上下文分离原理。文章通过 Claude Code 的案例分析，展示了如何通过保持 92% 的缓存命中率来将计算成本降低 81%，并总结了哈希敏感性和工程化落地的关键约束。 技术 › LLM ✍ Avi Chawla🕐 2026-04-20 Prompt CachingLLMAgentClaudeKV Cache成本优化系统架构Transformer
5 5步构建低Token消耗的自治Agent系统 文章介绍了构建消耗Token减少90%的自管理Agent系统的五个步骤：将上下文移出窗口、使用子代理处理脏活、利用自管理内存、避免破坏缓存以及手动管理上下文。强调了通过优化上下文管理和缓存机制来降低成本和提升效率的重要性。 技术 › Agent ✍ codila🕐 2026-07-17 AgentToken优化上下文管理缓存机制Claude Code子代理自管理内存
p pi-goal 源码解析与实测：DeepSeek 性能竟比 Gemini 好 30 倍 文章深入解析了 pi-goal 这一长程目标自动循环工具的源码机制，并设计了高难度的 Karpathy 开源项目洞察任务，对 Gemini、Claude 和 DeepSeek 三款模型进行了同台实测。结果表明，DeepSeek V4 Pro 在成本上仅是 Gemini 的 1/31，质量却更优。文章还发现过度推理会增加幻觉，以及软预算机制可作为模型行为探针，并指出了 pi-goal 在审计验证上的盲区。 技术 › Harness Engineering ✍ WquGuru🕐 2026-05-23 pi-goalDeepSeekAgentHarnessLLM测评源码解析长程任务成本优化幻觉问题Claude
深 深度解析: Claude Code 51万行源码背后的5个炸裂发现 本文基于Anthropic误暴露的51万行Claude Code源码，深度解析了其背后的产品哲学。核心发现包括：通过四维记忆系统解决AI遗忘问题；Coordinator模式揭示了AI管理逻辑与人类管理的一致性；23道安全检查与YOLO分类器构建的安全体系；极致的Token缓存策略优化；以及KAIROS等未发布的隐藏功能。文章指出，Prompt和自然语言指令体系才是AI产品的真正护城河。 技术 › Claude Code ✍ 傅盛🕐 2026-04-01 Claude Code源码解析Prompt工程AI产品架构设计傅盛AgentAI记忆安全机制Token优化
让 让 Claude 半夜自己干活，只有两条路 文章探讨了让 Claude 无人值守工作的两种安全路径：一是使用隔离的闲置机器给予完全权限；二是在现有机器上通过严格参数限制权限。作者通过分析两种方案的适用场景和风险控制，提出了“爆炸半径”公式，并给出了具体的实施建议和避坑指南。 技术 › Agent ✍ 老金🕐 2026-07-30 ClaudeAgent自动化安全DevOpsClaude Code无人值守权限管理
F From GPT2 to Kimi3, Explained 文章回顾了从 GPT-2 (2019) 到 KimiK3 (2026) 的大语言模型架构演进，重点对比了参数规模从 1.24 亿到 2.8 万亿的巨大跨越。深入解析了 GPT-2 的 Transformer 解码器结构、KV 缓存机制，并探讨了线性注意力机制在降低计算复杂度方面的原理与权衡。 技术 › LLM ✍ ali🕐 2026-07-28 LLMTransformerKimiK3GPT-2AttentionKV Cache架构演进线性注意力
实 实战踩坑：便宜模型执行、贵模型编排？没这么简单！ 文章通过三个真实案例，验证了“贵模型编排、便宜模型执行”这一省钱策略。作者发现，虽然便宜模型在文本判定等任务上能打平顶尖模型，但在高复杂度代码和开放式视觉任务上存在局限。关键在于控制模型能力代差和任务可验证性，否则返工成本将抵消节省的 token 费用。 技术 › Agent ✍ WquGuru🕐 2026-07-28 LLMAgent模型编排成本优化Claude Code多模型协作工程实践
使 使用 Claude Code 的十个关键技巧 作者基于1000小时的使用经验，分享了十个提升 Claude Code 效率的技巧。主要包括启用自动模式减少权限点击、使用计划模式防止构建错误、远程控制保持会话、利用 Superpowers 插件优化构建流程、设置 CLAUDE.md 规则、自定义技能、使用语音输入工具 Wispr Flow、优化 Token 使用、利用例行程序自动化任务，以及最重要的是构建第二大脑以积累上下文。 技术 › Claude Code ✍ Tom🕐 2026-07-23 Claude Code效率工具自动化开发技巧第二大脑Token优化远程控制语音输入
如 如何使用 Kimi K3 构建你的第一个 AI Agent 循环 本文介绍了如何利用 Kimi K3 模型的高性价比缓存机制构建 AI Agent 循环，包含原理图解、Claude Code 配置及原生 API 代码示例。文章详细阐述了目标设定、自动化检查、成本控制（低至 $0.39/轮）及常见避坑指南，帮助开发者实现自动化代码修复任务。 技术 › Agent ✍ darkzodchi🕐 2026-07-20 AI AgentKimi K3Claude Code自动化开发API 教程成本优化编程技巧DevOps大模型应用
用 用4300行代码复现Claude Code核心架构 本文介绍了一个项目，用4300行代码复现Claude Code的核心架构，包括Agent Loop、工具系统、并行执行等。提供分步教程，适合动手实践，帮助理解coding agent的工作原理。 技术 › Agent ✍ AI樱木🕐 2026-07-17 Claude CodeAgentTypeScriptPython源码解析工具系统编程实践
利 利用 Claude Code 开启单人商业（完整课程） 作者 Ronin 分享了如何利用 Claude Code 和技能文件夹独自经营一家月收入 4 万美元的代理公司。文章从市场现状切入，提供了涵盖从建站到自动化系统的三层商业模式，并详细演示了如何搭建 AI 操作系统（VS Code + Claude Code + Skills 文件夹），帮助个体开发者在无雇佣人员的情况下构建可扩展的业务。 技术 › Agent ✍ Ronin🕐 2026-07-14 ClaudeClaude Code独立开发自动化商业模式技能文件夹Web开发提示词工程副业AI创业