搞懂緩存機制，從 Gemma4 到 Claude Code 省 80% Token

原始來源與檔名：2026-05-26T095135+0800-搞懂缓存机制，从Gemma4到Claude Code省80%Token.md

NAPKIN | 餐巾纸

餐巾纸公式

Caching Efficiency = Prefix Match Length × (1 / Recompute Cost) × (TTL > Idle Time)

大語言模型對話的成本並非線性增長，只要保持前綴提示詞與歷史記錄不變，依賴 KV Cache 的機制就能將後續多輪對話的計算成本降至原本的十分之一。

一句话

理解 Transformer 中 KV Cache 的前綴匹配機制，就能透過避免頻繁開新對話、不隨意修改上下文設定，在 Claude Code 等工具中省下高達 80% 的 Token 花費。

餐巾纸草图

       [ System Prompt (Static) ] --> [ CLAUDE.md ] --> [ Tool Schema ]
                 |                         |                 |
                 v                         v                 v
          Global Cache (Shared)      Org Cache         Session Frozen
                 |_________________________|_________________|
                                           |
    +-----> [ Message 1 ] --> [ Message 2 ] --> [ Message 3 (New) ]
    |         (Cached)          (Cached)          (Recomputed Q)
    |
(Prefix Matching: 只要前綴不動，後方只需計算增量 KV 張量)

ROUND 1: SKELETON | 骨架掃描

“這本書在說什麼”

• 核心問題: 為什麼使用 Claude Code 這種依賴大量上下文的 AI 開發工具時，Token 消耗速度極快，且有時回應慢（30秒）有時快（0.2秒）？
• 核心答案: 這是因為大模型的 Attention 機制使用 KV Cache。只要對話前綴一致，歷史 Token 不需重新計算。掌握這套前綴匹配邏輯，就能避免破壞快取，大幅省錢。
• 論證結構: 演繹型與案例型結合（從本地實驗現象 -> Transformer 原理 -> Claude 原始碼解析 -> 實用操作指南）。

章節骨架

1. 本地實驗: 發現 Gemma4 處理相同對話，首輪耗時長，次輪耗時極短（100倍加速）。
2. 原理解密: 解釋 Transformer 中 Query(Q) 需重算，但 Key(K) 和 Value(V) 可以被快取。
3. 快取覆蓋率: 說明在多輪對話中，生成結果被拼回 Prompt 成為輸入，形成近似線性而非二次方增長的成本。
4. 原始碼解析: 拆解 Claude Code 如何構建 Prompt 區塊（系統提示、動態內容、工具、對話），並分析斷裂條件。
5. Sub-agent 盲區: 指出啟動 Sub-agent 等於冷啟動，無法複用主線程快取。
6. 省錢技巧: 總結保護快取（持續對話）與破壞快取（開新 session、切換模型、改檔）的紅綠燈行為。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

論證鏈

本地測試發現首輪極慢/次輪極快 --> 追溯 Decoder-only 架構的 KV Cache 特性 --> 分析 API 收費與快取命中的關聯 --> 逆向 Claude Code 原始碼證實其多層快取設計與 TTL 機制 --> 推導出使用者層面的最佳實踐（不要破壞前綴）

關鍵證據

1. 實驗數據: 本地執行 Gemma4 (8B) 首輪耗時 31 秒，次輪 0.25 秒；而 Qwen3.5 (0.8B) 耗時差異不大，證明參數越大的模型 KV 計算越昂貴，快取收益越巨大。
2. API 計費邏輯: 沒有快取的 10 輪對話（每輪增 1K）消耗約 255K Tokens；有前綴快取（價格 1/10）則僅需約 60K 等價 Tokens，節省高達 76%。
3. Claude Code 原始碼: 從 api.ts 和 claude.ts 發現其構建的結構為 [System Block 1-3(Global)] -> DYNAMIC_BOUNDARY -> [Block 4(Org)] -> [Tools] -> [Messages]。只要前面變動，後面全部失效。

隱形假設與邊界

• 隱形假設:
  • 模型供應商（如 Anthropic）確實按照前綴匹配原則給予使用者快取計費優惠（目前 Claude 已實裝 Prompt Caching）。
  • 系統內存/顯存足夠容納龐大的 KV Tensor。
• 邊界條件:
  • 雙向注意力模型 (如 BERT)：無法使用此快取策略，因為新 Token 加入會改變舊 Token 的表示。
  • TTL 過期: Claude 的快取存活時間（Pro 用戶為 1 小時），若超時未互動則必須重新計算。

ROUND 3: SOUL | 靈魂提取

“還能怎麼用”

• 作者盲點: 文章主要集中在文字對話的 KV Cache，未探討多模態（如圖片輸入）在 Cache 上的佔用與命中率差異。
• 知識連接: 快取一致性 (Cache Coherence) 與前綴樹 (Trie) 結構。LLM 的快取本質上是一棵以 Token 為節點的前綴樹，任何分岔都會導致重新計算分支。
• 行動觸發: 使用 AI 開發工具時，盡量在一個長 Session 中解決問題；不要在對話中途修改 CLAUDE.md 或切換模型；甚至可以寫個腳本每 55 分鐘發送一個 “Keep-alive” 請求來續命 Cache。

跨域映射

• 在 計算機架構，這叫 前綴匹配快取 (Prefix-Matching Cache) 與 局部性原理 (Locality)
• 在 資料庫，這叫 Materialized View (物化視圖) 的增量更新

STRUCTURE MAP | 全書結構圖

[ Phenomenon ] 本地模型次輪對話 100x 加速
      |
[ Mechanism ]  Transformer KV Cache (Decoder-only 單向注意力)
      |        Q 每次重算，K/V 存入顯存
      |
[ Structure ]  Claude Code 的多層次 Prompt 構建
      +------- Block 1-3 (Global 靜態)
      +------- Block 4 (CLAUDE.md 動態)
      +------- Tools Schema
      +------- Messages (歷史對話)
      |
[ Practical ]  最佳實踐
      +------- 綠燈：保持 Session、固定前綴
      +------- 紅燈：頻繁開新對話、中途改配置、切換模型
      +------- Hack：定時 Keep-alive 續命

搞懂緩存機制，從 Gemma4 到 Claude Code 省 80% Token (Architectural Deep Dive)

前言/背景

隨著 AI 開發工具（如 Claude Code、Cursor）的普及，開發者發現其 API Token 消耗量驚人。本文透過本地執行開源大模型（Gemma4）的效能測試，結合 Transformer 底層的注意力機制，並逆向分析 Claude Code 的 TypeScript 原始碼，深入剖析了大型語言模型 (LLM) 中的 KV Cache 機制。理解這套機制，能幫助開發者在日常使用中避免無效的快取失效，最高節省 80% 的 API 成本。

章節詳細總結

一、 實驗：KV Cache 帶來的百倍加速

作者在本地 (Apple Silicon, 16GB) 執行 Gemma4 (8B) 進行多輪對話測試。

• 現象：第一、二輪的 Prompt 處理時間高達 24-31 秒，但到了第三輪，處理時間驟降至 250 毫秒（100 倍加速）。而生成時間則穩定在 13-20 tok/s。小參數模型 (Qwen3.5 0.8B) 則沒有這種戲劇性的變化。
• 結論：大模型的運算瓶頸在於「消化輸入」，而非「吐出回答」。加速完全發生在理解 Prompt 的階段。

二、 核心原理：注意力機制的 QKV 分離

大模型生成文本依賴 Transformer 注意力機制：Attention(Q, K, V) = softmax(Q · Kᵀ / √d) · V。

• Query (Q)：代表當前新 Token「我要找什麼？」。這部分每次都不同，必須即時計算。
• Key (K) & Value (V)：代表歷史 Token 的屬性與內容。由於主流模型（Claude, GPT 等）採用 Decoder-only 架構（單向因果掩碼 Causal Mask），每個 Token 只關注前面的內容。
• 架構優勢：前面的 Token 算完後，其 KV 張量就固定不變了。系統可以將其存入記憶體（顯存），新 Token 只需要計算自己的 Q，然後查詢已有的 KV 即可，將原本密集的 GPU 計算瓶頸轉化為記憶體讀取瓶頸。

三、 快取的累加與成本模型

• 無損性：KV Cache 載入的結果與重新計算完全一致，是無損的。
• 生成結果的快取轉換：雖然模型輸出的 Token 由於不確定性（Temperature）不直接進 Prompt Cache，但在下一輪對話時，上輪的回答會被拼接到 Prompt 中作為輸入，從而自然地被快取覆蓋。
• 線性增長 vs 二次方增長： 若無快取，上下文不斷增加會導致成本呈現 $O(N^2)$ 的二次增長。 啟用快取後，因為歷史前綴（Prefix）的計費通常是原價的 1/10，只有末尾新增的對話需要全價計算，整體成本曲線變為近似線性。一個持續的 Session 消耗（60K 等價 Tokens）對比頻繁開新 Session（255K Tokens），能省下超過 75% 的成本。

四、 逆向解析：Claude Code 的精密快取工程

作者查閱了 Claude Code 的原始碼，發現 Anthropic 並非簡單地「快取全部」，而是將 Prompt 分層拼接，透過前綴匹配（Prefix-matching）來最大化命中率：

┌────────────────────────────────────────────────┐
│ system（系統提示詞，~20K tokens）                 │
│   Block 3: 靜態指令（全球用戶共享 Global Cache）  │
│   ──── DYNAMIC_BOUNDARY ────                    │
│   Block 4: 動態內容（CLAUDE.md 等 Org 級快取）    │
├─────────────────────────────────────────────────┤
│ tools（工具 schema，session 內凍結）               │
├─────────────────────────────────────────────────┤
│ messages（對話歷史，標記 cache_control）           │
└─────────────────────────────────────────────────┘

• 斷裂檢測 (Cache Break Detection)：系統會監控 cache_read_input_tokens，若下降幅度大於 5% 且絕對值 > 2000，便會觸發斷裂分析。
• TTL 策略：預設為 5 分鐘，Pro/Max 訂閱用戶及內部員工為 1 小時。

五、 快取失效的連鎖反應與 Sub-agent 盲區

快取是嚴格的前綴匹配，就像一條鏈條，只要中間有一環改變，後面的快取全部作廢。

• 修改前綴：若修改了 CLAUDE.md（Block 4），其後的 Tools 和 Messages 快取全廢；若切換模型（如從 Opus 切換至 Sonnet），由於權重不同，KV 張量不通用，導致 100% 重新計算。
• Sub-agent 架構缺陷：Claude Code 在調用 Sub-agent（如 Explore 搜尋代碼）時，由於工具集縮減、對話歷史獨立，甚至可能使用了更輕量的模型（Haiku），這意味著 Sub-agent 無法複用主線程的快取。每次啟動 Sub-agent 等同於一次高成本的「冷啟動」。

總結與結論

• 單一長 Session 策略：在開發過程中，盡量在同一個 Session 中持續對話，避免頻繁開新對話 (New Chat)，這樣能將 90% 的 Tokens 從全價轉化為 1/10 價格的快取讀取。
• 靜態化基礎配置：在開始工作前一次性配置好 CLAUDE.md 和所需的 MCP 工具。中途修改工具 Schema 或系統提示詞會從中斷點截斷快取鏈。
• 避免無謂的模型切換：在解決複雜問題的中途，不要頻繁在 Opus 與 Sonnet 之間切換。切換一次意味著數萬 Token 的上下文需要以全價重新計算 KV 張量。
• 進階保活策略 (Keep-Alive)：針對 Pro 用戶 1 小時的 TTL，架構師或深度使用者可以編寫簡單的 Cron Job 或腳本，每 55 分鐘發送一個無狀態的確認請求，來強制刷新 TTL 避免快取過期重置。